diff --git a/ianswett-path-validation/draft-ietf-quic-http.html b/ianswett-path-validation/draft-ietf-quic-http.html
index b5ebc3be27..969cec1f9c 100644
--- a/ianswett-path-validation/draft-ietf-quic-http.html
+++ b/ianswett-path-validation/draft-ietf-quic-http.html
@@ -903,392 +903,392 @@ <h2 id="name-copyright-notice">
         <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">
+<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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.1.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.1.2.2">
+              <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="ulEmpty toc compact" id="section-toc.1-1.2">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.2.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.2.2.2">
+              <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="ulEmpty toc compact" id="section-toc.1-1.3">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.3.2.2">
+              <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.2.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.3.2.2.2.2">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.3.2.3">
+              <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="ulEmpty toc compact" id="section-toc.1-1.3.2.4">
+              <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="ulEmpty toc compact" id="section-toc.1-1.4">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1">
+<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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.2">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.3">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.4.2.2">
+              <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="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
+              <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="ulEmpty toc compact" id="section-toc.1-1.4.2.4">
+              <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="ulEmpty toc compact" id="section-toc.1-1.5">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.5.2.2">
+              <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="ulEmpty toc compact" id="section-toc.1-1.5.2.3">
+              <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="ulEmpty toc compact" id="section-toc.1-1.5.2.4">
+              <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="ulEmpty toc compact" id="section-toc.1-1.6">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.6.2.2">
+              <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.2.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.6.2.2.2.2">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.6.2.2.2.3">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.7">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.7.2.2">
+              <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.2">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.3">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.4">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.5">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.6">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.7">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.7.2.2.2.8">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.8">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.9">
+          <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="ulEmpty toc compact" id="section-toc.1-1.10">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.10.2.2">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.3">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.4">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.5">
+              <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.5.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.10.2.5.2.2">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.10.2.6">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.7">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.8">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.9">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.10">
+              <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="ulEmpty toc compact" id="section-toc.1-1.10.2.11">
+              <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="ulEmpty toc compact" id="section-toc.1-1.11">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.11.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.11.2.2">
+              <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.11.2.2.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.11.2.2.2.2">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.11.2.2.2.3">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.11.2.2.2.4">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.12">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.12.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.12.2.2">
+              <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="ulEmpty toc compact" id="section-toc.1-1.13">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.13.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.13.2.2">
+              <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.2">
+                  <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="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.3">
+                  <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-flow-control-differences" class="xref">Flow Control Differences</a><a href="#section-toc.1-1.13.2.2.2.3.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.4">
+                  <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-guidance-for-new-frame-type" class="xref">Guidance for New Frame Type Definitions</a><a href="#section-toc.1-1.13.2.2.2.4.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.5">
+                  <li class="compact toc ulEmpty" 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-a.2.5" class="xref">A.2.5</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.5.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.3">
+              <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="ulEmpty toc compact" id="section-toc.1-1.13.2.4">
+              <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.13.2.4.2.1">
+<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="ulEmpty toc compact" id="section-toc.1-1.14">
+          <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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.14.2.1">
+<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-29</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.2">
+              <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-28</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.3">
+              <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-27" class="xref">Since draft-ietf-quic-http-27</a><a href="#section-toc.1-1.14.2.3.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.4">
+              <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-26" class="xref">Since draft-ietf-quic-http-26</a><a href="#section-toc.1-1.14.2.4.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.5">
+              <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-25" class="xref">Since draft-ietf-quic-http-25</a><a href="#section-toc.1-1.14.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.6">
+              <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-24" class="xref">Since draft-ietf-quic-http-24</a><a href="#section-toc.1-1.14.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.7">
+              <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-23" class="xref">Since draft-ietf-quic-http-23</a><a href="#section-toc.1-1.14.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.8">
+              <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-22" class="xref">Since draft-ietf-quic-http-22</a><a href="#section-toc.1-1.14.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.9">
+              <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-21" class="xref">Since draft-ietf-quic-http-21</a><a href="#section-toc.1-1.14.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.10">
+              <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-20" class="xref">Since draft-ietf-quic-http-20</a><a href="#section-toc.1-1.14.2.10.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.11">
+              <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-1" class="xref">Since draft-ietf-quic-http-19</a><a href="#section-toc.1-1.14.2.11.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.12">
+              <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-18" class="xref">Since draft-ietf-quic-http-18</a><a href="#section-toc.1-1.14.2.12.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.13">
+              <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-17" class="xref">Since draft-ietf-quic-http-17</a><a href="#section-toc.1-1.14.2.13.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.14">
+              <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-16" class="xref">Since draft-ietf-quic-http-16</a><a href="#section-toc.1-1.14.2.14.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.15">
+              <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-15" class="xref">Since draft-ietf-quic-http-15</a><a href="#section-toc.1-1.14.2.15.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.16">
+              <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-14" class="xref">Since draft-ietf-quic-http-14</a><a href="#section-toc.1-1.14.2.16.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.17">
+              <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-13" class="xref">Since draft-ietf-quic-http-13</a><a href="#section-toc.1-1.14.2.17.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.18">
+              <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-12" class="xref">Since draft-ietf-quic-http-12</a><a href="#section-toc.1-1.14.2.18.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.19">
+              <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-11" class="xref">Since draft-ietf-quic-http-11</a><a href="#section-toc.1-1.14.2.19.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.20">
+              <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-10" class="xref">Since draft-ietf-quic-http-10</a><a href="#section-toc.1-1.14.2.20.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.21">
+              <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-0" class="xref">Since draft-ietf-quic-http-09</a><a href="#section-toc.1-1.14.2.21.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.22">
+              <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-08" class="xref">Since draft-ietf-quic-http-08</a><a href="#section-toc.1-1.14.2.22.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.23">
+              <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-07" class="xref">Since draft-ietf-quic-http-07</a><a href="#section-toc.1-1.14.2.23.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.24">
+              <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-06" class="xref">Since draft-ietf-quic-http-06</a><a href="#section-toc.1-1.14.2.24.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.25">
+              <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-05" class="xref">Since draft-ietf-quic-http-05</a><a href="#section-toc.1-1.14.2.25.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.26">
+              <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-04" class="xref">Since draft-ietf-quic-http-04</a><a href="#section-toc.1-1.14.2.26.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.27">
+              <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-03" class="xref">Since draft-ietf-quic-http-03</a><a href="#section-toc.1-1.14.2.27.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.28">
+              <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-02" class="xref">Since draft-ietf-quic-http-02</a><a href="#section-toc.1-1.14.2.28.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.29">
+              <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-ietf-quic-http-01" class="xref">Since draft-ietf-quic-http-01</a><a href="#section-toc.1-1.14.2.29.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.30">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.14.2.30">
                 <p id="section-toc.1-1.14.2.30.1"><a href="#section-b.30" class="xref">B.30</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.30.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.31">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.14.2.31">
                 <p id="section-toc.1-1.14.2.31.1"><a href="#section-b.31" class="xref">B.31</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.31.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.15">
+          <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="ulEmpty toc compact" id="section-toc.1-1.16">
+          <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>
@@ -1530,8 +1530,8 @@ <h2 id="name-connection-setup-and-manage">
         <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="ulEmpty normal">
-<li class="ulEmpty normal" id="section-3.1-1.1">
+<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>
@@ -4509,8 +4509,8 @@ <h3 id="name-mapping-between-http-2-and-h">
       <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">
+<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>
diff --git a/ianswett-path-validation/draft-ietf-quic-invariants.html b/ianswett-path-validation/draft-ietf-quic-invariants.html
index efae5dbc48..d26dc7846d 100644
--- a/ianswett-path-validation/draft-ietf-quic-invariants.html
+++ b/ianswett-path-validation/draft-ietf-quic-invariants.html
@@ -898,20 +898,20 @@ <h2 id="name-copyright-notice">
         <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 ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.1">
+<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="compact ulEmpty toc" id="section-toc.1-1.2">
+          <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-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 ulEmpty toc" id="section-toc.1-1.3">
+          <li class="ulEmpty compact toc" 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="compact ulEmpty toc" id="section-toc.1-1.4">
+          <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-notational-conventions" class="xref">Notational Conventions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.5">
+          <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-quic-packets" class="xref">QUIC Packets</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">
@@ -928,16 +928,16 @@ <h2 id="name-copyright-notice">
 </li>
             </ul>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.6">
+          <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>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.7">
+          <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-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="compact ulEmpty toc" id="section-toc.1-1.8">
+          <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>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.9">
+          <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">
@@ -948,10 +948,10 @@ <h2 id="name-copyright-notice">
 </li>
             </ul>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.10">
+          <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-incorrect-assumptions" class="xref">Incorrect Assumptions</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.11">
+          <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"></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>
diff --git a/ianswett-path-validation/draft-ietf-quic-qpack.html b/ianswett-path-validation/draft-ietf-quic-qpack.html
index c143366b78..25361f40b6 100644
--- a/ianswett-path-validation/draft-ietf-quic-qpack.html
+++ b/ianswett-path-validation/draft-ietf-quic-qpack.html
@@ -909,281 +909,281 @@ <h2 id="name-copyright-notice">
         <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 ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.1">
+<nav class="toc"><ul class="toc compact ulEmpty">
+<li class="toc compact 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 ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.1.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.1.2.2">
+              <li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.2">
+          <li class="toc compact 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-compression-process-overvie" class="xref">Compression Process Overview</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">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-encoder" class="xref">Encoder</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.1.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.2.2.1.2.2">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.2.2.1.2.3">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.2.2.1.2.4">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.2.2.2">
+              <li class="toc compact 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-decoder" class="xref">Decoder</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.2.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.2.2.2.2.2">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.2.2.2.2.3">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.3">
+          <li class="toc compact 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-reference-tables" class="xref">Reference Tables</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">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-static-table" class="xref">Static Table</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">
+              <li class="toc compact 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-dynamic-table" class="xref">Dynamic Table</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.2.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.3.2.2.2.2">
+                  <li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.3.2.2.2.3">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.3.2.2.2.4">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.3.2.2.2.5">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.3.2.2.2.6">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4">
+          <li class="toc compact 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-wire-format" class="xref">Wire Format</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">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-primitives" class="xref">Primitives</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.1.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.4.2.1.2.2">
+                  <li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.4.2.2">
+              <li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.4.2.3">
+              <li class="toc compact 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-encoder-instructions" class="xref">Encoder Instructions</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.3.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.3.2.2">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.3.2.3">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.3.2.4">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.4">
+              <li class="toc compact 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-decoder-instructions" class="xref">Decoder Instructions</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.4.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.4.2.2">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.4.2.3">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.5">
+              <li class="toc compact ulEmpty" 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="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.5.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.5.2.2">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.5.2.3">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.5.2.4">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.5.2.5">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.4.2.5.2.6">
+                  <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.5">
+          <li class="toc compact 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-configuration" class="xref">Configuration</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.6">
+          <li class="toc compact 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-error-handling" class="xref">Error Handling</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.7">
+          <li class="toc compact 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 ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.7.2.2">
+              <li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.7.2.3">
+              <li class="toc compact 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-mitigation" class="xref">Mitigation</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">
+              <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.7.2.5">
+              <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.7.2.6">
+              <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.7.2.7">
+              <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.8">
+          <li class="toc compact 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>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-settings-registration" class="xref">Settings Registration</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.8.2.2">
+              <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.8.2.3">
+              <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.9">
+          <li class="toc compact 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 ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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 ulEmpty toc" id="section-toc.1-1.9.2.2">
+              <li class="toc compact 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 ulEmpty toc" id="section-toc.1-1.10">
+          <li class="toc compact 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-static-table-2" class="xref">Static Table</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.11">
+          <li class="toc compact 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-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="compact ulEmpty toc" id="section-toc.1-1.12">
+          <li class="toc compact 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 ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.1">
+<ul class="toc compact ulEmpty">
+<li class="toc compact 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-qpack" class="xref">Since draft-ietf-quic-qpack-16</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">
+              <li class="toc compact 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-qpack-" class="xref">Since draft-ietf-quic-qpack-15</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">
+              <li class="toc compact 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-qpack-1" class="xref">Since draft-ietf-quic-qpack-14</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">
+              <li class="toc compact 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-qpack-13" class="xref">Since draft-ietf-quic-qpack-13</a><a href="#section-toc.1-1.12.2.4.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.5">
+              <li class="toc compact 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-qpack-12" class="xref">Since draft-ietf-quic-qpack-12</a><a href="#section-toc.1-1.12.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.6">
+              <li class="toc compact 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-qpack-11" class="xref">Since draft-ietf-quic-qpack-11</a><a href="#section-toc.1-1.12.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.7">
+              <li class="toc compact 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-qpack-10" class="xref">Since draft-ietf-quic-qpack-10</a><a href="#section-toc.1-1.12.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.8">
+              <li class="toc compact 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-qpack-0" class="xref">Since draft-ietf-quic-qpack-09</a><a href="#section-toc.1-1.12.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.9">
+              <li class="toc compact 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-qpack-08" class="xref">Since draft-ietf-quic-qpack-08</a><a href="#section-toc.1-1.12.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.10">
+              <li class="toc compact 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-qpack-06" class="xref">Since draft-ietf-quic-qpack-06</a><a href="#section-toc.1-1.12.2.10.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.11">
+              <li class="toc compact 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-qpack-05" class="xref">Since draft-ietf-quic-qpack-05</a><a href="#section-toc.1-1.12.2.11.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.12">
+              <li class="toc compact 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-qpack-04" class="xref">Since draft-ietf-quic-qpack-04</a><a href="#section-toc.1-1.12.2.12.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.13">
+              <li class="toc compact 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-qpack-03" class="xref">Since draft-ietf-quic-qpack-03</a><a href="#section-toc.1-1.12.2.13.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.14">
+              <li class="toc compact 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-qpack-02" class="xref">Since draft-ietf-quic-qpack-02</a><a href="#section-toc.1-1.12.2.14.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.15">
+              <li class="toc compact 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-qpack-01" class="xref">Since draft-ietf-quic-qpack-01</a><a href="#section-toc.1-1.12.2.15.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.16">
+              <li class="toc compact 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-qpack-00" class="xref">Since draft-ietf-quic-qpack-00</a><a href="#section-toc.1-1.12.2.16.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.17">
+              <li class="toc compact 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-qcram" class="xref">Since draft-ietf-quic-qcram-00</a><a href="#section-toc.1-1.12.2.17.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.13">
+          <li class="toc compact ulEmpty" 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="compact ulEmpty toc" id="section-toc.1-1.14">
+          <li class="toc compact 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-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
diff --git a/ianswett-path-validation/draft-ietf-quic-recovery.html b/ianswett-path-validation/draft-ietf-quic-recovery.html
index 44ea4f6097..8488cb0aa3 100644
--- a/ianswett-path-validation/draft-ietf-quic-recovery.html
+++ b/ianswett-path-validation/draft-ietf-quic-recovery.html
@@ -903,351 +903,351 @@ <h2 id="name-copyright-notice">
         <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">
+<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="ulEmpty compact toc" id="section-toc.1-1.2">
+          <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="ulEmpty compact toc" id="section-toc.1-1.3">
+          <li class="compact toc ulEmpty" 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-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>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.4">
+          <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-relevant-differences-betwee" class="xref">Relevant Differences Between QUIC and TCP</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">
+<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-separate-packet-number-spac" class="xref">Separate Packet Number Spaces</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2">
+              <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-monotonically-increasing-pa" class="xref">Monotonically Increasing Packet Numbers</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">
+              <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-clearer-loss-epoch" class="xref">Clearer Loss Epoch</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">
+              <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-no-reneging" class="xref">No Reneging</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">
+              <li class="compact toc ulEmpty" 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-more-ack-ranges" class="xref">More ACK Ranges</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">
+              <li class="compact toc ulEmpty" 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-explicit-correction-for-del" class="xref">Explicit Correction For Delayed Acknowledgements</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">
+              <li class="compact toc ulEmpty" 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-probe-timeout-replaces-rto-" class="xref">Probe Timeout Replaces RTO and TLP</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">
+              <li class="compact toc ulEmpty" 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-the-minimum-congestion-wind" class="xref">The Minimum Congestion Window is Two Packets</a><a href="#section-toc.1-1.4.2.8.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.5">
+          <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-estimating-the-round-trip-t" class="xref">Estimating the Round-Trip Time</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">
+<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-generating-rtt-samples" class="xref">Generating RTT samples</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">
+              <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-estimating-min_rtt" class="xref">Estimating min_rtt</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">
+              <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-estimating-smoothed_rtt-and" class="xref">Estimating smoothed_rtt and rttvar</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.6">
+          <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-loss-detection" class="xref">Loss Detection</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">
+<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-acknowledgement-based-detec" class="xref">Acknowledgement-Based Detection</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.1.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1.2.1">
                     <p id="section-toc.1-1.6.2.1.2.1.1"><a href="#section-6.1.1" class="xref">6.1.1</a>.  <a href="#name-packet-threshold" class="xref">Packet Threshold</a><a href="#section-toc.1-1.6.2.1.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.6.2.1.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1.2.2">
                     <p id="section-toc.1-1.6.2.1.2.2.1"><a href="#section-6.1.2" class="xref">6.1.2</a>.  <a href="#name-time-threshold" class="xref">Time Threshold</a><a href="#section-toc.1-1.6.2.1.2.2.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.6.2.2">
+              <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-probe-timeout" class="xref">Probe Timeout</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.2.2.1">
+<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-computing-pto" class="xref">Computing PTO</a><a href="#section-toc.1-1.6.2.2.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.6.2.2.2.2">
+                  <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-handshakes-and-new-paths" class="xref">Handshakes and New Paths</a><a href="#section-toc.1-1.6.2.2.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.6.2.2.2.3">
+                  <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-speeding-up-handshake-compl" class="xref">Speeding Up Handshake Completion</a><a href="#section-toc.1-1.6.2.2.2.3.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.6.2.2.2.4">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2.2.4">
                     <p id="section-toc.1-1.6.2.2.2.4.1"><a href="#section-6.2.4" class="xref">6.2.4</a>.  <a href="#name-sending-probe-packets" class="xref">Sending Probe Packets</a><a href="#section-toc.1-1.6.2.2.2.4.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.6.2.3">
+              <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-handling-retry-packets" class="xref">Handling Retry Packets</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">
+              <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-discarding-keys-and-packet-" class="xref">Discarding Keys and Packet State</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.7">
+          <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-congestion-control" class="xref">Congestion Control</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">
+<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-explicit-congestion-notific" class="xref">Explicit Congestion Notification</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">
+              <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-initial-and-minimum-congest" class="xref">Initial and Minimum Congestion Window</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">
+              <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-congestion-control-states" class="xref">Congestion Control States</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3.2.1">
                     <p id="section-toc.1-1.7.2.3.2.1.1"><a href="#section-7.3.1" class="xref">7.3.1</a>.  <a href="#name-slow-start" class="xref">Slow Start</a><a href="#section-toc.1-1.7.2.3.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3.2.2">
                     <p id="section-toc.1-1.7.2.3.2.2.1"><a href="#section-7.3.2" class="xref">7.3.2</a>.  <a href="#name-recovery" class="xref">Recovery</a><a href="#section-toc.1-1.7.2.3.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3.2.3">
                     <p id="section-toc.1-1.7.2.3.2.3.1"><a href="#section-7.3.3" class="xref">7.3.3</a>.  <a href="#name-congestion-avoidance" class="xref">Congestion Avoidance</a><a href="#section-toc.1-1.7.2.3.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.4">
+              <li class="compact toc ulEmpty" 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-ignoring-loss-of-undecrypta" class="xref">Ignoring Loss of Undecryptable Packets</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">
+              <li class="compact toc ulEmpty" 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-probe-timeout-2" class="xref">Probe Timeout</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">
+              <li class="compact toc ulEmpty" 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-persistent-congestion" class="xref">Persistent Congestion</a><a href="#section-toc.1-1.7.2.6.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.6.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.6.2.1">
                     <p id="section-toc.1-1.7.2.6.2.1.1"><a href="#section-7.6.1" class="xref">7.6.1</a>.  <a href="#name-duration" class="xref">Duration</a><a href="#section-toc.1-1.7.2.6.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.6.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.6.2.2">
                     <p id="section-toc.1-1.7.2.6.2.2.1"><a href="#section-7.6.2" class="xref">7.6.2</a>.  <a href="#name-establishing-persistent-con" class="xref">Establishing Persistent Congestion</a><a href="#section-toc.1-1.7.2.6.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.6.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.6.2.3">
                     <p id="section-toc.1-1.7.2.6.2.3.1"><a href="#section-7.6.3" class="xref">7.6.3</a>.  <a href="#name-example" class="xref">Example</a><a href="#section-toc.1-1.7.2.6.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.7">
+              <li class="compact toc ulEmpty" 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-pacing" class="xref">Pacing</a><a href="#section-toc.1-1.7.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.8">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.8">
                 <p id="section-toc.1-1.7.2.8.1"><a href="#section-7.8" class="xref">7.8</a>.  <a href="#name-under-utilizing-the-congest" class="xref">Under-utilizing the Congestion Window</a><a href="#section-toc.1-1.7.2.8.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.8">
+          <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-security-considerations" class="xref">Security 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">
+<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-congestion-signals" class="xref">Congestion Signals</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">
+              <li class="compact toc ulEmpty" 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-traffic-analysis" class="xref">Traffic Analysis</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">
+              <li class="compact toc ulEmpty" 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-misreporting-ecn-markings" class="xref">Misreporting ECN Markings</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">
+          <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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.10">
+          <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-references" class="xref">References</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.10.2.1">
+<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-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.10.2.2">
+              <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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.11">
+          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
             <p id="section-toc.1-1.11.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.11.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.11.2.1">
+<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-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.11.2.1.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.11.2.1.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.1.2.1">
                     <p id="section-toc.1-1.11.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.11.2.1.2.1.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.2">
+              <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-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.11.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.3">
+              <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-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.11.2.3.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.4">
+              <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-a.4" class="xref">A.4</a>.  <a href="#name-initialization" class="xref">Initialization</a><a href="#section-toc.1-1.11.2.4.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.5">
+              <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-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.11.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.6">
+              <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-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.11.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.7">
+              <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-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.11.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.8">
+              <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-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.11.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.9">
+              <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-a.9" class="xref">A.9</a>.  <a href="#name-on-timeout" class="xref">On Timeout</a><a href="#section-toc.1-1.11.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.10">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.11.2.10">
                 <p id="section-toc.1-1.11.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.11.2.10.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.12">
+          <li class="compact toc ulEmpty" id="section-toc.1-1.12">
             <p id="section-toc.1-1.12.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.12.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1">
+<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-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.12.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2">
+              <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-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.12.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3">
+              <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-b.3" class="xref">B.3</a>.  <a href="#name-initialization-2" class="xref">Initialization</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">
+              <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-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.12.2.4.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.5">
+              <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-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.12.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.6">
+              <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-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.12.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.7">
+              <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-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.12.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.8">
+              <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-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.12.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.9">
+              <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-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.12.2.9.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.13">
+          <li class="compact toc ulEmpty" id="section-toc.1-1.13">
             <p id="section-toc.1-1.13.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.13.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.1">
+<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-c.1" class="xref">C.1</a>.  <a href="#name-since-draft-ietf-quic-recov" class="xref">Since draft-ietf-quic-recovery-29</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">
+              <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-c.2" class="xref">C.2</a>.  <a href="#name-since-draft-ietf-quic-recove" class="xref">Since draft-ietf-quic-recovery-28</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">
+              <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-c.3" class="xref">C.3</a>.  <a href="#name-since-draft-ietf-quic-recover" class="xref">Since draft-ietf-quic-recovery-27</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">
+              <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-c.4" class="xref">C.4</a>.  <a href="#name-since-draft-ietf-quic-recovery" class="xref">Since draft-ietf-quic-recovery-26</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">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.5">
                 <p id="section-toc.1-1.13.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-25</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">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.6">
                 <p id="section-toc.1-1.13.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-24</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">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.7">
                 <p id="section-toc.1-1.13.2.7.1"><a href="#section-c.7" class="xref">C.7</a>.  <a href="#name-since-draft-ietf-quic-recovery-23" class="xref">Since draft-ietf-quic-recovery-23</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">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.8">
                 <p id="section-toc.1-1.13.2.8.1"><a href="#section-c.8" class="xref">C.8</a>.  <a href="#name-since-draft-ietf-quic-recovery-22" class="xref">Since draft-ietf-quic-recovery-22</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">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.9">
                 <p id="section-toc.1-1.13.2.9.1"><a href="#section-c.9" class="xref">C.9</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.13.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.10">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.10">
                 <p id="section-toc.1-1.13.2.10.1"><a href="#section-c.10" class="xref">C.10</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.13.2.10.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.11">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.11">
                 <p id="section-toc.1-1.13.2.11.1"><a href="#section-c.11" class="xref">C.11</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.13.2.11.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.12">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.12">
                 <p id="section-toc.1-1.13.2.12.1"><a href="#section-c.12" class="xref">C.12</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.13.2.12.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.13">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.13">
                 <p id="section-toc.1-1.13.2.13.1"><a href="#section-c.13" class="xref">C.13</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.13.2.13.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.14">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.14">
                 <p id="section-toc.1-1.13.2.14.1"><a href="#section-c.14" class="xref">C.14</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.13.2.14.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.15">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.15">
                 <p id="section-toc.1-1.13.2.15.1"><a href="#section-c.15" class="xref">C.15</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.13.2.15.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.16">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.16">
                 <p id="section-toc.1-1.13.2.16.1"><a href="#section-c.16" class="xref">C.16</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.13.2.16.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.17">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.17">
                 <p id="section-toc.1-1.13.2.17.1"><a href="#section-c.17" class="xref">C.17</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.13.2.17.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.18">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.18">
                 <p id="section-toc.1-1.13.2.18.1"><a href="#section-c.18" class="xref">C.18</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.13.2.18.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.19">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.19">
                 <p id="section-toc.1-1.13.2.19.1"><a href="#section-c.19" class="xref">C.19</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.13.2.19.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.20">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.20">
                 <p id="section-toc.1-1.13.2.20.1"><a href="#section-c.20" class="xref">C.20</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.13.2.20.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.21">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.21">
                 <p id="section-toc.1-1.13.2.21.1"><a href="#section-c.21" class="xref">C.21</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.13.2.21.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.22">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.22">
                 <p id="section-toc.1-1.13.2.22.1"><a href="#section-c.22" class="xref">C.22</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.13.2.22.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.23">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.23">
                 <p id="section-toc.1-1.13.2.23.1"><a href="#section-c.23" class="xref">C.23</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.13.2.23.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.24">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.24">
                 <p id="section-toc.1-1.13.2.24.1"><a href="#section-c.24" class="xref">C.24</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.13.2.24.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.25">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.25">
                 <p id="section-toc.1-1.13.2.25.1"><a href="#section-c.25" class="xref">C.25</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.13.2.25.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.26">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.26">
                 <p id="section-toc.1-1.13.2.26.1"><a href="#section-c.26" class="xref">C.26</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.13.2.26.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.27">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.27">
                 <p id="section-toc.1-1.13.2.27.1"><a href="#section-c.27" class="xref">C.27</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.13.2.27.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.28">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.28">
                 <p id="section-toc.1-1.13.2.28.1"><a href="#section-c.28" class="xref">C.28</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.13.2.28.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.29">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.29">
                 <p id="section-toc.1-1.13.2.29.1"><a href="#section-c.29" class="xref">C.29</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.13.2.29.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.30">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.30">
                 <p id="section-toc.1-1.13.2.30.1"><a href="#section-c.30" class="xref">C.30</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.13.2.30.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.14">
+          <li class="compact toc ulEmpty" id="section-toc.1-1.14">
             <p id="section-toc.1-1.14.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.14.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="ulEmpty compact toc" id="section-toc.1-1.15">
+          <li class="compact toc ulEmpty" id="section-toc.1-1.15">
             <p id="section-toc.1-1.15.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</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">
+          <li class="compact toc ulEmpty" id="section-toc.1-1.16">
             <p id="section-toc.1-1.16.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.16.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
diff --git a/ianswett-path-validation/draft-ietf-quic-tls.html b/ianswett-path-validation/draft-ietf-quic-tls.html
index 1ffb413891..87c3debc2e 100644
--- a/ianswett-path-validation/draft-ietf-quic-tls.html
+++ b/ianswett-path-validation/draft-ietf-quic-tls.html
@@ -903,355 +903,355 @@ <h2 id="name-copyright-notice">
         <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.1">
+<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="toc compact ulEmpty" id="section-toc.1-1.2">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.2.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.3">
+          <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="toc compact ulEmpty" id="section-toc.1-1.4">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" 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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.1">
+<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="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.2">
+                  <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="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.3">
+                  <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="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.4">
+                  <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="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.5">
+                  <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="toc compact ulEmpty" id="section-toc.1-1.4.2.2">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.4.2.3">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.4.2.4">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.4.2.5">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.4.2.6">
+              <li class="ulEmpty toc compact" 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-0-rtt" class="xref">0-RTT</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
-<ul class="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.6.2.1">
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.6.2.1">
                     <p id="section-toc.1-1.4.2.6.2.1.1"><a href="#section-4.6.1" class="xref">4.6.1</a>.  <a href="#name-enabling-0-rtt" class="xref">Enabling 0-RTT</a><a href="#section-toc.1-1.4.2.6.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.6.2.2">
+                  <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.6.2.2">
                     <p id="section-toc.1-1.4.2.6.2.2.1"><a href="#section-4.6.2" class="xref">4.6.2</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.6.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.6.2.3">
+                  <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.6.2.3">
                     <p id="section-toc.1-1.4.2.6.2.3.1"><a href="#section-4.6.3" class="xref">4.6.3</a>.  <a href="#name-validating-0-rtt-configurat" class="xref">Validating 0-RTT Configuration</a><a href="#section-toc.1-1.4.2.6.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.7">
+              <li class="ulEmpty toc compact" 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-helloretryrequest" class="xref">HelloRetryRequest</a><a href="#section-toc.1-1.4.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.8">
+              <li class="ulEmpty toc compact" 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-tls-errors" class="xref">TLS Errors</a><a href="#section-toc.1-1.4.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.9">
+              <li class="ulEmpty toc compact" 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-discarding-unused-keys" class="xref">Discarding Unused Keys</a><a href="#section-toc.1-1.4.2.9.1" class="pilcrow">¶</a></p>
-<ul class="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.9.2.1">
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.9.2.1">
                     <p id="section-toc.1-1.4.2.9.2.1.1"><a href="#section-4.9.1" class="xref">4.9.1</a>.  <a href="#name-discarding-initial-keys" class="xref">Discarding Initial Keys</a><a href="#section-toc.1-1.4.2.9.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.9.2.2">
+                  <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.9.2.2">
                     <p id="section-toc.1-1.4.2.9.2.2.1"><a href="#section-4.9.2" class="xref">4.9.2</a>.  <a href="#name-discarding-handshake-keys" class="xref">Discarding Handshake Keys</a><a href="#section-toc.1-1.4.2.9.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.9.2.3">
+                  <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.9.2.3">
                     <p id="section-toc.1-1.4.2.9.2.3.1"><a href="#section-4.9.3" class="xref">4.9.3</a>.  <a href="#name-discarding-0-rtt-keys" class="xref">Discarding 0-RTT Keys</a><a href="#section-toc.1-1.4.2.9.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
             </ul>
 </li>
-          <li class="toc compact ulEmpty" id="section-toc.1-1.5">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.1">
+<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-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="toc compact ulEmpty" id="section-toc.1-1.5.2.2">
+              <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-initial-secrets" class="xref">Initial Secrets</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.3">
+              <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-aead-usage" class="xref">AEAD Usage</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.4">
+              <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-header-protection" class="xref">Header Protection</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
-<ul class="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.4.2.1">
+<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="toc compact ulEmpty" id="section-toc.1-1.5.2.4.2.2">
+                  <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="toc compact ulEmpty" id="section-toc.1-1.5.2.4.2.3">
+                  <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="toc compact ulEmpty" id="section-toc.1-1.5.2.4.2.4">
+                  <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="toc compact ulEmpty" id="section-toc.1-1.5.2.5">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.5.2.6">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.5.2.7">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.5.2.8">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.6">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.6.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.6.2.2">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.6.2.3">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.6.2.4">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.6.2.5">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.6.2.6">
+              <li class="ulEmpty toc compact" 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-limits-on-aead-usage" class="xref">Limits on AEAD Usage</a><a href="#section-toc.1-1.6.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.6.2.7">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.7">
+          <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="toc compact ulEmpty" id="section-toc.1-1.8">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.8.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.8.2.2">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.8.2.3">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.8.2.4">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.9">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.9.2.1">
+<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-session-linkability" class="xref">Session Linkability</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.9.2.2">
+              <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-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="toc compact ulEmpty" id="section-toc.1-1.9.2.3">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.9.2.4">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.9.2.5">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.9.2.6">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.10">
+          <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="toc compact ulEmpty" id="section-toc.1-1.11">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.11.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.11.2.2">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.12">
+          <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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.12.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.12.2.2">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.12.2.3">
+              <li class="ulEmpty toc compact" 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="toc compact ulEmpty" id="section-toc.1-1.12.2.4">
+              <li class="ulEmpty toc compact" 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>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.12.2.5">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.12.2.5">
                 <p id="section-toc.1-1.12.2.5.1"><a href="#section-a.5" class="xref">A.5</a>.  <a href="#name-chacha20-poly1305-short-hea" class="xref">ChaCha20-Poly1305 Short Header Packet</a><a href="#section-toc.1-1.12.2.5.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="toc compact ulEmpty" id="section-toc.1-1.13">
+          <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-aead-algorithm-analysis" class="xref">AEAD Algorithm Analysis</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
-<ul class="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.13.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" 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-analysis-of-aead_aes_128_gc" class="xref">Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.13.2.1.2.1">
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.1.2.1">
                     <p id="section-toc.1-1.13.2.1.2.1.1"><a href="#section-b.1.1" class="xref">B.1.1</a>.  <a href="#name-confidentiality-limit" class="xref">Confidentiality Limit</a><a href="#section-toc.1-1.13.2.1.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="toc compact ulEmpty" id="section-toc.1-1.13.2.1.2.2">
+                  <li class="ulEmpty compact toc" id="section-toc.1-1.13.2.1.2.2">
                     <p id="section-toc.1-1.13.2.1.2.2.1"><a href="#section-b.1.2" class="xref">B.1.2</a>.  <a href="#name-integrity-limit" class="xref">Integrity Limit</a><a href="#section-toc.1-1.13.2.1.2.2.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.13.2.2">
+              <li class="ulEmpty toc compact" 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-analysis-of-aead_aes_128_cc" class="xref">Analysis of AEAD_AES_128_CCM Usage Limits</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.13.2.2.2.1">
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact 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-b.2.1" class="xref">B.2.1</a>.  <a href="#name-confidentiality-limits" class="xref">Confidentiality Limits</a><a href="#section-toc.1-1.13.2.2.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="toc compact ulEmpty" id="section-toc.1-1.13.2.2.2.2">
+                  <li class="ulEmpty compact 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-b.2.2" class="xref">B.2.2</a>.  <a href="#name-integrity-limits" class="xref">Integrity Limits</a><a href="#section-toc.1-1.13.2.2.2.2.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
             </ul>
 </li>
-          <li class="toc compact ulEmpty" id="section-toc.1-1.14">
+          <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">Appendix C</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="toc compact ulEmpty">
-<li class="toc compact ulEmpty" id="section-toc.1-1.14.2.1">
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" id="section-toc.1-1.14.2.1">
                 <p id="section-toc.1-1.14.2.1.1"><a href="#section-c.1" class="xref">C.1</a>.  <a href="#name-since-draft-ietf-quic-tls-2" class="xref">Since draft-ietf-quic-tls-29</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.2">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.2">
                 <p id="section-toc.1-1.14.2.2.1"><a href="#section-c.2" class="xref">C.2</a>.  <a href="#name-since-draft-ietf-quic-tls-28" class="xref">Since draft-ietf-quic-tls-28</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.3">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.3">
                 <p id="section-toc.1-1.14.2.3.1"><a href="#section-c.3" class="xref">C.3</a>.  <a href="#name-since-draft-ietf-quic-tls-27" class="xref">Since draft-ietf-quic-tls-27</a><a href="#section-toc.1-1.14.2.3.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.4">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.4">
                 <p id="section-toc.1-1.14.2.4.1"><a href="#section-c.4" class="xref">C.4</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.14.2.4.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.5">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.5">
                 <p id="section-toc.1-1.14.2.5.1"><a href="#section-c.5" class="xref">C.5</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.14.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.6">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.6">
                 <p id="section-toc.1-1.14.2.6.1"><a href="#section-c.6" class="xref">C.6</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.14.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.7">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.7">
                 <p id="section-toc.1-1.14.2.7.1"><a href="#section-c.7" class="xref">C.7</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.14.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.8">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.8">
                 <p id="section-toc.1-1.14.2.8.1"><a href="#section-c.8" class="xref">C.8</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.14.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.9">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.9">
                 <p id="section-toc.1-1.14.2.9.1"><a href="#section-c.9" class="xref">C.9</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.14.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.10">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.10">
                 <p id="section-toc.1-1.14.2.10.1"><a href="#section-c.10" class="xref">C.10</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.14.2.10.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.11">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.11">
                 <p id="section-toc.1-1.14.2.11.1"><a href="#section-c.11" class="xref">C.11</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.14.2.11.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.12">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.12">
                 <p id="section-toc.1-1.14.2.12.1"><a href="#section-c.12" class="xref">C.12</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.14.2.12.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.13">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.13">
                 <p id="section-toc.1-1.14.2.13.1"><a href="#section-c.13" class="xref">C.13</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.14.2.13.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.14">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.14">
                 <p id="section-toc.1-1.14.2.14.1"><a href="#section-c.14" class="xref">C.14</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.14.2.14.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.15">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.15">
                 <p id="section-toc.1-1.14.2.15.1"><a href="#section-c.15" class="xref">C.15</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.14.2.15.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.16">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.16">
                 <p id="section-toc.1-1.14.2.16.1"><a href="#section-c.16" class="xref">C.16</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.14.2.16.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.17">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.17">
                 <p id="section-toc.1-1.14.2.17.1"><a href="#section-c.17" class="xref">C.17</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.14.2.17.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.18">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.18">
                 <p id="section-toc.1-1.14.2.18.1"><a href="#section-c.18" class="xref">C.18</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.14.2.18.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.19">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.19">
                 <p id="section-toc.1-1.14.2.19.1"><a href="#section-c.19" class="xref">C.19</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.14.2.19.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.20">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.20">
                 <p id="section-toc.1-1.14.2.20.1"><a href="#section-c.20" class="xref">C.20</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.14.2.20.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.21">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.21">
                 <p id="section-toc.1-1.14.2.21.1"><a href="#section-c.21" class="xref">C.21</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.14.2.21.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.22">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.22">
                 <p id="section-toc.1-1.14.2.22.1"><a href="#section-c.22" class="xref">C.22</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.14.2.22.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.23">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.23">
                 <p id="section-toc.1-1.14.2.23.1"><a href="#section-c.23" class="xref">C.23</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.14.2.23.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.24">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.24">
                 <p id="section-toc.1-1.14.2.24.1"><a href="#section-c.24" class="xref">C.24</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.14.2.24.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.25">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.25">
                 <p id="section-toc.1-1.14.2.25.1"><a href="#section-c.25" class="xref">C.25</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.14.2.25.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.26">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.26">
                 <p id="section-toc.1-1.14.2.26.1"><a href="#section-c.26" class="xref">C.26</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.14.2.26.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="toc compact ulEmpty" id="section-toc.1-1.14.2.27">
+              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.27">
                 <p id="section-toc.1-1.14.2.27.1"><a href="#section-c.27" class="xref">C.27</a>. <a href="#name-since-draft-thomson-quic-tl" class="xref">Since draft-thomson-quic-tls-01</a><a href="#section-toc.1-1.14.2.27.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="toc compact ulEmpty" id="section-toc.1-1.15">
+          <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-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="toc compact ulEmpty" id="section-toc.1-1.16">
+          <li class="ulEmpty compact toc" id="section-toc.1-1.16">
             <p id="section-toc.1-1.16.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.16.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
diff --git a/ianswett-path-validation/draft-ietf-quic-transport.html b/ianswett-path-validation/draft-ietf-quic-transport.html
index bb5cbc5eb3..cec29fa61d 100644
--- a/ianswett-path-validation/draft-ietf-quic-transport.html
+++ b/ianswett-path-validation/draft-ietf-quic-transport.html
@@ -905,768 +905,768 @@ <h2 id="name-copyright-notice">
         <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">
+<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"><a href="#section-1" class="xref">1</a>.  <a href="#name-overview" class="xref">Overview</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.1.2.1">
+<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-document-structure" class="xref">Document Structure</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.1.2.2">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.1.2.3">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.2">
+          <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-streams" class="xref">Streams</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.2.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.2.2.2">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.2.2.3">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.2.2.4">
+              <li class="compact toc ulEmpty" 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-operations-on-streams" class="xref">Operations on Streams</a><a href="#section-toc.1-1.2.2.4.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
+          <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-stream-states" class="xref">Stream States</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.3.2.2">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.3.2.3">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.3.2.4">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.3.2.5">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.4">
+          <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-flow-control" class="xref">Flow Control</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.4.2.2">
+              <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-increasing-flow-control-lim" class="xref">Increasing Flow Control Limits</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.4.2.4">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.4.2.5">
+              <li class="compact toc ulEmpty" 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>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.6">
+              <li class="compact toc ulEmpty" 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-flow-control-performance" class="xref">Flow Control Performance</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.5">
+          <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-connections" class="xref">Connections</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">
+<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-connection-id" class="xref">Connection ID</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.1.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.5.2.1.2.2">
+                  <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-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="ulEmpty toc compact" id="section-toc.1-1.5.2.2">
+              <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-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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.2.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.5.2.2.2.2">
+                  <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-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="ulEmpty toc compact" id="section-toc.1-1.5.2.2.2.3">
+                  <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-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="ulEmpty toc compact" id="section-toc.1-1.5.2.3">
+              <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-operations-on-connections" class="xref">Operations on Connections</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.6">
+          <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-version-negotiation" class="xref">Version Negotiation</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.6.2.2">
+              <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-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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.2.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.6.2.3">
+              <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-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 toc compact" id="section-toc.1-1.7">
+          <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-cryptographic-and-transport" class="xref">Cryptographic and Transport Handshake</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.7.2.2">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.7.2.3">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.7.2.4">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.4.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.7.2.4.2.2">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.7.2.5">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.8">
+          <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-address-validation" class="xref">Address Validation</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1">
+<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-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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.8.2.1.2.2">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.8.2.1.2.3">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.8.2.1.2.4">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.8.2.2">
+              <li class="compact toc ulEmpty" 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>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2.2.1">
                     <p id="section-toc.1-1.8.2.2.2.1.1"><a href="#section-8.2.1" class="xref">8.2.1</a>.  <a href="#name-initiating-path-validation" class="xref">Initiating Path Validation</a><a href="#section-toc.1-1.8.2.2.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2.2.2">
                     <p id="section-toc.1-1.8.2.2.2.2.1"><a href="#section-8.2.2" class="xref">8.2.2</a>.  <a href="#name-path-validation-responses" class="xref">Path Validation Responses</a><a href="#section-toc.1-1.8.2.2.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2.2.3">
                     <p id="section-toc.1-1.8.2.2.2.3.1"><a href="#section-8.2.3" class="xref">8.2.3</a>.  <a href="#name-successful-path-validation" class="xref">Successful Path Validation</a><a href="#section-toc.1-1.8.2.2.2.3.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2.2.4">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2.2.4">
                     <p id="section-toc.1-1.8.2.2.2.4.1"><a href="#section-8.2.4" class="xref">8.2.4</a>.  <a href="#name-failed-path-validation" class="xref">Failed Path Validation</a><a href="#section-toc.1-1.8.2.2.2.4.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
+          <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-connection-migration" class="xref">Connection Migration</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">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.9.2.2">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.9.2.3">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.9.2.3.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.9.2.3.2.2">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.9.2.3.2.3">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.9.2.4">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.9.2.5">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.9.2.6">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.9.2.6.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.9.2.6.2.2">
+                  <li class="compact toc ulEmpty" 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-migration-to-a-preferred-ad" class="xref">Migration to a Preferred Address</a><a href="#section-toc.1-1.9.2.6.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.6.2.3">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.9.2.7">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.10">
+          <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-connection-termination" class="xref">Connection Termination</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.1">
+<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-idle-timeout" class="xref">Idle Timeout</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.1.2.1">
+<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-10.1.1" class="xref">10.1.1</a>.  <a href="#name-liveness-testing" class="xref">Liveness Testing</a><a href="#section-toc.1-1.10.2.1.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.1.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1.2.2">
                     <p id="section-toc.1-1.10.2.1.2.2.1"><a href="#section-10.1.2" class="xref">10.1.2</a>.  <a href="#name-deferring-idle-timeout" class="xref">Deferring Idle Timeout</a><a href="#section-toc.1-1.10.2.1.2.2.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.2">
+              <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-immediate-close" class="xref">Immediate Close</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.2.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2.2.1">
                     <p id="section-toc.1-1.10.2.2.2.1.1"><a href="#section-10.2.1" class="xref">10.2.1</a>.  <a href="#name-closing-connection-state" class="xref">Closing Connection State</a><a href="#section-toc.1-1.10.2.2.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.2.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2.2.2">
                     <p id="section-toc.1-1.10.2.2.2.2.1"><a href="#section-10.2.2" class="xref">10.2.2</a>.  <a href="#name-draining-connection-state" class="xref">Draining Connection State</a><a href="#section-toc.1-1.10.2.2.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.2.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2.2.3">
                     <p id="section-toc.1-1.10.2.2.2.3.1"><a href="#section-10.2.3" class="xref">10.2.3</a>.  <a href="#name-immediate-close-during-the-" class="xref">Immediate Close During the Handshake</a><a href="#section-toc.1-1.10.2.2.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.3">
+              <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-stateless-reset" class="xref">Stateless Reset</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.3.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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-detecting-a-stateless-reset" class="xref">Detecting a Stateless Reset</a><a href="#section-toc.1-1.10.2.3.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.3.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3.2.2">
                     <p id="section-toc.1-1.10.2.3.2.2.1"><a href="#section-10.3.2" class="xref">10.3.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.3.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.3.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3.2.3">
                     <p id="section-toc.1-1.10.2.3.2.3.1"><a href="#section-10.3.3" class="xref">10.3.3</a>.  <a href="#name-looping" class="xref">Looping</a><a href="#section-toc.1-1.10.2.3.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.11">
+          <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-error-handling" class="xref">Error Handling</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.11.2.1">
+<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-connection-errors" class="xref">Connection Errors</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.2">
+              <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-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 toc compact" id="section-toc.1-1.12">
+          <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-packets-and-frames" class="xref">Packets and Frames</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.12.2.1">
+<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-protected-packets" class="xref">Protected Packets</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.12.2.2">
+              <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-coalescing-packets" class="xref">Coalescing Packets</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.12.2.3">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.12.2.4">
+              <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-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 toc compact" id="section-toc.1-1.13">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.13.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.13.2.2">
+              <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-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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.1">
+<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-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="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.2">
+                  <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-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="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.3">
+                  <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-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="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.4">
+                  <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-13.2.4" class="xref">13.2.4</a>.  <a href="#name-limiting-ranges-by-tracking" class="xref">Limiting Ranges by Tracking ACK Frames</a><a href="#section-toc.1-1.13.2.2.2.4.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.5">
+                  <li class="compact toc ulEmpty" 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-measuring-and-reporting-hos" class="xref">Measuring and Reporting Host Delay</a><a href="#section-toc.1-1.13.2.2.2.5.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.6">
+                  <li class="compact toc ulEmpty" 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-ack-frames-and-packet-prote" class="xref">ACK Frames and Packet Protection</a><a href="#section-toc.1-1.13.2.2.2.6.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.2.2.7">
+                  <li class="compact toc ulEmpty" 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-padding-frames-consume-cong" class="xref">PADDING Frames Consume Congestion Window</a><a href="#section-toc.1-1.13.2.2.2.7.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.3">
+              <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-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="ulEmpty toc compact" id="section-toc.1-1.13.2.4">
+              <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-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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.13.2.4.2.1">
+<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-13.4.1" class="xref">13.4.1</a>.  <a href="#name-reporting-ecn-counts" class="xref">Reporting ECN Counts</a><a href="#section-toc.1-1.13.2.4.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.13.2.4.2.2">
+                  <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.14">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.14.2.1">
+<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-14.1" class="xref">14.1</a>.  <a href="#name-initial-packet-size" class="xref">Initial Packet Size</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.2">
+              <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-14.2" class="xref">14.2</a>.  <a href="#name-path-maximum-transmission-u" class="xref">Path Maximum Transmission Unit</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.14.2.2.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.2.2.1">
                     <p id="section-toc.1-1.14.2.2.2.1.1"><a href="#section-14.2.1" class="xref">14.2.1</a>.  <a href="#name-handling-of-icmp-messages-b" class="xref">Handling of ICMP Messages by PMTUD</a><a href="#section-toc.1-1.14.2.2.2.1.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.3">
+              <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-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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.14.2.3.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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-dplpmtud-and-initial-connec" class="xref">DPLPMTUD and Initial Connectivity</a><a href="#section-toc.1-1.14.2.3.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.3.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.14.2.3.2.2">
                     <p id="section-toc.1-1.14.2.3.2.2.1"><a href="#section-14.3.2" class="xref">14.3.2</a>.  <a href="#name-validating-the-quic-path-wi" class="xref">Validating the QUIC Path with DPLPMTUD</a><a href="#section-toc.1-1.14.2.3.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.3.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.14.2.3.2.3">
                     <p id="section-toc.1-1.14.2.3.2.3.1"><a href="#section-14.3.3" class="xref">14.3.3</a>.  <a href="#name-handling-of-icmp-messages-by" class="xref">Handling of ICMP Messages by DPLPMTUD</a><a href="#section-toc.1-1.14.2.3.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.14.2.4">
+              <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-14.4" class="xref">14.4</a>.  <a href="#name-sending-quic-pmtu-probes" class="xref">Sending QUIC PMTU Probes</a><a href="#section-toc.1-1.14.2.4.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.14.2.4.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.4.2.1">
                     <p id="section-toc.1-1.14.2.4.2.1.1"><a href="#section-14.4.1" class="xref">14.4.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.4.2.1.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.15">
+          <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.16">
+          <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.17">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.17.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.17.2.2">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.17.2.2.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.17.2.2.2.2">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.17.2.2.2.3">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.17.2.2.2.4">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.17.2.2.2.5">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.17.2.3">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.17.2.3.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.18">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.18.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.18.2.2">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.19">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.19.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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-frames" class="xref">PADDING Frames</a><a href="#section-toc.1-1.19.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.2">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">PING Frames</a><a href="#section-toc.1-1.19.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.3">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.19.2.3.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.19.2.3.2.2">
+                  <li class="compact toc ulEmpty" 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" 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="ulEmpty toc compact" id="section-toc.1-1.19.2.4">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">RESET_STREAM Frames</a><a href="#section-toc.1-1.19.2.4.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.5">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">STOP_SENDING Frames</a><a href="#section-toc.1-1.19.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.6">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">CRYPTO Frames</a><a href="#section-toc.1-1.19.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.7">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">NEW_TOKEN Frames</a><a href="#section-toc.1-1.19.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.8">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.19.2.9">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">MAX_DATA Frames</a><a href="#section-toc.1-1.19.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.10">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">MAX_STREAM_DATA Frames</a><a href="#section-toc.1-1.19.2.10.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.11">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.19.2.12">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">DATA_BLOCKED Frames</a><a href="#section-toc.1-1.19.2.12.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.13">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">STREAM_DATA_BLOCKED Frames</a><a href="#section-toc.1-1.19.2.13.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.14">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.19.2.15">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">NEW_CONNECTION_ID Frames</a><a href="#section-toc.1-1.19.2.15.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.16">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">RETIRE_CONNECTION_ID Frames</a><a href="#section-toc.1-1.19.2.16.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.17">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">PATH_CHALLENGE Frames</a><a href="#section-toc.1-1.19.2.17.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.18">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">PATH_RESPONSE Frames</a><a href="#section-toc.1-1.19.2.18.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.19">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.19.2.20">
+              <li class="compact toc ulEmpty" 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-frames" class="xref">HANDSHAKE_DONE Frames</a><a href="#section-toc.1-1.19.2.20.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.19.2.21">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.20">
+          <li class="compact toc ulEmpty" 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-error-codes" class="xref">Error Codes</a><a href="#section-toc.1-1.20.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.20.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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-transport-error-codes" class="xref">Transport Error Codes</a><a href="#section-toc.1-1.20.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.20.2.2">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.20.2.2">
                 <p id="section-toc.1-1.20.2.2.1"><a href="#section-20.2" class="xref">20.2</a>.  <a href="#name-application-protocol-error-" class="xref">Application Protocol Error Codes</a><a href="#section-toc.1-1.20.2.2.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.21">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.21.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.21.2.2">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.21.2.3">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.21.2.4">
+              <li class="compact toc ulEmpty" 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-request-forgery-attacks" class="xref">Request Forgery Attacks</a><a href="#section-toc.1-1.21.2.4.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.21.2.4.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.21.2.4.2.1">
                     <p id="section-toc.1-1.21.2.4.2.1.1"><a href="#section-21.4.1" class="xref">21.4.1</a>.  <a href="#name-control-options-for-endpoin" class="xref">Control Options for Endpoints</a><a href="#section-toc.1-1.21.2.4.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.4.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.21.2.4.2.2">
                     <p id="section-toc.1-1.21.2.4.2.2.1"><a href="#section-21.4.2" class="xref">21.4.2</a>.  <a href="#name-request-forgery-with-client" class="xref">Request Forgery with Client Initial Packets</a><a href="#section-toc.1-1.21.2.4.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.4.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.21.2.4.2.3">
                     <p id="section-toc.1-1.21.2.4.2.3.1"><a href="#section-21.4.3" class="xref">21.4.3</a>.  <a href="#name-request-forgery-with-prefer" class="xref">Request Forgery with Preferred Addresses</a><a href="#section-toc.1-1.21.2.4.2.3.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.4.2.4">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.21.2.4.2.4">
                     <p id="section-toc.1-1.21.2.4.2.4.1"><a href="#section-21.4.4" class="xref">21.4.4</a>.  <a href="#name-request-forgery-with-spoofe" class="xref">Request Forgery with Spoofed Migration</a><a href="#section-toc.1-1.21.2.4.2.4.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.4.2.5">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.21.2.4.2.5">
                     <p id="section-toc.1-1.21.2.4.2.5.1"><a href="#section-21.4.5" class="xref">21.4.5</a>.  <a href="#name-generic-request-forgery-cou" class="xref">Generic Request Forgery Countermeasures</a><a href="#section-toc.1-1.21.2.4.2.5.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.5">
+              <li class="compact toc ulEmpty" 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-slowloris-attacks" class="xref">Slowloris Attacks</a><a href="#section-toc.1-1.21.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.6">
+              <li class="compact toc ulEmpty" 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-fragmentation-and-re" class="xref">Stream Fragmentation and Reassembly Attacks</a><a href="#section-toc.1-1.21.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.7">
+              <li class="compact toc ulEmpty" 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-stream-commitment-attack" class="xref">Stream Commitment Attack</a><a href="#section-toc.1-1.21.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.8">
+              <li class="compact toc ulEmpty" 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-peer-denial-of-service" class="xref">Peer Denial of Service</a><a href="#section-toc.1-1.21.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.9">
+              <li class="compact toc ulEmpty" 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-explicit-congestion-notifica" class="xref">Explicit Congestion Notification Attacks</a><a href="#section-toc.1-1.21.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.10">
+              <li class="compact toc ulEmpty" 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-stateless-reset-oracle" class="xref">Stateless Reset Oracle</a><a href="#section-toc.1-1.21.2.10.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.11">
+              <li class="compact toc ulEmpty" 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-version-downgrade" class="xref">Version Downgrade</a><a href="#section-toc.1-1.21.2.11.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.12">
+              <li class="compact toc ulEmpty" 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-targeted-attacks-by-routing" class="xref">Targeted Attacks by Routing</a><a href="#section-toc.1-1.21.2.12.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.13">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.21.2.13">
                 <p id="section-toc.1-1.21.2.13.1"><a href="#section-21.13" class="xref">21.13</a>. <a href="#name-overview-of-security-proper" class="xref">Overview of Security Properties</a><a href="#section-toc.1-1.21.2.13.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.21.2.13.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.21.2.13.2.1">
                     <p id="section-toc.1-1.21.2.13.2.1.1"><a href="#section-21.13.1" class="xref">21.13.1</a>.  <a href="#name-handshake" class="xref">Handshake</a><a href="#section-toc.1-1.21.2.13.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.13.2.2">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.21.2.13.2.2">
                     <p id="section-toc.1-1.21.2.13.2.2.1"><a href="#section-21.13.2" class="xref">21.13.2</a>.  <a href="#name-protected-packets-2" class="xref">Protected Packets</a><a href="#section-toc.1-1.21.2.13.2.2.1" class="pilcrow">¶</a></p>
 </li>
-                  <li class="ulEmpty toc compact" id="section-toc.1-1.21.2.13.2.3">
+                  <li class="compact toc ulEmpty" id="section-toc.1-1.21.2.13.2.3">
                     <p id="section-toc.1-1.21.2.13.2.3.1"><a href="#section-21.13.3" class="xref">21.13.3</a>.  <a href="#name-connection-migration-2" class="xref">Connection Migration</a><a href="#section-toc.1-1.21.2.13.2.3.1" class="pilcrow">¶</a></p>
 </li>
                 </ul>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.22">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.22.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.22.2.1.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.22.2.1.2.2">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.22.2.1.2.3">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.22.2.1.2.4">
+                  <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.22.2.2">
+              <li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.22.2.3">
+              <li class="compact toc ulEmpty" 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-types-registry" class="xref">QUIC Frame Types Registry</a><a href="#section-toc.1-1.22.2.3.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.22.2.4">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.23">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.23.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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="ulEmpty toc compact" id="section-toc.1-1.23.2.2">
+              <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.24">
+          <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.25">
+          <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.26">
+          <li class="compact toc ulEmpty" 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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" id="section-toc.1-1.26.2.1">
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" 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-29</a><a href="#section-toc.1-1.26.2.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.2">
+              <li class="compact toc ulEmpty" 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-28</a><a href="#section-toc.1-1.26.2.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.3">
+              <li class="compact toc ulEmpty" 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-27</a><a href="#section-toc.1-1.26.2.3.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.4">
+              <li class="compact toc ulEmpty" 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-26</a><a href="#section-toc.1-1.26.2.4.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.5">
+              <li class="compact toc ulEmpty" 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-25</a><a href="#section-toc.1-1.26.2.5.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.6">
+              <li class="compact toc ulEmpty" 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-24</a><a href="#section-toc.1-1.26.2.6.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.7">
+              <li class="compact toc ulEmpty" 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-23</a><a href="#section-toc.1-1.26.2.7.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.8">
+              <li class="compact toc ulEmpty" 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-22" class="xref">Since draft-ietf-quic-transport-22</a><a href="#section-toc.1-1.26.2.8.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.9">
+              <li class="compact toc ulEmpty" 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-21" class="xref">Since draft-ietf-quic-transport-21</a><a href="#section-toc.1-1.26.2.9.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.10">
+              <li class="compact toc ulEmpty" 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-20" class="xref">Since draft-ietf-quic-transport-20</a><a href="#section-toc.1-1.26.2.10.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.11">
+              <li class="compact toc ulEmpty" 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-1" class="xref">Since draft-ietf-quic-transport-19</a><a href="#section-toc.1-1.26.2.11.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.12">
+              <li class="compact toc ulEmpty" 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-18" class="xref">Since draft-ietf-quic-transport-18</a><a href="#section-toc.1-1.26.2.12.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.13">
+              <li class="compact toc ulEmpty" 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-17" class="xref">Since draft-ietf-quic-transport-17</a><a href="#section-toc.1-1.26.2.13.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.14">
+              <li class="compact toc ulEmpty" 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-16" class="xref">Since draft-ietf-quic-transport-16</a><a href="#section-toc.1-1.26.2.14.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.15">
+              <li class="compact toc ulEmpty" 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-15" class="xref">Since draft-ietf-quic-transport-15</a><a href="#section-toc.1-1.26.2.15.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.16">
+              <li class="compact toc ulEmpty" 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-14" class="xref">Since draft-ietf-quic-transport-14</a><a href="#section-toc.1-1.26.2.16.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.17">
+              <li class="compact toc ulEmpty" 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-13" class="xref">Since draft-ietf-quic-transport-13</a><a href="#section-toc.1-1.26.2.17.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.18">
+              <li class="compact toc ulEmpty" 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-12" class="xref">Since draft-ietf-quic-transport-12</a><a href="#section-toc.1-1.26.2.18.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.19">
+              <li class="compact toc ulEmpty" 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-11" class="xref">Since draft-ietf-quic-transport-11</a><a href="#section-toc.1-1.26.2.19.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.20">
+              <li class="compact toc ulEmpty" 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-10" class="xref">Since draft-ietf-quic-transport-10</a><a href="#section-toc.1-1.26.2.20.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.21">
+              <li class="compact toc ulEmpty" 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-0" class="xref">Since draft-ietf-quic-transport-09</a><a href="#section-toc.1-1.26.2.21.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.22">
+              <li class="compact toc ulEmpty" 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-08" class="xref">Since draft-ietf-quic-transport-08</a><a href="#section-toc.1-1.26.2.22.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.23">
+              <li class="compact toc ulEmpty" 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-07" class="xref">Since draft-ietf-quic-transport-07</a><a href="#section-toc.1-1.26.2.23.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.24">
+              <li class="compact toc ulEmpty" 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-06" class="xref">Since draft-ietf-quic-transport-06</a><a href="#section-toc.1-1.26.2.24.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.25">
+              <li class="compact toc ulEmpty" 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-05" class="xref">Since draft-ietf-quic-transport-05</a><a href="#section-toc.1-1.26.2.25.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.26">
+              <li class="compact toc ulEmpty" 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-04" class="xref">Since draft-ietf-quic-transport-04</a><a href="#section-toc.1-1.26.2.26.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.27">
+              <li class="compact toc ulEmpty" 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-03" class="xref">Since draft-ietf-quic-transport-03</a><a href="#section-toc.1-1.26.2.27.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.28">
+              <li class="compact toc ulEmpty" 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-02" class="xref">Since draft-ietf-quic-transport-02</a><a href="#section-toc.1-1.26.2.28.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.29">
+              <li class="compact toc ulEmpty" 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-ietf-quic-transport-01" class="xref">Since draft-ietf-quic-transport-01</a><a href="#section-toc.1-1.26.2.29.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.30">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.26.2.30">
                 <p id="section-toc.1-1.26.2.30.1"><a href="#section-c.30" class="xref">C.30</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.30.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="ulEmpty toc compact" id="section-toc.1-1.26.2.31">
+              <li class="compact toc ulEmpty" id="section-toc.1-1.26.2.31">
                 <p id="section-toc.1-1.26.2.31.1"><a href="#section-c.31" class="xref">C.31</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.31.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </li>
-          <li class="ulEmpty toc compact" id="section-toc.1-1.27">
+          <li class="compact toc ulEmpty" 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 toc compact" id="section-toc.1-1.28">
+          <li class="compact toc ulEmpty" 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>
@@ -3923,6 +3923,8 @@ <h3 id="name-path-validation">
 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-7" class="pilcrow">¶</a></p>
+<p id="section-8.2-8">The number of new paths an endpoint can probe is limited by the number of
+extra Connection IDs the peer has previously supplied.<a href="#section-8.2-8" class="pilcrow">¶</a></p>
 <div id="initiating-path-validation">
 <section id="section-8.2.1">
           <h4 id="name-initiating-path-validation">
diff --git a/ianswett-path-validation/draft-ietf-quic-transport.txt b/ianswett-path-validation/draft-ietf-quic-transport.txt
index 766d424a61..84f8a66284 100644
--- a/ianswett-path-validation/draft-ietf-quic-transport.txt
+++ b/ianswett-path-validation/draft-ietf-quic-transport.txt
@@ -3038,6 +3038,9 @@ Internet-Draft           QUIC Transport Protocol          September 2020
    same packet.  This ensures that an unused connection ID will be
    available to the peer when sending a response.
 
+   The number of new paths an endpoint can probe is limited by the
+   number of extra Connection IDs the peer has previously supplied.
+
 8.2.1.  Initiating Path Validation
 
    To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
@@ -3074,9 +3077,6 @@ Internet-Draft           QUIC Transport Protocol          September 2020
 
 
 
-
-
-
 Iyengar & Thomson         Expires 20 March 2021                [Page 55]
 
 Internet-Draft           QUIC Transport Protocol          September 2020
diff --git a/index.html b/index.html
index c22a24eb84..989ba5057f 100644
--- a/index.html
+++ b/index.html
@@ -73,1074 +73,1024 @@ <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="ianswett-iw-decrease">ianswett-iw-decrease</a></h2>
-    <table id="branch-ianswett-iw-decrease">
+    <h2>Preview for branch <a href="hex-d">hex-d</a></h2>
+    <table id="branch-hex-d">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-iw-decrease/draft-ietf-quic-http.html"
+        <td><a href="hex-d/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-iw-decrease/draft-ietf-quic-http.txt"
+        <td><a href="hex-d/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-iw-decrease/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-iw-decrease/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/hex-d/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/hex-d/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-iw-decrease/draft-ietf-quic-invariants.html"
+        <td><a href="hex-d/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-iw-decrease/draft-ietf-quic-invariants.txt"
+        <td><a href="hex-d/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-iw-decrease/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-iw-decrease/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/hex-d/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/hex-d/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-iw-decrease/draft-ietf-quic-qpack.html"
+        <td><a href="hex-d/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-iw-decrease/draft-ietf-quic-qpack.txt"
+        <td><a href="hex-d/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-iw-decrease/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-iw-decrease/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/hex-d/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/hex-d/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-iw-decrease/draft-ietf-quic-recovery.html"
+        <td><a href="hex-d/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-iw-decrease/draft-ietf-quic-recovery.txt"
+        <td><a href="hex-d/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-iw-decrease/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-iw-decrease/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/hex-d/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/hex-d/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-iw-decrease/draft-ietf-quic-tls.html"
+        <td><a href="hex-d/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-iw-decrease/draft-ietf-quic-tls.txt"
+        <td><a href="hex-d/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-iw-decrease/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-iw-decrease/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/hex-d/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/hex-d/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-iw-decrease/draft-ietf-quic-transport.html"
+        <td><a href="hex-d/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-iw-decrease/draft-ietf-quic-transport.txt"
+        <td><a href="hex-d/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-iw-decrease/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-iw-decrease/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/hex-d/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/hex-d/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="async-cert-validation">async-cert-validation</a></h2>
-    <table id="branch-async-cert-validation">
+    <h2>Preview for branch <a href="not-delay">not-delay</a></h2>
+    <table id="branch-not-delay">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="async-cert-validation/draft-ietf-quic-http.html"
+        <td><a href="not-delay/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="async-cert-validation/draft-ietf-quic-http.txt"
+        <td><a href="not-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/async-cert-validation/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/async-cert-validation/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/not-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/not-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="async-cert-validation/draft-ietf-quic-invariants.html"
+        <td><a href="not-delay/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="async-cert-validation/draft-ietf-quic-invariants.txt"
+        <td><a href="not-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/async-cert-validation/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/async-cert-validation/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/not-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/not-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="async-cert-validation/draft-ietf-quic-qpack.html"
+        <td><a href="not-delay/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="async-cert-validation/draft-ietf-quic-qpack.txt"
+        <td><a href="not-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/async-cert-validation/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/async-cert-validation/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/not-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/not-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="async-cert-validation/draft-ietf-quic-recovery.html"
+        <td><a href="not-delay/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="async-cert-validation/draft-ietf-quic-recovery.txt"
+        <td><a href="not-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/async-cert-validation/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/async-cert-validation/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/not-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/not-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="async-cert-validation/draft-ietf-quic-tls.html"
+        <td><a href="not-delay/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="async-cert-validation/draft-ietf-quic-tls.txt"
+        <td><a href="not-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/async-cert-validation/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/async-cert-validation/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/not-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/not-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="async-cert-validation/draft-ietf-quic-transport.html"
+        <td><a href="not-delay/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="async-cert-validation/draft-ietf-quic-transport.txt"
+        <td><a href="not-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/async-cert-validation/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/async-cert-validation/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/not-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/not-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="ianswett-cwnd-limit-consistency">ianswett-cwnd-limit-consistency</a></h2>
-    <table id="branch-ianswett-cwnd-limit-consistency">
+    <h2>Preview for branch <a href="gorry-ecn-rewrite">gorry-ecn-rewrite</a></h2>
+    <table id="branch-gorry-ecn-rewrite">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-http.html"
+        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-http.txt"
+        <td><a href="gorry-ecn-rewrite/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-cwnd-limit-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/ianswett-cwnd-limit-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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-cwnd-limit-consistency/draft-ietf-quic-invariants.html"
+        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-invariants.txt"
+        <td><a href="gorry-ecn-rewrite/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-cwnd-limit-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/ianswett-cwnd-limit-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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-cwnd-limit-consistency/draft-ietf-quic-qpack.html"
+        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-qpack.txt"
+        <td><a href="gorry-ecn-rewrite/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-cwnd-limit-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/ianswett-cwnd-limit-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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-cwnd-limit-consistency/draft-ietf-quic-recovery.html"
+        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-recovery.txt"
+        <td><a href="gorry-ecn-rewrite/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-cwnd-limit-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/ianswett-cwnd-limit-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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-cwnd-limit-consistency/draft-ietf-quic-tls.html"
+        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-tls.txt"
+        <td><a href="gorry-ecn-rewrite/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-cwnd-limit-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/ianswett-cwnd-limit-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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-cwnd-limit-consistency/draft-ietf-quic-transport.html"
+        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-transport.txt"
+        <td><a href="gorry-ecn-rewrite/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-cwnd-limit-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/ianswett-cwnd-limit-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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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="split-initial-close">split-initial-close</a></h2>
-    <table id="branch-split-initial-close">
+    <h2>Preview for branch <a href="pseudocode-indent">pseudocode-indent</a></h2>
+    <table id="branch-pseudocode-indent">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="split-initial-close/draft-ietf-quic-http.html"
+        <td><a href="pseudocode-indent/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="split-initial-close/draft-ietf-quic-http.txt"
+        <td><a href="pseudocode-indent/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/split-initial-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/split-initial-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/pseudocode-indent/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/pseudocode-indent/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="split-initial-close/draft-ietf-quic-invariants.html"
+        <td><a href="pseudocode-indent/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="split-initial-close/draft-ietf-quic-invariants.txt"
+        <td><a href="pseudocode-indent/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/split-initial-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/split-initial-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/pseudocode-indent/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/pseudocode-indent/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="split-initial-close/draft-ietf-quic-qpack.html"
+        <td><a href="pseudocode-indent/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="split-initial-close/draft-ietf-quic-qpack.txt"
+        <td><a href="pseudocode-indent/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/split-initial-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/split-initial-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/pseudocode-indent/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/pseudocode-indent/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="split-initial-close/draft-ietf-quic-recovery.html"
+        <td><a href="pseudocode-indent/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="split-initial-close/draft-ietf-quic-recovery.txt"
+        <td><a href="pseudocode-indent/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/split-initial-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/split-initial-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/pseudocode-indent/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/pseudocode-indent/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="split-initial-close/draft-ietf-quic-tls.html"
+        <td><a href="pseudocode-indent/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="split-initial-close/draft-ietf-quic-tls.txt"
+        <td><a href="pseudocode-indent/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/split-initial-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/split-initial-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/pseudocode-indent/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/pseudocode-indent/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="split-initial-close/draft-ietf-quic-transport.html"
+        <td><a href="pseudocode-indent/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="split-initial-close/draft-ietf-quic-transport.txt"
+        <td><a href="pseudocode-indent/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/split-initial-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/split-initial-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/pseudocode-indent/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/pseudocode-indent/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-three-pto">ianswett-three-pto</a></h2>
-    <table id="branch-ianswett-three-pto">
+    <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/fields-again">qpack/fields-again</a></h2>
+    <table id="branch-qpack/fields-again">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-three-pto/draft-ietf-quic-http.html"
+        <td><a href="qpack/fields-again/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-three-pto/draft-ietf-quic-http.txt"
+        <td><a href="qpack/fields-again/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-three-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-three-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/qpack/fields-again/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/fields-again/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-three-pto/draft-ietf-quic-invariants.html"
+        <td><a href="qpack/fields-again/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-three-pto/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack/fields-again/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-three-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-three-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/qpack/fields-again/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/fields-again/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-three-pto/draft-ietf-quic-qpack.html"
+        <td><a href="qpack/fields-again/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-three-pto/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack/fields-again/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-three-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-three-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/qpack/fields-again/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/fields-again/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-three-pto/draft-ietf-quic-recovery.html"
+        <td><a href="qpack/fields-again/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-three-pto/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack/fields-again/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-three-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-three-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/qpack/fields-again/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/fields-again/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-three-pto/draft-ietf-quic-tls.html"
+        <td><a href="qpack/fields-again/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-three-pto/draft-ietf-quic-tls.txt"
+        <td><a href="qpack/fields-again/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-three-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-three-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/qpack/fields-again/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/fields-again/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-three-pto/draft-ietf-quic-transport.html"
+        <td><a href="qpack/fields-again/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-three-pto/draft-ietf-quic-transport.txt"
+        <td><a href="qpack/fields-again/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-three-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-three-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/qpack/fields-again/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/fields-again/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="hex-d">hex-d</a></h2>
-    <table id="branch-hex-d">
+    <h2>Preview for branch <a href="qpack/new_layout">qpack/new_layout</a></h2>
+    <table id="branch-qpack/new_layout">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="hex-d/draft-ietf-quic-http.html"
+        <td><a href="qpack/new_layout/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="hex-d/draft-ietf-quic-http.txt"
+        <td><a href="qpack/new_layout/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/hex-d/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/hex-d/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/new_layout/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/new_layout/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="hex-d/draft-ietf-quic-invariants.html"
+        <td><a href="qpack/new_layout/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="hex-d/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack/new_layout/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/hex-d/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/hex-d/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/new_layout/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/new_layout/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="hex-d/draft-ietf-quic-qpack.html"
+        <td><a href="qpack/new_layout/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="hex-d/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack/new_layout/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/hex-d/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/hex-d/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/new_layout/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/new_layout/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="hex-d/draft-ietf-quic-recovery.html"
+        <td><a href="qpack/new_layout/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="hex-d/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack/new_layout/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/hex-d/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/hex-d/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/new_layout/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/new_layout/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="hex-d/draft-ietf-quic-tls.html"
+        <td><a href="qpack/new_layout/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="hex-d/draft-ietf-quic-tls.txt"
+        <td><a href="qpack/new_layout/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/hex-d/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/hex-d/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/new_layout/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/new_layout/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="hex-d/draft-ietf-quic-transport.html"
+        <td><a href="qpack/new_layout/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="hex-d/draft-ietf-quic-transport.txt"
+        <td><a href="qpack/new_layout/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/hex-d/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/hex-d/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/new_layout/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/new_layout/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="no-retry-after-retry">no-retry-after-retry</a></h2>
-    <table id="branch-no-retry-after-retry">
+    <h2>Preview for branch <a href="qpack/no-blocked-state">qpack/no-blocked-state</a></h2>
+    <table id="branch-qpack/no-blocked-state">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="no-retry-after-retry/draft-ietf-quic-http.html"
+        <td><a href="qpack/no-blocked-state/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="no-retry-after-retry/draft-ietf-quic-http.txt"
+        <td><a href="qpack/no-blocked-state/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/no-retry-after-retry/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/no-retry-after-retry/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/no-blocked-state/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/no-blocked-state/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="no-retry-after-retry/draft-ietf-quic-invariants.html"
+        <td><a href="qpack/no-blocked-state/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="no-retry-after-retry/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack/no-blocked-state/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/no-retry-after-retry/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/no-retry-after-retry/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/no-blocked-state/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/no-blocked-state/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="no-retry-after-retry/draft-ietf-quic-qpack.html"
+        <td><a href="qpack/no-blocked-state/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="no-retry-after-retry/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack/no-blocked-state/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/no-retry-after-retry/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/no-retry-after-retry/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/no-blocked-state/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/no-blocked-state/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="no-retry-after-retry/draft-ietf-quic-recovery.html"
+        <td><a href="qpack/no-blocked-state/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="no-retry-after-retry/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack/no-blocked-state/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/no-retry-after-retry/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/no-retry-after-retry/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/no-blocked-state/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/no-blocked-state/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="no-retry-after-retry/draft-ietf-quic-tls.html"
+        <td><a href="qpack/no-blocked-state/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="no-retry-after-retry/draft-ietf-quic-tls.txt"
+        <td><a href="qpack/no-blocked-state/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/no-retry-after-retry/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/no-retry-after-retry/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/no-blocked-state/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/no-blocked-state/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="no-retry-after-retry/draft-ietf-quic-transport.html"
+        <td><a href="qpack/no-blocked-state/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="no-retry-after-retry/draft-ietf-quic-transport.txt"
+        <td><a href="qpack/no-blocked-state/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/no-retry-after-retry/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/no-retry-after-retry/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/no-blocked-state/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/no-blocked-state/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="ecn-any-time">ecn-any-time</a></h2>
-    <table id="branch-ecn-any-time">
+    <h2>Preview for branch <a href="qpack/mbishop_wglc">qpack/mbishop_wglc</a></h2>
+    <table id="branch-qpack/mbishop_wglc">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ecn-any-time/draft-ietf-quic-http.html"
+        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ecn-any-time/draft-ietf-quic-http.txt"
+        <td><a href="qpack/mbishop_wglc/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/ecn-any-time/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/ecn-any-time/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/mbishop_wglc/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/mbishop_wglc/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="ecn-any-time/draft-ietf-quic-invariants.html"
+        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ecn-any-time/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack/mbishop_wglc/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/ecn-any-time/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/ecn-any-time/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/mbishop_wglc/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/mbishop_wglc/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="ecn-any-time/draft-ietf-quic-qpack.html"
+        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ecn-any-time/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack/mbishop_wglc/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/ecn-any-time/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/ecn-any-time/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/mbishop_wglc/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/mbishop_wglc/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="ecn-any-time/draft-ietf-quic-recovery.html"
+        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ecn-any-time/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack/mbishop_wglc/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/ecn-any-time/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/ecn-any-time/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/mbishop_wglc/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/mbishop_wglc/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="ecn-any-time/draft-ietf-quic-tls.html"
+        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ecn-any-time/draft-ietf-quic-tls.txt"
+        <td><a href="qpack/mbishop_wglc/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/ecn-any-time/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/ecn-any-time/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/mbishop_wglc/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/mbishop_wglc/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="ecn-any-time/draft-ietf-quic-transport.html"
+        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ecn-any-time/draft-ietf-quic-transport.txt"
+        <td><a href="qpack/mbishop_wglc/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/ecn-any-time/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/ecn-any-time/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/mbishop_wglc/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/mbishop_wglc/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="too-small-no-vn">too-small-no-vn</a></h2>
-    <table id="branch-too-small-no-vn">
+    <h2>Preview for branch <a href="ianswett-iw-decrease">ianswett-iw-decrease</a></h2>
+    <table id="branch-ianswett-iw-decrease">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="too-small-no-vn/draft-ietf-quic-http.html"
+        <td><a href="ianswett-iw-decrease/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="too-small-no-vn/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-iw-decrease/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/too-small-no-vn/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/too-small-no-vn/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-iw-decrease/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-iw-decrease/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="too-small-no-vn/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-iw-decrease/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="too-small-no-vn/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-iw-decrease/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/too-small-no-vn/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/too-small-no-vn/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-iw-decrease/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-iw-decrease/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="too-small-no-vn/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-iw-decrease/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="too-small-no-vn/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-iw-decrease/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/too-small-no-vn/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/too-small-no-vn/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-iw-decrease/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-iw-decrease/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="too-small-no-vn/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-iw-decrease/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="too-small-no-vn/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-iw-decrease/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/too-small-no-vn/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/too-small-no-vn/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-iw-decrease/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-iw-decrease/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="too-small-no-vn/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-iw-decrease/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="too-small-no-vn/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-iw-decrease/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/too-small-no-vn/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/too-small-no-vn/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-iw-decrease/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-iw-decrease/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="too-small-no-vn/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-iw-decrease/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="too-small-no-vn/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-iw-decrease/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/too-small-no-vn/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/too-small-no-vn/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-iw-decrease/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-iw-decrease/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="no-pc-pseudocode">no-pc-pseudocode</a></h2>
-    <table id="branch-no-pc-pseudocode">
+    <h2>Preview for branch <a href="no-retry-after-retry">no-retry-after-retry</a></h2>
+    <table id="branch-no-retry-after-retry">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="no-pc-pseudocode/draft-ietf-quic-http.html"
+        <td><a href="no-retry-after-retry/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="no-pc-pseudocode/draft-ietf-quic-http.txt"
+        <td><a href="no-retry-after-retry/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/no-pc-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/no-pc-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/no-retry-after-retry/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/no-retry-after-retry/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="no-pc-pseudocode/draft-ietf-quic-invariants.html"
+        <td><a href="no-retry-after-retry/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="no-pc-pseudocode/draft-ietf-quic-invariants.txt"
+        <td><a href="no-retry-after-retry/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/no-pc-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/no-pc-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/no-retry-after-retry/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/no-retry-after-retry/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="no-pc-pseudocode/draft-ietf-quic-qpack.html"
+        <td><a href="no-retry-after-retry/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="no-pc-pseudocode/draft-ietf-quic-qpack.txt"
+        <td><a href="no-retry-after-retry/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/no-pc-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/no-pc-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/no-retry-after-retry/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/no-retry-after-retry/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="no-pc-pseudocode/draft-ietf-quic-recovery.html"
+        <td><a href="no-retry-after-retry/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="no-pc-pseudocode/draft-ietf-quic-recovery.txt"
+        <td><a href="no-retry-after-retry/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/no-pc-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/no-pc-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/no-retry-after-retry/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/no-retry-after-retry/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="no-pc-pseudocode/draft-ietf-quic-tls.html"
+        <td><a href="no-retry-after-retry/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="no-pc-pseudocode/draft-ietf-quic-tls.txt"
+        <td><a href="no-retry-after-retry/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/no-pc-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/no-pc-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/no-retry-after-retry/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/no-retry-after-retry/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="no-pc-pseudocode/draft-ietf-quic-transport.html"
+        <td><a href="no-retry-after-retry/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="no-pc-pseudocode/draft-ietf-quic-transport.txt"
+        <td><a href="no-retry-after-retry/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/no-pc-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/no-pc-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/no-retry-after-retry/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/no-retry-after-retry/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="deconflict-tls-errors">deconflict-tls-errors</a></h2>
-    <table id="branch-deconflict-tls-errors">
+    <h2>Preview for branch <a href="define-ss-ca">define-ss-ca</a></h2>
+    <table id="branch-define-ss-ca">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="deconflict-tls-errors/draft-ietf-quic-http.html"
+        <td><a href="define-ss-ca/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="deconflict-tls-errors/draft-ietf-quic-http.txt"
+        <td><a href="define-ss-ca/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/deconflict-tls-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/deconflict-tls-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/define-ss-ca/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/define-ss-ca/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="deconflict-tls-errors/draft-ietf-quic-invariants.html"
+        <td><a href="define-ss-ca/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="deconflict-tls-errors/draft-ietf-quic-invariants.txt"
+        <td><a href="define-ss-ca/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/deconflict-tls-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/deconflict-tls-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/define-ss-ca/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/define-ss-ca/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="deconflict-tls-errors/draft-ietf-quic-qpack.html"
+        <td><a href="define-ss-ca/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="deconflict-tls-errors/draft-ietf-quic-qpack.txt"
+        <td><a href="define-ss-ca/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/deconflict-tls-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/deconflict-tls-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/define-ss-ca/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/define-ss-ca/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="deconflict-tls-errors/draft-ietf-quic-recovery.html"
+        <td><a href="define-ss-ca/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="deconflict-tls-errors/draft-ietf-quic-recovery.txt"
+        <td><a href="define-ss-ca/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/deconflict-tls-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/deconflict-tls-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/define-ss-ca/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/define-ss-ca/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="deconflict-tls-errors/draft-ietf-quic-tls.html"
+        <td><a href="define-ss-ca/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="deconflict-tls-errors/draft-ietf-quic-tls.txt"
+        <td><a href="define-ss-ca/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/deconflict-tls-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/deconflict-tls-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/define-ss-ca/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/define-ss-ca/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="deconflict-tls-errors/draft-ietf-quic-transport.html"
+        <td><a href="define-ss-ca/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="deconflict-tls-errors/draft-ietf-quic-transport.txt"
+        <td><a href="define-ss-ca/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/deconflict-tls-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/deconflict-tls-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/define-ss-ca/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/define-ss-ca/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="add-scid-tls">add-scid-tls</a></h2>
-    <table id="branch-add-scid-tls">
+    <h2>Preview for branch <a href="cc-fsm">cc-fsm</a></h2>
+    <table id="branch-cc-fsm">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="add-scid-tls/draft-ietf-quic-http.html"
+        <td><a href="cc-fsm/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="add-scid-tls/draft-ietf-quic-http.txt"
+        <td><a href="cc-fsm/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/add-scid-tls/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/add-scid-tls/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/cc-fsm/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/cc-fsm/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="add-scid-tls/draft-ietf-quic-invariants.html"
+        <td><a href="cc-fsm/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="add-scid-tls/draft-ietf-quic-invariants.txt"
+        <td><a href="cc-fsm/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/add-scid-tls/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/add-scid-tls/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/cc-fsm/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/cc-fsm/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="add-scid-tls/draft-ietf-quic-qpack.html"
+        <td><a href="cc-fsm/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="add-scid-tls/draft-ietf-quic-qpack.txt"
+        <td><a href="cc-fsm/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/add-scid-tls/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/add-scid-tls/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/cc-fsm/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/cc-fsm/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="add-scid-tls/draft-ietf-quic-recovery.html"
+        <td><a href="cc-fsm/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="add-scid-tls/draft-ietf-quic-recovery.txt"
+        <td><a href="cc-fsm/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/add-scid-tls/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/add-scid-tls/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/cc-fsm/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/cc-fsm/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="add-scid-tls/draft-ietf-quic-tls.html"
+        <td><a href="cc-fsm/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="add-scid-tls/draft-ietf-quic-tls.txt"
+        <td><a href="cc-fsm/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/add-scid-tls/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/add-scid-tls/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/cc-fsm/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/cc-fsm/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="add-scid-tls/draft-ietf-quic-transport.html"
+        <td><a href="cc-fsm/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="add-scid-tls/draft-ietf-quic-transport.txt"
+        <td><a href="cc-fsm/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/add-scid-tls/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/add-scid-tls/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/cc-fsm/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/cc-fsm/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="define-ss-ca">define-ss-ca</a></h2>
-    <table id="branch-define-ss-ca">
+    <h2>Preview for branch <a href="recovery-confirmed">recovery-confirmed</a></h2>
+    <table id="branch-recovery-confirmed">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="define-ss-ca/draft-ietf-quic-http.html"
+        <td><a href="recovery-confirmed/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="define-ss-ca/draft-ietf-quic-http.txt"
+        <td><a href="recovery-confirmed/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/define-ss-ca/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/define-ss-ca/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-confirmed/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-confirmed/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="define-ss-ca/draft-ietf-quic-invariants.html"
+        <td><a href="recovery-confirmed/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="define-ss-ca/draft-ietf-quic-invariants.txt"
+        <td><a href="recovery-confirmed/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/define-ss-ca/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/define-ss-ca/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-confirmed/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-confirmed/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="define-ss-ca/draft-ietf-quic-qpack.html"
+        <td><a href="recovery-confirmed/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="define-ss-ca/draft-ietf-quic-qpack.txt"
+        <td><a href="recovery-confirmed/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/define-ss-ca/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/define-ss-ca/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-confirmed/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-confirmed/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="define-ss-ca/draft-ietf-quic-recovery.html"
+        <td><a href="recovery-confirmed/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="define-ss-ca/draft-ietf-quic-recovery.txt"
+        <td><a href="recovery-confirmed/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/define-ss-ca/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/define-ss-ca/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-confirmed/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-confirmed/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="define-ss-ca/draft-ietf-quic-tls.html"
+        <td><a href="recovery-confirmed/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="define-ss-ca/draft-ietf-quic-tls.txt"
+        <td><a href="recovery-confirmed/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/define-ss-ca/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/define-ss-ca/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-confirmed/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-confirmed/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="define-ss-ca/draft-ietf-quic-transport.html"
+        <td><a href="recovery-confirmed/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="define-ss-ca/draft-ietf-quic-transport.txt"
+        <td><a href="recovery-confirmed/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/define-ss-ca/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/define-ss-ca/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-confirmed/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-confirmed/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="gorry-ecn-rewrite">gorry-ecn-rewrite</a></h2>
-    <table id="branch-gorry-ecn-rewrite">
+    <h2>Preview for branch <a href="ianswett-path-validation">ianswett-path-validation</a></h2>
+    <table id="branch-ianswett-path-validation">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-http.html"
+        <td><a href="ianswett-path-validation/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-path-validation/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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-path-validation/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-path-validation/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="gorry-ecn-rewrite/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-path-validation/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-path-validation/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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-path-validation/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-path-validation/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="gorry-ecn-rewrite/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-path-validation/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-path-validation/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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-path-validation/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-path-validation/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="gorry-ecn-rewrite/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-path-validation/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-path-validation/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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-path-validation/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-path-validation/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="gorry-ecn-rewrite/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-path-validation/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-path-validation/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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-path-validation/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-path-validation/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="gorry-ecn-rewrite/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-path-validation/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="gorry-ecn-rewrite/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-path-validation/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/gorry-ecn-rewrite/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/gorry-ecn-rewrite/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-path-validation/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-path-validation/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-31">samples-31</a></h2>
-    <table id="branch-samples-31">
+    <h2>Preview for branch <a href="add-scid-tls">add-scid-tls</a></h2>
+    <table id="branch-add-scid-tls">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="samples-31/draft-ietf-quic-http.html"
+        <td><a href="add-scid-tls/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="samples-31/draft-ietf-quic-http.txt"
+        <td><a href="add-scid-tls/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-31/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-31/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/add-scid-tls/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/add-scid-tls/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-31/draft-ietf-quic-invariants.html"
+        <td><a href="add-scid-tls/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="samples-31/draft-ietf-quic-invariants.txt"
+        <td><a href="add-scid-tls/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-31/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-31/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/add-scid-tls/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/add-scid-tls/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-31/draft-ietf-quic-qpack.html"
+        <td><a href="add-scid-tls/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="samples-31/draft-ietf-quic-qpack.txt"
+        <td><a href="add-scid-tls/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-31/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-31/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/add-scid-tls/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/add-scid-tls/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-31/draft-ietf-quic-recovery.html"
+        <td><a href="add-scid-tls/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="samples-31/draft-ietf-quic-recovery.txt"
+        <td><a href="add-scid-tls/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-31/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-31/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/add-scid-tls/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/add-scid-tls/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-31/draft-ietf-quic-tls.html"
+        <td><a href="add-scid-tls/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="samples-31/draft-ietf-quic-tls.txt"
+        <td><a href="add-scid-tls/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-31/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-31/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/add-scid-tls/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/add-scid-tls/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-31/draft-ietf-quic-transport.html"
+        <td><a href="add-scid-tls/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="samples-31/draft-ietf-quic-transport.txt"
+        <td><a href="add-scid-tls/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-31/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-31/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/add-scid-tls/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/add-scid-tls/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-confirmed">recovery-confirmed</a></h2>
-    <table id="branch-recovery-confirmed">
-      <tr>
-        <th>draft-ietf-quic-http</th>
-        <td><a href="recovery-confirmed/draft-ietf-quic-http.html"
-           class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="recovery-confirmed/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-confirmed/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-confirmed/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-confirmed/draft-ietf-quic-invariants.html"
-           class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="recovery-confirmed/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-confirmed/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-confirmed/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-confirmed/draft-ietf-quic-qpack.html"
-           class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="recovery-confirmed/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-confirmed/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-confirmed/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-confirmed/draft-ietf-quic-recovery.html"
-           class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="recovery-confirmed/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-confirmed/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-confirmed/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-confirmed/draft-ietf-quic-tls.html"
-           class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="recovery-confirmed/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-confirmed/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-confirmed/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-confirmed/draft-ietf-quic-transport.html"
-           class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="recovery-confirmed/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-confirmed/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-confirmed/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-and-rtt-estimate">ianswett-and-rtt-estimate</a></h2>
-    <table id="branch-ianswett-and-rtt-estimate">
+    <h2>Preview for branch <a href="hex-caps">hex-caps</a></h2>
+    <table id="branch-hex-caps">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-http.html"
+        <td><a href="hex-caps/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-http.txt"
+        <td><a href="hex-caps/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-and-rtt-estimate/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-and-rtt-estimate/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/hex-caps/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/hex-caps/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-and-rtt-estimate/draft-ietf-quic-invariants.html"
+        <td><a href="hex-caps/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-invariants.txt"
+        <td><a href="hex-caps/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-and-rtt-estimate/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-and-rtt-estimate/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/hex-caps/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/hex-caps/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-and-rtt-estimate/draft-ietf-quic-qpack.html"
+        <td><a href="hex-caps/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-qpack.txt"
+        <td><a href="hex-caps/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-and-rtt-estimate/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-and-rtt-estimate/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/hex-caps/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/hex-caps/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-and-rtt-estimate/draft-ietf-quic-recovery.html"
+        <td><a href="hex-caps/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-recovery.txt"
+        <td><a href="hex-caps/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-and-rtt-estimate/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-and-rtt-estimate/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/hex-caps/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/hex-caps/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-and-rtt-estimate/draft-ietf-quic-tls.html"
+        <td><a href="hex-caps/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-tls.txt"
+        <td><a href="hex-caps/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-and-rtt-estimate/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-and-rtt-estimate/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/hex-caps/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/hex-caps/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-and-rtt-estimate/draft-ietf-quic-transport.html"
+        <td><a href="hex-caps/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-transport.txt"
+        <td><a href="hex-caps/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-and-rtt-estimate/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-and-rtt-estimate/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/hex-caps/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/hex-caps/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
@@ -1207,1163 +1157,1163 @@ <h2>Preview for branch <a href="ianswett-must-new-reno">ianswett-must-new-reno</
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="hex-caps">hex-caps</a></h2>
-    <table id="branch-hex-caps">
+    <h2>Preview for branch <a href="ianswett-three-pto">ianswett-three-pto</a></h2>
+    <table id="branch-ianswett-three-pto">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="hex-caps/draft-ietf-quic-http.html"
+        <td><a href="ianswett-three-pto/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="hex-caps/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-three-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/hex-caps/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/hex-caps/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-three-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-three-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="hex-caps/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-three-pto/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="hex-caps/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-three-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/hex-caps/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/hex-caps/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-three-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-three-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="hex-caps/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-three-pto/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="hex-caps/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-three-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/hex-caps/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/hex-caps/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-three-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-three-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="hex-caps/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-three-pto/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="hex-caps/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-three-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/hex-caps/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/hex-caps/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-three-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-three-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="hex-caps/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-three-pto/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="hex-caps/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-three-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/hex-caps/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/hex-caps/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-three-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-three-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="hex-caps/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-three-pto/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="hex-caps/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-three-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/hex-caps/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/hex-caps/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-three-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-three-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="qpack-examples">qpack-examples</a></h2>
-    <table id="branch-qpack-examples">
+    <h2>Preview for branch <a href="ianswett-out-of-order-ack">ianswett-out-of-order-ack</a></h2>
+    <table id="branch-ianswett-out-of-order-ack">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack-examples/draft-ietf-quic-http.html"
+        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack-examples/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-out-of-order-ack/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-examples/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-examples/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-out-of-order-ack/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-out-of-order-ack/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-examples/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack-examples/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-out-of-order-ack/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-examples/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-examples/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-out-of-order-ack/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-out-of-order-ack/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-examples/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack-examples/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-out-of-order-ack/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-examples/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-examples/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-out-of-order-ack/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-out-of-order-ack/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-examples/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack-examples/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-out-of-order-ack/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-examples/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-examples/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-out-of-order-ack/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-out-of-order-ack/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-examples/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack-examples/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-out-of-order-ack/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-examples/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-examples/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-out-of-order-ack/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-out-of-order-ack/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-examples/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack-examples/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-out-of-order-ack/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-examples/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-examples/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-out-of-order-ack/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-out-of-order-ack/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="pc-starts-now">pc-starts-now</a></h2>
-    <table id="branch-pc-starts-now">
+    <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/orders">transport/orders</a></h2>
+    <table id="branch-transport/orders">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="pc-starts-now/draft-ietf-quic-http.html"
+        <td><a href="transport/orders/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="pc-starts-now/draft-ietf-quic-http.txt"
+        <td><a href="transport/orders/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/pc-starts-now/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/pc-starts-now/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/orders/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/orders/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="pc-starts-now/draft-ietf-quic-invariants.html"
+        <td><a href="transport/orders/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="pc-starts-now/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/orders/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/pc-starts-now/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/pc-starts-now/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/orders/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/orders/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="pc-starts-now/draft-ietf-quic-qpack.html"
+        <td><a href="transport/orders/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="pc-starts-now/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/orders/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/pc-starts-now/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/pc-starts-now/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/orders/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/orders/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="pc-starts-now/draft-ietf-quic-recovery.html"
+        <td><a href="transport/orders/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="pc-starts-now/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/orders/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/pc-starts-now/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/pc-starts-now/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/orders/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/orders/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="pc-starts-now/draft-ietf-quic-tls.html"
+        <td><a href="transport/orders/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="pc-starts-now/draft-ietf-quic-tls.txt"
+        <td><a href="transport/orders/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/pc-starts-now/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/pc-starts-now/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/orders/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/orders/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="pc-starts-now/draft-ietf-quic-transport.html"
+        <td><a href="transport/orders/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="pc-starts-now/draft-ietf-quic-transport.txt"
+        <td><a href="transport/orders/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/pc-starts-now/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/pc-starts-now/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/orders/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/orders/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="request-forgery">request-forgery</a></h2>
-    <table id="branch-request-forgery">
+    <h2>Preview for branch <a href="transport/define-violation">transport/define-violation</a></h2>
+    <table id="branch-transport/define-violation">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="request-forgery/draft-ietf-quic-http.html"
+        <td><a href="transport/define-violation/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="request-forgery/draft-ietf-quic-http.txt"
+        <td><a href="transport/define-violation/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/request-forgery/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/request-forgery/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/define-violation/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/define-violation/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="request-forgery/draft-ietf-quic-invariants.html"
+        <td><a href="transport/define-violation/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="request-forgery/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/define-violation/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/request-forgery/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/request-forgery/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/define-violation/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/define-violation/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="request-forgery/draft-ietf-quic-qpack.html"
+        <td><a href="transport/define-violation/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="request-forgery/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/define-violation/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/request-forgery/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/request-forgery/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/define-violation/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/define-violation/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="request-forgery/draft-ietf-quic-recovery.html"
+        <td><a href="transport/define-violation/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="request-forgery/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/define-violation/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/request-forgery/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/request-forgery/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/define-violation/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/define-violation/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="request-forgery/draft-ietf-quic-tls.html"
+        <td><a href="transport/define-violation/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="request-forgery/draft-ietf-quic-tls.txt"
+        <td><a href="transport/define-violation/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/request-forgery/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/request-forgery/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/define-violation/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/define-violation/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="request-forgery/draft-ietf-quic-transport.html"
+        <td><a href="transport/define-violation/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="request-forgery/draft-ietf-quic-transport.txt"
+        <td><a href="transport/define-violation/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/request-forgery/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/request-forgery/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/define-violation/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/define-violation/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="tp-error">tp-error</a></h2>
-    <table id="branch-tp-error">
+    <h2>Preview for branch <a href="transport/should_vn">transport/should_vn</a></h2>
+    <table id="branch-transport/should_vn">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="tp-error/draft-ietf-quic-http.html"
+        <td><a href="transport/should_vn/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="tp-error/draft-ietf-quic-http.txt"
+        <td><a href="transport/should_vn/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/tp-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/tp-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/should_vn/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/should_vn/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="tp-error/draft-ietf-quic-invariants.html"
+        <td><a href="transport/should_vn/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="tp-error/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/should_vn/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/tp-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/tp-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/should_vn/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/should_vn/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="tp-error/draft-ietf-quic-qpack.html"
+        <td><a href="transport/should_vn/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="tp-error/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/should_vn/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/tp-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/tp-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/should_vn/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/should_vn/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="tp-error/draft-ietf-quic-recovery.html"
+        <td><a href="transport/should_vn/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="tp-error/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/should_vn/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/tp-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/tp-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/should_vn/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/should_vn/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="tp-error/draft-ietf-quic-tls.html"
+        <td><a href="transport/should_vn/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="tp-error/draft-ietf-quic-tls.txt"
+        <td><a href="transport/should_vn/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/tp-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/tp-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/should_vn/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/should_vn/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="tp-error/draft-ietf-quic-transport.html"
+        <td><a href="transport/should_vn/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="tp-error/draft-ietf-quic-transport.txt"
+        <td><a href="transport/should_vn/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/tp-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/tp-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/should_vn/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/should_vn/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="path-reponse-path">path-reponse-path</a></h2>
-    <table id="branch-path-reponse-path">
+    <h2>Preview for branch <a href="transport/what-is-absence">transport/what-is-absence</a></h2>
+    <table id="branch-transport/what-is-absence">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="path-reponse-path/draft-ietf-quic-http.html"
+        <td><a href="transport/what-is-absence/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="path-reponse-path/draft-ietf-quic-http.txt"
+        <td><a href="transport/what-is-absence/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/path-reponse-path/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/path-reponse-path/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/what-is-absence/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/what-is-absence/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="path-reponse-path/draft-ietf-quic-invariants.html"
+        <td><a href="transport/what-is-absence/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="path-reponse-path/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/what-is-absence/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/path-reponse-path/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/path-reponse-path/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/what-is-absence/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/what-is-absence/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="path-reponse-path/draft-ietf-quic-qpack.html"
+        <td><a href="transport/what-is-absence/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="path-reponse-path/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/what-is-absence/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/path-reponse-path/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/path-reponse-path/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/what-is-absence/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/what-is-absence/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="path-reponse-path/draft-ietf-quic-recovery.html"
+        <td><a href="transport/what-is-absence/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="path-reponse-path/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/what-is-absence/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/path-reponse-path/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/path-reponse-path/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/what-is-absence/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/what-is-absence/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="path-reponse-path/draft-ietf-quic-tls.html"
+        <td><a href="transport/what-is-absence/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="path-reponse-path/draft-ietf-quic-tls.txt"
+        <td><a href="transport/what-is-absence/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/path-reponse-path/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/path-reponse-path/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/what-is-absence/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/what-is-absence/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="path-reponse-path/draft-ietf-quic-transport.html"
+        <td><a href="transport/what-is-absence/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="path-reponse-path/draft-ietf-quic-transport.txt"
+        <td><a href="transport/what-is-absence/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/path-reponse-path/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/path-reponse-path/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/what-is-absence/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/what-is-absence/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="udp-packets">udp-packets</a></h2>
-    <table id="branch-udp-packets">
+    <h2>Preview for branch <a href="transport/cap-NOT">transport/cap-NOT</a></h2>
+    <table id="branch-transport/cap-NOT">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="udp-packets/draft-ietf-quic-http.html"
+        <td><a href="transport/cap-NOT/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="udp-packets/draft-ietf-quic-http.txt"
+        <td><a href="transport/cap-NOT/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/udp-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/udp-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/transport/cap-NOT/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/cap-NOT/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="udp-packets/draft-ietf-quic-invariants.html"
+        <td><a href="transport/cap-NOT/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="udp-packets/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/cap-NOT/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/udp-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/udp-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/transport/cap-NOT/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/cap-NOT/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="udp-packets/draft-ietf-quic-qpack.html"
+        <td><a href="transport/cap-NOT/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="udp-packets/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/cap-NOT/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/udp-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/udp-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/transport/cap-NOT/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/cap-NOT/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="udp-packets/draft-ietf-quic-recovery.html"
+        <td><a href="transport/cap-NOT/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="udp-packets/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/cap-NOT/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/udp-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/udp-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/transport/cap-NOT/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/cap-NOT/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="udp-packets/draft-ietf-quic-tls.html"
+        <td><a href="transport/cap-NOT/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="udp-packets/draft-ietf-quic-tls.txt"
+        <td><a href="transport/cap-NOT/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/udp-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/udp-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/transport/cap-NOT/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/cap-NOT/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="udp-packets/draft-ietf-quic-transport.html"
+        <td><a href="transport/cap-NOT/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="udp-packets/draft-ietf-quic-transport.txt"
+        <td><a href="transport/cap-NOT/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/udp-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/udp-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/transport/cap-NOT/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/cap-NOT/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="pseudocode-indent">pseudocode-indent</a></h2>
-    <table id="branch-pseudocode-indent">
+    <h2>Preview for branch <a href="request-forgery">request-forgery</a></h2>
+    <table id="branch-request-forgery">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="pseudocode-indent/draft-ietf-quic-http.html"
+        <td><a href="request-forgery/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="pseudocode-indent/draft-ietf-quic-http.txt"
+        <td><a href="request-forgery/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/pseudocode-indent/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/pseudocode-indent/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/request-forgery/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/request-forgery/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="pseudocode-indent/draft-ietf-quic-invariants.html"
+        <td><a href="request-forgery/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="pseudocode-indent/draft-ietf-quic-invariants.txt"
+        <td><a href="request-forgery/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/pseudocode-indent/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/pseudocode-indent/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/request-forgery/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/request-forgery/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="pseudocode-indent/draft-ietf-quic-qpack.html"
+        <td><a href="request-forgery/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="pseudocode-indent/draft-ietf-quic-qpack.txt"
+        <td><a href="request-forgery/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/pseudocode-indent/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/pseudocode-indent/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/request-forgery/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/request-forgery/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="pseudocode-indent/draft-ietf-quic-recovery.html"
+        <td><a href="request-forgery/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="pseudocode-indent/draft-ietf-quic-recovery.txt"
+        <td><a href="request-forgery/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/pseudocode-indent/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/pseudocode-indent/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/request-forgery/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/request-forgery/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="pseudocode-indent/draft-ietf-quic-tls.html"
+        <td><a href="request-forgery/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="pseudocode-indent/draft-ietf-quic-tls.txt"
+        <td><a href="request-forgery/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/pseudocode-indent/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/pseudocode-indent/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/request-forgery/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/request-forgery/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="pseudocode-indent/draft-ietf-quic-transport.html"
+        <td><a href="request-forgery/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="pseudocode-indent/draft-ietf-quic-transport.txt"
+        <td><a href="request-forgery/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/pseudocode-indent/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/pseudocode-indent/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/request-forgery/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/request-forgery/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-gorry">ianswett-gorry</a></h2>
-    <table id="branch-ianswett-gorry">
+    <h2>Preview for branch <a href="qpack-examples">qpack-examples</a></h2>
+    <table id="branch-qpack-examples">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-gorry/draft-ietf-quic-http.html"
+        <td><a href="qpack-examples/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-gorry/draft-ietf-quic-http.txt"
+        <td><a href="qpack-examples/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-gorry/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-gorry/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-examples/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-examples/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-gorry/draft-ietf-quic-invariants.html"
+        <td><a href="qpack-examples/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-gorry/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack-examples/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-gorry/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-gorry/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-examples/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-examples/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-gorry/draft-ietf-quic-qpack.html"
+        <td><a href="qpack-examples/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-gorry/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack-examples/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-gorry/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-gorry/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-examples/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-examples/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-gorry/draft-ietf-quic-recovery.html"
+        <td><a href="qpack-examples/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-gorry/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack-examples/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-gorry/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-gorry/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-examples/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-examples/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-gorry/draft-ietf-quic-tls.html"
+        <td><a href="qpack-examples/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-gorry/draft-ietf-quic-tls.txt"
+        <td><a href="qpack-examples/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-gorry/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-gorry/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-examples/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-examples/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-gorry/draft-ietf-quic-transport.html"
+        <td><a href="qpack-examples/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-gorry/draft-ietf-quic-transport.txt"
+        <td><a href="qpack-examples/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-gorry/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-gorry/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-examples/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-examples/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="cc-fsm">cc-fsm</a></h2>
-    <table id="branch-cc-fsm">
+    <h2>Preview for branch <a href="ianswett-4091">ianswett-4091</a></h2>
+    <table id="branch-ianswett-4091">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="cc-fsm/draft-ietf-quic-http.html"
+        <td><a href="ianswett-4091/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="cc-fsm/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-4091/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/cc-fsm/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/cc-fsm/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-4091/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-4091/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="cc-fsm/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-4091/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="cc-fsm/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-4091/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/cc-fsm/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/cc-fsm/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-4091/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-4091/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="cc-fsm/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-4091/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="cc-fsm/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-4091/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/cc-fsm/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/cc-fsm/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-4091/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-4091/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="cc-fsm/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-4091/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="cc-fsm/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-4091/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/cc-fsm/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/cc-fsm/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-4091/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-4091/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="cc-fsm/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-4091/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="cc-fsm/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-4091/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/cc-fsm/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/cc-fsm/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-4091/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-4091/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="cc-fsm/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-4091/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="cc-fsm/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-4091/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/cc-fsm/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/cc-fsm/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-4091/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-4091/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="clarify-pto">clarify-pto</a></h2>
-    <table id="branch-clarify-pto">
+    <h2>Preview for branch <a href="closing-draining-refactor">closing-draining-refactor</a></h2>
+    <table id="branch-closing-draining-refactor">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="clarify-pto/draft-ietf-quic-http.html"
+        <td><a href="closing-draining-refactor/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="clarify-pto/draft-ietf-quic-http.txt"
+        <td><a href="closing-draining-refactor/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/clarify-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/clarify-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/closing-draining-refactor/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/closing-draining-refactor/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="clarify-pto/draft-ietf-quic-invariants.html"
+        <td><a href="closing-draining-refactor/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="clarify-pto/draft-ietf-quic-invariants.txt"
+        <td><a href="closing-draining-refactor/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/clarify-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/clarify-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/closing-draining-refactor/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/closing-draining-refactor/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="clarify-pto/draft-ietf-quic-qpack.html"
+        <td><a href="closing-draining-refactor/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="clarify-pto/draft-ietf-quic-qpack.txt"
+        <td><a href="closing-draining-refactor/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/clarify-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/clarify-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/closing-draining-refactor/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/closing-draining-refactor/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="clarify-pto/draft-ietf-quic-recovery.html"
+        <td><a href="closing-draining-refactor/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="clarify-pto/draft-ietf-quic-recovery.txt"
+        <td><a href="closing-draining-refactor/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/clarify-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/clarify-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/closing-draining-refactor/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/closing-draining-refactor/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="clarify-pto/draft-ietf-quic-tls.html"
+        <td><a href="closing-draining-refactor/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="clarify-pto/draft-ietf-quic-tls.txt"
+        <td><a href="closing-draining-refactor/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/clarify-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/clarify-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/closing-draining-refactor/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/closing-draining-refactor/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="clarify-pto/draft-ietf-quic-transport.html"
+        <td><a href="closing-draining-refactor/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="clarify-pto/draft-ietf-quic-transport.txt"
+        <td><a href="closing-draining-refactor/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/clarify-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/clarify-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/closing-draining-refactor/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/closing-draining-refactor/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-pscode-fix">qpack-pscode-fix</a></h2>
-    <table id="branch-qpack-pscode-fix">
+    <h2>Preview for branch <a href="changelog-30">changelog-30</a></h2>
+    <table id="branch-changelog-30">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack-pscode-fix/draft-ietf-quic-http.html"
+        <td><a href="changelog-30/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack-pscode-fix/draft-ietf-quic-http.txt"
+        <td><a href="changelog-30/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-pscode-fix/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-pscode-fix/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-30/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-30/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-pscode-fix/draft-ietf-quic-invariants.html"
+        <td><a href="changelog-30/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack-pscode-fix/draft-ietf-quic-invariants.txt"
+        <td><a href="changelog-30/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-pscode-fix/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-pscode-fix/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-30/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-30/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-pscode-fix/draft-ietf-quic-qpack.html"
+        <td><a href="changelog-30/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack-pscode-fix/draft-ietf-quic-qpack.txt"
+        <td><a href="changelog-30/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-pscode-fix/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-pscode-fix/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-30/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-30/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-pscode-fix/draft-ietf-quic-recovery.html"
+        <td><a href="changelog-30/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack-pscode-fix/draft-ietf-quic-recovery.txt"
+        <td><a href="changelog-30/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-pscode-fix/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-pscode-fix/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-30/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-30/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-pscode-fix/draft-ietf-quic-tls.html"
+        <td><a href="changelog-30/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack-pscode-fix/draft-ietf-quic-tls.txt"
+        <td><a href="changelog-30/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-pscode-fix/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-pscode-fix/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-30/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-30/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-pscode-fix/draft-ietf-quic-transport.html"
+        <td><a href="changelog-30/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack-pscode-fix/draft-ietf-quic-transport.txt"
+        <td><a href="changelog-30/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-pscode-fix/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-pscode-fix/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-30/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-30/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="repeat-initial-reprise">repeat-initial-reprise</a></h2>
-    <table id="branch-repeat-initial-reprise">
+    <h2>Preview for branch <a href="samples-31">samples-31</a></h2>
+    <table id="branch-samples-31">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="repeat-initial-reprise/draft-ietf-quic-http.html"
+        <td><a href="samples-31/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="repeat-initial-reprise/draft-ietf-quic-http.txt"
+        <td><a href="samples-31/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/repeat-initial-reprise/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/repeat-initial-reprise/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-31/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-31/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="repeat-initial-reprise/draft-ietf-quic-invariants.html"
+        <td><a href="samples-31/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="repeat-initial-reprise/draft-ietf-quic-invariants.txt"
+        <td><a href="samples-31/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/repeat-initial-reprise/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/repeat-initial-reprise/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-31/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-31/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="repeat-initial-reprise/draft-ietf-quic-qpack.html"
+        <td><a href="samples-31/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="repeat-initial-reprise/draft-ietf-quic-qpack.txt"
+        <td><a href="samples-31/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/repeat-initial-reprise/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/repeat-initial-reprise/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-31/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-31/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="repeat-initial-reprise/draft-ietf-quic-recovery.html"
+        <td><a href="samples-31/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="repeat-initial-reprise/draft-ietf-quic-recovery.txt"
+        <td><a href="samples-31/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/repeat-initial-reprise/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/repeat-initial-reprise/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-31/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-31/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="repeat-initial-reprise/draft-ietf-quic-tls.html"
+        <td><a href="samples-31/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="repeat-initial-reprise/draft-ietf-quic-tls.txt"
+        <td><a href="samples-31/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/repeat-initial-reprise/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/repeat-initial-reprise/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-31/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-31/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="repeat-initial-reprise/draft-ietf-quic-transport.html"
+        <td><a href="samples-31/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="repeat-initial-reprise/draft-ietf-quic-transport.txt"
+        <td><a href="samples-31/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/repeat-initial-reprise/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/repeat-initial-reprise/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-31/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-31/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="not-delay">not-delay</a></h2>
-    <table id="branch-not-delay">
+    <h2>Preview for branch <a href="too-small-no-vn">too-small-no-vn</a></h2>
+    <table id="branch-too-small-no-vn">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="not-delay/draft-ietf-quic-http.html"
+        <td><a href="too-small-no-vn/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="not-delay/draft-ietf-quic-http.txt"
+        <td><a href="too-small-no-vn/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/not-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/not-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/too-small-no-vn/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/too-small-no-vn/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="not-delay/draft-ietf-quic-invariants.html"
+        <td><a href="too-small-no-vn/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="not-delay/draft-ietf-quic-invariants.txt"
+        <td><a href="too-small-no-vn/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/not-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/not-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/too-small-no-vn/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/too-small-no-vn/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="not-delay/draft-ietf-quic-qpack.html"
+        <td><a href="too-small-no-vn/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="not-delay/draft-ietf-quic-qpack.txt"
+        <td><a href="too-small-no-vn/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/not-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/not-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/too-small-no-vn/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/too-small-no-vn/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="not-delay/draft-ietf-quic-recovery.html"
+        <td><a href="too-small-no-vn/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="not-delay/draft-ietf-quic-recovery.txt"
+        <td><a href="too-small-no-vn/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/not-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/not-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/too-small-no-vn/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/too-small-no-vn/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="not-delay/draft-ietf-quic-tls.html"
+        <td><a href="too-small-no-vn/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="not-delay/draft-ietf-quic-tls.txt"
+        <td><a href="too-small-no-vn/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/not-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/not-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/too-small-no-vn/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/too-small-no-vn/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="not-delay/draft-ietf-quic-transport.html"
+        <td><a href="too-small-no-vn/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="not-delay/draft-ietf-quic-transport.txt"
+        <td><a href="too-small-no-vn/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/not-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/not-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="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 *">
+        <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/too-small-no-vn/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/too-small-no-vn/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/no-blocked-state">qpack/no-blocked-state</a></h2>
-    <table id="branch-qpack/no-blocked-state">
+    <h2>Preview for branch <a href="ecn-any-time">ecn-any-time</a></h2>
+    <table id="branch-ecn-any-time">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack/no-blocked-state/draft-ietf-quic-http.html"
+        <td><a href="ecn-any-time/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack/no-blocked-state/draft-ietf-quic-http.txt"
+        <td><a href="ecn-any-time/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/no-blocked-state/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/no-blocked-state/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/ecn-any-time/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/ecn-any-time/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/no-blocked-state/draft-ietf-quic-invariants.html"
+        <td><a href="ecn-any-time/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack/no-blocked-state/draft-ietf-quic-invariants.txt"
+        <td><a href="ecn-any-time/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/no-blocked-state/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/no-blocked-state/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/ecn-any-time/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/ecn-any-time/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/no-blocked-state/draft-ietf-quic-qpack.html"
+        <td><a href="ecn-any-time/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack/no-blocked-state/draft-ietf-quic-qpack.txt"
+        <td><a href="ecn-any-time/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/no-blocked-state/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/no-blocked-state/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/ecn-any-time/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/ecn-any-time/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/no-blocked-state/draft-ietf-quic-recovery.html"
+        <td><a href="ecn-any-time/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack/no-blocked-state/draft-ietf-quic-recovery.txt"
+        <td><a href="ecn-any-time/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/no-blocked-state/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/no-blocked-state/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/ecn-any-time/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/ecn-any-time/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/no-blocked-state/draft-ietf-quic-tls.html"
+        <td><a href="ecn-any-time/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack/no-blocked-state/draft-ietf-quic-tls.txt"
+        <td><a href="ecn-any-time/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/no-blocked-state/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/no-blocked-state/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/ecn-any-time/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/ecn-any-time/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/no-blocked-state/draft-ietf-quic-transport.html"
+        <td><a href="ecn-any-time/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack/no-blocked-state/draft-ietf-quic-transport.txt"
+        <td><a href="ecn-any-time/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/no-blocked-state/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/no-blocked-state/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/ecn-any-time/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/ecn-any-time/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/mbishop_wglc">qpack/mbishop_wglc</a></h2>
-    <table id="branch-qpack/mbishop_wglc">
+    <h2>Preview for branch <a href="qpack-pscode-fix">qpack-pscode-fix</a></h2>
+    <table id="branch-qpack-pscode-fix">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-http.html"
+        <td><a href="qpack-pscode-fix/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-http.txt"
+        <td><a href="qpack-pscode-fix/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/mbishop_wglc/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/mbishop_wglc/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-pscode-fix/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-pscode-fix/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/mbishop_wglc/draft-ietf-quic-invariants.html"
+        <td><a href="qpack-pscode-fix/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack-pscode-fix/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/mbishop_wglc/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/mbishop_wglc/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-pscode-fix/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-pscode-fix/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/mbishop_wglc/draft-ietf-quic-qpack.html"
+        <td><a href="qpack-pscode-fix/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack-pscode-fix/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/mbishop_wglc/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/mbishop_wglc/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-pscode-fix/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-pscode-fix/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/mbishop_wglc/draft-ietf-quic-recovery.html"
+        <td><a href="qpack-pscode-fix/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack-pscode-fix/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/mbishop_wglc/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/mbishop_wglc/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-pscode-fix/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-pscode-fix/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/mbishop_wglc/draft-ietf-quic-tls.html"
+        <td><a href="qpack-pscode-fix/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-tls.txt"
+        <td><a href="qpack-pscode-fix/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/mbishop_wglc/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/mbishop_wglc/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-pscode-fix/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-pscode-fix/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/mbishop_wglc/draft-ietf-quic-transport.html"
+        <td><a href="qpack-pscode-fix/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack/mbishop_wglc/draft-ietf-quic-transport.txt"
+        <td><a href="qpack-pscode-fix/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/mbishop_wglc/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/mbishop_wglc/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-pscode-fix/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-pscode-fix/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/new_layout">qpack/new_layout</a></h2>
-    <table id="branch-qpack/new_layout">
+    <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/push_flow">http/push_flow</a></h2>
+    <table id="branch-http/push_flow">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack/new_layout/draft-ietf-quic-http.html"
+        <td><a href="http/push_flow/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack/new_layout/draft-ietf-quic-http.txt"
+        <td><a href="http/push_flow/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/new_layout/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/new_layout/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_flow/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_flow/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/new_layout/draft-ietf-quic-invariants.html"
+        <td><a href="http/push_flow/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack/new_layout/draft-ietf-quic-invariants.txt"
+        <td><a href="http/push_flow/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/new_layout/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/new_layout/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_flow/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_flow/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/new_layout/draft-ietf-quic-qpack.html"
+        <td><a href="http/push_flow/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack/new_layout/draft-ietf-quic-qpack.txt"
+        <td><a href="http/push_flow/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/new_layout/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/new_layout/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_flow/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_flow/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/new_layout/draft-ietf-quic-recovery.html"
+        <td><a href="http/push_flow/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack/new_layout/draft-ietf-quic-recovery.txt"
+        <td><a href="http/push_flow/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/new_layout/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/new_layout/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_flow/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_flow/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/new_layout/draft-ietf-quic-tls.html"
+        <td><a href="http/push_flow/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack/new_layout/draft-ietf-quic-tls.txt"
+        <td><a href="http/push_flow/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/new_layout/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/new_layout/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_flow/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_flow/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/new_layout/draft-ietf-quic-transport.html"
+        <td><a href="http/push_flow/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack/new_layout/draft-ietf-quic-transport.txt"
+        <td><a href="http/push_flow/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/new_layout/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/new_layout/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_flow/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_flow/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/fields-again">qpack/fields-again</a></h2>
-    <table id="branch-qpack/fields-again">
+    <h2>Preview for branch <a href="http/frame_errors">http/frame_errors</a></h2>
+    <table id="branch-http/frame_errors">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack/fields-again/draft-ietf-quic-http.html"
+        <td><a href="http/frame_errors/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack/fields-again/draft-ietf-quic-http.txt"
+        <td><a href="http/frame_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/qpack/fields-again/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/fields-again/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/frame_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/frame_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="qpack/fields-again/draft-ietf-quic-invariants.html"
+        <td><a href="http/frame_errors/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack/fields-again/draft-ietf-quic-invariants.txt"
+        <td><a href="http/frame_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/qpack/fields-again/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/fields-again/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/frame_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/frame_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="qpack/fields-again/draft-ietf-quic-qpack.html"
+        <td><a href="http/frame_errors/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack/fields-again/draft-ietf-quic-qpack.txt"
+        <td><a href="http/frame_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/qpack/fields-again/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/fields-again/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/frame_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/frame_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="qpack/fields-again/draft-ietf-quic-recovery.html"
+        <td><a href="http/frame_errors/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack/fields-again/draft-ietf-quic-recovery.txt"
+        <td><a href="http/frame_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/qpack/fields-again/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/fields-again/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/frame_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/frame_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="qpack/fields-again/draft-ietf-quic-tls.html"
+        <td><a href="http/frame_errors/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack/fields-again/draft-ietf-quic-tls.txt"
+        <td><a href="http/frame_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/qpack/fields-again/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/fields-again/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/frame_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/frame_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="qpack/fields-again/draft-ietf-quic-transport.html"
+        <td><a href="http/frame_errors/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack/fields-again/draft-ietf-quic-transport.txt"
+        <td><a href="http/frame_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/qpack/fields-again/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/fields-again/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/http/frame_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/frame_errors/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
@@ -2556,66 +2506,66 @@ <h2>Preview for branch <a href="http/3815">http/3815</a></h2>
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/frame_errors">http/frame_errors</a></h2>
-    <table id="branch-http/frame_errors">
+    <h2>Preview for branch <a href="http/h2_settings_reserved">http/h2_settings_reserved</a></h2>
+    <table id="branch-http/h2_settings_reserved">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/frame_errors/draft-ietf-quic-http.html"
+        <td><a href="http/h2_settings_reserved/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/frame_errors/draft-ietf-quic-http.txt"
+        <td><a href="http/h2_settings_reserved/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/frame_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/frame_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/h2_settings_reserved/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/h2_settings_reserved/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/frame_errors/draft-ietf-quic-invariants.html"
+        <td><a href="http/h2_settings_reserved/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/frame_errors/draft-ietf-quic-invariants.txt"
+        <td><a href="http/h2_settings_reserved/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/frame_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/frame_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/h2_settings_reserved/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/h2_settings_reserved/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/frame_errors/draft-ietf-quic-qpack.html"
+        <td><a href="http/h2_settings_reserved/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/frame_errors/draft-ietf-quic-qpack.txt"
+        <td><a href="http/h2_settings_reserved/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/frame_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/frame_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/h2_settings_reserved/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/h2_settings_reserved/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/frame_errors/draft-ietf-quic-recovery.html"
+        <td><a href="http/h2_settings_reserved/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/frame_errors/draft-ietf-quic-recovery.txt"
+        <td><a href="http/h2_settings_reserved/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/frame_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/frame_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/h2_settings_reserved/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/h2_settings_reserved/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/frame_errors/draft-ietf-quic-tls.html"
+        <td><a href="http/h2_settings_reserved/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/frame_errors/draft-ietf-quic-tls.txt"
+        <td><a href="http/h2_settings_reserved/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/frame_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/frame_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/h2_settings_reserved/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/h2_settings_reserved/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/frame_errors/draft-ietf-quic-transport.html"
+        <td><a href="http/h2_settings_reserved/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/frame_errors/draft-ietf-quic-transport.txt"
+        <td><a href="http/h2_settings_reserved/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/frame_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/frame_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/h2_settings_reserved/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/h2_settings_reserved/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
@@ -2808,835 +2758,822 @@ <h2>Preview for branch <a href="http/mbishop_wglc">http/mbishop_wglc</a></h2>
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/push_flow">http/push_flow</a></h2>
-    <table id="branch-http/push_flow">
+    <h2>Preview for branch <a href="clarify-pto">clarify-pto</a></h2>
+    <table id="branch-clarify-pto">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/push_flow/draft-ietf-quic-http.html"
+        <td><a href="clarify-pto/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/push_flow/draft-ietf-quic-http.txt"
+        <td><a href="clarify-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/push_flow/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_flow/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/clarify-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/clarify-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/push_flow/draft-ietf-quic-invariants.html"
+        <td><a href="clarify-pto/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/push_flow/draft-ietf-quic-invariants.txt"
+        <td><a href="clarify-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/push_flow/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_flow/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/clarify-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/clarify-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/push_flow/draft-ietf-quic-qpack.html"
+        <td><a href="clarify-pto/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/push_flow/draft-ietf-quic-qpack.txt"
+        <td><a href="clarify-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/push_flow/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_flow/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/clarify-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/clarify-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/push_flow/draft-ietf-quic-recovery.html"
+        <td><a href="clarify-pto/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/push_flow/draft-ietf-quic-recovery.txt"
+        <td><a href="clarify-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/push_flow/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_flow/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/clarify-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/clarify-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/push_flow/draft-ietf-quic-tls.html"
+        <td><a href="clarify-pto/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/push_flow/draft-ietf-quic-tls.txt"
+        <td><a href="clarify-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/push_flow/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_flow/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/clarify-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/clarify-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/push_flow/draft-ietf-quic-transport.html"
+        <td><a href="clarify-pto/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/push_flow/draft-ietf-quic-transport.txt"
+        <td><a href="clarify-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/push_flow/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_flow/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/clarify-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/clarify-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/h2_settings_reserved">http/h2_settings_reserved</a></h2>
-    <table id="branch-http/h2_settings_reserved">
+    <h2>Preview for branch <a href="ianswett-and-rtt-estimate">ianswett-and-rtt-estimate</a></h2>
+    <table id="branch-ianswett-and-rtt-estimate">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/h2_settings_reserved/draft-ietf-quic-http.html"
+        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/h2_settings_reserved/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-and-rtt-estimate/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/h2_settings_reserved/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/h2_settings_reserved/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-and-rtt-estimate/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-and-rtt-estimate/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/h2_settings_reserved/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/h2_settings_reserved/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-and-rtt-estimate/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/h2_settings_reserved/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/h2_settings_reserved/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-and-rtt-estimate/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-and-rtt-estimate/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/h2_settings_reserved/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/h2_settings_reserved/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-and-rtt-estimate/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/h2_settings_reserved/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/h2_settings_reserved/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-and-rtt-estimate/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-and-rtt-estimate/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/h2_settings_reserved/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/h2_settings_reserved/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-and-rtt-estimate/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/h2_settings_reserved/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/h2_settings_reserved/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-and-rtt-estimate/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-and-rtt-estimate/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/h2_settings_reserved/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/h2_settings_reserved/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-and-rtt-estimate/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/h2_settings_reserved/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/h2_settings_reserved/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-and-rtt-estimate/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-and-rtt-estimate/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/h2_settings_reserved/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-and-rtt-estimate/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/h2_settings_reserved/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-and-rtt-estimate/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/h2_settings_reserved/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/h2_settings_reserved/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-and-rtt-estimate/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-and-rtt-estimate/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="closing-draining-refactor">closing-draining-refactor</a></h2>
-    <table id="branch-closing-draining-refactor">
+    <h2>Preview for branch <a href="udp-packets">udp-packets</a></h2>
+    <table id="branch-udp-packets">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="closing-draining-refactor/draft-ietf-quic-http.html"
+        <td><a href="udp-packets/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="closing-draining-refactor/draft-ietf-quic-http.txt"
+        <td><a href="udp-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/closing-draining-refactor/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/closing-draining-refactor/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/udp-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/udp-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="closing-draining-refactor/draft-ietf-quic-invariants.html"
+        <td><a href="udp-packets/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="closing-draining-refactor/draft-ietf-quic-invariants.txt"
+        <td><a href="udp-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/closing-draining-refactor/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/closing-draining-refactor/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/udp-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/udp-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="closing-draining-refactor/draft-ietf-quic-qpack.html"
+        <td><a href="udp-packets/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="closing-draining-refactor/draft-ietf-quic-qpack.txt"
+        <td><a href="udp-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/closing-draining-refactor/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/closing-draining-refactor/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/udp-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/udp-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="closing-draining-refactor/draft-ietf-quic-recovery.html"
+        <td><a href="udp-packets/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="closing-draining-refactor/draft-ietf-quic-recovery.txt"
+        <td><a href="udp-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/closing-draining-refactor/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/closing-draining-refactor/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/udp-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/udp-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="closing-draining-refactor/draft-ietf-quic-tls.html"
+        <td><a href="udp-packets/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="closing-draining-refactor/draft-ietf-quic-tls.txt"
+        <td><a href="udp-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/closing-draining-refactor/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/closing-draining-refactor/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/udp-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/udp-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="closing-draining-refactor/draft-ietf-quic-transport.html"
+        <td><a href="udp-packets/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="closing-draining-refactor/draft-ietf-quic-transport.txt"
+        <td><a href="udp-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/closing-draining-refactor/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/closing-draining-refactor/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">
-      <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 *">
+        <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/udp-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/udp-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="transport/what-is-absence">transport/what-is-absence</a></h2>
-    <table id="branch-transport/what-is-absence">
+    <h2>Preview for branch <a href="remove-new-token-forgery-req">remove-new-token-forgery-req</a></h2>
+    <table id="branch-remove-new-token-forgery-req">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/what-is-absence/draft-ietf-quic-http.html"
+        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/what-is-absence/draft-ietf-quic-http.txt"
+        <td><a href="remove-new-token-forgery-req/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/what-is-absence/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/what-is-absence/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/what-is-absence/draft-ietf-quic-invariants.html"
+        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/what-is-absence/draft-ietf-quic-invariants.txt"
+        <td><a href="remove-new-token-forgery-req/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/what-is-absence/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/what-is-absence/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/what-is-absence/draft-ietf-quic-qpack.html"
+        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/what-is-absence/draft-ietf-quic-qpack.txt"
+        <td><a href="remove-new-token-forgery-req/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/what-is-absence/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/what-is-absence/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/what-is-absence/draft-ietf-quic-recovery.html"
+        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/what-is-absence/draft-ietf-quic-recovery.txt"
+        <td><a href="remove-new-token-forgery-req/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/what-is-absence/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/what-is-absence/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/what-is-absence/draft-ietf-quic-tls.html"
+        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/what-is-absence/draft-ietf-quic-tls.txt"
+        <td><a href="remove-new-token-forgery-req/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/what-is-absence/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/what-is-absence/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/what-is-absence/draft-ietf-quic-transport.html"
+        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/what-is-absence/draft-ietf-quic-transport.txt"
+        <td><a href="remove-new-token-forgery-req/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/what-is-absence/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/what-is-absence/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/define-violation">transport/define-violation</a></h2>
-    <table id="branch-transport/define-violation">
+    <h2>Preview for branch <a href="tp-error">tp-error</a></h2>
+    <table id="branch-tp-error">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/define-violation/draft-ietf-quic-http.html"
+        <td><a href="tp-error/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/define-violation/draft-ietf-quic-http.txt"
+        <td><a href="tp-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/define-violation/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/define-violation/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/tp-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/tp-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/define-violation/draft-ietf-quic-invariants.html"
+        <td><a href="tp-error/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/define-violation/draft-ietf-quic-invariants.txt"
+        <td><a href="tp-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/define-violation/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/define-violation/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/tp-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/tp-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/define-violation/draft-ietf-quic-qpack.html"
+        <td><a href="tp-error/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/define-violation/draft-ietf-quic-qpack.txt"
+        <td><a href="tp-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/define-violation/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/define-violation/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/tp-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/tp-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/define-violation/draft-ietf-quic-recovery.html"
+        <td><a href="tp-error/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/define-violation/draft-ietf-quic-recovery.txt"
+        <td><a href="tp-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/define-violation/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/define-violation/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/tp-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/tp-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/define-violation/draft-ietf-quic-tls.html"
+        <td><a href="tp-error/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/define-violation/draft-ietf-quic-tls.txt"
+        <td><a href="tp-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/define-violation/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/define-violation/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/tp-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/tp-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/define-violation/draft-ietf-quic-transport.html"
+        <td><a href="tp-error/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/define-violation/draft-ietf-quic-transport.txt"
+        <td><a href="tp-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/define-violation/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/define-violation/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/tp-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/tp-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/cap-NOT">transport/cap-NOT</a></h2>
-    <table id="branch-transport/cap-NOT">
+    <h2>Preview for branch <a href="deconflict-tls-errors">deconflict-tls-errors</a></h2>
+    <table id="branch-deconflict-tls-errors">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/cap-NOT/draft-ietf-quic-http.html"
+        <td><a href="deconflict-tls-errors/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/cap-NOT/draft-ietf-quic-http.txt"
+        <td><a href="deconflict-tls-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/transport/cap-NOT/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/cap-NOT/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/deconflict-tls-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/deconflict-tls-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="transport/cap-NOT/draft-ietf-quic-invariants.html"
+        <td><a href="deconflict-tls-errors/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/cap-NOT/draft-ietf-quic-invariants.txt"
+        <td><a href="deconflict-tls-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/transport/cap-NOT/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/cap-NOT/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/deconflict-tls-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/deconflict-tls-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="transport/cap-NOT/draft-ietf-quic-qpack.html"
+        <td><a href="deconflict-tls-errors/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/cap-NOT/draft-ietf-quic-qpack.txt"
+        <td><a href="deconflict-tls-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/transport/cap-NOT/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/cap-NOT/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/deconflict-tls-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/deconflict-tls-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="transport/cap-NOT/draft-ietf-quic-recovery.html"
+        <td><a href="deconflict-tls-errors/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/cap-NOT/draft-ietf-quic-recovery.txt"
+        <td><a href="deconflict-tls-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/transport/cap-NOT/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/cap-NOT/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/deconflict-tls-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/deconflict-tls-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="transport/cap-NOT/draft-ietf-quic-tls.html"
+        <td><a href="deconflict-tls-errors/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/cap-NOT/draft-ietf-quic-tls.txt"
+        <td><a href="deconflict-tls-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/transport/cap-NOT/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/cap-NOT/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/deconflict-tls-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/deconflict-tls-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="transport/cap-NOT/draft-ietf-quic-transport.html"
+        <td><a href="deconflict-tls-errors/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/cap-NOT/draft-ietf-quic-transport.txt"
+        <td><a href="deconflict-tls-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/transport/cap-NOT/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/cap-NOT/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/deconflict-tls-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/deconflict-tls-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="transport/should_vn">transport/should_vn</a></h2>
-    <table id="branch-transport/should_vn">
+    <h2>Preview for branch <a href="ianswett-cwnd-limit-consistency">ianswett-cwnd-limit-consistency</a></h2>
+    <table id="branch-ianswett-cwnd-limit-consistency">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/should_vn/draft-ietf-quic-http.html"
+        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/should_vn/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-cwnd-limit-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/should_vn/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/should_vn/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-cwnd-limit-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/ianswett-cwnd-limit-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/should_vn/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/should_vn/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-cwnd-limit-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/should_vn/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/should_vn/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-cwnd-limit-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/ianswett-cwnd-limit-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/should_vn/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/should_vn/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-cwnd-limit-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/should_vn/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/should_vn/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-cwnd-limit-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/ianswett-cwnd-limit-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/should_vn/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/should_vn/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-cwnd-limit-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/should_vn/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/should_vn/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-cwnd-limit-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/ianswett-cwnd-limit-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/should_vn/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/should_vn/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-cwnd-limit-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/should_vn/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/should_vn/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-cwnd-limit-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/ianswett-cwnd-limit-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/should_vn/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-cwnd-limit-consistency/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/should_vn/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-cwnd-limit-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/should_vn/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/should_vn/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-cwnd-limit-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/ianswett-cwnd-limit-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/orders">transport/orders</a></h2>
-    <table id="branch-transport/orders">
+    <h2>Preview for branch <a href="repeat-initial-reprise">repeat-initial-reprise</a></h2>
+    <table id="branch-repeat-initial-reprise">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/orders/draft-ietf-quic-http.html"
+        <td><a href="repeat-initial-reprise/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/orders/draft-ietf-quic-http.txt"
+        <td><a href="repeat-initial-reprise/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/orders/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/orders/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/repeat-initial-reprise/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/repeat-initial-reprise/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/orders/draft-ietf-quic-invariants.html"
+        <td><a href="repeat-initial-reprise/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/orders/draft-ietf-quic-invariants.txt"
+        <td><a href="repeat-initial-reprise/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/orders/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/orders/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/repeat-initial-reprise/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/repeat-initial-reprise/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/orders/draft-ietf-quic-qpack.html"
+        <td><a href="repeat-initial-reprise/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/orders/draft-ietf-quic-qpack.txt"
+        <td><a href="repeat-initial-reprise/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/orders/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/orders/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/repeat-initial-reprise/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/repeat-initial-reprise/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/orders/draft-ietf-quic-recovery.html"
+        <td><a href="repeat-initial-reprise/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/orders/draft-ietf-quic-recovery.txt"
+        <td><a href="repeat-initial-reprise/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/orders/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/orders/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/repeat-initial-reprise/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/repeat-initial-reprise/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/orders/draft-ietf-quic-tls.html"
+        <td><a href="repeat-initial-reprise/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/orders/draft-ietf-quic-tls.txt"
+        <td><a href="repeat-initial-reprise/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/orders/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/orders/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/repeat-initial-reprise/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/repeat-initial-reprise/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/orders/draft-ietf-quic-transport.html"
+        <td><a href="repeat-initial-reprise/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/orders/draft-ietf-quic-transport.txt"
+        <td><a href="repeat-initial-reprise/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/orders/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/orders/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/repeat-initial-reprise/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/repeat-initial-reprise/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-path-validation">ianswett-path-validation</a></h2>
-    <table id="branch-ianswett-path-validation">
+    <h2>Preview for branch <a href="no-pc-pseudocode">no-pc-pseudocode</a></h2>
+    <table id="branch-no-pc-pseudocode">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-path-validation/draft-ietf-quic-http.html"
+        <td><a href="no-pc-pseudocode/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-path-validation/draft-ietf-quic-http.txt"
+        <td><a href="no-pc-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/ianswett-path-validation/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-path-validation/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/no-pc-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/no-pc-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="ianswett-path-validation/draft-ietf-quic-invariants.html"
+        <td><a href="no-pc-pseudocode/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-path-validation/draft-ietf-quic-invariants.txt"
+        <td><a href="no-pc-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/ianswett-path-validation/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-path-validation/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/no-pc-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/no-pc-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="ianswett-path-validation/draft-ietf-quic-qpack.html"
+        <td><a href="no-pc-pseudocode/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-path-validation/draft-ietf-quic-qpack.txt"
+        <td><a href="no-pc-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/ianswett-path-validation/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-path-validation/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/no-pc-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/no-pc-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="ianswett-path-validation/draft-ietf-quic-recovery.html"
+        <td><a href="no-pc-pseudocode/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-path-validation/draft-ietf-quic-recovery.txt"
+        <td><a href="no-pc-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/ianswett-path-validation/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-path-validation/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/no-pc-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/no-pc-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="ianswett-path-validation/draft-ietf-quic-tls.html"
+        <td><a href="no-pc-pseudocode/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-path-validation/draft-ietf-quic-tls.txt"
+        <td><a href="no-pc-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/ianswett-path-validation/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-path-validation/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/no-pc-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/no-pc-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="ianswett-path-validation/draft-ietf-quic-transport.html"
+        <td><a href="no-pc-pseudocode/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-path-validation/draft-ietf-quic-transport.txt"
+        <td><a href="no-pc-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/ianswett-path-validation/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-path-validation/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/no-pc-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/no-pc-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="changelog-30">changelog-30</a></h2>
-    <table id="branch-changelog-30">
+    <h2>Preview for branch <a href="async-cert-validation">async-cert-validation</a></h2>
+    <table id="branch-async-cert-validation">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="changelog-30/draft-ietf-quic-http.html"
+        <td><a href="async-cert-validation/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="changelog-30/draft-ietf-quic-http.txt"
+        <td><a href="async-cert-validation/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-30/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-30/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/async-cert-validation/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/async-cert-validation/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-30/draft-ietf-quic-invariants.html"
+        <td><a href="async-cert-validation/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="changelog-30/draft-ietf-quic-invariants.txt"
+        <td><a href="async-cert-validation/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-30/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-30/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/async-cert-validation/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/async-cert-validation/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-30/draft-ietf-quic-qpack.html"
+        <td><a href="async-cert-validation/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="changelog-30/draft-ietf-quic-qpack.txt"
+        <td><a href="async-cert-validation/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-30/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-30/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/async-cert-validation/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/async-cert-validation/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-30/draft-ietf-quic-recovery.html"
+        <td><a href="async-cert-validation/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="changelog-30/draft-ietf-quic-recovery.txt"
+        <td><a href="async-cert-validation/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-30/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-30/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/async-cert-validation/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/async-cert-validation/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-30/draft-ietf-quic-tls.html"
+        <td><a href="async-cert-validation/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="changelog-30/draft-ietf-quic-tls.txt"
+        <td><a href="async-cert-validation/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-30/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-30/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/async-cert-validation/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/async-cert-validation/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-30/draft-ietf-quic-transport.html"
+        <td><a href="async-cert-validation/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="changelog-30/draft-ietf-quic-transport.txt"
+        <td><a href="async-cert-validation/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-30/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-30/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/async-cert-validation/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/async-cert-validation/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-4091">ianswett-4091</a></h2>
-    <table id="branch-ianswett-4091">
+    <h2>Preview for branch <a href="pc-starts-now">pc-starts-now</a></h2>
+    <table id="branch-pc-starts-now">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-4091/draft-ietf-quic-http.html"
+        <td><a href="pc-starts-now/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-4091/draft-ietf-quic-http.txt"
+        <td><a href="pc-starts-now/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-4091/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-4091/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/pc-starts-now/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/pc-starts-now/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-4091/draft-ietf-quic-invariants.html"
+        <td><a href="pc-starts-now/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-4091/draft-ietf-quic-invariants.txt"
+        <td><a href="pc-starts-now/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-4091/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-4091/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/pc-starts-now/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/pc-starts-now/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-4091/draft-ietf-quic-qpack.html"
+        <td><a href="pc-starts-now/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-4091/draft-ietf-quic-qpack.txt"
+        <td><a href="pc-starts-now/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-4091/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-4091/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/pc-starts-now/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/pc-starts-now/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-4091/draft-ietf-quic-recovery.html"
+        <td><a href="pc-starts-now/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-4091/draft-ietf-quic-recovery.txt"
+        <td><a href="pc-starts-now/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-4091/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-4091/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/pc-starts-now/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/pc-starts-now/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-4091/draft-ietf-quic-tls.html"
+        <td><a href="pc-starts-now/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-4091/draft-ietf-quic-tls.txt"
+        <td><a href="pc-starts-now/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-4091/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-4091/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/pc-starts-now/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/pc-starts-now/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-4091/draft-ietf-quic-transport.html"
+        <td><a href="pc-starts-now/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-4091/draft-ietf-quic-transport.txt"
+        <td><a href="pc-starts-now/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-4091/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-4091/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/pc-starts-now/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/pc-starts-now/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="remove-new-token-forgery-req">remove-new-token-forgery-req</a></h2>
-    <table id="branch-remove-new-token-forgery-req">
+    <h2>Preview for branch <a href="path-reponse-path">path-reponse-path</a></h2>
+    <table id="branch-path-reponse-path">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-http.html"
+        <td><a href="path-reponse-path/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-http.txt"
+        <td><a href="path-reponse-path/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/path-reponse-path/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/path-reponse-path/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="remove-new-token-forgery-req/draft-ietf-quic-invariants.html"
+        <td><a href="path-reponse-path/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-invariants.txt"
+        <td><a href="path-reponse-path/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/path-reponse-path/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/path-reponse-path/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="remove-new-token-forgery-req/draft-ietf-quic-qpack.html"
+        <td><a href="path-reponse-path/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-qpack.txt"
+        <td><a href="path-reponse-path/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/path-reponse-path/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/path-reponse-path/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="remove-new-token-forgery-req/draft-ietf-quic-recovery.html"
+        <td><a href="path-reponse-path/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-recovery.txt"
+        <td><a href="path-reponse-path/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/path-reponse-path/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/path-reponse-path/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="remove-new-token-forgery-req/draft-ietf-quic-tls.html"
+        <td><a href="path-reponse-path/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-tls.txt"
+        <td><a href="path-reponse-path/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/path-reponse-path/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/path-reponse-path/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="remove-new-token-forgery-req/draft-ietf-quic-transport.html"
+        <td><a href="path-reponse-path/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="remove-new-token-forgery-req/draft-ietf-quic-transport.txt"
+        <td><a href="path-reponse-path/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/remove-new-token-forgery-req/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/remove-new-token-forgery-req/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/path-reponse-path/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/path-reponse-path/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-out-of-order-ack">ianswett-out-of-order-ack</a></h2>
-    <table id="branch-ianswett-out-of-order-ack">
+    <h2>Preview for branch <a href="ianswett-gorry">ianswett-gorry</a></h2>
+    <table id="branch-ianswett-gorry">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-http.html"
+        <td><a href="ianswett-gorry/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-gorry/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-out-of-order-ack/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-out-of-order-ack/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-gorry/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-gorry/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-out-of-order-ack/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-gorry/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-gorry/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-out-of-order-ack/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-out-of-order-ack/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-gorry/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-gorry/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-out-of-order-ack/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-gorry/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-gorry/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-out-of-order-ack/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-out-of-order-ack/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-gorry/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-gorry/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-out-of-order-ack/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-gorry/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-gorry/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-out-of-order-ack/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-out-of-order-ack/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-gorry/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-gorry/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-out-of-order-ack/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-gorry/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-gorry/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-out-of-order-ack/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-out-of-order-ack/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-gorry/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-gorry/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-out-of-order-ack/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-gorry/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-out-of-order-ack/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-gorry/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-out-of-order-ack/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-out-of-order-ack/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-gorry/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-gorry/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
diff --git a/split-initial-close/draft-ietf-quic-http.html b/split-initial-close/draft-ietf-quic-http.html
deleted file mode 100644
index b896a60fdf..0000000000
--- a/split-initial-close/draft-ietf-quic-http.html
+++ /dev/null
@@ -1,5150 +0,0 @@
-<!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.47.0" 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 {
-  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 {
-  max-width: 100%;
-  margin: 0 0 1em;
-  border-collapse: collapse;
-}
-table.right {
-  margin-left: auto;
-}
-table.center {
-  margin-left: auto;
-  margin-right: auto;
-}
-table.left {
-  margin-right: auto;
-}
-thead, tbody {
-  border: 1px solid var(--line-color);
-}
-th, td {
-  text-align: left;
-  vertical-align: top;
-  padding: 5px 10px;
-}
-th {
-  background-color: var(--line-color);
-}
-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 {
-  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;
-}
-
-/* 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">August 2020</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Bishop</td>
-<td class="center">Expires 18 February 2021</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-08-17" class="published">17 August 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="2021-02-18">18 February 2021</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
-(quic@ietf.org), 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 18 February 2021.<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-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="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-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="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-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="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-document-organization" class="xref">Document Organization</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
-</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-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="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-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="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-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="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-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="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-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="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-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="ulEmpty compact 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-connection-establishment" class="xref">Connection Establishment</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact 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-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="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-http-request-lifecycle" class="xref">HTTP Request Lifecycle</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-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="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-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="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-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="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-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="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-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="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-http-upgrade" class="xref">HTTP Upgrade</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-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="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-connection-closure" class="xref">Connection Closure</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-idle-connections" class="xref">Idle Connections</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-connection-shutdown" class="xref">Connection Shutdown</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-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="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-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="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-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="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-bidirectional-streams" class="xref">Bidirectional Streams</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-unidirectional-streams" class="xref">Unidirectional Streams</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact 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-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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="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-http-framing-layer" class="xref">HTTP Framing Layer</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-frame-layout" class="xref">Frame Layout</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-frame-definitions" class="xref">Frame Definitions</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="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-error-handling" class="xref">Error Handling</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-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="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-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="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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact 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-server-authority" class="xref">Server Authority</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact 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-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="ulEmpty compact 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-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="ulEmpty compact 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-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="ulEmpty compact toc" 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="ulEmpty compact toc">
-<li class="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="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-iana-considerations" class="xref">IANA Considerations</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-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="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-new-registries" class="xref">New Registries</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty compact toc">
-<li class="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="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-references" class="xref">References</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-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="ulEmpty compact 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-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="ulEmpty compact toc" 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="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-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="ulEmpty compact toc" 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="ulEmpty compact toc">
-<li class="ulEmpty compact 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-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="ulEmpty compact 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-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="ulEmpty compact 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-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="ulEmpty compact 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-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="ulEmpty compact toc" 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="ulEmpty compact toc" 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="ulEmpty compact toc">
-<li class="ulEmpty compact 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-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="ulEmpty compact toc" 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="ulEmpty compact toc">
-<li class="ulEmpty compact toc" 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-28</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-27</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-26" class="xref">Since draft-ietf-quic-http-26</a><a href="#section-toc.1-1.14.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-25" class="xref">Since draft-ietf-quic-http-25</a><a href="#section-toc.1-1.14.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-24" class="xref">Since draft-ietf-quic-http-24</a><a href="#section-toc.1-1.14.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-23" class="xref">Since draft-ietf-quic-http-23</a><a href="#section-toc.1-1.14.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-22" class="xref">Since draft-ietf-quic-http-22</a><a href="#section-toc.1-1.14.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-21" class="xref">Since draft-ietf-quic-http-21</a><a href="#section-toc.1-1.14.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-20" class="xref">Since draft-ietf-quic-http-20</a><a href="#section-toc.1-1.14.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-1" class="xref">Since draft-ietf-quic-http-19</a><a href="#section-toc.1-1.14.2.10.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-18" class="xref">Since draft-ietf-quic-http-18</a><a href="#section-toc.1-1.14.2.11.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-17" class="xref">Since draft-ietf-quic-http-17</a><a href="#section-toc.1-1.14.2.12.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-16" class="xref">Since draft-ietf-quic-http-16</a><a href="#section-toc.1-1.14.2.13.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-15" class="xref">Since draft-ietf-quic-http-15</a><a href="#section-toc.1-1.14.2.14.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-14" class="xref">Since draft-ietf-quic-http-14</a><a href="#section-toc.1-1.14.2.15.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-13" class="xref">Since draft-ietf-quic-http-13</a><a href="#section-toc.1-1.14.2.16.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-12" class="xref">Since draft-ietf-quic-http-12</a><a href="#section-toc.1-1.14.2.17.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-11" class="xref">Since draft-ietf-quic-http-11</a><a href="#section-toc.1-1.14.2.18.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-10" class="xref">Since draft-ietf-quic-http-10</a><a href="#section-toc.1-1.14.2.19.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-0" class="xref">Since draft-ietf-quic-http-09</a><a href="#section-toc.1-1.14.2.20.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-08" class="xref">Since draft-ietf-quic-http-08</a><a href="#section-toc.1-1.14.2.21.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-07" class="xref">Since draft-ietf-quic-http-07</a><a href="#section-toc.1-1.14.2.22.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-06" class="xref">Since draft-ietf-quic-http-06</a><a href="#section-toc.1-1.14.2.23.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-05" class="xref">Since draft-ietf-quic-http-05</a><a href="#section-toc.1-1.14.2.24.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-04" class="xref">Since draft-ietf-quic-http-04</a><a href="#section-toc.1-1.14.2.25.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-03" class="xref">Since draft-ietf-quic-http-03</a><a href="#section-toc.1-1.14.2.26.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-02" class="xref">Since draft-ietf-quic-http-02</a><a href="#section-toc.1-1.14.2.27.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-01" class="xref">Since draft-ietf-quic-http-01</a><a href="#section-toc.1-1.14.2.28.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" 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-ietf-quic-http-00" class="xref">Since draft-ietf-quic-http-00</a><a href="#section-toc.1-1.14.2.29.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty compact toc" id="section-toc.1-1.14.2.30">
-                <p id="section-toc.1-1.14.2.30.1"><a href="#section-b.30" class="xref">B.30</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.30.1" class="pilcrow">¶</a></p>
-</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-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="ulEmpty compact toc" 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 HTTP/1.1, over a variety of transport and session layers, and with HTTP/2
-over TLS. 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>) 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 excessive
-tolerance of variant behavior.  Because HTTP/1.x does not include a multiplexing
-layer, multiple TCP connections are often used to service requests in parallel.
-However, that has a negative impact on congestion control and network
-efficiency, since TCP does not share congestion control across multiple
-connections.<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>) that
-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">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-2" class="pilcrow">¶</a></p>
-<p id="section-2.2-3">The following terms are used:<a href="#section-2.2-3" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-2.2-4">
-          <dt id="section-2.2-4.1">abort:</dt>
-          <dd id="section-2.2-4.2">
-  An abrupt termination of a connection or stream, possibly due to an error
-condition.<a href="#section-2.2-4.2" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.3">client:</dt>
-          <dd id="section-2.2-4.4">
-  The endpoint that initiates an HTTP/3 connection.  Clients send HTTP requests
-and receive HTTP responses.<a href="#section-2.2-4.4" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.5">connection:</dt>
-          <dd id="section-2.2-4.6">
-  A transport-layer connection between two endpoints, using QUIC as the
-transport protocol.<a href="#section-2.2-4.6" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.7">connection error:</dt>
-          <dd id="section-2.2-4.8">
-  An error that affects the entire HTTP/3 connection.<a href="#section-2.2-4.8" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.9">endpoint:</dt>
-          <dd id="section-2.2-4.10">
-  Either the client or server of the connection.<a href="#section-2.2-4.10" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.11">frame:</dt>
-          <dd id="section-2.2-4.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-4.12" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.13">peer:</dt>
-          <dd id="section-2.2-4.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-4.14" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.15">receiver:</dt>
-          <dd id="section-2.2-4.16">
-  An endpoint that is receiving frames.<a href="#section-2.2-4.16" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.17">sender:</dt>
-          <dd id="section-2.2-4.18">
-  An endpoint that is transmitting frames.<a href="#section-2.2-4.18" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.19">server:</dt>
-          <dd id="section-2.2-4.20">
-  The endpoint that accepts an HTTP/3 connection.  Servers receive HTTP requests
-and send HTTP responses.<a href="#section-2.2-4.20" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.21">stream:</dt>
-          <dd id="section-2.2-4.22">
-  A bidirectional or unidirectional bytestream provided by the QUIC transport.<a href="#section-2.2-4.22" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-2.2-4.23">stream error:</dt>
-          <dd id="section-2.2-4.24">
-  An error on the individual HTTP/3 stream.<a href="#section-2.2-4.24" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-2.2-5">The term "payload body" is defined in Section 7.3.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
-<p id="section-2.2-6">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-6" class="pilcrow">¶</a></p>
-<p id="section-2.2-7">Packet diagrams in this document use the format defined in Section 1.3 of
-<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> to illustrate the order and size of fields.<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="ulEmpty normal">
-<li class="ulEmpty normal" 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 that 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 5.4.1.1 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>. Experimenters are
-encouraged to coordinate their experiments on the quic@ietf.org 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 6.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 Application Layer Protocol Negotiation (ALPN; see <span>[<a href="#RFC7301" class="xref">RFC7301</a>]</span>) 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; if this
-connection is successful, the client can 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 that are also authoritative and that 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 6.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 connection, 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.  See Section 10 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>
-for a description of interim and final HTTP responses.<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, 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, sent as a series of DATA frames
-(see <a href="#frame-data" class="xref">Section 7.2.1</a>), and<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, sent as a single HEADERS
-frame.<a href="#section-4.1-5.3" class="pilcrow">¶</a>
-</li>
-        </ol>
-<p id="section-4.1-6">Header and trailer field sections are described in Section 5 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>;
-the payload body is described in Section 7.3.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
-<p id="section-4.1-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-4.1-8">A server MAY send one or more PUSH_PROMISE frames (<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
-that includes PUSH_PROMISE frames MUST be treated as a connection error of type
-H3_FRAME_UNEXPECTED.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
-<p id="section-4.1-9">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-9" class="pilcrow">¶</a></p>
-<p id="section-4.1-10">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-10" class="pilcrow">¶</a></p>
-<p id="section-4.1-11">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-11" class="pilcrow">¶</a></p>
-<p id="section-4.1-12">A response MAY consist of multiple messages when and only when one or more
-interim responses (1xx; see Section 10.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-12" class="pilcrow">¶</a></p>
-<p id="section-4.1-13">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-13" class="pilcrow">¶</a></p>
-<p id="section-4.1-14">When a stream is closed, this indicates the end of the final 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-initiated 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-14" class="pilcrow">¶</a></p>
-<p id="section-4.1-15">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 the request, clients SHOULD
-continue sending the body of the request and close the stream normally.<a href="#section-4.1-15" 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 5.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>
-<span class="break"></span><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 8 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 that 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 or "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 10 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 that 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 that has received this parameter SHOULD NOT send an HTTP message
-header that 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">Once a request stream has been opened, the request MAY be cancelled by either
-endpoint.  Clients cancel requests if the response is no longer of interest;
-servers cancel requests if they are unable to or choose not to respond.  When
-possible, it is RECOMMENDED that servers send an HTTP response with an
-appropriate status code rather than canceling a request it has already begun
-processing.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
-<p id="section-4.1.2-2">Implementations SHOULD cancel requests by abruptly terminating any
-directions of a stream that are still open.  This means resetting the
-sending parts of streams and aborting reading on receiving parts of streams;
-see Section 2.4 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
-<p id="section-4.1.2-3">When the server cancels a request without performing any application processing,
-the request is considered "rejected."  The server 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.<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
-<p id="section-4.1.2-4">Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that 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-4" class="pilcrow">¶</a></p>
-<p id="section-4.1.2-5">Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel requests.  Upon
-receipt of this error code, 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-5" class="pilcrow">¶</a></p>
-<p id="section-4.1.2-6">If a stream is canceled 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-6" 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 7.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 indicating the error
-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 10.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. The payload of 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 known 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 close the send stream
-that it sends to the client. TCP connections that 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 10.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 that 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 Section 8.2 of
-<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 assigned a unique Push ID by the server.  The Push ID is
-used to refer to the push in various contexts throughout the lifetime of the
-connection.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
-<p id="section-4.4-3">The Push ID space begins at zero, and ends at a maximum value set by the
-MAX_PUSH_ID frame; see <a href="#frame-max-push-id" class="xref">Section 7.2.7</a>.  In particular, a server is not
-able to push until after the client sends a MAX_PUSH_ID frame.  A client sends
-MAX_PUSH_ID frames to control the number of pushes that a server can promise.  A
-server SHOULD use Push IDs sequentially, beginning from zero.  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 Push ID is used in one or more PUSH_PROMISE frames (<a href="#frame-push-promise" class="xref">Section 7.2.5</a>)
-that carry the header section of the request message.  These frames are sent on
-the request stream that generated the push.  This allows the server push to be
-associated with a client request.  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
-identical.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
-<p id="section-4.4-5">The Push ID is then included with the push stream that ultimately fulfills
-those promises; 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
-as described in <a href="#request-response" class="xref">Section 4.1</a>.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
-<p id="section-4.4-6">Finally, the Push ID can be used in CANCEL_PUSH frames; see
-<a href="#frame-cancel-push" class="xref">Section 7.2.3</a>.  Clients use this frame to indicate they do not wish to
-receive a promised resource.  Servers use this frame to indicate they will not
-be fulfilling a previous promise.<a href="#section-4.4-6" class="pilcrow">¶</a></p>
-<p id="section-4.4-7">Not all requests can be pushed.  A server MAY push requests that have the
-following properties:<a href="#section-4.4-7" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-4.4-8.1">cacheable; see Section 8.2.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span><a href="#section-4.4-8.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-4.4-8.2">safe; see Section 8.2.1 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span><a href="#section-4.4-8.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-4.4-8.3">does not include a request body or trailer section<a href="#section-4.4-8.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-4.4-9">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-9" class="pilcrow">¶</a></p>
-<p id="section-4.4-10">Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame
-carrying a request that 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-10" class="pilcrow">¶</a></p>
-<p id="section-4.4-11">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-11" class="pilcrow">¶</a></p>
-<p id="section-4.4-12">Ordering of a PUSH_PROMISE frame 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-12" class="pilcrow">¶</a></p>
-<p id="section-4.4-13">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-13" class="pilcrow">¶</a></p>
-<p id="section-4.4-14">Push stream data can also arrive after a client has canceled a push. In this
-case, 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-14" class="pilcrow">¶</a></p>
-<p id="section-4.4-15">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; see 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-15" class="pilcrow">¶</a></p>
-<p id="section-4.4-16">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-16" 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 10.1.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 (<a href="#server-push" class="xref">Section 4.4</a>).  Requests or pushes with the indicated identifier or
-greater are rejected (<a href="#request-cancellation" class="xref">Section 4.1.2</a>) 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 contained in the GOAWAY
-frame, those requests will not be processed.  Clients can safely retry
-unprocessed requests on a different connection.  A client that is unable to
-retry requests loses all requests that are in flight when the server closes
-the 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 contained in the 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">An endpoint MAY send multiple GOAWAY frames indicating different identifiers,
-but the identifier in each frame MUST NOT be greater than the identifier in any
-previous frame, since clients might already have retried unprocessed requests on
-another connection.  Receiving a GOAWAY containing a larger identifier than
-previously received MUST be treated as a connection error of type H3_ID_ERROR.<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 that have already been promised. 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 no greater than any previously sent value.<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 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 that 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 that
-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 that 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">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.  Some stream types are reserved
-(<a href="#stream-grease" class="xref">Section 6.2.3</a>).<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 that 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 or a reserved error code
-(<a href="#http-error-codes" class="xref">Section 8.1</a>), 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 that 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 claiming 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 sending
-implementation chooses.  When sending a reserved stream type, the implementation
-MAY either terminate the stream cleanly or reset it.  When resetting the stream,
-either the H3_NO_ERROR error code 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 their permitted stream
-types; 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>
-<span class="break"></span><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 (<a href="#errors" class="xref">Section 8</a>) 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 that 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 body.<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 or 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="#server-push" class="xref">Section 4.4</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.  The client cannot expect the corresponding promise to be fulfilled,
-unless it has already received and processed the promised response. A server
-SHOULD send a CANCEL_PUSH frame even if it has opened the corresponding stream.<a href="#section-7.2.3-3" class="pilcrow">¶</a></p>
-<p id="section-7.2.3-4">Sending a CANCEL_PUSH frame has no direct effect on the state of existing push
-streams. A client SHOULD NOT send a CANCEL_PUSH frame when it has already
-received a corresponding push stream.  A push stream could arrive after a client
-has sent a CANCEL_PUSH frame, because a server might not have processed the
-CANCEL_PUSH. The client SHOULD abort reading the stream with an error code of
-H3_REQUEST_CANCELLED.<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="#server-push" class="xref">Section 4.4</a>.  If a CANCEL_PUSH frame is received that 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 that 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>
-<span class="break"></span><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 that 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
-the packet containing SETTINGS being processed by QUIC, 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 that 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>
-<span class="break"></span><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 frame 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 frame that
-uses a Push ID that they have already consumed and discarded are forced to
-ignore the 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 (i),
-}
-</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="#server-push" class="xref">Section 4.4</a>.  A
-MAX_PUSH_ID frame cannot reduce the maximum Push ID; receipt of a MAX_PUSH_ID
-frame 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 that 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; see Sections 2.4 and 5.3 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.  These
-are referred to as "stream errors" or "connection errors" (see Section 11 of
-<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>) and have associated error codes, but do not necessarily
-indicate a problem with the connection or either implementation.  For example, a
-stream can be reset if the requested resource is no longer needed.<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; for example, 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 that 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>
-<span class="break"></span><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 that does not 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 that 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 does not 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 12.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 5.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 can transport field values that are not valid. While most
-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 5.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 that 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 does not 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_FIELD_SECTION_SIZE
-(<a href="#header-size-constraints" class="xref">Section 4.1.1.3</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 a 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 7.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 contexts 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>
-<span class="break"></span><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>
-<span class="break"></span><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>
-<span class="break"></span><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>, this registry
-includes two additional fields.  Permanent registrations in this registry MUST
-include the following field:<a href="#section-11.2.3-3" class="pilcrow">¶</a></p>
-<span class="break"></span><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.<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 <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>
-<span class="break"></span><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 and 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" class="refDate">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-10</span>, <time datetime="2020-07-12" class="refDate">12 July 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-cache-10.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-cache-10.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" class="refDate">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-08-17" class="refDate">17 August 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-08-17" class="refDate">17 August 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" class="refDate">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" class="refDate">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" class="refDate">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="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" class="refDate">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" class="refDate">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" class="refDate">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="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" class="refDate">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="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" class="refDate">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" class="refDate">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" class="refDate">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-10</span>, <time datetime="2020-07-12" class="refDate">12 July 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-10.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-10.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" class="refDate">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" class="refDate">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-10</span>, <time datetime="2020-07-12" class="refDate">12 July 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-messaging-10.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-messaging-10.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" class="refDate">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" class="refDate">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="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" class="refDate">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" class="refDate">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" class="refDate">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 from 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 same
-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) that 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 that 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
-that 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 these issues, 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>
-<span class="break"></span><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 in HTTP/3, 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 frame 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 in HTTP/3, as 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 in HTTP/3, 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 in HTTP/3; 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>
-<span class="break"></span><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 frame, 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 the SETTINGS_MAX_CONCURRENT_STREAMS parameter 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 the
-SETTINGS_INITIAL_WINDOW_SIZE parameter 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_HEADER_LIST_SIZE:</dt>
-          <dd id="section-a.3-4.12">
-  This setting identifier has been renamed SETTINGS_MAX_FIELD_SECTION_SIZE.  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 that
-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 not to 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>
-<span class="break"></span><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. Such cases include 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">HTTP_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; see
-<a href="#request-cancellation" class="xref">Section 4.1.2</a>.<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="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>
-<div id="since-draft-ietf-quic-http-28">
-<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-28</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-b.1-1.1">CANCEL_PUSH is recommended even when the stream is reset (#3698, #3700)<a href="#section-b.1-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.1-1.2">Use H3_ID_ERROR when GOAWAY contains a larger identifier (#3631, #3634)<a href="#section-b.1-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-27">
-<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-27</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-b.2-1.1">Updated text to refer to latest HTTP revisions<a href="#section-b.2-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.2-1.2">Use the HTTP definition of authority for establishing and coalescing
-connections (#253, #2223, #3558)<a href="#section-b.2-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.2-1.3">Define use of GOAWAY from both endpoints (#2632, #3129)<a href="#section-b.2-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.2-1.4">Require either :authority or Host if the URI scheme has a mandatory
-authority component (#3408, #3475)<a href="#section-b.2-1.4" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-26">
-<section id="section-b.3">
-        <h2 id="name-since-draft-ietf-quic-http-26">
-<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-since-draft-ietf-quic-http-26" class="section-name selfRef">Since draft-ietf-quic-http-26</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-http-25">
-<section id="section-b.4">
-        <h2 id="name-since-draft-ietf-quic-http-25">
-<a href="#section-b.4" class="section-number selfRef">B.4. </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.4-1.1">Require QUICv1 for HTTP/3 (#3117, #3323)<a href="#section-b.4-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.4-1.2">Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275, #3309)<a href="#section-b.4-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.4-1.3">Clarify the definition of "malformed" (#3352, #3345)<a href="#section-b.4-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-24">
-<section id="section-b.5">
-        <h2 id="name-since-draft-ietf-quic-http-24">
-<a href="#section-b.5" class="section-number selfRef">B.5. </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.5-1.1">Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended instead
-(#3130,#3208)<a href="#section-b.5-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.5-1.2">Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331)<a href="#section-b.5-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.5-1.3">Some error codes are reserved for greasing (#3325,#3360)<a href="#section-b.5-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-23">
-<section id="section-b.6">
-        <h2 id="name-since-draft-ietf-quic-http-23">
-<a href="#section-b.6" class="section-number selfRef">B.6. </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.6-1.1">Removed <code>quic</code> Alt-Svc parameter (#3061,#3118)<a href="#section-b.6-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.6-1.2">Clients need not persist unknown settings for use in 0-RTT (#3110,#3113)<a href="#section-b.6-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.6-1.3">Clarify error cases around CANCEL_PUSH (#2819,#3083)<a href="#section-b.6-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-22">
-<section id="section-b.7">
-        <h2 id="name-since-draft-ietf-quic-http-22">
-<a href="#section-b.7" class="section-number selfRef">B.7. </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.7-1.1">Removed priority signaling (#2922,#2924)<a href="#section-b.7-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.7-1.2">
-            <p id="section-b.7-1.2.1">Further changes to error codes (#2662,#2551):<a href="#section-b.7-1.2.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-b.7-1.2.2.1">Error codes renumbered<a href="#section-b.7-1.2.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.7-1.2.2.2">HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR, HTTP_ID_ERROR, and others<a href="#section-b.7-1.2.2.2" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-b.7-1.3">Clarify how unknown frame types interact with required frame sequence
-(#2867,#2858)<a href="#section-b.7-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.7-1.4">Describe interactions with the transport in terms of defined interface terms
-(#2857,#2805)<a href="#section-b.7-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.7-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.7-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.7-1.6">Settings identifiers cannot be duplicated (#2979)<a href="#section-b.7-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.7-1.7">
-            <p id="section-b.7-1.7.1">Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945):<a href="#section-b.7-1.7.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-b.7-1.7.2.1">Servers must send all settings with non-default values in their SETTINGS
-frame, even when resuming<a href="#section-b.7-1.7.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.7-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.7-1.7.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.7-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.7-1.7.2.3" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-b.7-1.8">Clarify that Upgrade and the 101 status code are prohibited (#2898,#2889)<a href="#section-b.7-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.7-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.7-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.7-1.10">Unknown error codes cannot be treated as errors (#2998,#2816)<a href="#section-b.7-1.10" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-21">
-<section id="section-b.8">
-        <h2 id="name-since-draft-ietf-quic-http-21">
-<a href="#section-b.8" class="section-number selfRef">B.8. </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.8-1">No changes<a href="#section-b.8-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-20">
-<section id="section-b.9">
-        <h2 id="name-since-draft-ietf-quic-http-20">
-<a href="#section-b.9" class="section-number selfRef">B.9. </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.9-1.1">Prohibit closing the control stream (#2509, #2666)<a href="#section-b.9-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.2">Change default priority to use an orphan node (#2502, #2690)<a href="#section-b.9-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.3">Exclusive priorities are restored (#2754, #2781)<a href="#section-b.9-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.4">Restrict use of frames when using CONNECT (#2229, #2702)<a href="#section-b.9-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.5">Close and maybe reset streams if a connection error occurs for CONNECT (#2228,
-#2703)<a href="#section-b.9-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.6">Encourage provision of sufficient unidirectional streams for QPACK (#2100,
-#2529, #2762)<a href="#section-b.9-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.7">Allow extensions to use server-initiated bidirectional streams (#2711, #2773)<a href="#section-b.9-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.8">Clarify use of maximum header list size setting (#2516, #2774)<a href="#section-b.9-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.9-1.9">
-            <p id="section-b.9-1.9.1">Extensive changes to error codes and conditions of their sending<a href="#section-b.9-1.9.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-b.9-1.9.2.1">Require connection errors for more error conditions (#2511, #2510)<a href="#section-b.9-1.9.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.2">Updated the error codes for illegal GOAWAY frames (#2714, #2707)<a href="#section-b.9-1.9.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.3">Specified error code for HEADERS on control stream (#2708)<a href="#section-b.9-1.9.2.3" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.4">Specified error code for servers receiving PUSH_PROMISE (#2709)<a href="#section-b.9-1.9.2.4" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.5">Specified error code for receiving DATA before HEADERS (#2715)<a href="#section-b.9-1.9.2.5" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.6">Describe malformed messages and their handling (#2410, #2764)<a href="#section-b.9-1.9.2.6" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.7">Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813)<a href="#section-b.9-1.9.2.7" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.8">Refactor Push ID related errors (#2818, #2820)<a href="#section-b.9-1.9.2.8" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.9-1.9.2.9">Rationalize HTTP/3 stream creation errors (#2821, #2822)<a href="#section-b.9-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.10">
-        <h2 id="name-since-draft-ietf-quic-http-1">
-<a href="#section-b.10" class="section-number selfRef">B.10. </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.10-1.1">SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530)<a href="#section-b.10-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.10-1.2">Non-zero bits in the Empty field of the PRIORITY frame MAY be treated as an
-error (#2501)<a href="#section-b.10-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-18">
-<section id="section-b.11">
-        <h2 id="name-since-draft-ietf-quic-http-18">
-<a href="#section-b.11" class="section-number selfRef">B.11. </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.11-1.1">Resetting streams following a GOAWAY is recommended, but not required
-(#2256,#2457)<a href="#section-b.11-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.11-1.2">
-            <p id="section-b.11-1.2.1">Use variable-length integers throughout (#2437,#2233,#2253,#2275)<a href="#section-b.11-1.2.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-b.11-1.2.2.1">Variable-length frame types, stream types, and settings identifiers<a href="#section-b.11-1.2.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.11-1.2.2.2">Renumbered stream type assignments<a href="#section-b.11-1.2.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.11-1.2.2.3">Modified associated reserved values<a href="#section-b.11-1.2.2.3" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-b.11-1.3">Frame layout switched from Length-Type-Value to Type-Length-Value
-(#2395,#2235)<a href="#section-b.11-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.11-1.4">Specified error code for servers receiving DUPLICATE_PUSH (#2497)<a href="#section-b.11-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.11-1.5">Use connection error for invalid PRIORITY (#2507, #2508)<a href="#section-b.11-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-17">
-<section id="section-b.12">
-        <h2 id="name-since-draft-ietf-quic-http-17">
-<a href="#section-b.12" class="section-number selfRef">B.12. </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.12-1.1">HTTP_REQUEST_REJECTED is used to indicate a request can be retried (#2106,
-#2325)<a href="#section-b.12-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.12-1.2">Changed error code for GOAWAY on the wrong stream (#2231, #2343)<a href="#section-b.12-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-16">
-<section id="section-b.13">
-        <h2 id="name-since-draft-ietf-quic-http-16">
-<a href="#section-b.13" class="section-number selfRef">B.13. </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.13-1.1">Rename "HTTP/QUIC" to "HTTP/3" (#1973)<a href="#section-b.13-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.13-1.2">
-            <p id="section-b.13-1.2.1">Changes to PRIORITY frame (#1865, #2075)<a href="#section-b.13-1.2.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-b.13-1.2.2.1">Permitted as first frame of request streams<a href="#section-b.13-1.2.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.13-1.2.2.2">Remove exclusive reprioritization<a href="#section-b.13-1.2.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.13-1.2.2.3">Changes to Prioritized Element Type bits<a href="#section-b.13-1.2.2.3" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-b.13-1.3">Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE (#2072)<a href="#section-b.13-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.13-1.4">Set defaults for settings, allow request before receiving SETTINGS (#1809,
-#1846, #2038)<a href="#section-b.13-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.13-1.5">Clarify message processing rules for streams that aren't closed (#1972, #2003)<a href="#section-b.13-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.13-1.6">Removed reservation of error code 0 and moved HTTP_NO_ERROR to this value
-(#1922)<a href="#section-b.13-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.13-1.7">Removed prohibition of zero-length DATA frames (#2098)<a href="#section-b.13-1.7" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-15">
-<section id="section-b.14">
-        <h2 id="name-since-draft-ietf-quic-http-15">
-<a href="#section-b.14" class="section-number selfRef">B.14. </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.14-1">Substantial editorial reorganization; no technical changes.<a href="#section-b.14-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-14">
-<section id="section-b.15">
-        <h2 id="name-since-draft-ietf-quic-http-14">
-<a href="#section-b.15" class="section-number selfRef">B.15. </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.15-1.1">Recommend sensible values for QUIC transport parameters (#1720,#1806)<a href="#section-b.15-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.15-1.2">Define error for missing SETTINGS frame (#1697,#1808)<a href="#section-b.15-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.15-1.3">Setting values are variable-length integers (#1556,#1807) and do not have
-separate maximum values (#1820)<a href="#section-b.15-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.15-1.4">Expanded discussion of connection closure (#1599,#1717,#1712)<a href="#section-b.15-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.15-1.5">HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)<a href="#section-b.15-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-13">
-<section id="section-b.16">
-        <h2 id="name-since-draft-ietf-quic-http-13">
-<a href="#section-b.16" class="section-number selfRef">B.16. </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.16-1.1">Reserved some frame types for grease (#1333, #1446)<a href="#section-b.16-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.16-1.2">Unknown unidirectional stream types are tolerated, not errors; some reserved
-for grease (#1490, #1525)<a href="#section-b.16-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.16-1.3">Require settings to be remembered for 0-RTT, prohibit reductions (#1541,
-#1641)<a href="#section-b.16-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.16-1.4">Specify behavior for truncated requests (#1596, #1643)<a href="#section-b.16-1.4" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-12">
-<section id="section-b.17">
-        <h2 id="name-since-draft-ietf-quic-http-12">
-<a href="#section-b.17" class="section-number selfRef">B.17. </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.17-1.1">TLS SNI extension isn't mandatory if an alternative method is used (#1459,
-#1462, #1466)<a href="#section-b.17-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.17-1.2">Removed flags from HTTP/3 frames (#1388, #1398)<a href="#section-b.17-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.17-1.3">Reserved frame types and settings for use in preserving extensibility (#1333,
-#1446)<a href="#section-b.17-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.17-1.4">Added general error code (#1391, #1397)<a href="#section-b.17-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.17-1.5">Unidirectional streams carry a type byte and are extensible (#910,#1359)<a href="#section-b.17-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.17-1.6">Priority mechanism now uses explicit placeholders to enable persistent
-structure in the tree (#441,#1421,#1422)<a href="#section-b.17-1.6" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-11">
-<section id="section-b.18">
-        <h2 id="name-since-draft-ietf-quic-http-11">
-<a href="#section-b.18" class="section-number selfRef">B.18. </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.18-1.1">Moved QPACK table updates and acknowledgments to dedicated streams (#1121,
-#1122, #1238)<a href="#section-b.18-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-10">
-<section id="section-b.19">
-        <h2 id="name-since-draft-ietf-quic-http-10">
-<a href="#section-b.19" class="section-number selfRef">B.19. </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.19-1.1">Settings need to be remembered when attempting and accepting 0-RTT (#1157,
-#1207)<a href="#section-b.19-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-09">
-<section id="section-b.20">
-        <h2 id="name-since-draft-ietf-quic-http-0">
-<a href="#section-b.20" class="section-number selfRef">B.20. </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.20-1.1">Selected QCRAM for header compression (#228, #1117)<a href="#section-b.20-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.20-1.2">The server_name TLS extension is now mandatory (#296, #495)<a href="#section-b.20-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.20-1.3">Specified handling of unsupported versions in Alt-Svc (#1093, #1097)<a href="#section-b.20-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-08">
-<section id="section-b.21">
-        <h2 id="name-since-draft-ietf-quic-http-08">
-<a href="#section-b.21" class="section-number selfRef">B.21. </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.21-1.1">Clarified connection coalescing rules (#940, #1024)<a href="#section-b.21-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-07">
-<section id="section-b.22">
-        <h2 id="name-since-draft-ietf-quic-http-07">
-<a href="#section-b.22" class="section-number selfRef">B.22. </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.22-1.1">Changes for integer encodings in QUIC (#595,#905)<a href="#section-b.22-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.22-1.2">Use unidirectional streams as appropriate (#515, #240, #281, #886)<a href="#section-b.22-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.22-1.3">Improvement to the description of GOAWAY (#604, #898)<a href="#section-b.22-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.22-1.4">Improve description of server push usage (#947, #950, #957)<a href="#section-b.22-1.4" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-06">
-<section id="section-b.23">
-        <h2 id="name-since-draft-ietf-quic-http-06">
-<a href="#section-b.23" class="section-number selfRef">B.23. </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.23-1.1">Track changes in QUIC error code usage (#485)<a href="#section-b.23-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-05">
-<section id="section-b.24">
-        <h2 id="name-since-draft-ietf-quic-http-05">
-<a href="#section-b.24" class="section-number selfRef">B.24. </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.24-1.1">Made push ID sequential, add MAX_PUSH_ID, remove SETTINGS_ENABLE_PUSH (#709)<a href="#section-b.24-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.24-1.2">Guidance about keep-alive and QUIC PINGs (#729)<a href="#section-b.24-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.24-1.3">Expanded text on GOAWAY and cancellation (#757)<a href="#section-b.24-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-04">
-<section id="section-b.25">
-        <h2 id="name-since-draft-ietf-quic-http-04">
-<a href="#section-b.25" class="section-number selfRef">B.25. </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.25-1.1">Cite RFC 5234 (#404)<a href="#section-b.25-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.25-1.2">Return to a single stream per request (#245,#557)<a href="#section-b.25-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.25-1.3">Use separate frame type and settings registries from HTTP/2 (#81)<a href="#section-b.25-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.25-1.4">SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)<a href="#section-b.25-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.25-1.5">Restored GOAWAY (#696)<a href="#section-b.25-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.25-1.6">Identify server push using Push ID rather than a stream ID (#702,#281)<a href="#section-b.25-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.25-1.7">DATA frames cannot be empty (#700)<a href="#section-b.25-1.7" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-03">
-<section id="section-b.26">
-        <h2 id="name-since-draft-ietf-quic-http-03">
-<a href="#section-b.26" class="section-number selfRef">B.26. </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.26-1">None.<a href="#section-b.26-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-02">
-<section id="section-b.27">
-        <h2 id="name-since-draft-ietf-quic-http-02">
-<a href="#section-b.27" class="section-number selfRef">B.27. </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.27-1.1">Track changes in transport draft<a href="#section-b.27-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-01">
-<section id="section-b.28">
-        <h2 id="name-since-draft-ietf-quic-http-01">
-<a href="#section-b.28" class="section-number selfRef">B.28. </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.28-1.1">
-            <p id="section-b.28-1.1.1">SETTINGS changes (#181):<a href="#section-b.28-1.1.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-b.28-1.1.2.1">SETTINGS can be sent only once at the start of a connection;
-no changes thereafter<a href="#section-b.28-1.1.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.28-1.1.2.2">SETTINGS_ACK removed<a href="#section-b.28-1.1.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.28-1.1.2.3">Settings can only occur in the SETTINGS frame a single time<a href="#section-b.28-1.1.2.3" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-b.28-1.1.2.4">Boolean format updated<a href="#section-b.28-1.1.2.4" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-b.28-1.2">Alt-Svc parameter changed from "v" to "quic"; format updated (#229)<a href="#section-b.28-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.28-1.3">Closing the connection control stream or any message control stream is a
-fatal error (#176)<a href="#section-b.28-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.28-1.4">HPACK Sequence counter can wrap (#173)<a href="#section-b.28-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.28-1.5">0-RTT guidance added<a href="#section-b.28-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.28-1.6">Guide to differences from HTTP/2 and porting HTTP/2 extensions added
-(#127,#242)<a href="#section-b.28-1.6" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-http-00">
-<section id="section-b.29">
-        <h2 id="name-since-draft-ietf-quic-http-00">
-<a href="#section-b.29" class="section-number selfRef">B.29. </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.29-1.1">Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)<a href="#section-b.29-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.29-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.29-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.29-1.3">Adopted SETTINGS format from draft-bishop-httpbis-extended-settings-01<a href="#section-b.29-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.29-1.4">Reworked SETTINGS_ACK to account for indeterminate inter-stream order (#75)<a href="#section-b.29-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.29-1.5">Described CONNECT pseudo-method (#95)<a href="#section-b.29-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.29-1.6">Updated ALPN token and Alt-Svc guidance (#13,#87)<a href="#section-b.29-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.29-1.7">Application-layer-defined error codes (#19,#74)<a href="#section-b.29-1.7" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-shade-quic-http2-mapping-00">
-<section id="section-b.30">
-        <h2 id="name-since-draft-shade-quic-http">
-<a href="#section-b.30" class="section-number selfRef">B.30. </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.30-1.1">Adopted as base for draft-ietf-quic-http<a href="#section-b.30-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-b.30-1.2">Updated authors/editors list<a href="#section-b.30-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/split-initial-close/draft-ietf-quic-http.txt b/split-initial-close/draft-ietf-quic-http.txt
deleted file mode 100644
index cab752ef58..0000000000
--- a/split-initial-close/draft-ietf-quic-http.txt
+++ /dev/null
@@ -1,3976 +0,0 @@
-
-
-
-
-QUIC                                                      M. Bishop, Ed.
-Internet-Draft                                                    Akamai
-Intended status: Standards Track                          17 August 2020
-Expires: 18 February 2021
-
-
-             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), 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 18 February 2021.
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021                [Page 1]
-
-Internet-Draft                   HTTP/3                      August 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  . . . . . . . . . . . . . . . . .   5
-     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  . . . . . . . . . .  14
-       4.1.2.  Request Cancellation and Rejection  . . . . . . . . .  17
-       4.1.3.  Malformed Requests and Responses  . . . . . . . . . .  18
-     4.2.  The CONNECT Method  . . . . . . . . . . . . . . . . . . .  19
-     4.3.  HTTP Upgrade  . . . . . . . . . . . . . . . . . . . . . .  20
-     4.4.  Server Push . . . . . . . . . . . . . . . . . . . . . . .  20
-   5.  Connection Closure  . . . . . . . . . . . . . . . . . . . . .  22
-     5.1.  Idle Connections  . . . . . . . . . . . . . . . . . . . .  23
-     5.2.  Connection Shutdown . . . . . . . . . . . . . . . . . . .  23
-     5.3.  Immediate Application Closure . . . . . . . . . . . . . .  25
-     5.4.  Transport Closure . . . . . . . . . . . . . . . . . . . .  25
-   6.  Stream Mapping and Usage  . . . . . . . . . . . . . . . . . .  26
-     6.1.  Bidirectional Streams . . . . . . . . . . . . . . . . . .  26
-     6.2.  Unidirectional Streams  . . . . . . . . . . . . . . . . .  26
-       6.2.1.  Control Streams . . . . . . . . . . . . . . . . . . .  28
-       6.2.2.  Push Streams  . . . . . . . . . . . . . . . . . . . .  28
-       6.2.3.  Reserved Stream Types . . . . . . . . . . . . . . . .  29
-
-
-
-Bishop                  Expires 18 February 2021                [Page 2]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   7.  HTTP Framing Layer  . . . . . . . . . . . . . . . . . . . . .  29
-     7.1.  Frame Layout  . . . . . . . . . . . . . . . . . . . . . .  30
-     7.2.  Frame Definitions . . . . . . . . . . . . . . . . . . . .  31
-       7.2.1.  DATA  . . . . . . . . . . . . . . . . . . . . . . . .  31
-       7.2.2.  HEADERS . . . . . . . . . . . . . . . . . . . . . . .  31
-       7.2.3.  CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . .  32
-       7.2.4.  SETTINGS  . . . . . . . . . . . . . . . . . . . . . .  33
-       7.2.5.  PUSH_PROMISE  . . . . . . . . . . . . . . . . . . . .  36
-       7.2.6.  GOAWAY  . . . . . . . . . . . . . . . . . . . . . . .  38
-       7.2.7.  MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . .  38
-       7.2.8.  Reserved Frame Types  . . . . . . . . . . . . . . . .  39
-   8.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  39
-     8.1.  HTTP/3 Error Codes  . . . . . . . . . . . . . . . . . . .  40
-   9.  Extensions to HTTP/3  . . . . . . . . . . . . . . . . . . . .  41
-   10. Security Considerations . . . . . . . . . . . . . . . . . . .  42
-     10.1.  Server Authority . . . . . . . . . . . . . . . . . . . .  42
-     10.2.  Cross-Protocol Attacks . . . . . . . . . . . . . . . . .  42
-     10.3.  Intermediary Encapsulation Attacks . . . . . . . . . . .  43
-     10.4.  Cacheability of Pushed Responses . . . . . . . . . . . .  43
-     10.5.  Denial-of-Service Considerations . . . . . . . . . . . .  43
-       10.5.1.  Limits on Field Section Size . . . . . . . . . . . .  44
-       10.5.2.  CONNECT Issues . . . . . . . . . . . . . . . . . . .  45
-     10.6.  Use of Compression . . . . . . . . . . . . . . . . . . .  45
-     10.7.  Padding and Traffic Analysis . . . . . . . . . . . . . .  46
-     10.8.  Frame Parsing  . . . . . . . . . . . . . . . . . . . . .  46
-     10.9.  Early Data . . . . . . . . . . . . . . . . . . . . . . .  46
-     10.10. Migration  . . . . . . . . . . . . . . . . . . . . . . .  47
-     10.11. Privacy Considerations . . . . . . . . . . . . . . . . .  47
-   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
-     11.1.  Registration of HTTP/3 Identification String . . . . . .  47
-     11.2.  New Registries . . . . . . . . . . . . . . . . . . . . .  48
-       11.2.1.  Frame Types  . . . . . . . . . . . . . . . . . . . .  48
-       11.2.2.  Settings Parameters  . . . . . . . . . . . . . . . .  49
-       11.2.3.  Error Codes  . . . . . . . . . . . . . . . . . . . .  50
-       11.2.4.  Stream Types . . . . . . . . . . . . . . . . . . . .  53
-   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  53
-     12.1.  Normative References . . . . . . . . . . . . . . . . . .  53
-     12.2.  Informative References . . . . . . . . . . . . . . . . .  55
-   Appendix A.  Considerations for Transitioning from HTTP/2 . . . .  56
-     A.1.  Streams . . . . . . . . . . . . . . . . . . . . . . . . .  56
-     A.2.  HTTP Frame Types  . . . . . . . . . . . . . . . . . . . .  57
-       A.2.1.  Prioritization Differences  . . . . . . . . . . . . .  57
-       A.2.2.  Field Compression Differences . . . . . . . . . . . .  58
-       A.2.3.  Guidance for New Frame Type Definitions . . . . . . .  58
-       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  . . . . . .  62
-
-
-
-Bishop                  Expires 18 February 2021                [Page 3]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  62
-     B.1.  Since draft-ietf-quic-http-28 . . . . . . . . . . . . . .  62
-     B.2.  Since draft-ietf-quic-http-27 . . . . . . . . . . . . . .  63
-     B.3.  Since draft-ietf-quic-http-26 . . . . . . . . . . . . . .  63
-     B.4.  Since draft-ietf-quic-http-25 . . . . . . . . . . . . . .  63
-     B.5.  Since draft-ietf-quic-http-24 . . . . . . . . . . . . . .  63
-     B.6.  Since draft-ietf-quic-http-23 . . . . . . . . . . . . . .  63
-     B.7.  Since draft-ietf-quic-http-22 . . . . . . . . . . . . . .  63
-     B.8.  Since draft-ietf-quic-http-21 . . . . . . . . . . . . . .  64
-     B.9.  Since draft-ietf-quic-http-20 . . . . . . . . . . . . . .  64
-     B.10. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . .  65
-     B.11. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . .  65
-     B.12. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . .  66
-     B.13. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . .  66
-     B.14. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . .  67
-     B.15. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . .  67
-     B.16. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . .  67
-     B.17. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . .  67
-     B.18. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . .  68
-     B.19. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . .  68
-     B.20. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . .  68
-     B.21. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . .  68
-     B.22. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . .  68
-     B.23. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . .  68
-     B.24. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . .  68
-     B.25. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . .  68
-     B.26. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . .  69
-     B.27. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . .  69
-     B.28. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . .  69
-     B.29. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . .  70
-     B.30. Since draft-shade-quic-http2-mapping-00 . . . . . . . . .  70
-   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  70
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  71
-
-1.  Introduction
-
-   HTTP semantics ([SEMANTICS]) are used for a broad range of services
-   on the Internet.  These semantics have most commonly been used with
-   HTTP/1.1, over a variety of transport and session layers, and with
-   HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new
-   transport protocol, QUIC.
-
-
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021                [Page 4]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-1.1.  Prior versions of HTTP
-
-   HTTP/1.1 ([HTTP11]) 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
-   excessive tolerance of variant behavior.  Because HTTP/1.x does not
-   include a multiplexing layer, multiple TCP connections are often used
-   to service requests in parallel.  However, that has a negative impact
-   on congestion control and network efficiency, since TCP does not
-   share congestion control across multiple connections.
-
-   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.
-
-
-
-
-Bishop                  Expires 18 February 2021                [Page 5]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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).
-
-   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])
-   that 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.
-
-
-
-Bishop                  Expires 18 February 2021                [Page 6]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   *  Error Handling (Section 8) describes how error conditions are
-      handled and expressed, either on a particular stream or for the
-      connection as a whole.
-
-   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.
-
-   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.
-
-
-
-
-Bishop                  Expires 18 February 2021                [Page 7]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   peer:  An endpoint.  When discussing a particular endpoint, "peer"
-      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 7.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.
-
-   Packet diagrams in this document use the format defined in
-   Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of
-   fields.
-
-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.
-
-
-
-
-Bishop                  Expires 18 February 2021                [Page 8]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 that 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 5.4.1.1 of [SEMANTICS].  Experimenters are encouraged to
-   coordinate their experiments on the 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 6.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 Application Layer Protocol
-   Negotiation (ALPN; see [RFC7301]) token defined in Section 3.3.
-
-
-
-
-
-Bishop                  Expires 18 February 2021                [Page 9]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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"
-
-   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; if this connection is successful, the client can 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 that are also authoritative and that 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 18 February 2021               [Page 10]
-
-Internet-Draft                   HTTP/3                      August 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 6.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
-   connection, 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 18 February 2021               [Page 11]
-
-Internet-Draft                   HTTP/3                      August 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.  See Section 10 of [SEMANTICS] for a description
-   of interim and final HTTP responses.
-
-   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, sent as a single HEADERS frame (see
-       Section 7.2.2),
-
-   2.  optionally, the payload body, if present, sent as a series of
-       DATA frames (see Section 7.2.1), and
-
-   3.  optionally, the trailer field section, if present, sent as a
-       single HEADERS frame.
-
-   Header and trailer field sections are described in Section 5 of
-   [SEMANTICS]; the payload body is described in Section 7.3.3 of
-   [SEMANTICS].
-
-   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 (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 that includes PUSH_PROMISE frames
-   MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 12]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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.
-
-   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 interim responses (1xx; see Section 10.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 the final 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-initiated
-   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 the request, clients SHOULD continue sending the body of the
-   request and close the stream normally.
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 13]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-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/.
-
-   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 5.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
-
-
-
-Bishop                  Expires 18 February 2021               [Page 14]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   trailers.  Endpoints MUST treat a request or response that contains
-   undefined or invalid pseudo-header fields as malformed
-   (Section 4.1.3).
-
-   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 8 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].
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 15]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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.
-
-   If the ":scheme" pseudo-header field identifies a scheme that 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 or "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 10 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 that 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.
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 16]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-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
-   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 that
-   has received this parameter SHOULD NOT send an HTTP message header
-   that 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
-
-   Once a request stream has been opened, the request MAY be cancelled
-   by either endpoint.  Clients cancel requests if the response is no
-   longer of interest; servers cancel requests if they are unable to or
-   choose not to respond.  When possible, it is RECOMMENDED that servers
-   send an HTTP response with an appropriate status code rather than
-   canceling a request it has already begun processing.
-
-   Implementations SHOULD cancel requests by abruptly terminating any
-   directions of a stream that are still open.  This means resetting the
-   sending parts of streams and aborting reading on receiving parts of
-   streams; see Section 2.4 of [QUIC-TRANSPORT].
-
-   When the server cancels a request without performing any application
-   processing, the request is considered "rejected."  The server 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.
-
-   Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests
-   that 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.
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 17]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel
-   requests.  Upon receipt of this error code, 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 canceled 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).
-
-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 7.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.
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 18]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   For malformed requests, a server MAY send an HTTP response indicating
-   the error 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.
-
-   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 10.3 of [SEMANTICS].
-
-   All DATA frames on the stream correspond to data sent or received on
-   the TCP connection.  The payload of 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.
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 19]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 known 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 close the send stream that it sends to the
-   client.  TCP connections that 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 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 10.2.2 of [SEMANTICS]).
-
-4.4.  Server Push
-
-   Server push is an interaction mode that 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 Section 8.2 of [HTTP2], but uses different mechanisms.
-
-   Each server push is assigned a unique Push ID by the server.  The
-   Push ID is used to refer to the push in various contexts throughout
-   the lifetime of the connection.
-
-
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 20]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   The Push ID space begins at zero, and ends at a maximum value set by
-   the MAX_PUSH_ID frame; see Section 7.2.7.  In particular, a server is
-   not able to push until after the client sends a MAX_PUSH_ID frame.  A
-   client sends MAX_PUSH_ID frames to control the number of pushes that
-   a server can promise.  A server SHOULD use Push IDs sequentially,
-   beginning from zero.  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 Push ID is used in one or more PUSH_PROMISE frames
-   (Section 7.2.5) that carry the header section of the request message.
-   These frames are sent on the request stream that generated the push.
-   This allows the server push to be associated with a client request.
-   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
-   identical.
-
-   The Push ID is then included with the push stream that ultimately
-   fulfills those promises; 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 as described in Section 4.1.
-
-   Finally, the Push ID can be used in CANCEL_PUSH frames; see
-   Section 7.2.3.  Clients use this frame to indicate they do not wish
-   to receive a promised resource.  Servers use this frame to indicate
-   they will not be fulfilling a previous promise.
-
-   Not all requests can be pushed.  A server MAY push requests that have
-   the following properties:
-
-   *  cacheable; see Section 8.2.3 of [SEMANTICS]
-
-   *  safe; see Section 8.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 that 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
-
-
-
-Bishop                  Expires 18 February 2021               [Page 21]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 frame 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.
-
-   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.
-
-   Push stream data can also arrive after a client has canceled a push.
-   In this case, 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.
-
-   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; see
-   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.
-
-
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 22]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-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 10.1.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.
-
-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 (Section 4.4).  Requests or pushes with the indicated
-   identifier or greater are rejected (Section 4.1.2) 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:
-
-
-
-Bishop                  Expires 18 February 2021               [Page 23]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   *  Upon receipt of a GOAWAY frame, if the client has already sent
-      requests with a Stream ID greater than or equal to the identifier
-      contained in the GOAWAY frame, those requests will not be
-      processed.  Clients can safely retry unprocessed requests on a
-      different connection.  A client that is unable to retry requests
-      loses all requests that are in flight when the server closes the
-      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 contained
-      in the GOAWAY frame, those pushes will not be accepted.
-
-   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.
-
-   An endpoint MAY send multiple GOAWAY frames indicating different
-   identifiers, but the identifier in each frame MUST NOT be greater
-   than the identifier in any previous frame, since clients might
-   already have retried unprocessed requests on another connection.
-   Receiving a GOAWAY containing a larger identifier than previously
-   received MUST be treated as a connection error of type H3_ID_ERROR.
-
-   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 that have already been
-
-
-
-Bishop                  Expires 18 February 2021               [Page 24]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   promised.  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 no greater than any previously sent value.
-
-   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 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.
-
-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 that 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 that interrupts connectivity.
-
-   If a connection terminates without a GOAWAY frame, clients MUST
-   assume that any request that was sent, whether in whole or in part,
-   might have been processed.
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 25]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-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.
-
-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.
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 26]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   Unidirectional Stream Header {
-     Stream Type (i),
-   }
-
-                   Figure 1: Unidirectional Stream Header
-
-   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.  Some stream
-   types are reserved (Section 6.2.3).
-
-   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
-   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 that 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
-   or a reserved error code (Section 8.1), 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 that 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.
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 27]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 claiming 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 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.
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 28]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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.
-
-   The payload and length of the stream are selected in any manner the
-   sending implementation chooses.  When sending a reserved stream type,
-   the implementation MAY either terminate the stream cleanly or reset
-   it.  When resetting the stream, either the H3_NO_ERROR error code 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
-   their permitted stream types; see Table 1 for an overview.  A
-   comparison between HTTP/2 and HTTP/3 frames is provided in
-   Appendix A.2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 29]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   +==============+================+================+========+=========+
-   | 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
-
-   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 (..),
-   }
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 30]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-                       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 (Section 8) 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 that 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 body.
-
-   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.
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 31]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   HEADERS Frame {
-     Type (i) = 0x1,
-     Length (i),
-     Encoded Field Section (..),
-   }
-
-                          Figure 5: HEADERS Frame
-
-   HEADERS frames can only be sent on request or 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 4.4), 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.
-
-   When a server sends CANCEL_PUSH, it is indicating that it will not be
-   fulfilling a promise.  The client cannot expect the corresponding
-   promise to be fulfilled, unless it has already received and processed
-   the promised response.  A server SHOULD send a CANCEL_PUSH frame even
-   if it has opened the corresponding stream.
-
-   Sending a CANCEL_PUSH frame has no direct effect on the state of
-   existing push streams.  A client SHOULD NOT send a CANCEL_PUSH frame
-   when it has already received a corresponding push stream.  A push
-   stream could arrive after a client has sent a CANCEL_PUSH frame,
-   because a server might not have processed the CANCEL_PUSH.  The
-   client SHOULD abort reading the stream with an error code of
-   H3_REQUEST_CANCELLED.
-
-   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.
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 32]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 4.4.  If a CANCEL_PUSH frame is received that
-   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".
-
-   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.
-
-
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 33]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   SETTINGS parameters are not negotiated; they describe characteristics
-   of the sending peer that 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.
-
-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.
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 34]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 that 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 the packet containing SETTINGS being processed by
-   QUIC, 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 18 February 2021               [Page 35]
-
-Internet-Draft                   HTTP/3                      August 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 that 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 18 February 2021               [Page 36]
-
-Internet-Draft                   HTTP/3                      August 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 frame 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 frame that uses a Push ID that
-   they have already consumed and discarded are forced to ignore the
-   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 18 February 2021               [Page 37]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 38]
-
-Internet-Draft                   HTTP/3                      August 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 (i),
-   }
-
-                    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 4.4.  A MAX_PUSH_ID frame cannot reduce the maximum Push
-   ID; receipt of a MAX_PUSH_ID frame 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 that 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; see Sections 2.4 and 5.3 of
-   [QUIC-TRANSPORT].  These are referred to as "stream errors" or
-   "connection errors" (see Section 11 of [QUIC-TRANSPORT]) and have
-   associated error codes, but do not necessarily indicate a problem
-   with the connection or either implementation.  For example, a stream
-   can be reset if the requested resource is no longer needed.
-
-
-
-Bishop                  Expires 18 February 2021               [Page 39]
-
-Internet-Draft                   HTTP/3                      August 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; for example, see Section 4.1.
-
-   This section describes HTTP/3-specific error codes that 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 that does not 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 that 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 18 February 2021               [Page 40]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 41]
-
-Internet-Draft                   HTTP/3                      August 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 does not 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 12.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 18 February 2021               [Page 42]
-
-Internet-Draft                   HTTP/3                      August 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 5.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 can transport field values that are not valid.
-   While most 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 5.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 18 February 2021               [Page 43]
-
-Internet-Draft                   HTTP/3                      August 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 that 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 does not 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_FIELD_SECTION_SIZE
-   (Section 4.1.1.3) 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 18 February 2021               [Page 44]
-
-Internet-Draft                   HTTP/3                      August 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 a
-   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 7.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 contexts 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 18 February 2021               [Page 45]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 46]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 47]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 48]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 49]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 50]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   In addition to common fields as described in Section 11.2, this
-   registry includes two additional fields.  Permanent registrations in
-   this registry MUST include the following field:
-
-   Name:  A name for the error code.
-
-   Description:  A brief description of the error code semantics.
-
-   The entries in 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 18 February 2021               [Page 51]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 52]
-
-Internet-Draft                   HTTP/3                      August 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 and 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 18 February 2021               [Page 53]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   [CACHING]  Fielding, R., Nottingham, M., and J. Reschke, "HTTP
-              Caching", Work in Progress, Internet-Draft, draft-ietf-
-              httpbis-cache-10, 12 July 2020, <http://www.ietf.org/
-              internet-drafts/draft-ietf-httpbis-cache-10.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, 17 August
-              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, 17
-              August 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>.
-
-   [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>.
-
-   [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>.
-
-
-
-Bishop                  Expires 18 February 2021               [Page 54]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
-              DOI 10.17487/RFC6265, April 2011,
-              <https://www.rfc-editor.org/info/rfc6265>.
-
-   [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>.
-
-   [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-10, 12 July 2020, <http://www.ietf.org/
-              internet-drafts/draft-ietf-httpbis-semantics-10.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-10, 12 July 2020, <http://www.ietf.org/
-              internet-drafts/draft-ietf-httpbis-messaging-10.txt>.
-
-   [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>.
-
-
-
-Bishop                  Expires 18 February 2021               [Page 55]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   [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>.
-
-   [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 from HTTP/2.
-
-   These departures are noted in this section.
-
-A.1.  Streams
-
-   HTTP/3 permits use of a larger number of streams (2^62-1) than
-   HTTP/2.  The same 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
-
-
-
-Bishop                  Expires 18 February 2021               [Page 56]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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) that 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.
-
-   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.
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 57]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 that 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.
-
-   Because the Flags field is not present in generic HTTP/3 frames,
-   those frames that depend on the presence of flags need to allocate
-   space for flags as part of their frame payload.
-
-   Other than these issues, 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.
-
-
-
-Bishop                  Expires 18 February 2021               [Page 58]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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 in HTTP/3, 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 frame 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 in HTTP/3, as 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 in HTTP/3,
-      since QUIC provides flow control.
-
-   CONTINUATION (0x9):  CONTINUATION frames do not exist in HTTP/3;
-      instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are
-      permitted.
-
-   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:
-
-
-
-Bishop                  Expires 18 February 2021               [Page 59]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   SETTINGS_HEADER_TABLE_SIZE:  See [QPACK].
-
-   SETTINGS_ENABLE_PUSH:  This is removed in favor of the MAX_PUSH_ID
-      frame, 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 the
-      SETTINGS_MAX_CONCURRENT_STREAMS parameter 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 the
-      SETTINGS_INITIAL_WINDOW_SIZE parameter 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_HEADER_LIST_SIZE:  This setting identifier has been
-      renamed 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 that 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.
-
-   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 not
-   to 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:
-
-
-
-Bishop                  Expires 18 February 2021               [Page 60]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-   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.
-      Such cases include 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].
-
-   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.
-
-   HTTP_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.
-
-
-
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 61]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-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; see Section 4.1.2.
-
-   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.
-
-B.1.  Since draft-ietf-quic-http-28
-
-   *  CANCEL_PUSH is recommended even when the stream is reset (#3698,
-      #3700)
-
-   *  Use H3_ID_ERROR when GOAWAY contains a larger identifier (#3631,
-      #3634)
-
-
-
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 62]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-B.2.  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.3.  Since draft-ietf-quic-http-26
-
-   *  No changes
-
-B.4.  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.5.  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.6.  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.7.  Since draft-ietf-quic-http-22
-
-   *  Removed priority signaling (#2922,#2924)
-
-   *  Further changes to error codes (#2662,#2551):
-
-
-
-Bishop                  Expires 18 February 2021               [Page 63]
-
-Internet-Draft                   HTTP/3                      August 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.8.  Since draft-ietf-quic-http-21
-
-   No changes
-
-B.9.  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 18 February 2021               [Page 64]
-
-Internet-Draft                   HTTP/3                      August 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.10.  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.11.  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 18 February 2021               [Page 65]
-
-Internet-Draft                   HTTP/3                      August 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.12.  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.13.  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 18 February 2021               [Page 66]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-B.14.  Since draft-ietf-quic-http-15
-
-   Substantial editorial reorganization; no technical changes.
-
-B.15.  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.16.  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.17.  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 18 February 2021               [Page 67]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-B.18.  Since draft-ietf-quic-http-11
-
-   *  Moved QPACK table updates and acknowledgments to dedicated streams
-      (#1121, #1122, #1238)
-
-B.19.  Since draft-ietf-quic-http-10
-
-   *  Settings need to be remembered when attempting and accepting 0-RTT
-      (#1157, #1207)
-
-B.20.  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.21.  Since draft-ietf-quic-http-08
-
-   *  Clarified connection coalescing rules (#940, #1024)
-
-B.22.  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.23.  Since draft-ietf-quic-http-06
-
-   *  Track changes in QUIC error code usage (#485)
-
-B.24.  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.25.  Since draft-ietf-quic-http-04
-
-
-
-
-Bishop                  Expires 18 February 2021               [Page 68]
-
-Internet-Draft                   HTTP/3                      August 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.26.  Since draft-ietf-quic-http-03
-
-   None.
-
-B.27.  Since draft-ietf-quic-http-02
-
-   *  Track changes in transport draft
-
-B.28.  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 18 February 2021               [Page 69]
-
-Internet-Draft                   HTTP/3                      August 2020
-
-
-B.29.  Since draft-ietf-quic-http-00
-
-   *  Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
-
-   *  Changed from using HTTP/2 framing within Stream 3 to new framing
-      format and two-stream-per-request model (#71,#72,#73)
-
-   *  Adopted SETTINGS format from draft-bishop-httpbis-extended-
-      settings-01
-
-   *  Reworked SETTINGS_ACK to account for indeterminate inter-stream
-      order (#75)
-
-   *  Described CONNECT pseudo-method (#95)
-
-   *  Updated ALPN token and Alt-Svc guidance (#13,#87)
-
-   *  Application-layer-defined error codes (#19,#74)
-
-B.30.  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 18 February 2021               [Page 70]
-
-Internet-Draft                   HTTP/3                      August 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 18 February 2021               [Page 71]
diff --git a/split-initial-close/draft-ietf-quic-invariants.html b/split-initial-close/draft-ietf-quic-invariants.html
deleted file mode 100644
index bd7b22ee73..0000000000
--- a/split-initial-close/draft-ietf-quic-invariants.html
+++ /dev/null
@@ -1,1398 +0,0 @@
-<!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.47.0" 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 {
-  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 {
-  max-width: 100%;
-  margin: 0 0 1em;
-  border-collapse: collapse;
-}
-table.right {
-  margin-left: auto;
-}
-table.center {
-  margin-left: auto;
-  margin-right: auto;
-}
-table.left {
-  margin-right: auto;
-}
-thead, tbody {
-  border: 1px solid var(--line-color);
-}
-th, td {
-  text-align: left;
-  vertical-align: top;
-  padding: 5px 10px;
-}
-th {
-  background-color: var(--line-color);
-}
-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 {
-  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;
-}
-
-/* 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">August 2020</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Thomson</td>
-<td class="center">Expires 18 February 2021</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-08-17" class="published">17 August 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="2021-02-18">18 February 2021</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 18 February 2021.<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" 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="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-notational-conventions" class="xref">Notational Conventions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
-</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-quic-packets" class="xref">QUIC Packets</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-long-header" class="xref">Long Header</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-short-header" class="xref">Short Header</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-connection-id" class="xref">Connection ID</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-version" class="xref">Version</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-version-negotiation" class="xref">Version Negotiation</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-</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-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="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-incorrect-assumptions" class="xref">Incorrect Assumptions</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
-</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"></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 cannot change, this
-document aims to preserve the ability for QUIC endpoints to negotiate changes to
-any other aspect of the protocol.  As a consequence, this also guarantees a
-minimal amount of information that is made available to entities other than
-endpoints.  Unless specifically prohibited 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>
-<span class="break"></span><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">This document uses network byte order (that is, big endian) values.  Fields
-are placed starting from the high-order bits of each byte.<a href="#section-4-5" class="pilcrow">¶</a></p>
-<p id="section-4-6"><a href="#fig-ex-format" class="xref">Figure 1</a> shows an example structure:<a href="#section-4-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-4-7.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-packets">
-<section id="section-5">
-      <h2 id="name-quic-packets">
-<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-quic-packets" class="section-name selfRef">QUIC Packets</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">QUIC packets might be integrity protected, including the header.  However, QUIC
-Version Negotiation packets are not integrity protected; see <a href="#vn" class="xref">Section 6</a>.<a href="#section-5-3" class="pilcrow">¶</a></p>
-<p id="section-5-4">Aside from the values described here, the payload of QUIC packets is
-version-specific and of arbitrary length.<a href="#section-5-4" 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),
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..2040),
-  Source Connection ID 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.  Versions are described in
-<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
-field that follows it.  This length is encoded as an 8-bit unsigned integer.
-The Destination Connection ID field follows the Destination Connection ID Length
-field and is between 0 and 255 bytes in length.  Connection IDs are described in
-<a href="#connection-id" class="xref">Section 5.3</a>.<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 an 8-bit unsigned integer.  The
-Source Connection ID field follows the Source Connection ID 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 encoded 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) do not cause packets for a QUIC
-connection to be delivered to the wrong QUIC 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">The Version field contains a 4-byte identifier.  This value can be used by
-endpoints to identify a QUIC Version.  A Version field with a value of
-0x00000000 is reserved for version negotiation; see <a href="#vn" class="xref">Section 6</a>.  All other values
-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 that 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="vn">
-<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,
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..2040),
-  Source Connection ID 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">Only the most significant bit of the first byte of a Version Negotiation packet
-has any defined value.  The remaining 7 bits, labeled Unused, can be set to any
-value when sending and MUST be ignored on receipt.<a href="#section-6-4" class="pilcrow">¶</a></p>
-<p id="section-6-5">After the Source Connection ID field, the Version Negotiation packet contains a
-list of Supported Version fields, each identifying a version that the endpoint
-sending the packet supports.  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-5" class="pilcrow">¶</a></p>
-<p id="section-6-6">Version Negotiation packets do not use integrity or confidentiality protection.
-Specific QUIC versions might include protocol elements that allow endpoints to
-detect modification or corruption in the set of supported versions.<a href="#section-6-6" class="pilcrow">¶</a></p>
-<p id="section-6-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-6-8">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-8" class="pilcrow">¶</a></p>
-<p id="section-6-9">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-9" 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.  An endpoint MUST authenticate the contents of a Version Negotiation
-packet if it attempts a different QUIC version as a result.<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" class="refDate">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" class="refDate">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-08-17" class="refDate">17 August 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-08-17" class="refDate">17 August 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" class="refDate">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">The last packet before a long period of quiescence might be assumed
-to contain only 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">A QUIC packet with a particular value in the Version field means that the
-corresponding version of QUIC is in use<a href="#section-appendix.a-4.16" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.a-4.17">Only one connection at a time is established between any pair of QUIC
-endpoints<a href="#section-appendix.a-4.17" 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/split-initial-close/draft-ietf-quic-invariants.txt b/split-initial-close/draft-ietf-quic-invariants.txt
deleted file mode 100644
index 18509c3ec4..0000000000
--- a/split-initial-close/draft-ietf-quic-invariants.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-
-QUIC                                                          M. Thomson
-Internet-Draft                                                   Mozilla
-Intended status: Standards Track                          17 August 2020
-Expires: 18 February 2021
-
-
-                 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 18 February 2021.
-
-Copyright Notice
-
-   Copyright (c) 2020 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 1]
-
-Internet-Draft               QUIC Invariants                 August 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 Packets  . . . . . . . . . . . . . . . . . . . . . . . .   4
-     5.1.  Long Header . . . . . . . . . . . . . . . . . . . . . . .   4
-     5.2.  Short Header  . . . . . . . . . . . . . . . . . . . . . .   5
-     5.3.  Connection ID . . . . . . . . . . . . . . . . . . . . . .   6
-     5.4.  Version . . . . . . . . . . . . . . . . . . . . . . . . .   6
-   6.  Version Negotiation . . . . . . . . . . . . . . . . . . . . .   6
-   7.  Security and Privacy Considerations . . . . . . . . . . . . .   8
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
-     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
-     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
-   Appendix A.  Incorrect Assumptions  . . . . . . . . . . . . . . .   9
-   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.
-
-
-
-
-
-
-
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 2]
-
-Internet-Draft               QUIC Invariants                 August 2020
-
-
-   The primary goal of this document is to ensure that it is possible to
-   deploy new versions of QUIC.  By documenting the properties that
-   cannot change, this document aims to preserve the ability for QUIC
-   endpoints to negotiate changes to any other aspect of the protocol.
-   As a consequence, this also guarantees a minimal amount of
-   information that is made available to entities other than endpoints.
-   Unless specifically prohibited in this document, any aspect of the
-   protocol can change between different versions.
-
-   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
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 3]
-
-Internet-Draft               QUIC Invariants                 August 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 (E) ...:  Indicates that x is repeated zero or more times (and that
-      each instance is length E)
-
-   This document uses network byte order (that is, big endian) values.
-   Fields are placed starting from the high-order bits of each byte.
-
-   Figure 1 shows an example structure:
-
-   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 Packets
-
-   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.
-
-   QUIC packets might be integrity protected, including the header.
-   However, QUIC Version Negotiation packets are not integrity
-   protected; see Section 6.
-
-   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.
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 4]
-
-Internet-Draft               QUIC Invariants                 August 2020
-
-
-   Long Header Packet {
-     Header Form (1) = 1,
-     Version-Specific Bits (7),
-     Version (32),
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..2040),
-     Source Connection ID 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.  Versions are
-   described in Section 5.4.
-
-   The next byte contains the length in bytes of the Destination
-   Connection ID field that follows it.  This length is encoded as an
-   8-bit unsigned integer.  The Destination Connection ID field follows
-   the Destination Connection ID Length field and is between 0 and 255
-   bytes in length.  Connection IDs are described in Section 5.3.
-
-   The next byte contains the length in bytes of the Source Connection
-   ID field that follows it.  This length is encoded as an 8-bit
-   unsigned integer.  The Source Connection ID field follows the Source
-   Connection ID 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.
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 5]
-
-Internet-Draft               QUIC Invariants                 August 2020
-
-
-   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 encoded
-   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.
-
-   The primary function of a connection ID is to ensure that changes in
-   addressing at lower protocol layers (UDP, IP, and below) do not cause
-   packets for a QUIC connection to be delivered to the wrong QUIC
-   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
-
-   The Version field contains a 4-byte identifier.  This value can be
-   used by endpoints to identify a QUIC Version.  A Version field with a
-   value of 0x00000000 is reserved for version negotiation; see
-   Section 6.  All other values 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 that 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.
-
-
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 6]
-
-Internet-Draft               QUIC Invariants                 August 2020
-
-
-   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,
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..2040),
-     Source Connection ID Length (8),
-     Source Connection ID (0..2040),
-     Supported Version (32) ...,
-   }
-
-                    Figure 4: Version Negotiation Packet
-
-   Only the most significant bit of the first byte of a Version
-   Negotiation packet has any defined value.  The remaining 7 bits,
-   labeled Unused, can be set to any value when sending and MUST be
-   ignored on receipt.
-
-   After the Source Connection ID field, the Version Negotiation packet
-   contains a list of Supported Version fields, each identifying a
-   version that the endpoint sending the packet supports.  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.  Specific QUIC versions might include protocol elements
-   that allow endpoints to detect modification or corruption in the set
-   of supported versions.
-
-   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.
-
-
-
-Thomson                 Expires 18 February 2021                [Page 7]
-
-Internet-Draft               QUIC Invariants                 August 2020
-
-
-   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.
-
-   The Version Negotiation packet described in this document is not
-   integrity-protected; it only has modest protection against insertion
-   by off-path attackers.  An endpoint MUST authenticate the contents of
-   a Version Negotiation packet if it attempts a different QUIC version
-   as a result.
-
-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
-
-
-
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 8]
-
-Internet-Draft               QUIC Invariants                 August 2020
-
-
-   [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, 17 August
-              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, 17
-              August 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.
-
-   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
-
-   *  The last packet before a long period of quiescence might be
-      assumed to contain only an acknowledgment
-
-   *  QUIC uses an AEAD (AEAD_AES_128_GCM [RFC5116]) to protect the
-      packets it exchanges during connection establishment
-
-
-
-
-Thomson                 Expires 18 February 2021                [Page 9]
-
-Internet-Draft               QUIC Invariants                 August 2020
-
-
-   *  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
-
-   *  A QUIC packet with a particular value in the Version field means
-      that the corresponding version of QUIC is in use
-
-   *  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 18 February 2021               [Page 10]
diff --git a/split-initial-close/draft-ietf-quic-qpack.html b/split-initial-close/draft-ietf-quic-qpack.html
deleted file mode 100644
index fd95185140..0000000000
--- a/split-initial-close/draft-ietf-quic-qpack.html
+++ /dev/null
@@ -1,3815 +0,0 @@
-<!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.47.0" 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 {
-  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 {
-  max-width: 100%;
-  margin: 0 0 1em;
-  border-collapse: collapse;
-}
-table.right {
-  margin-left: auto;
-}
-table.center {
-  margin-left: auto;
-  margin-right: auto;
-}
-table.left {
-  margin-right: auto;
-}
-thead, tbody {
-  border: 1px solid var(--line-color);
-}
-th, td {
-  text-align: left;
-  vertical-align: top;
-  padding: 5px 10px;
-}
-th {
-  background-color: var(--line-color);
-}
-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 {
-  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;
-}
-
-/* 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">August 2020</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Krasic, et al.</td>
-<td class="center">Expires 18 February 2021</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-08-17" class="published">17 August 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="2021-02-18">18 February 2021</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 18 February 2021.<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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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="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-compression-process-overvie" class="xref">Compression Process Overview</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" 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 toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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="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-reference-tables" class="xref">Reference Tables</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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="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-wire-format" class="xref">Wire Format</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" 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 toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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="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-configuration" class="xref">Configuration</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
-</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-error-handling" class="xref">Error Handling</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-</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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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="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>
-<ul class="ulEmpty toc compact">
-<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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="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="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="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-static-table-2" class="xref">Static Table</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
-</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-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="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="ulEmpty toc compact">
-<li class="ulEmpty toc compact" 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-15</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-14</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-13</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-12" class="xref">Since draft-ietf-quic-qpack-12</a><a href="#section-toc.1-1.12.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-11" class="xref">Since draft-ietf-quic-qpack-11</a><a href="#section-toc.1-1.12.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-10" class="xref">Since draft-ietf-quic-qpack-10</a><a href="#section-toc.1-1.12.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-0" class="xref">Since draft-ietf-quic-qpack-09</a><a href="#section-toc.1-1.12.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-08" class="xref">Since draft-ietf-quic-qpack-08</a><a href="#section-toc.1-1.12.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-06" class="xref">Since draft-ietf-quic-qpack-06</a><a href="#section-toc.1-1.12.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-05" class="xref">Since draft-ietf-quic-qpack-05</a><a href="#section-toc.1-1.12.2.10.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-04" class="xref">Since draft-ietf-quic-qpack-04</a><a href="#section-toc.1-1.12.2.11.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-03" class="xref">Since draft-ietf-quic-qpack-03</a><a href="#section-toc.1-1.12.2.12.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-02" class="xref">Since draft-ietf-quic-qpack-02</a><a href="#section-toc.1-1.12.2.13.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-01" class="xref">Since draft-ietf-quic-qpack-01</a><a href="#section-toc.1-1.12.2.14.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-qpack-00" class="xref">Since draft-ietf-quic-qpack-00</a><a href="#section-toc.1-1.12.2.15.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="ulEmpty toc compact" 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-qcram" class="xref">Since draft-ietf-quic-qcram-00</a><a href="#section-toc.1-1.12.2.16.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"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</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-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>
-<span class="break"></span><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 5 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 that 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 that 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 that 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 that
-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>
-<span class="break"></span><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 that 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 that 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 that 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 that 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 that 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 that 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 that has already been evicted or that 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 that 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 that 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 does not 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 that 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 that 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 that 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, 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, 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 that 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 for the HTTP/3 SETTINGS frame:<a href="#section-5-1" class="pilcrow">¶</a></p>
-<span class="break"></span><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 that prevent the connection from continuing:<a href="#section-6-1" class="pilcrow">¶</a></p>
-<span class="break"></span><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>
-<span class="break"></span><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>
-<span class="break"></span><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 does not 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 that 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-08-17" class="refDate">17 August 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-08-17" class="refDate">17 August 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" class="refDate">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" class="refDate">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" class="refDate">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-10</span>, <time datetime="2020-07-12" class="refDate">12 July 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-10.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-10.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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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:
-    # Could not 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-15">
-<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-15</a>
-        </h2>
-<p id="section-c.1-1">No changes<a href="#section-c.1-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-14">
-<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-14</a>
-        </h2>
-<p id="section-c.2-1">Added security considerations<a href="#section-c.2-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-13">
-<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-13</a>
-        </h2>
-<p id="section-c.3-1">No changes<a href="#section-c.3-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-12">
-<section id="section-c.4">
-        <h2 id="name-since-draft-ietf-quic-qpack-12">
-<a href="#section-c.4" class="section-number selfRef">C.4. </a><a href="#name-since-draft-ietf-quic-qpack-12" class="section-name selfRef">Since draft-ietf-quic-qpack-12</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-11">
-<section id="section-c.5">
-        <h2 id="name-since-draft-ietf-quic-qpack-11">
-<a href="#section-c.5" class="section-number selfRef">C.5. </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.5-1">Editorial changes only<a href="#section-c.5-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-10">
-<section id="section-c.6">
-        <h2 id="name-since-draft-ietf-quic-qpack-10">
-<a href="#section-c.6" class="section-number selfRef">C.6. </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.6-1">Editorial changes only<a href="#section-c.6-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-09">
-<section id="section-c.7">
-        <h2 id="name-since-draft-ietf-quic-qpack-0">
-<a href="#section-c.7" class="section-number selfRef">C.7. </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.7-1.1">Decoders MUST emit Header Acknowledgements (#2939)<a href="#section-c.7-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.2">Updated error code for multiple encoder or decoder streams (#2970)<a href="#section-c.7-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.3">Added explicit defaults for new SETTINGS (#2974)<a href="#section-c.7-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-08">
-<section id="section-c.8">
-        <h2 id="name-since-draft-ietf-quic-qpack-08">
-<a href="#section-c.8" class="section-number selfRef">C.8. </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.8-1.1">Endpoints are permitted to create encoder and decoder streams even if they
-can't use them (#2100, #2529)<a href="#section-c.8-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.8-1.2">Maximum values for settings removed (#2766, #2767)<a href="#section-c.8-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-06">
-<section id="section-c.9">
-        <h2 id="name-since-draft-ietf-quic-qpack-06">
-<a href="#section-c.9" class="section-number selfRef">C.9. </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.9-1.1">Clarify initial dynamic table capacity maximums (#2276, #2330, #2330)<a href="#section-c.9-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-05">
-<section id="section-c.10">
-        <h2 id="name-since-draft-ietf-quic-qpack-05">
-<a href="#section-c.10" class="section-number selfRef">C.10. </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.10-1.1">Introduced the terms dynamic table capacity and maximum dynamic table
-capacity.<a href="#section-c.10-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.2">Renamed SETTINGS_HEADER_TABLE_SIZE to SETTINGS_QPACK_MAX_TABLE_CAPACITY.<a href="#section-c.10-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-04">
-<section id="section-c.11">
-        <h2 id="name-since-draft-ietf-quic-qpack-04">
-<a href="#section-c.11" class="section-number selfRef">C.11. </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.11-1.1">Changed calculation of Delta Base Index to avoid an illegal value (#2002,
-#2005)<a href="#section-c.11-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-03">
-<section id="section-c.12">
-        <h2 id="name-since-draft-ietf-quic-qpack-03">
-<a href="#section-c.12" class="section-number selfRef">C.12. </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.12-1.1">Change HTTP settings defaults (#2038)<a href="#section-c.12-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.2">Substantial editorial reorganization<a href="#section-c.12-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-02">
-<section id="section-c.13">
-        <h2 id="name-since-draft-ietf-quic-qpack-02">
-<a href="#section-c.13" class="section-number selfRef">C.13. </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.13-1.1">Largest Reference encoded modulo MaxEntries (#1763)<a href="#section-c.13-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.2">New Static Table (#1355)<a href="#section-c.13-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.3">Table Size Update with Insert Count=0 is a connection error (#1762)<a href="#section-c.13-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.4">Stream Cancellations are optional when SETTINGS_HEADER_TABLE_SIZE=0 (#1761)<a href="#section-c.13-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.5">Implementations must handle 62 bit integers (#1760)<a href="#section-c.13-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.6">Different error types for each QPACK stream, other changes to error
-handling (#1726)<a href="#section-c.13-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.7">Preserve header field order (#1725)<a href="#section-c.13-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.8">Initial table size is the maximum permitted when table is first usable (#1642)<a href="#section-c.13-1.8" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-01">
-<section id="section-c.14">
-        <h2 id="name-since-draft-ietf-quic-qpack-01">
-<a href="#section-c.14" class="section-number selfRef">C.14. </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.14-1.1">Only header blocks that reference the dynamic table are acknowledged (#1603,
-#1605)<a href="#section-c.14-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qpack-00">
-<section id="section-c.15">
-        <h2 id="name-since-draft-ietf-quic-qpack-00">
-<a href="#section-c.15" class="section-number selfRef">C.15. </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.15-1.1">Renumbered instructions for consistency (#1471, #1472)<a href="#section-c.15-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.2">Decoder is allowed to validate largest reference (#1404, #1469)<a href="#section-c.15-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.3">Header block acknowledgments also acknowledge the associated largest reference
-(#1370, #1400)<a href="#section-c.15-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.4">Added an acknowledgment for unread streams (#1371, #1400)<a href="#section-c.15-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.5">Removed framing from encoder stream (#1361,#1467)<a href="#section-c.15-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.6">Control streams use typed unidirectional streams rather than fixed stream IDs
-(#910,#1359)<a href="#section-c.15-1.6" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-qcram-00">
-<section id="section-c.16">
-        <h2 id="name-since-draft-ietf-quic-qcram">
-<a href="#section-c.16" class="section-number selfRef">C.16. </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.16-1.1">Separate instruction sets for table updates and header blocks (#1235, #1142,
-#1141)<a href="#section-c.16-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.2">Reworked indexing scheme (#1176, #1145, #1136, #1130, #1125, #1314)<a href="#section-c.16-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.3">Added mechanisms that support one-pass encoding (#1138, #1320)<a href="#section-c.16-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.4">Added a setting to control the number of blocked decoders (#238, #1140, #1143)<a href="#section-c.16-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.5">Moved table updates and acknowledgments to dedicated streams (#1121, #1122,
-#1238)<a href="#section-c.16-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/split-initial-close/draft-ietf-quic-qpack.txt b/split-initial-close/draft-ietf-quic-qpack.txt
deleted file mode 100644
index 59f566ad7d..0000000000
--- a/split-initial-close/draft-ietf-quic-qpack.txt
+++ /dev/null
@@ -1,2464 +0,0 @@
-
-
-
-
-QUIC                                                           C. Krasic
-Internet-Draft                                                   Netflix
-Intended status: Standards Track                               M. Bishop
-Expires: 18 February 2021                            Akamai Technologies
-                                                        A. Frindell, Ed.
-                                                                Facebook
-                                                          17 August 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 18 February 2021.
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 1]
-
-Internet-Draft                    QPACK                      August 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 . . . . . . . . . . . . . . . . . . . . . . . . .   6
-       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  . . . . . . . . . . . . . . . .   9
-     2.2.  Decoder . . . . . . . . . . . . . . . . . . . . . . . . .   9
-       2.2.1.  Blocked Decoding  . . . . . . . . . . . . . . . . . .   9
-       2.2.2.  State Synchronization . . . . . . . . . . . . . . . .  10
-       2.2.3.  Invalid References  . . . . . . . . . . . . . . . . .  11
-   3.  Reference Tables  . . . . . . . . . . . . . . . . . . . . . .  11
-     3.1.  Static Table  . . . . . . . . . . . . . . . . . . . . . .  11
-     3.2.  Dynamic Table . . . . . . . . . . . . . . . . . . . . . .  12
-       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 . . . . . . . . . . . . . . . . . .  14
-       3.2.6.  Post-Base Indexing  . . . . . . . . . . . . . . . . .  15
-   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 18 February 2021                [Page 2]
-
-Internet-Draft                    QPACK                      August 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-15  . . . . . . . . . . . . .  40
-     C.2.  Since draft-ietf-quic-qpack-14  . . . . . . . . . . . . .  41
-     C.3.  Since draft-ietf-quic-qpack-13  . . . . . . . . . . . . .  41
-     C.4.  Since draft-ietf-quic-qpack-12  . . . . . . . . . . . . .  41
-     C.5.  Since draft-ietf-quic-qpack-11  . . . . . . . . . . . . .  41
-     C.6.  Since draft-ietf-quic-qpack-10  . . . . . . . . . . . . .  41
-     C.7.  Since draft-ietf-quic-qpack-09  . . . . . . . . . . . . .  41
-     C.8.  Since draft-ietf-quic-qpack-08  . . . . . . . . . . . . .  41
-     C.9.  Since draft-ietf-quic-qpack-06  . . . . . . . . . . . . .  41
-     C.10. Since draft-ietf-quic-qpack-05  . . . . . . . . . . . . .  41
-     C.11. Since draft-ietf-quic-qpack-04  . . . . . . . . . . . . .  42
-     C.12. Since draft-ietf-quic-qpack-03  . . . . . . . . . . . . .  42
-     C.13. Since draft-ietf-quic-qpack-02  . . . . . . . . . . . . .  42
-     C.14. Since draft-ietf-quic-qpack-01  . . . . . . . . . . . . .  42
-     C.15. Since draft-ietf-quic-qpack-00  . . . . . . . . . . . . .  42
-     C.16. Since draft-ietf-quic-qcram-00  . . . . . . . . . . . . .  43
-   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  43
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 3]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44
-
-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 5 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.
-
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 4]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   Representation:  An instruction that represents a field line,
-      possibly by reference to the dynamic and static tables.
-
-   Encoder:  An implementation that encodes field sections.
-
-   Decoder:  An implementation that 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 that 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.
-
-
-
-
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 5]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-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
-   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 that 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 that 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.
-
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 6]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-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
-   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.
-
-
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 7]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   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 that
-   can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; see
-   Section 5.  An encoder MUST limit the number of streams that 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.
-
-   Note that the decoder might not become blocked on every stream that
-   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 that 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.
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 8]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-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.
-
-   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.
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021                [Page 9]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   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.
-
-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.
-
-
-
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 10]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-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.
-
-2.2.3.  Invalid References
-
-   If the decoder encounters a reference in a field line representation
-   to a dynamic table entry that has already been evicted or that 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 that 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.
-
-
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 11]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   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.
-
-   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.
-
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 12]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   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.
-
-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 that 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.
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 13]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-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.
-
-         +-----+---------------+-------+
-         | 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
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 14]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-        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.
-
-   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.
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 15]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   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.
-
-   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 does not 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 18 February 2021               [Page 16]
-
-Internet-Draft                    QPACK                      August 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 that 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 that 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 that
-   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 18 February 2021               [Page 17]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 18]
-
-Internet-Draft                    QPACK                      August 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,
-   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 18 February 2021               [Page 19]
-
-Internet-Draft                    QPACK                      August 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, 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 18 February 2021               [Page 20]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 21]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 22]
-
-Internet-Draft                    QPACK                      August 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 that 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 18 February 2021               [Page 23]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 24]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 25]
-
-Internet-Draft                    QPACK                      August 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 for 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 that 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 18 February 2021               [Page 26]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 27]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 28]
-
-Internet-Draft                    QPACK                      August 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 does not 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 18 February 2021               [Page 29]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 30]
-
-Internet-Draft                    QPACK                      August 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 that 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 18 February 2021               [Page 31]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 32]
-
-Internet-Draft                    QPACK                      August 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, 17 August 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, 17
-              August 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 18 February 2021               [Page 33]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   [SEMANTICS]
-              Fielding, R., Nottingham, M., and J. Reschke, "HTTP
-              Semantics", Work in Progress, Internet-Draft, draft-ietf-
-              httpbis-semantics-10, 12 July 2020, <http://www.ietf.org/
-              internet-drafts/draft-ietf-httpbis-semantics-10.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 18 February 2021               [Page 34]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 35]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 36]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 37]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 38]
-
-Internet-Draft                    QPACK                      August 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 18 February 2021               [Page 39]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-         dynamicIndex = dynamicTable.add(line)
-
-     if dynamicIndex is None:
-       # Could not 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-15
-
-   No changes
-
-
-
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 40]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-C.2.  Since draft-ietf-quic-qpack-14
-
-   Added security considerations
-
-C.3.  Since draft-ietf-quic-qpack-13
-
-   No changes
-
-C.4.  Since draft-ietf-quic-qpack-12
-
-   Editorial changes only
-
-C.5.  Since draft-ietf-quic-qpack-11
-
-   Editorial changes only
-
-C.6.  Since draft-ietf-quic-qpack-10
-
-   Editorial changes only
-
-C.7.  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.8.  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.9.  Since draft-ietf-quic-qpack-06
-
-   *  Clarify initial dynamic table capacity maximums (#2276, #2330,
-      #2330)
-
-C.10.  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.
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 41]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-C.11.  Since draft-ietf-quic-qpack-04
-
-   *  Changed calculation of Delta Base Index to avoid an illegal value
-      (#2002, #2005)
-
-C.12.  Since draft-ietf-quic-qpack-03
-
-   *  Change HTTP settings defaults (#2038)
-
-   *  Substantial editorial reorganization
-
-C.13.  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.14.  Since draft-ietf-quic-qpack-01
-
-   *  Only header blocks that reference the dynamic table are
-      acknowledged (#1603, #1605)
-
-C.15.  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)
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 42]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   *  Removed framing from encoder stream (#1361,#1467)
-
-   *  Control streams use typed unidirectional streams rather than fixed
-      stream IDs (#910,#1359)
-
-C.16.  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
-
-
-
-
-Krasic, et al.          Expires 18 February 2021               [Page 43]
-
-Internet-Draft                    QPACK                      August 2020
-
-
-   *  Biren Roy
-
-   *  Ian Swett
-
-   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 18 February 2021               [Page 44]
diff --git a/split-initial-close/draft-ietf-quic-recovery.html b/split-initial-close/draft-ietf-quic-recovery.html
deleted file mode 100644
index 4a5ff1d793..0000000000
--- a/split-initial-close/draft-ietf-quic-recovery.html
+++ /dev/null
@@ -1,3724 +0,0 @@
-<!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.47.0" 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 {
-  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 {
-  max-width: 100%;
-  margin: 0 0 1em;
-  border-collapse: collapse;
-}
-table.right {
-  margin-left: auto;
-}
-table.center {
-  margin-left: auto;
-  margin-right: auto;
-}
-table.left {
-  margin-right: auto;
-}
-thead, tbody {
-  border: 1px solid var(--line-color);
-}
-th, td {
-  text-align: left;
-  vertical-align: top;
-  padding: 5px 10px;
-}
-th {
-  background-color: var(--line-color);
-}
-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 {
-  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;
-}
-
-/* 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">August 2020</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Iyengar &amp; Swett</td>
-<td class="center">Expires 18 February 2021</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-08-17" class="published">17 August 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="2021-02-18">18 February 2021</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 18 February 2021.<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="toc ulEmpty compact">
-<li class="toc ulEmpty 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="toc ulEmpty 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="toc ulEmpty 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-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>
-</li>
-          <li class="toc ulEmpty 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-relevant-differences-betwee" class="xref">Relevant Differences Between QUIC and TCP</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-separate-packet-number-spac" class="xref">Separate Packet Number Spaces</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-monotonically-increasing-pa" class="xref">Monotonically Increasing Packet Numbers</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-clearer-loss-epoch" class="xref">Clearer Loss Epoch</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-no-reneging" class="xref">No Reneging</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-more-ack-ranges" class="xref">More ACK Ranges</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-explicit-correction-for-del" class="xref">Explicit Correction For Delayed Acknowledgements</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-probe-timeout-replaces-rto-" class="xref">Probe Timeout Replaces RTO and TLP</a><a href="#section-toc.1-1.4.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-the-minimum-congestion-wind" class="xref">The Minimum Congestion Window is Two Packets</a><a href="#section-toc.1-1.4.2.8.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty 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-estimating-the-round-trip-t" class="xref">Estimating the Round-Trip Time</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty 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-generating-rtt-samples" class="xref">Generating RTT samples</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty 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-estimating-min_rtt" class="xref">Estimating min_rtt</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty 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-estimating-smoothed_rtt-and" class="xref">Estimating smoothed_rtt and rttvar</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty 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-loss-detection" class="xref">Loss Detection</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-acknowledgement-based-detec" class="xref">Acknowledgement-Based Detection</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.6.2.1.2.1">
-                    <p id="section-toc.1-1.6.2.1.2.1.1"><a href="#section-6.1.1" class="xref">6.1.1</a>.  <a href="#name-packet-threshold" class="xref">Packet Threshold</a><a href="#section-toc.1-1.6.2.1.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.1.2.2">
-                    <p id="section-toc.1-1.6.2.1.2.2.1"><a href="#section-6.1.2" class="xref">6.1.2</a>.  <a href="#name-time-threshold" class="xref">Time Threshold</a><a href="#section-toc.1-1.6.2.1.2.2.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" 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-probe-timeout" class="xref">Probe Timeout</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-computing-pto" class="xref">Computing PTO</a><a href="#section-toc.1-1.6.2.2.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" 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-handshakes-and-new-paths" class="xref">Handshakes and New Paths</a><a href="#section-toc.1-1.6.2.2.2.2.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" 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-speeding-up-handshake-compl" class="xref">Speeding Up Handshake Completion</a><a href="#section-toc.1-1.6.2.2.2.3.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.2.2.4">
-                    <p id="section-toc.1-1.6.2.2.2.4.1"><a href="#section-6.2.4" class="xref">6.2.4</a>.  <a href="#name-sending-probe-packets" class="xref">Sending Probe Packets</a><a href="#section-toc.1-1.6.2.2.2.4.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" 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-handling-retry-packets" class="xref">Handling Retry Packets</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-discarding-keys-and-packet-" class="xref">Discarding Keys and Packet State</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty 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-congestion-control" class="xref">Congestion Control</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-explicit-congestion-notific" class="xref">Explicit Congestion Notification</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-initial-and-minimum-congest" class="xref">Initial and Minimum Congestion Window</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-slow-start" class="xref">Slow Start</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-congestion-avoidance" class="xref">Congestion Avoidance</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-recovery-period" class="xref">Recovery Period</a><a href="#section-toc.1-1.7.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-ignoring-loss-of-undecrypta" class="xref">Ignoring Loss of Undecryptable Packets</a><a href="#section-toc.1-1.7.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-probe-timeout-2" class="xref">Probe Timeout</a><a href="#section-toc.1-1.7.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.7.2.8">
-                <p id="section-toc.1-1.7.2.8.1"><a href="#section-7.8" class="xref">7.8</a>.  <a href="#name-persistent-congestion" class="xref">Persistent Congestion</a><a href="#section-toc.1-1.7.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.7.2.9">
-                <p id="section-toc.1-1.7.2.9.1"><a href="#section-7.9" class="xref">7.9</a>.  <a href="#name-pacing" class="xref">Pacing</a><a href="#section-toc.1-1.7.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.7.2.10">
-                <p id="section-toc.1-1.7.2.10.1"><a href="#section-7.10" class="xref">7.10</a>. <a href="#name-under-utilizing-the-congest" class="xref">Under-utilizing the Congestion Window</a><a href="#section-toc.1-1.7.2.10.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty 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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-congestion-signals" class="xref">Congestion Signals</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-traffic-analysis" class="xref">Traffic Analysis</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-misreporting-ecn-markings" class="xref">Misreporting ECN Markings</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="toc ulEmpty compact" 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-references" class="xref">References</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" id="section-toc.1-1.11">
-            <p id="section-toc.1-1.11.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.11.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.11.2.1">
-                <p id="section-toc.1-1.11.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.11.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.11.2.1.2.1">
-                    <p id="section-toc.1-1.11.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.11.2.1.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.2">
-                <p id="section-toc.1-1.11.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.11.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.3">
-                <p id="section-toc.1-1.11.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.11.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.4">
-                <p id="section-toc.1-1.11.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.11.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.5">
-                <p id="section-toc.1-1.11.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.11.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.6">
-                <p id="section-toc.1-1.11.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.11.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.7">
-                <p id="section-toc.1-1.11.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.11.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.8">
-                <p id="section-toc.1-1.11.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.11.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.9">
-                <p id="section-toc.1-1.11.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.11.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.10">
-                <p id="section-toc.1-1.11.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.11.2.10.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" id="section-toc.1-1.12">
-            <p id="section-toc.1-1.12.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.12.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.12.2.1">
-                <p id="section-toc.1-1.12.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.12.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.2">
-                <p id="section-toc.1-1.12.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.12.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.3">
-                <p id="section-toc.1-1.12.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.12.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.4">
-                <p id="section-toc.1-1.12.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.12.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.5">
-                <p id="section-toc.1-1.12.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.12.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.6">
-                <p id="section-toc.1-1.12.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.12.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.7">
-                <p id="section-toc.1-1.12.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.12.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.8">
-                <p id="section-toc.1-1.12.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.12.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.12.2.9">
-                <p id="section-toc.1-1.12.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.12.2.9.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" id="section-toc.1-1.13">
-            <p id="section-toc.1-1.13.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.13.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.13.2.1">
-                <p id="section-toc.1-1.13.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-28</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.2">
-                <p id="section-toc.1-1.13.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-27</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.3">
-                <p id="section-toc.1-1.13.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-26</a><a href="#section-toc.1-1.13.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.4">
-                <p id="section-toc.1-1.13.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-25</a><a href="#section-toc.1-1.13.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.5">
-                <p id="section-toc.1-1.13.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-24</a><a href="#section-toc.1-1.13.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.6">
-                <p id="section-toc.1-1.13.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-23</a><a href="#section-toc.1-1.13.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.7">
-                <p id="section-toc.1-1.13.2.7.1"><a href="#section-c.7" class="xref">C.7</a>.  <a href="#name-since-draft-ietf-quic-recovery-22" class="xref">Since draft-ietf-quic-recovery-22</a><a href="#section-toc.1-1.13.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.8">
-                <p id="section-toc.1-1.13.2.8.1"><a href="#section-c.8" class="xref">C.8</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.13.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.9">
-                <p id="section-toc.1-1.13.2.9.1"><a href="#section-c.9" class="xref">C.9</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.13.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.10">
-                <p id="section-toc.1-1.13.2.10.1"><a href="#section-c.10" class="xref">C.10</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.13.2.10.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.11">
-                <p id="section-toc.1-1.13.2.11.1"><a href="#section-c.11" class="xref">C.11</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.13.2.11.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.12">
-                <p id="section-toc.1-1.13.2.12.1"><a href="#section-c.12" class="xref">C.12</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.13.2.12.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.13">
-                <p id="section-toc.1-1.13.2.13.1"><a href="#section-c.13" class="xref">C.13</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.13.2.13.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.14">
-                <p id="section-toc.1-1.13.2.14.1"><a href="#section-c.14" class="xref">C.14</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.13.2.14.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.15">
-                <p id="section-toc.1-1.13.2.15.1"><a href="#section-c.15" class="xref">C.15</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.13.2.15.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.16">
-                <p id="section-toc.1-1.13.2.16.1"><a href="#section-c.16" class="xref">C.16</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.13.2.16.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.17">
-                <p id="section-toc.1-1.13.2.17.1"><a href="#section-c.17" class="xref">C.17</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.13.2.17.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.18">
-                <p id="section-toc.1-1.13.2.18.1"><a href="#section-c.18" class="xref">C.18</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.13.2.18.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.19">
-                <p id="section-toc.1-1.13.2.19.1"><a href="#section-c.19" class="xref">C.19</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.13.2.19.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.20">
-                <p id="section-toc.1-1.13.2.20.1"><a href="#section-c.20" class="xref">C.20</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.13.2.20.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.21">
-                <p id="section-toc.1-1.13.2.21.1"><a href="#section-c.21" class="xref">C.21</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.13.2.21.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.22">
-                <p id="section-toc.1-1.13.2.22.1"><a href="#section-c.22" class="xref">C.22</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.13.2.22.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.23">
-                <p id="section-toc.1-1.13.2.23.1"><a href="#section-c.23" class="xref">C.23</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.13.2.23.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.24">
-                <p id="section-toc.1-1.13.2.24.1"><a href="#section-c.24" class="xref">C.24</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.13.2.24.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.25">
-                <p id="section-toc.1-1.13.2.25.1"><a href="#section-c.25" class="xref">C.25</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.13.2.25.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.26">
-                <p id="section-toc.1-1.13.2.26.1"><a href="#section-c.26" class="xref">C.26</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.13.2.26.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.27">
-                <p id="section-toc.1-1.13.2.27.1"><a href="#section-c.27" class="xref">C.27</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.13.2.27.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.28">
-                <p id="section-toc.1-1.13.2.28.1"><a href="#section-c.28" class="xref">C.28</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.13.2.28.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.13.2.29">
-                <p id="section-toc.1-1.13.2.29.1"><a href="#section-c.29" class="xref">C.29</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.13.2.29.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" id="section-toc.1-1.14">
-            <p id="section-toc.1-1.14.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.14.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="toc ulEmpty compact" id="section-toc.1-1.15">
-            <p id="section-toc.1-1.15.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="toc ulEmpty compact" id="section-toc.1-1.16">
-            <p id="section-toc.1-1.16.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.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">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>
-<span class="break"></span><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 acknowledgement 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 discarded 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; this 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>
-</section>
-</div>
-<div id="relevant-differences-between-quic-and-tcp">
-<section id="section-4">
-      <h2 id="name-relevant-differences-betwee">
-<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-relevant-differences-betwee" class="section-name selfRef">Relevant Differences Between QUIC and TCP</a>
-      </h2>
-<p id="section-4-1">Readers familiar with TCP's loss detection and congestion control will find
-algorithms here that parallel well-known TCP ones. However, protocol differences
-between QUIC and TCP contribute to algorithmic differences. These protocol
-differences are briefly described below.<a href="#section-4-1" class="pilcrow">¶</a></p>
-<div id="separate-packet-number-spaces">
-<section id="section-4.1">
-        <h3 id="name-separate-packet-number-spac">
-<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-separate-packet-number-spac" class="section-name selfRef">Separate Packet Number Spaces</a>
-        </h3>
-<p id="section-4.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-4.1-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="monotonically-increasing-packet-numbers">
-<section id="section-4.2">
-        <h3 id="name-monotonically-increasing-pa">
-<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-monotonically-increasing-pa" class="section-name selfRef">Monotonically Increasing Packet Numbers</a>
-        </h3>
-<p id="section-4.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-4.2-1" class="pilcrow">¶</a></p>
-<p id="section-4.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 includes 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-4.2-2" class="pilcrow">¶</a></p>
-<p id="section-4.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-4.2-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="clearer-loss-epoch">
-<section id="section-4.3">
-        <h3 id="name-clearer-loss-epoch">
-<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-clearer-loss-epoch" class="section-name selfRef">Clearer Loss Epoch</a>
-        </h3>
-<p id="section-4.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-4.3-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="no-reneging">
-<section id="section-4.4">
-        <h3 id="name-no-reneging">
-<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-no-reneging" class="section-name selfRef">No Reneging</a>
-        </h3>
-<p id="section-4.4-1">QUIC ACKs contain information that is similar to TCP SACK, but QUIC does not
-allow any acknowledged packet to be reneged, greatly simplifying implementations
-on both sides and reducing memory pressure on the sender.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="more-ack-ranges">
-<section id="section-4.5">
-        <h3 id="name-more-ack-ranges">
-<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-more-ack-ranges" class="section-name selfRef">More ACK Ranges</a>
-        </h3>
-<p id="section-4.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-4.5-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="explicit-correction-for-delayed-acknowledgements">
-<section id="section-4.6">
-        <h3 id="name-explicit-correction-for-del">
-<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-explicit-correction-for-del" class="section-name selfRef">Explicit Correction For Delayed Acknowledgements</a>
-        </h3>
-<p id="section-4.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-4.6-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="probe-timeout-replaces-rto-and-tlp">
-<section id="section-4.7">
-        <h3 id="name-probe-timeout-replaces-rto-">
-<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-probe-timeout-replaces-rto-" class="section-name selfRef">Probe Timeout Replaces RTO and TLP</a>
-        </h3>
-<p id="section-4.7-1">QUIC uses a probe timeout (PTO; see <a href="#pto" class="xref">Section 6.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 7.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-4.7-1" class="pilcrow">¶</a></p>
-<p id="section-4.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-4.7-2" class="pilcrow">¶</a></p>
-<p id="section-4.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 7.8</a>.<a href="#section-4.7-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="the-minimum-congestion-window-is-two-packets">
-<section id="section-4.8">
-        <h3 id="name-the-minimum-congestion-wind">
-<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-the-minimum-congestion-wind" class="section-name selfRef">The Minimum Congestion Window is Two Packets</a>
-        </h3>
-<p id="section-4.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 6.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-4.8-1" class="pilcrow">¶</a></p>
-<p id="section-4.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 6.2</a>).<a href="#section-4.8-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="compute-rtt">
-<section id="section-5">
-      <h2 id="name-estimating-the-round-trip-t">
-<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-estimating-the-round-trip-t" class="section-name selfRef">Estimating the Round-Trip Time</a>
-      </h2>
-<p id="section-5-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-5-1" class="pilcrow">¶</a></p>
-<div id="latest-rtt">
-<section id="section-5.1">
-        <h3 id="name-generating-rtt-samples">
-<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-generating-rtt-samples" class="section-name selfRef">Generating RTT samples</a>
-        </h3>
-<p id="section-5.1-1">An endpoint generates an RTT sample on receiving an ACK frame that meets the
-following two conditions:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-5.1-2.1">the largest acknowledged packet number is newly acknowledged, and<a href="#section-5.1-2.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.1-2.2">at least one of the newly acknowledged packets was ack-eliciting.<a href="#section-5.1-2.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-5.1-3">The RTT sample, latest_rtt, is generated as the time elapsed since the largest
-acknowledged packet was sent:<a href="#section-5.1-3" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-5.1-4">
-<pre>
-latest_rtt = ack_time - send_time_of_largest_acked
-</pre><a href="#section-5.1-4" class="pilcrow">¶</a>
-</div>
-<p id="section-5.1-5">An RTT sample is generated using only the largest acknowledged packet in the
-received ACK frame.  This is because a peer reports acknowledgment delays for
-only the largest acknowledged packet in an ACK frame.  While the reported
-acknowledgment 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 5.3</a>).<a href="#section-5.1-5" class="pilcrow">¶</a></p>
-<p id="section-5.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-5.1-6" class="pilcrow">¶</a></p>
-<p id="section-5.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-5.1-7" class="pilcrow">¶</a></p>
-<p id="section-5.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-5.1-8" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="min-rtt">
-<section id="section-5.2">
-        <h3 id="name-estimating-min_rtt">
-<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-estimating-min_rtt" class="section-name selfRef">Estimating min_rtt</a>
-        </h3>
-<p id="section-5.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-5.2-1" class="pilcrow">¶</a></p>
-<p id="section-5.2-2">An endpoint uses only locally observed times in computing the min_rtt and does
-not adjust for acknowledgment 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 5.3</a>), and limits potential underestimation due to
-erroneously-reported delays by the peer.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
-<p id="section-5.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 to be included in
-smoothed_rtt.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="smoothed-rtt">
-<section id="section-5.3">
-        <h3 id="name-estimating-smoothed_rtt-and">
-<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-estimating-smoothed_rtt-and" class="section-name selfRef">Estimating smoothed_rtt and rttvar</a>
-        </h3>
-<p id="section-5.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-5.3-1" class="pilcrow">¶</a></p>
-<p id="section-5.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 Application Data 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 acknowledgment 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-5.3-2" class="pilcrow">¶</a></p>
-<p id="section-5.3-3">When adjusting an RTT sample using peer-reported acknowledgement delays, an
-endpoint:<a href="#section-5.3-3" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-5.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-5.3-4.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.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-5.3-4.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.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-5.3-4.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-5.3-5">smoothed_rtt and rttvar are computed as follows, similar to <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>.<a href="#section-5.3-5" class="pilcrow">¶</a></p>
-<p id="section-5.3-6">When there are no samples for a network path, and on the first RTT sample for
-the network path:<a href="#section-5.3-6" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-5.3-7">
-<pre>
-smoothed_rtt = rtt_sample
-rttvar = rtt_sample / 2
-</pre><a href="#section-5.3-7" class="pilcrow">¶</a>
-</div>
-<p id="section-5.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-5.3-8" class="pilcrow">¶</a></p>
-<p id="section-5.3-9">On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:<a href="#section-5.3-9" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-5.3-10">
-<pre>
-ack_delay = acknowledgement delay from ACK frame
-ack_delay = min(ack_delay, 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-5.3-10" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="loss-detection">
-<section id="section-6">
-      <h2 id="name-loss-detection">
-<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-loss-detection" class="section-name selfRef">Loss Detection</a>
-      </h2>
-<p id="section-6-1">QUIC senders use acknowledgements to detect lost packets, and a probe
-time out (see <a href="#pto" class="xref">Section 6.2</a>) to ensure acknowledgements are received. This section
-provides a description of these algorithms.<a href="#section-6-1" class="pilcrow">¶</a></p>
-<p id="section-6-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 discarding the
-frame.  For more information, see Section 13.3 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">Loss detection is separate per packet number space, unlike RTT measurement and
-congestion control, because RTT and congestion control are properties of the
-path, whereas loss detection also relies upon key availability.<a href="#section-6-3" class="pilcrow">¶</a></p>
-<div id="ack-loss-detection">
-<section id="section-6.1">
-        <h3 id="name-acknowledgement-based-detec">
-<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-acknowledgement-based-detec" class="section-name selfRef">Acknowledgement-Based Detection</a>
-        </h3>
-<p id="section-6.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-6.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.1-2">A packet is declared lost if it meets all the following conditions:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-6.1-3.1">The packet is unacknowledged, in-flight, and was sent prior to an
-acknowledged packet.<a href="#section-6.1-3.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-6.1-3.2">Either its packet number is kPacketThreshold smaller than an acknowledged
-packet (<a href="#packet-threshold" class="xref">Section 6.1.1</a>), or it was sent long enough in the past
-(<a href="#time-threshold" class="xref">Section 6.1.2</a>).<a href="#section-6.1-3.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-6.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-6.1-4" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.1-5" class="pilcrow">¶</a></p>
-<div id="packet-threshold">
-<section id="section-6.1.1">
-          <h4 id="name-packet-threshold">
-<a href="#section-6.1.1" class="section-number selfRef">6.1.1. </a><a href="#name-packet-threshold" class="section-name selfRef">Packet Threshold</a>
-          </h4>
-<p id="section-6.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>).  In order to remain similar to TCP,
-implementations SHOULD NOT use a packet threshold less than 3; see <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>.<a href="#section-6.1.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.1.1-2">Some networks may exhibit higher degrees of packet reordering, causing a sender
-to detect spurious losses. Additionally, packet reordering could be more common
-with QUIC than TCP, because network elements that could observe and fix the
-order of reordered TCP packets cannot do that for QUIC. Algorithms that increase
-the reordering threshold after spuriously detecting losses, such as RACK
-<span>[<a href="#RACK" class="xref">RACK</a>]</span>, have proven to be useful in TCP and are expected to at least as
-useful in QUIC.<a href="#section-6.1.1-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="time-threshold">
-<section id="section-6.1.2">
-          <h4 id="name-time-threshold">
-<a href="#section-6.1.2" class="section-number selfRef">6.1.2. </a><a href="#name-time-threshold" class="section-name selfRef">Time Threshold</a>
-          </h4>
-<p id="section-6.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-6.1.2-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-6.1.2-2">
-<pre>
-max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)
-</pre><a href="#section-6.1.2-2" class="pilcrow">¶</a>
-</div>
-<p id="section-6.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-6.1.2-3" class="pilcrow">¶</a></p>
-<p id="section-6.1.2-4">Using max(smoothed_rtt, latest_rtt) protects from the two following cases:<a href="#section-6.1.2-4" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-6.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-6.1.2-5.1" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-6.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-6.1.2-5.2" class="pilcrow">¶</a>
-</li>
-          </ul>
-<p id="section-6.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-6.1.2-6" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.1.2-7" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="pto">
-<section id="section-6.2">
-        <h3 id="name-probe-timeout">
-<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-probe-timeout" class="section-name selfRef">Probe Timeout</a>
-        </h3>
-<p id="section-6.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-6.2-1" class="pilcrow">¶</a></p>
-<p id="section-6.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 6.1</a>.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
-<p id="section-6.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 (<span>[<a href="#RFC5682" class="xref">RFC5682</a>]</span>) algorithms for TCP.
-The timeout computation is based on TCP's retransmission timeout period
-(<span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>).<a href="#section-6.2-3" class="pilcrow">¶</a></p>
-<div id="computing-pto">
-<section id="section-6.2.1">
-          <h4 id="name-computing-pto">
-<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-computing-pto" class="section-name selfRef">Computing PTO</a>
-          </h4>
-<p id="section-6.2.1-1">When an ack-eliciting packet is transmitted, the sender schedules a timer for
-the PTO period as follows:<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-6.2.1-2">
-<pre>
-PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay
-</pre><a href="#section-6.2.1-2" class="pilcrow">¶</a>
-</div>
-<p id="section-6.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 round-trip 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-6.2.1-3" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-4">The PTO value MUST be set to at least kGranularity, to avoid the timer expiring
-immediately.<a href="#section-6.2.1-4" class="pilcrow">¶</a></p>
-<p id="section-6.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 ack-eliciting
-packet in the correct packet number space. When the PTO expires and there are
-no ack-eliciting packets in flight, the PTO is set from that moment.<a href="#section-6.2.1-5" class="pilcrow">¶</a></p>
-<p id="section-6.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 Application Data 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 Application Data 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-6.2.1-6" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.2.1-7" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.2.1-8" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-9">The life of a connection that is experiencing consecutive PTOs is limited by
-the endpoint's idle timeout.<a href="#section-6.2.1-9" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-10">The probe timer MUST NOT be set if the time threshold (<a href="#time-threshold" class="xref">Section 6.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-6.2.1-10" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="pto-handshake">
-<section id="section-6.2.2">
-          <h4 id="name-handshakes-and-new-paths">
-<a href="#section-6.2.2" class="section-number selfRef">6.2.2. </a><a href="#name-handshakes-and-new-paths" class="section-name selfRef">Handshakes and New Paths</a>
-          </h4>
-<p id="section-6.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-6.2.2-1" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.2.2-2" class="pilcrow">¶</a></p>
-<p id="section-6.2.2-3">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 <a href="#discarding-packets" class="xref">Section 6.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-6.2.2-3" class="pilcrow">¶</a></p>
-<div id="before-address-validation">
-<section id="section-6.2.2.1">
-            <h5 id="name-before-address-validation">
-<a href="#section-6.2.2.1" class="section-number selfRef">6.2.2.1. </a><a href="#name-before-address-validation" class="section-name selfRef">Before Address Validation</a>
-            </h5>
-<p id="section-6.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-6.2.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.2.2.1-2">Since the server could be blocked until more datagrams 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,
-even if there are no packets in flight. When the PTO fires, the client MUST
-send a Handshake packet if it has Handshake keys, otherwise it MUST
-send an Initial packet in a UDP datagram of at least 1200 bytes.<a href="#section-6.2.2.1-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="speeding-up-handshake-completion">
-<section id="section-6.2.3">
-          <h4 id="name-speeding-up-handshake-compl">
-<a href="#section-6.2.3" class="section-number selfRef">6.2.3. </a><a href="#name-speeding-up-handshake-compl" class="section-name selfRef">Speeding Up Handshake Completion</a>
-          </h4>
-<p id="section-6.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-6.2.3-1" class="pilcrow">¶</a></p>
-<p id="section-6.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 the address validation limits in Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-6.2.3-2" class="pilcrow">¶</a></p>
-<p id="section-6.2.3-3">Endpoints can also use coalesced packets to ensure that each datagram elicits at
-least one acknowledgement.  For example, a client 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-6.2.3-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="sending-probe-packets">
-<section id="section-6.2.4">
-          <h4 id="name-sending-probe-packets">
-<a href="#section-6.2.4" class="section-number selfRef">6.2.4. </a><a href="#name-sending-probe-packets" class="section-name selfRef">Sending Probe Packets</a>
-          </h4>
-<p id="section-6.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.  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-6.2.4-1" class="pilcrow">¶</a></p>
-<p id="section-6.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 Application Data in-flight,
-because the peer might only have receive keys for one of the two packet number
-spaces.<a href="#section-6.2.4-2" class="pilcrow">¶</a></p>
-<p id="section-6.2.4-3">If the sender wants to elicit a faster acknowledgement on PTO, it can skip a
-packet number to eliminate the acknowledgment delay.<a href="#section-6.2.4-3" class="pilcrow">¶</a></p>
-<p id="section-6.2.4-4">When the PTO timer expires, an ack-eliciting packet MUST be sent.  An endpoint
-SHOULD include new data in this packet.  Previously sent data MAY be sent if
-no new data can be sent.  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-6.2.4-4" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.2.4-5" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.2.4-6" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.2.4-7" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.2.4-8" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="handling-retry-packets">
-<section id="section-6.3">
-        <h3 id="name-handling-retry-packets">
-<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-handling-retry-packets" class="section-name selfRef">Handling Retry Packets</a>
-        </h3>
-<p id="section-6.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-6.3-1" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.3-2" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.3-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="discarding-packets">
-<section id="section-6.4">
-        <h3 id="name-discarding-keys-and-packet-">
-<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-discarding-keys-and-packet-" class="section-name selfRef">Discarding Keys and Packet State</a>
-        </h3>
-<p id="section-6.4-1">When packet protection keys are discarded (see Section 4.8 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-6.4-1" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.4-2" class="pilcrow">¶</a></p>
-<p id="section-6.4-3">When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
-discarded.<a href="#section-6.4-3" class="pilcrow">¶</a></p>
-<p id="section-6.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-6.4-4" class="pilcrow">¶</a></p>
-<p id="section-6.4-5">It is expected that keys are discarded after packets encrypted with them would
-be acknowledged or declared lost.  However, Initial secrets are discarded as
-soon as handshake keys are proven to be available to both client and server;
-see Section 4.9.1 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-6.4-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="congestion-control">
-<section id="section-7">
-      <h2 id="name-congestion-control">
-<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-congestion-control" class="section-name selfRef">Congestion Control</a>
-      </h2>
-<p id="section-7-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-7-1" class="pilcrow">¶</a></p>
-<p id="section-7-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-7-2" class="pilcrow">¶</a></p>
-<p id="section-7-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-7-3" class="pilcrow">¶</a></p>
-<p id="section-7-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-7-4" class="pilcrow">¶</a></p>
-<p id="section-7-5">The algorithm in this document specifies and uses the controller's congestion
-window in bytes.<a href="#section-7-5" class="pilcrow">¶</a></p>
-<p id="section-7-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 6.2</a>.<a href="#section-7-6" class="pilcrow">¶</a></p>
-<div id="congestion-ecn">
-<section id="section-7.1">
-        <h3 id="name-explicit-congestion-notific">
-<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-explicit-congestion-notific" class="section-name selfRef">Explicit Congestion Notification</a>
-        </h3>
-<p id="section-7.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-7.1-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="initial-cwnd">
-<section id="section-7.2">
-        <h3 id="name-initial-and-minimum-congest">
-<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-initial-and-minimum-congest" class="section-name selfRef">Initial and Minimum Congestion Window</a>
-        </h3>
-<p id="section-7.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-7.2-1" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.2-2" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.2-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="slow-start">
-<section id="section-7.3">
-        <h3 id="name-slow-start">
-<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-slow-start" class="section-name selfRef">Slow Start</a>
-        </h3>
-<p id="section-7.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-7.3-1" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.3-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="congestion-avoidance">
-<section id="section-7.4">
-        <h3 id="name-congestion-avoidance">
-<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-congestion-avoidance" class="section-name selfRef">Congestion Avoidance</a>
-        </h3>
-<p id="section-7.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-7.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="recovery-period">
-<section id="section-7.5">
-        <h3 id="name-recovery-period">
-<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-recovery-period" class="section-name selfRef">Recovery Period</a>
-        </h3>
-<p id="section-7.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-7.5-1" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.5-2" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.5-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="ignoring-loss-of-undecryptable-packets">
-<section id="section-7.6">
-        <h3 id="name-ignoring-loss-of-undecrypta">
-<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-ignoring-loss-of-undecrypta" class="section-name selfRef">Ignoring Loss of Undecryptable Packets</a>
-        </h3>
-<p id="section-7.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-7.6-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="probe-timeout">
-<section id="section-7.7">
-        <h3 id="name-probe-timeout-2">
-<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-probe-timeout-2" class="section-name selfRef">Probe Timeout</a>
-        </h3>
-<p id="section-7.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-7.7-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="persistent-congestion">
-<section id="section-7.8">
-        <h3 id="name-persistent-congestion">
-<a href="#section-7.8" class="section-number selfRef">7.8. </a><a href="#name-persistent-congestion" class="section-name selfRef">Persistent Congestion</a>
-        </h3>
-<p id="section-7.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; see <span>[<a href="#RACK" class="xref">RACK</a>]</span>), before establishing
-persistent congestion, as TCP does with a Retransmission Timeout (RTO; see
-<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-7.8-1" class="pilcrow">¶</a></p>
-<p id="section-7.8-2">The persistent congestion period SHOULD NOT start until there is at
-least one RTT sample.  Prior to an RTT sample, the duration cannot be
-correctly calculated.  Waiting for one RTT sample also avoids spuriously
-declaring persistent congestion when the initial RTT is larger than the
-actual RTT.<a href="#section-7.8-2" class="pilcrow">¶</a></p>
-<p id="section-7.8-3">This duration is computed as follows:<a href="#section-7.8-3" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-7.8-4">
-<pre>
-(smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
-    kPersistentCongestionThreshold
-</pre><a href="#section-7.8-4" class="pilcrow">¶</a>
-</div>
-<p id="section-7.8-5">Unlike the PTO computation in <a href="#pto" class="xref">Section 6.2</a>, persistent congestion includes the
-max_ack_delay irrespective of the packet number spaces in which losses are
-established.<a href="#section-7.8-5" class="pilcrow">¶</a></p>
-<p id="section-7.8-6">The following example illustrates how persistent congestion can be
-established. Assume:<a href="#section-7.8-6" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-7.8-7">
-<pre>
-smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
-kPersistentCongestionThreshold = 3
-</pre><a href="#section-7.8-7" class="pilcrow">¶</a>
-</div>
-<p id="section-7.8-8">Consider the following sequence of events:<a href="#section-7.8-8" 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 packet #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 packet #2 (app data)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=1.2</td>
-              <td class="text-left" rowspan="1" colspan="1">Recv acknowledgement of #1</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=2</td>
-              <td class="text-left" rowspan="1" colspan="1">Send packet #3 (app data)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=3</td>
-              <td class="text-left" rowspan="1" colspan="1">Send packet #4 (app data)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=4</td>
-              <td class="text-left" rowspan="1" colspan="1">Send packet #5 (app data)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=5</td>
-              <td class="text-left" rowspan="1" colspan="1">Send packet #6 (app data)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=6</td>
-              <td class="text-left" rowspan="1" colspan="1">Send packet #7 (app data)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=8</td>
-              <td class="text-left" rowspan="1" colspan="1">Send packet #8 (PTO 1)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=12</td>
-              <td class="text-left" rowspan="1" colspan="1">Send packet #9 (PTO 2)</td>
-            </tr>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">t=12.2</td>
-              <td class="text-left" rowspan="1" colspan="1">Recv acknowledgement of #9</td>
-            </tr>
-          </tbody>
-        </table>
-<p id="section-7.8-10">Packets 2 through 8 are declared lost when the acknowledgement for packet 9 is
-received at t = 12.2.<a href="#section-7.8-10" class="pilcrow">¶</a></p>
-<p id="section-7.8-11">The congestion period is calculated as the time between the oldest and newest
-lost packets: 8 - 1 = 7.  The duration for establishing persistent congestion
-is: 2 * 3 = 6.  Because the threshold was reached and because none of the
-packets between the oldest and the newest lost packets were acknowledged, the
-network is considered to have experienced persistent congestion.<a href="#section-7.8-11" class="pilcrow">¶</a></p>
-<p id="section-7.8-12">While this example shows the occurrence of PTOs, they are not required for
-persistent congestion to be established.<a href="#section-7.8-12" class="pilcrow">¶</a></p>
-<p id="section-7.8-13">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; see <span>[<a href="#RACK" class="xref">RACK</a>]</span>).<a href="#section-7.8-13" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="pacing">
-<section id="section-7.9">
-        <h3 id="name-pacing">
-<a href="#section-7.9" class="section-number selfRef">7.9. </a><a href="#name-pacing" class="section-name selfRef">Pacing</a>
-        </h3>
-<p id="section-7.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 7.2</a>.<a href="#section-7.9-1" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.9-2" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.9-3" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.9-4" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-7.9-5">
-<pre>
-rate = N * congestion_window / smoothed_rtt
-</pre><a href="#section-7.9-5" class="pilcrow">¶</a>
-</div>
-<p id="section-7.9-6">Or, expressed as an inter-packet interval:<a href="#section-7.9-6" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-7.9-7">
-<pre>
-interval = smoothed_rtt * packet_size / congestion_window / N
-</pre><a href="#section-7.9-7" class="pilcrow">¶</a>
-</div>
-<p id="section-7.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 do not 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-7.9-8" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.9-9" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.9-10" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="under-utilizing-the-congestion-window">
-<section id="section-7.10">
-        <h3 id="name-under-utilizing-the-congest">
-<a href="#section-7.10" class="section-number selfRef">7.10. </a><a href="#name-under-utilizing-the-congest" class="section-name selfRef">Under-utilizing the Congestion Window</a>
-        </h3>
-<p id="section-7.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-7.10-1" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.10-2" class="pilcrow">¶</a></p>
-<p id="section-7.10-3">A sender that paces packets (see <a href="#pacing" class="xref">Section 7.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-7.10-3" class="pilcrow">¶</a></p>
-<p id="section-7.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-7.10-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="security-considerations">
-<section id="section-8">
-      <h2 id="name-security-considerations">
-<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
-      </h2>
-<div id="congestion-signals">
-<section id="section-8.1">
-        <h3 id="name-congestion-signals">
-<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-congestion-signals" class="section-name selfRef">Congestion Signals</a>
-        </h3>
-<p id="section-8.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-8.1-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="traffic-analysis">
-<section id="section-8.2">
-        <h3 id="name-traffic-analysis">
-<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-traffic-analysis" class="section-name selfRef">Traffic Analysis</a>
-        </h3>
-<p id="section-8.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.  To reduce leaked information,
-endpoints can bundle acknowledgments with other frames, or they can use PADDING
-frames at a potential cost to performance.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="misreporting-ecn-markings">
-<section id="section-8.3">
-        <h3 id="name-misreporting-ecn-markings">
-<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-misreporting-ecn-markings" class="section-name selfRef">Misreporting ECN Markings</a>
-        </h3>
-<p id="section-8.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-8.3-1" class="pilcrow">¶</a></p>
-<p id="section-8.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-8.3-2" class="pilcrow">¶</a></p>
-<p id="section-8.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-8.3-3" class="pilcrow">¶</a></p>
-<p id="section-8.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-8.3-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="iana-considerations">
-<section id="section-9">
-      <h2 id="name-iana-considerations">
-<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
-      </h2>
-<p id="section-9-1">This document has no IANA actions.<a href="#section-9-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<section id="section-10">
-      <h2 id="name-references">
-<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
-      </h2>
-<section id="section-10.1">
-        <h3 id="name-normative-references">
-<a href="#section-10.1" class="section-number selfRef">10.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-08-17" class="refDate">17 August 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-08-17" class="refDate">17 August 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" class="refDate">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" class="refDate">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" class="refDate">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-10.2">
-        <h3 id="name-informative-references">
-<a href="#section-10.2" class="section-number selfRef">10.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" class="refDate">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-TLP: a time-based efficient loss detection for TCP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tcpm-rack-09</span>, <time datetime="2020-07-13" class="refDate">13 July 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-09.txt">http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-09.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" class="refDate">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="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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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 6</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>
-<span class="break"></span><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 max_ack_delay.<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>
-<span class="break"></span><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 6.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 6.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 6.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 6.2.2</a> is 333ms.<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>
-<span class="break"></span><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 5.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 5.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 acknowledgment delay, as
-described in <a href="#min-rtt" class="xref">Section 5.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 Application Data 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 = kInitialRtt
-   rttvar = kInitialRtt / 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].sent_bytes =
-       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>
-IncludesAckEliciting(packets):
-  for packet in packets:
-    if (packet.ack_eliciting):
-      return true
-  return false
-
-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)
-
-  // DetectAndRemoveAckedPackets 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() - newly_acked_packets.largest().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 acknowledgment 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 acknowledgment 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 Application Data until handshake complete.
-      if (handshake is not complete):
-        return pto_timeout, pto_space
-      // Include max_ack_delay and backoff for Application Data.
-      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 = DetectAndRemoveLostPackets(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(!PeerCompletedAddressValidation())
-    // 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 7</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>
-<span class="break"></span><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 7.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 7.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.
-<a href="#congestion-control" class="xref">Section 7</a> 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. <a href="#persistent-congestion" class="xref">Section 7.8</a> 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>
-<span class="break"></span><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 acknowledged 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 acked_packet in acked_packets:
-      OnPacketAcked(acked_packet)
-
-  OnPacketAcked(acked_packet):
-    // Remove from bytes_in_flight.
-    bytes_in_flight -= acked_packet.sent_bytes
-
-    // Do not increase congestion_window if application
-    // limited or flow control limited.
-    if (IsAppOrFlowControlLimited())
-      return
-
-    // Do not increase congestion window in recovery period.
-    if (InCongestionRecovery(acked_packet.time_sent)):
-      return
-
-    if (congestion_window &lt; ssthresh):
-      // Slow start.
-      congestion_window += acked_packet.sent_bytes
-    else:
-      // Congestion avoidance.
-      congestion_window +=
-        max_datagram_size * acked_packet.sent_bytes
-        / 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>
-   OnCongestionEvent(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
-       sent_time = sent_packets[ack.largest_acked].time_sent
-       OnCongestionEvent(sent_time)
-</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 when DetectAndRemoveLostPackets deems packets lost.<a href="#section-b.8-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-b.8-2">
-<pre>
-   InPersistentCongestion(largest_lost):
-     // Persistent congestion cannot be declared on the
-     // first RTT sample.
-     if (is first RTT sample):
-       return false
-     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 and
-     // across all packet number spaces, are marked lost.
-     return AreAllPacketsLost(largest_lost, congestion_period)
-
-   OnPacketsLost(lost_packets):
-     // Remove lost packets from bytes_in_flight.
-     for lost_packet in lost_packets:
-       bytes_in_flight -= lost_packet.sent_bytes
-     OnCongestionEvent(lost_packets.largest().time_sent)
-
-     // Collapse congestion window if persistent congestion
-     if (InPersistentCongestion(lost_packets.largest())):
-       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-28">
-<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-28</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.1-1.1">Refactored pseudocode to correct PTO calculation (#3564, #3674, #3681)<a href="#section-c.1-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-27">
-<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-27</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.2-1.1">Added recommendations for speeding up handshake under some loss conditions
-(#3078, #3080)<a href="#section-c.2-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.2">PTO count is reset when handshake progress is made (#3272, #3415)<a href="#section-c.2-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.3">PTO count is not reset by a client when the server might be awaiting
-address validation (#3546, #3551)<a href="#section-c.2-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.4">Recommend repairing losses immediately after entering the recovery period
-(#3335, #3443)<a href="#section-c.2-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.5">Clarified what loss conditions can be ignored during the handshake (#3456,
-#3450)<a href="#section-c.2-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.6">Allow, but don't recommend, using RTT from previous connection to seed RTT
-(#3464, #3496)<a href="#section-c.2-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.7">Recommend use of adaptive loss detection thresholds (#3571, #3572)<a href="#section-c.2-1.7" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-26">
-<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-26</a>
-        </h2>
-<p id="section-c.3-1">No changes.<a href="#section-c.3-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-25">
-<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-25</a>
-        </h2>
-<p id="section-c.4-1">No significant changes.<a href="#section-c.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-24">
-<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-24</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.5-1.1">Require congestion control of some sort (#3247, #3244, #3248)<a href="#section-c.5-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.2">Set a minimum reordering threshold (#3256, #3240)<a href="#section-c.5-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.3">PTO is specific to a packet number space (#3067, #3074, #3066)<a href="#section-c.5-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-23">
-<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-23</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.6-1.1">Define under-utilizing the congestion window (#2630, #2686, #2675)<a href="#section-c.6-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.2">PTO MUST send data if possible (#3056, #3057)<a href="#section-c.6-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.3">Connection Close is not ack-eliciting (#3097, #3098)<a href="#section-c.6-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.4">MUST limit bursts to the initial congestion window (#3160)<a href="#section-c.6-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.5">Define the current max_datagram_size for congestion control
-(#3041, #3167)<a href="#section-c.6-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-22">
-<section id="section-c.7">
-        <h2 id="name-since-draft-ietf-quic-recovery-22">
-<a href="#section-c.7" class="section-number selfRef">C.7. </a><a href="#name-since-draft-ietf-quic-recovery-22" class="section-name selfRef">Since draft-ietf-quic-recovery-22</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.7-1.1">PTO should always send an ack-eliciting packet (#2895)<a href="#section-c.7-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.2">Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886)<a href="#section-c.7-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.3">Move ACK generation text to transport draft (#1860, #2916)<a href="#section-c.7-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-21">
-<section id="section-c.8">
-        <h2 id="name-since-draft-ietf-quic-recovery-21">
-<a href="#section-c.8" class="section-number selfRef">C.8. </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.8-1.1">No changes<a href="#section-c.8-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-20">
-<section id="section-c.9">
-        <h2 id="name-since-draft-ietf-quic-recovery-20">
-<a href="#section-c.9" class="section-number selfRef">C.9. </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.9-1.1">Path validation can be used as initial RTT value (#2644, #2687)<a href="#section-c.9-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.2">max_ack_delay transport parameter defaults to 0 (#2638, #2646)<a href="#section-c.9-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.3">ACK delay only measures intentional delays induced by the implementation
-(#2596, #2786)<a href="#section-c.9-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-19">
-<section id="section-c.10">
-        <h2 id="name-since-draft-ietf-quic-recovery-1">
-<a href="#section-c.10" class="section-number selfRef">C.10. </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.10-1.1">Change kPersistentThreshold from an exponent to a multiplier (#2557)<a href="#section-c.10-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.2">Send a PING if the PTO timer fires and there's nothing to send (#2624)<a href="#section-c.10-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.3">Set loss delay to at least kGranularity (#2617)<a href="#section-c.10-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-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.10-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-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.10-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.6">Don't arm the handshake timer if there is no handshake data (#2590)<a href="#section-c.10-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.7">Clarify that the time threshold loss alarm takes precedence over the
-crypto handshake timer (#2590, #2620)<a href="#section-c.10-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.8">Change initial RTT to 500ms to align with RFC6298 (#2184)<a href="#section-c.10-1.8" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-18">
-<section id="section-c.11">
-        <h2 id="name-since-draft-ietf-quic-recovery-18">
-<a href="#section-c.11" class="section-number selfRef">C.11. </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.11-1.1">Change IW byte limit to 14720 from 14600 (#2494)<a href="#section-c.11-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.2">Update PTO calculation to match RFC6298 (#2480, #2489, #2490)<a href="#section-c.11-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.3">Improve loss detection's description of multiple packet number spaces and
-pseudocode (#2485, #2451, #2417)<a href="#section-c.11-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-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.11-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.5">Move pseudocode to the appendices (#2408)<a href="#section-c.11-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.6">What to send on multiple PTOs (#2380)<a href="#section-c.11-1.6" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-17">
-<section id="section-c.12">
-        <h2 id="name-since-draft-ietf-quic-recovery-17">
-<a href="#section-c.12" class="section-number selfRef">C.12. </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.12-1.1">After Probe Timeout discard in-flight packets or send another (#2212, #1965)<a href="#section-c.12-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.2">Endpoints discard initial keys as soon as handshake keys are available (#1951,
-#2045)<a href="#section-c.12-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.3">0-RTT state is discarded when 0-RTT is rejected (#2300)<a href="#section-c.12-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.4">Loss detection timer is cancelled when ack-eliciting frames are in flight
-(#2117, #2093)<a href="#section-c.12-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.5">Packets are declared lost if they are in flight (#2104)<a href="#section-c.12-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.6">After becoming idle, either pace packets or reset the congestion controller
-(#2138, 2187)<a href="#section-c.12-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.7">Process ECN counts before marking packets lost (#2142)<a href="#section-c.12-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.8">Mark packets lost before resetting crypto_count and pto_count (#2208, #2209)<a href="#section-c.12-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.9">Congestion and loss recovery state are discarded when keys are discarded
-(#2327)<a href="#section-c.12-1.9" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-16">
-<section id="section-c.13">
-        <h2 id="name-since-draft-ietf-quic-recovery-16">
-<a href="#section-c.13" class="section-number selfRef">C.13. </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.13-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.13-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.2">Redefine how congestion avoidance in terms of when the period starts (#1928,
-#1930)<a href="#section-c.13-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.3">Document what needs to be tracked for packets that are in flight (#765, #1724,
-#1939)<a href="#section-c.13-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.4">Integrate both time and packet thresholds into loss detection (#1969, #1212,
-#934, #1974)<a href="#section-c.13-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.5">Reduce congestion window after idle, unless pacing is used (#2007, #2023)<a href="#section-c.13-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.6">Disable RTT calculation for packets that don't elicit acknowledgment (#2060,
-#2078)<a href="#section-c.13-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.7">Limit ack_delay by max_ack_delay (#2060, #2099)<a href="#section-c.13-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.8">Initial keys are discarded once Handshake keys are available (#1951, #2045)<a href="#section-c.13-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.9">Reorder ECN and loss detection in pseudocode (#2142)<a href="#section-c.13-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.10">Only cancel loss detection timer if ack-eliciting packets are in flight
-(#2093, #2117)<a href="#section-c.13-1.10" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-14">
-<section id="section-c.14">
-        <h2 id="name-since-draft-ietf-quic-recovery-14">
-<a href="#section-c.14" class="section-number selfRef">C.14. </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.14-1.1">Used max_ack_delay from transport params (#1796, #1782)<a href="#section-c.14-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.14-1.2">Merge ACK and ACK_ECN (#1783)<a href="#section-c.14-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-13">
-<section id="section-c.15">
-        <h2 id="name-since-draft-ietf-quic-recovery-13">
-<a href="#section-c.15" class="section-number selfRef">C.15. </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.15-1.1">Corrected the lack of ssthresh reduction in CongestionEvent pseudocode (#1598)<a href="#section-c.15-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.2">Considerations for ECN spoofing (#1426, #1626)<a href="#section-c.15-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.3">Clarifications for PADDING and congestion control (#837, #838, #1517, #1531,
-#1540)<a href="#section-c.15-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.4">Reduce early retransmission timer to RTT/8 (#945, #1581)<a href="#section-c.15-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.5">Packets are declared lost after an RTO is verified (#935, #1582)<a href="#section-c.15-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-12">
-<section id="section-c.16">
-        <h2 id="name-since-draft-ietf-quic-recovery-12">
-<a href="#section-c.16" class="section-number selfRef">C.16. </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.16-1.1">Changes to manage separate packet number spaces and encryption levels (#1190,
-#1242, #1413, #1450)<a href="#section-c.16-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.2">Added ECN feedback mechanisms and handling; new ACK_ECN frame (#804, #805,
-#1372)<a href="#section-c.16-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-11">
-<section id="section-c.17">
-        <h2 id="name-since-draft-ietf-quic-recovery-11">
-<a href="#section-c.17" class="section-number selfRef">C.17. </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.17-1">No significant changes.<a href="#section-c.17-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-10">
-<section id="section-c.18">
-        <h2 id="name-since-draft-ietf-quic-recovery-10">
-<a href="#section-c.18" class="section-number selfRef">C.18. </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.18-1.1">Improved text on ack generation (#1139, #1159)<a href="#section-c.18-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.2">Make references to TCP recovery mechanisms informational (#1195)<a href="#section-c.18-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.3">Define time_of_last_sent_handshake_packet (#1171)<a href="#section-c.18-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.4">Added signal from TLS the data it includes needs to be sent in a Retry packet
-(#1061, #1199)<a href="#section-c.18-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.5">Minimum RTT (min_rtt) is initialized with an infinite value (#1169)<a href="#section-c.18-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-09">
-<section id="section-c.19">
-        <h2 id="name-since-draft-ietf-quic-recovery-0">
-<a href="#section-c.19" class="section-number selfRef">C.19. </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.19-1">No significant changes.<a href="#section-c.19-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-08">
-<section id="section-c.20">
-        <h2 id="name-since-draft-ietf-quic-recovery-08">
-<a href="#section-c.20" class="section-number selfRef">C.20. </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.20-1.1">Clarified pacing and RTO (#967, #977)<a href="#section-c.20-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-07">
-<section id="section-c.21">
-        <h2 id="name-since-draft-ietf-quic-recovery-07">
-<a href="#section-c.21" class="section-number selfRef">C.21. </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.21-1.1">Include ACK delay in RTO(and TLP) computations (#981)<a href="#section-c.21-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.2">ACK delay in SRTT computation (#961)<a href="#section-c.21-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.3">Default RTT and Slow Start (#590)<a href="#section-c.21-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.4">Many editorial fixes.<a href="#section-c.21-1.4" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-06">
-<section id="section-c.22">
-        <h2 id="name-since-draft-ietf-quic-recovery-06">
-<a href="#section-c.22" class="section-number selfRef">C.22. </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.22-1">No significant changes.<a href="#section-c.22-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-05">
-<section id="section-c.23">
-        <h2 id="name-since-draft-ietf-quic-recovery-05">
-<a href="#section-c.23" class="section-number selfRef">C.23. </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.23-1.1">Add more congestion control text (#776)<a href="#section-c.23-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-04">
-<section id="section-c.24">
-        <h2 id="name-since-draft-ietf-quic-recovery-04">
-<a href="#section-c.24" class="section-number selfRef">C.24. </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.24-1">No significant changes.<a href="#section-c.24-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-03">
-<section id="section-c.25">
-        <h2 id="name-since-draft-ietf-quic-recovery-03">
-<a href="#section-c.25" class="section-number selfRef">C.25. </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.25-1">No significant changes.<a href="#section-c.25-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-02">
-<section id="section-c.26">
-        <h2 id="name-since-draft-ietf-quic-recovery-02">
-<a href="#section-c.26" class="section-number selfRef">C.26. </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.26-1.1">Integrate F-RTO (#544, #409)<a href="#section-c.26-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.26-1.2">Add congestion control (#545, #395)<a href="#section-c.26-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.26-1.3">Require connection abort if a skipped packet was acknowledged (#415)<a href="#section-c.26-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.26-1.4">Simplify RTO calculations (#142, #417)<a href="#section-c.26-1.4" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-01">
-<section id="section-c.27">
-        <h2 id="name-since-draft-ietf-quic-recovery-01">
-<a href="#section-c.27" class="section-number selfRef">C.27. </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.27-1.1">Overview added to loss detection<a href="#section-c.27-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.2">Changes initial default RTT to 100ms<a href="#section-c.27-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.3">Added time-based loss detection and fixes early retransmit<a href="#section-c.27-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.4">Clarified loss recovery for handshake packets<a href="#section-c.27-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.5">Fixed references and made TCP references informative<a href="#section-c.27-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-recovery-00">
-<section id="section-c.28">
-        <h2 id="name-since-draft-ietf-quic-recovery-00">
-<a href="#section-c.28" class="section-number selfRef">C.28. </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.28-1.1">Improved description of constants and ACK behavior<a href="#section-c.28-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-iyengar-quic-loss-recovery-01">
-<section id="section-c.29">
-        <h2 id="name-since-draft-iyengar-quic-lo">
-<a href="#section-c.29" class="section-number selfRef">C.29. </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.29-1.1">Adopted as base for draft-ietf-quic-recovery<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 table of contents<a href="#section-c.29-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 Balasubramanian.<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/split-initial-close/draft-ietf-quic-recovery.txt b/split-initial-close/draft-ietf-quic-recovery.txt
deleted file mode 100644
index 774620927d..0000000000
--- a/split-initial-close/draft-ietf-quic-recovery.txt
+++ /dev/null
@@ -1,2632 +0,0 @@
-
-
-
-
-QUIC                                                     J. Iyengar, Ed.
-Internet-Draft                                                    Fastly
-Intended status: Standards Track                           I. Swett, Ed.
-Expires: 18 February 2021                                         Google
-                                                          17 August 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 18 February 2021.
-
-Copyright Notice
-
-   Copyright (c) 2020 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 1]
-
-Internet-Draft             QUIC Loss Detection               August 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
-   4.  Relevant Differences Between QUIC and TCP . . . . . . . . . .   5
-     4.1.  Separate Packet Number Spaces . . . . . . . . . . . . . .   6
-     4.2.  Monotonically Increasing Packet Numbers . . . . . . . . .   6
-     4.3.  Clearer Loss Epoch  . . . . . . . . . . . . . . . . . . .   6
-     4.4.  No Reneging . . . . . . . . . . . . . . . . . . . . . . .   7
-     4.5.  More ACK Ranges . . . . . . . . . . . . . . . . . . . . .   7
-     4.6.  Explicit Correction For Delayed Acknowledgements  . . . .   7
-     4.7.  Probe Timeout Replaces RTO and TLP  . . . . . . . . . . .   7
-     4.8.  The Minimum Congestion Window is Two Packets  . . . . . .   8
-   5.  Estimating the Round-Trip Time  . . . . . . . . . . . . . . .   8
-     5.1.  Generating RTT samples  . . . . . . . . . . . . . . . . .   8
-     5.2.  Estimating min_rtt  . . . . . . . . . . . . . . . . . . .   9
-     5.3.  Estimating smoothed_rtt and rttvar  . . . . . . . . . . .   9
-   6.  Loss Detection  . . . . . . . . . . . . . . . . . . . . . . .  11
-     6.1.  Acknowledgement-Based Detection . . . . . . . . . . . . .  11
-       6.1.1.  Packet Threshold  . . . . . . . . . . . . . . . . . .  12
-       6.1.2.  Time Threshold  . . . . . . . . . . . . . . . . . . .  12
-     6.2.  Probe Timeout . . . . . . . . . . . . . . . . . . . . . .  13
-       6.2.1.  Computing PTO . . . . . . . . . . . . . . . . . . . .  13
-       6.2.2.  Handshakes and New Paths  . . . . . . . . . . . . . .  15
-       6.2.3.  Speeding Up Handshake Completion  . . . . . . . . . .  16
-       6.2.4.  Sending Probe Packets . . . . . . . . . . . . . . . .  16
-     6.3.  Handling Retry Packets  . . . . . . . . . . . . . . . . .  17
-     6.4.  Discarding Keys and Packet State  . . . . . . . . . . . .  18
-   7.  Congestion Control  . . . . . . . . . . . . . . . . . . . . .  18
-     7.1.  Explicit Congestion Notification  . . . . . . . . . . . .  19
-     7.2.  Initial and Minimum Congestion Window . . . . . . . . . .  19
-     7.3.  Slow Start  . . . . . . . . . . . . . . . . . . . . . . .  19
-     7.4.  Congestion Avoidance  . . . . . . . . . . . . . . . . . .  20
-     7.5.  Recovery Period . . . . . . . . . . . . . . . . . . . . .  20
-     7.6.  Ignoring Loss of Undecryptable Packets  . . . . . . . . .  20
-     7.7.  Probe Timeout . . . . . . . . . . . . . . . . . . . . . .  21
-     7.8.  Persistent Congestion . . . . . . . . . . . . . . . . . .  21
-     7.9.  Pacing  . . . . . . . . . . . . . . . . . . . . . . . . .  23
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 2]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-     7.10. Under-utilizing the Congestion Window . . . . . . . . . .  24
-   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
-     8.1.  Congestion Signals  . . . . . . . . . . . . . . . . . . .  24
-     8.2.  Traffic Analysis  . . . . . . . . . . . . . . . . . . . .  24
-     8.3.  Misreporting ECN Markings . . . . . . . . . . . . . . . .  24
-   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
-   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
-     10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
-     10.2.  Informative References . . . . . . . . . . . . . . . . .  26
-   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 . . . . . . . . . . . . . . . . . . .  30
-     A.6.  On Receiving a Datagram . . . . . . . . . . . . . . . . .  30
-     A.7.  On Receiving an Acknowledgment  . . . . . . . . . . . . .  31
-     A.8.  Setting the Loss Detection Timer  . . . . . . . . . . . .  32
-     A.9.  On Timeout  . . . . . . . . . . . . . . . . . . . . . . .  34
-     A.10. Detecting Lost Packets  . . . . . . . . . . . . . . . . .  35
-   Appendix B.  Congestion Control Pseudocode  . . . . . . . . . . .  36
-     B.1.  Constants of interest . . . . . . . . . . . . . . . . . .  36
-     B.2.  Variables of interest . . . . . . . . . . . . . . . . . .  37
-     B.3.  Initialization  . . . . . . . . . . . . . . . . . . . . .  37
-     B.4.  On Packet Sent  . . . . . . . . . . . . . . . . . . . . .  38
-     B.5.  On Packet Acknowledgement . . . . . . . . . . . . . . . .  38
-     B.6.  On New Congestion Event . . . . . . . . . . . . . . . . .  39
-     B.7.  Process ECN Information . . . . . . . . . . . . . . . . .  39
-     B.8.  On Packets Lost . . . . . . . . . . . . . . . . . . . . .  39
-     B.9.  Upon dropping Initial or Handshake keys . . . . . . . . .  40
-   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  40
-     C.1.  Since draft-ietf-quic-recovery-28 . . . . . . . . . . . .  41
-     C.2.  Since draft-ietf-quic-recovery-27 . . . . . . . . . . . .  41
-     C.3.  Since draft-ietf-quic-recovery-26 . . . . . . . . . . . .  41
-     C.4.  Since draft-ietf-quic-recovery-25 . . . . . . . . . . . .  41
-     C.5.  Since draft-ietf-quic-recovery-24 . . . . . . . . . . . .  41
-     C.6.  Since draft-ietf-quic-recovery-23 . . . . . . . . . . . .  41
-     C.7.  Since draft-ietf-quic-recovery-22 . . . . . . . . . . . .  42
-     C.8.  Since draft-ietf-quic-recovery-21 . . . . . . . . . . . .  42
-     C.9.  Since draft-ietf-quic-recovery-20 . . . . . . . . . . . .  42
-     C.10. Since draft-ietf-quic-recovery-19 . . . . . . . . . . . .  42
-     C.11. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . .  43
-     C.12. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . .  43
-     C.13. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . .  44
-     C.14. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . .  44
-     C.15. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . .  44
-     C.16. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . .  45
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 3]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-     C.17. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . .  45
-     C.18. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . .  45
-     C.19. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . .  45
-     C.20. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . .  45
-     C.21. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . .  45
-     C.22. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . .  46
-     C.23. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . .  46
-     C.24. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . .  46
-     C.25. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . .  46
-     C.26. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . .  46
-     C.27. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . .  46
-     C.28. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . .  46
-     C.29. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . .  47
-   Appendix D.  Contributors . . . . . . . . . . . . . . . . . . . .  47
-   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  47
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  47
-
-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 acknowledgement
-      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 discarded along with old
-      keys.
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 4]
-
-Internet-Draft             QUIC Loss Detection               August 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; this 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.
-
-4.  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.
-   However, protocol differences between QUIC and TCP contribute to
-   algorithmic differences.  These protocol differences are briefly
-   described below.
-
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 5]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-4.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.
-
-4.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 includes
-   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.
-
-4.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 18 February 2021                [Page 6]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-4.4.  No Reneging
-
-   QUIC ACKs contain information that is similar to TCP SACK, but QUIC
-   does not allow any acknowledged packet to be reneged, greatly
-   simplifying implementations on both sides and reducing memory
-   pressure on the sender.
-
-4.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.
-
-4.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].
-
-4.7.  Probe Timeout Replaces RTO and TLP
-
-   QUIC uses a probe timeout (PTO; see Section 6.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 7.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 7.8.
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 7]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-4.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 6.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 6.2).
-
-5.  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).
-
-5.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
-   acknowledgment delays for only the largest acknowledged packet in an
-   ACK frame.  While the reported acknowledgment 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 5.3).
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 8]
-
-Internet-Draft             QUIC Loss Detection               August 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.
-
-5.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 acknowledgment 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 5.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 to be included in smoothed_rtt.
-
-5.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
-
-
-
-Iyengar & Swett         Expires 18 February 2021                [Page 9]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   [QUIC-TRANSPORT].  For packets sent in the Application Data 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 acknowledgment 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 = acknowledgement delay from ACK frame
-   ack_delay = min(ack_delay, 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 18 February 2021               [Page 10]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-6.  Loss Detection
-
-   QUIC senders use acknowledgements to detect lost packets, and a probe
-   time out (see Section 6.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 discarding the frame.  For more information, see Section 13.3 of
-   [QUIC-TRANSPORT].
-
-   Loss detection is separate per packet number space, unlike RTT
-   measurement and congestion control, because RTT and congestion
-   control are properties of the path, whereas loss detection also
-   relies upon key availability.
-
-6.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 6.1.1), or it was sent long enough in
-      the past (Section 6.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.
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 11]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-6.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]).  In order to remain similar to TCP,
-   implementations SHOULD NOT use a packet threshold less than 3; see
-   [RFC5681].
-
-   Some networks may exhibit higher degrees of packet reordering,
-   causing a sender to detect spurious losses.  Additionally, packet
-   reordering could be more common with QUIC than TCP, because network
-   elements that could observe and fix the order of reordered TCP
-   packets cannot do that for QUIC.  Algorithms that increase the
-   reordering threshold after spuriously detecting losses, such as RACK
-   [RACK], have proven to be useful in TCP and are expected to at least
-   as useful in QUIC.
-
-6.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.
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 12]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   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.
-
-6.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 6.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 ([RFC5682])
-   algorithms for TCP.  The timeout computation is based on TCP's
-   retransmission timeout period ([RFC6298]).
-
-6.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 round-trip 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
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 13]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   ensures the PTO is always set based on the latest RTT information and
-   for the last sent ack-eliciting packet in the correct packet number
-   space.  When the PTO expires and there are no ack-eliciting packets
-   in flight, the PTO is set from that moment.
-
-   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 Application Data packet
-   number space (Section 4.1.1 of [QUIC-TLS]) MUST be ignored until the
-   handshake completes.  Not arming the PTO for Application Data
-   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 6.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.
-
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 14]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-6.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.
-
-   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 6.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.
-
-6.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 datagrams 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, even if there are no packets in
-   flight.  When the PTO fires, the client MUST send a Handshake packet
-   if it has Handshake keys, otherwise it MUST send an Initial packet in
-   a UDP datagram of at least 1200 bytes.
-
-
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 15]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-6.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.
-
-   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 the address validation limits in
-   Section 8.1 of [QUIC-TRANSPORT].
-
-   Endpoints can also use coalesced packets to ensure that each datagram
-   elicits at least one acknowledgement.  For example, a client 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.
-
-6.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.  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 Application Data 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 acknowledgment delay.
-
-   When the PTO timer expires, an ack-eliciting packet MUST be sent.  An
-   endpoint SHOULD include new data in this packet.  Previously sent
-   data MAY be sent if no new data can be sent.  Implementations MAY use
-   alternative strategies for determining the content of probe packets,
-   including sending new or retransmitted data based on the
-   application's priorities.
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 16]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   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.
-
-   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.
-
-6.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.
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 17]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-6.4.  Discarding Keys and Packet State
-
-   When packet protection keys are discarded (see Section 4.8 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.
-
-   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.  However, Initial
-   secrets are discarded as soon as handshake keys are proven to be
-   available to both client and server; see Section 4.9.1 of [QUIC-TLS].
-
-7.  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.
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 18]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   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 6.2.
-
-7.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.
-
-7.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.
-
-7.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 18 February 2021               [Page 19]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-7.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.
-
-7.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.
-
-7.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 18 February 2021               [Page 20]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-7.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.
-
-7.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; see [RACK]), before establishing
-   persistent congestion, as TCP does with a Retransmission Timeout
-   (RTO; see [RFC5681]).  The RECOMMENDED value for
-   kPersistentCongestionThreshold is 3, which is approximately
-   equivalent to two TLPs before an RTO in TCP.
-
-   The persistent congestion period SHOULD NOT start until there is at
-   least one RTT sample.  Prior to an RTT sample, the duration cannot be
-   correctly calculated.  Waiting for one RTT sample also avoids
-   spuriously declaring persistent congestion when the initial RTT is
-   larger than the actual RTT.
-
-   This duration is computed as follows:
-
-   (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
-       kPersistentCongestionThreshold
-
-   Unlike the PTO computation in Section 6.2, persistent congestion
-   includes the max_ack_delay irrespective of the packet number spaces
-   in which losses are established.
-
-   The following example illustrates how persistent congestion can be
-   established.  Assume:
-
-   smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
-   kPersistentCongestionThreshold = 3
-
-   Consider the following sequence of events:
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 21]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-                  +========+============================+
-                  | Time   | Action                     |
-                  +========+============================+
-                  | t=0    | Send packet #1 (app data)  |
-                  +--------+----------------------------+
-                  | t=1    | Send packet #2 (app data)  |
-                  +--------+----------------------------+
-                  | t=1.2  | Recv acknowledgement of #1 |
-                  +--------+----------------------------+
-                  | t=2    | Send packet #3 (app data)  |
-                  +--------+----------------------------+
-                  | t=3    | Send packet #4 (app data)  |
-                  +--------+----------------------------+
-                  | t=4    | Send packet #5 (app data)  |
-                  +--------+----------------------------+
-                  | t=5    | Send packet #6 (app data)  |
-                  +--------+----------------------------+
-                  | t=6    | Send packet #7 (app data)  |
-                  +--------+----------------------------+
-                  | t=8    | Send packet #8 (PTO 1)     |
-                  +--------+----------------------------+
-                  | t=12   | Send packet #9 (PTO 2)     |
-                  +--------+----------------------------+
-                  | t=12.2 | Recv acknowledgement of #9 |
-                  +--------+----------------------------+
-
-                                  Table 1
-
-   Packets 2 through 8 are declared lost when the acknowledgement for
-   packet 9 is received at t = 12.2.
-
-   The congestion period is calculated as the time between the oldest
-   and newest lost packets: 8 - 1 = 7.  The duration for establishing
-   persistent congestion is: 2 * 3 = 6.  Because the threshold was
-   reached and because none of the packets between the oldest and the
-   newest lost packets were acknowledged, the network is considered to
-   have experienced persistent congestion.
-
-   While this example shows the occurrence of PTOs, they are not
-   required for persistent congestion to be established.
-
-   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; see [RACK]).
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 22]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-7.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 7.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.
-
-   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 do not 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.
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 23]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-7.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 7.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.
-
-   A sender MAY implement alternative mechanisms to update its
-   congestion window after periods of under-utilization, such as those
-   proposed for TCP in [RFC7661].
-
-8.  Security Considerations
-
-8.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.
-
-8.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.  To
-   reduce leaked information, endpoints can bundle acknowledgments with
-   other frames, or they can use PADDING frames at a potential cost to
-   performance.
-
-8.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.
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 24]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   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.
-
-9.  IANA Considerations
-
-   This document has no IANA actions.
-
-10.  References
-
-10.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, 17 August 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, 17
-              August 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>.
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 25]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-10.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-
-              TLP: a time-based efficient loss detection for TCP", Work
-              in Progress, Internet-Draft, draft-ietf-tcpm-rack-09, 13
-              July 2020, <http://www.ietf.org/internet-drafts/draft-
-              ietf-tcpm-rack-09.txt>.
-
-   [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>.
-
-   [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>.
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 26]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   [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>.
-
-   [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 6.
-
-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-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 27]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-      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 max_ack_delay.
-
-   in_flight:  A boolean that indicates whether the packet counts
-      towards bytes in flight.
-
-   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 6.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 6.1.2 is 9/8.
-
-   kGranularity:  Timer granularity.  This is a system-dependent value,
-      and Section 6.1.2 recommends a value of 1ms.
-
-   kInitialRtt:  The RTT used before an RTT sample is taken.  The value
-      recommended in Section 6.2.2 is 333ms.
-
-   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.
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 28]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   smoothed_rtt:  The smoothed RTT of the connection, computed as
-      described in Section 5.3.
-
-   rttvar:  The RTT variation, computed as described in Section 5.3.
-
-   min_rtt:  The minimum RTT seen in the connection, ignoring
-      acknowledgment delay, as described in Section 5.2.
-
-   max_ack_delay:  The maximum amount of time by which the receiver
-      intends to delay acknowledgments for packets in the Application
-      Data 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:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 29]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-      loss_detection_timer.reset()
-      pto_count = 0
-      latest_rtt = 0
-      smoothed_rtt = kInitialRtt
-      rttvar = kInitialRtt / 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.
-
-   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].sent_bytes =
-          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:
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 30]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   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:
-
-   IncludesAckEliciting(packets):
-     for packet in packets:
-       if (packet.ack_eliciting):
-         return true
-     return false
-
-   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)
-
-     // DetectAndRemoveAckedPackets 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 &&
-         IncludesAckEliciting(newly_acked_packets)):
-       latest_rtt =
-         now() - newly_acked_packets.largest().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):
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 31]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-         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 acknowledgment 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 acknowledgment delay if plausible.
-     adjusted_rtt = latest_rtt
-     if (latest_rtt > 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
-
-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:
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 32]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   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 Application Data until handshake complete.
-         if (handshake is not complete):
-           return pto_timeout, pto_space
-         // Include max_ack_delay and backoff for Application Data.
-         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():
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 33]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-     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 18 February 2021               [Page 34]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   OnLossDetectionTimeout():
-     earliest_loss_time, pn_space = GetLossTimeAndSpace()
-     if (earliest_loss_time != 0):
-       // Time threshold loss Detection
-       lost_packets = DetectAndRemoveLostPackets(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(!PeerCompletedAddressValidation())
-       // 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 18 February 2021               [Page 35]
-
-Internet-Draft             QUIC Loss Detection               August 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 7.
-
-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 7.2.
-
-   kMinimumWindow:  Minimum congestion window in bytes as described in
-      Section 7.2.
-
-   kLossReductionFactor:  Reduction in congestion window when a new loss
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 36]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-      event is detected.  Section 7 recommends a value is 0.5.
-
-   kPersistentCongestionThreshold:  Period of time for persistent
-      congestion to be established, specified as a PTO multiplier.
-      Section 7.8 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 acknowledged 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 18 February 2021               [Page 37]
-
-Internet-Draft             QUIC Loss Detection               August 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 acked_packet in acked_packets:
-         OnPacketAcked(acked_packet)
-
-     OnPacketAcked(acked_packet):
-       // Remove from bytes_in_flight.
-       bytes_in_flight -= acked_packet.sent_bytes
-
-       // Do not increase congestion_window if application
-       // limited or flow control limited.
-       if (IsAppOrFlowControlLimited())
-         return
-
-       // Do not increase congestion window in recovery period.
-       if (InCongestionRecovery(acked_packet.time_sent)):
-         return
-
-       if (congestion_window < ssthresh):
-         // Slow start.
-         congestion_window += acked_packet.sent_bytes
-       else:
-         // Congestion avoidance.
-         congestion_window +=
-           max_datagram_size * acked_packet.sent_bytes
-           / congestion_window
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 38]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-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.
-
-      OnCongestionEvent(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
-          sent_time = sent_packets[ack.largest_acked].time_sent
-          OnCongestionEvent(sent_time)
-
-B.8.  On Packets Lost
-
-   Invoked when DetectAndRemoveLostPackets deems packets lost.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 39]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-      InPersistentCongestion(largest_lost):
-        // Persistent congestion cannot be declared on the
-        // first RTT sample.
-        if (is first RTT sample):
-          return false
-        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 and
-        // across all packet number spaces, are marked lost.
-        return AreAllPacketsLost(largest_lost, congestion_period)
-
-      OnPacketsLost(lost_packets):
-        // Remove lost packets from bytes_in_flight.
-        for lost_packet in lost_packets:
-          bytes_in_flight -= lost_packet.sent_bytes
-        OnCongestionEvent(lost_packets.largest().time_sent)
-
-        // Collapse congestion window if persistent congestion
-        if (InPersistentCongestion(lost_packets.largest())):
-          congestion_window = kMinimumWindow
-
-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.
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 40]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   Issue and pull request numbers are listed with a leading octothorp.
-
-C.1.  Since draft-ietf-quic-recovery-28
-
-   *  Refactored pseudocode to correct PTO calculation (#3564, #3674,
-      #3681)
-
-C.2.  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)
-
-C.3.  Since draft-ietf-quic-recovery-26
-
-   No changes.
-
-C.4.  Since draft-ietf-quic-recovery-25
-
-   No significant changes.
-
-C.5.  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.6.  Since draft-ietf-quic-recovery-23
-
-   *  Define under-utilizing the congestion window (#2630, #2686, #2675)
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 41]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   *  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.7.  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.8.  Since draft-ietf-quic-recovery-21
-
-   *  No changes
-
-C.9.  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)
-
-   *  ACK delay only measures intentional delays induced by the
-      implementation (#2596, #2786)
-
-C.10.  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)
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 42]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   *  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.11.  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.12.  Since draft-ietf-quic-recovery-17
-
-   *  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)
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 43]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   *  Congestion and loss recovery state are discarded when keys are
-      discarded (#2327)
-
-C.13.  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)
-
-   *  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.14.  Since draft-ietf-quic-recovery-14
-
-   *  Used max_ack_delay from transport params (#1796, #1782)
-
-   *  Merge ACK and ACK_ECN (#1783)
-
-C.15.  Since draft-ietf-quic-recovery-13
-
-   *  Corrected the lack of ssthresh reduction in CongestionEvent
-      pseudocode (#1598)
-
-   *  Considerations for ECN spoofing (#1426, #1626)
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 44]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   *  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.16.  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.17.  Since draft-ietf-quic-recovery-11
-
-   No significant changes.
-
-C.18.  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)
-
-   *  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.19.  Since draft-ietf-quic-recovery-09
-
-   No significant changes.
-
-C.20.  Since draft-ietf-quic-recovery-08
-
-   *  Clarified pacing and RTO (#967, #977)
-
-C.21.  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)
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 45]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-   *  Many editorial fixes.
-
-C.22.  Since draft-ietf-quic-recovery-06
-
-   No significant changes.
-
-C.23.  Since draft-ietf-quic-recovery-05
-
-   *  Add more congestion control text (#776)
-
-C.24.  Since draft-ietf-quic-recovery-04
-
-   No significant changes.
-
-C.25.  Since draft-ietf-quic-recovery-03
-
-   No significant changes.
-
-C.26.  Since draft-ietf-quic-recovery-02
-
-   *  Integrate F-RTO (#544, #409)
-
-   *  Add congestion control (#545, #395)
-
-   *  Require connection abort if a skipped packet was acknowledged
-      (#415)
-
-   *  Simplify RTO calculations (#142, #417)
-
-C.27.  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.28.  Since draft-ietf-quic-recovery-00
-
-   *  Improved description of constants and ACK behavior
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 46]
-
-Internet-Draft             QUIC Loss Detection               August 2020
-
-
-C.29.  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 Balasubramanian.
-
-Acknowledgments
-
-Authors' Addresses
-
-   Jana Iyengar (editor)
-   Fastly
-
-   Email: jri.ietf@gmail.com
-
-
-   Ian Swett (editor)
-   Google
-
-   Email: ianswett@google.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Swett         Expires 18 February 2021               [Page 47]
diff --git a/split-initial-close/draft-ietf-quic-tls.html b/split-initial-close/draft-ietf-quic-tls.html
deleted file mode 100644
index 69425b0505..0000000000
--- a/split-initial-close/draft-ietf-quic-tls.html
+++ /dev/null
@@ -1,4278 +0,0 @@
-<!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.47.0" 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 {
-  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 {
-  max-width: 100%;
-  margin: 0 0 1em;
-  border-collapse: collapse;
-}
-table.right {
-  margin-left: auto;
-}
-table.center {
-  margin-left: auto;
-  margin-right: auto;
-}
-table.left {
-  margin-right: auto;
-}
-thead, tbody {
-  border: 1px solid var(--line-color);
-}
-th, td {
-  text-align: left;
-  vertical-align: top;
-  padding: 5px 10px;
-}
-th {
-  background-color: var(--line-color);
-}
-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 {
-  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;
-}
-
-/* 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">August 2020</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Thomson &amp; Turner</td>
-<td class="center">Expires 18 February 2021</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-08-17" class="published">17 August 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="2021-02-18">18 February 2021</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
-(quic@ietf.org), 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 18 February 2021.<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 ulEmpty toc">
-<li class="compact ulEmpty 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="compact ulEmpty 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="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" 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="compact ulEmpty 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="compact ulEmpty 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="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-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="compact ulEmpty toc">
-<li class="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="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-tls-version" class="xref">TLS Version</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-clienthello-size" class="xref">ClientHello Size</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-peer-authentication" class="xref">Peer Authentication</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-session-resumption" class="xref">Session Resumption</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty 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-0-rtt" class="xref">0-RTT</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.6.2.1">
-                    <p id="section-toc.1-1.4.2.6.2.1.1"><a href="#section-4.6.1" class="xref">4.6.1</a>.  <a href="#name-enabling-0-rtt" class="xref">Enabling 0-RTT</a><a href="#section-toc.1-1.4.2.6.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.6.2.2">
-                    <p id="section-toc.1-1.4.2.6.2.2.1"><a href="#section-4.6.2" class="xref">4.6.2</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.6.2.2.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.6.2.3">
-                    <p id="section-toc.1-1.4.2.6.2.3.1"><a href="#section-4.6.3" class="xref">4.6.3</a>.  <a href="#name-validating-0-rtt-configurat" class="xref">Validating 0-RTT Configuration</a><a href="#section-toc.1-1.4.2.6.2.3.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="compact ulEmpty 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-helloretryrequest" class="xref">HelloRetryRequest</a><a href="#section-toc.1-1.4.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty 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-tls-errors" class="xref">TLS Errors</a><a href="#section-toc.1-1.4.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty 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-discarding-unused-keys" class="xref">Discarding Unused Keys</a><a href="#section-toc.1-1.4.2.9.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.9.2.1">
-                    <p id="section-toc.1-1.4.2.9.2.1.1"><a href="#section-4.9.1" class="xref">4.9.1</a>.  <a href="#name-discarding-initial-keys" class="xref">Discarding Initial Keys</a><a href="#section-toc.1-1.4.2.9.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.9.2.2">
-                    <p id="section-toc.1-1.4.2.9.2.2.1"><a href="#section-4.9.2" class="xref">4.9.2</a>.  <a href="#name-discarding-handshake-keys" class="xref">Discarding Handshake Keys</a><a href="#section-toc.1-1.4.2.9.2.2.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.9.2.3">
-                    <p id="section-toc.1-1.4.2.9.2.3.1"><a href="#section-4.9.3" class="xref">4.9.3</a>.  <a href="#name-discarding-0-rtt-keys" class="xref">Discarding 0-RTT Keys</a><a href="#section-toc.1-1.4.2.9.2.3.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-            </ul>
-</li>
-          <li class="compact ulEmpty 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="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-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="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-initial-secrets" class="xref">Initial Secrets</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
-</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-aead-usage" class="xref">AEAD Usage</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-header-protection" class="xref">Header Protection</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty toc">
-<li class="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="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-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="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-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="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-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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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-minimum-key-update-frequenc" class="xref">Minimum Key Update Frequency</a><a href="#section-toc.1-1.6.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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="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-protocol-negotiation" class="xref">Protocol Negotiation</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
-</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-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="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-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="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-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="compact ulEmpty 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="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-session-linkability" class="xref">Session Linkability</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-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="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-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="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-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="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-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="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-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="compact ulEmpty 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="compact ulEmpty 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="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-normative-references" class="xref">Normative References</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-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="compact ulEmpty 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="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-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="compact ulEmpty 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="compact ulEmpty 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="compact ulEmpty 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>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.5">
-                <p id="section-toc.1-1.12.2.5.1"><a href="#section-a.5" class="xref">A.5</a>.  <a href="#name-chacha20-poly1305-short-hea" class="xref">ChaCha20-Poly1305 Short Header Packet</a><a href="#section-toc.1-1.12.2.5.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact ulEmpty 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-analysis-of-limits-on-aead_" class="xref">Analysis of Limits on AEAD_AES_128_CCM Usage</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-b.1" class="xref">B.1</a>.  <a href="#name-confidentiality-limits" class="xref">Confidentiality Limits</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-b.2" class="xref">B.2</a>.  <a href="#name-integrity-limits" class="xref">Integrity Limits</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.14">
-            <p id="section-toc.1-1.14.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.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-c.1" class="xref">C.1</a>.  <a href="#name-since-draft-ietf-quic-tls-2" class="xref">Since draft-ietf-quic-tls-28</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-c.2" class="xref">C.2</a>.  <a href="#name-since-draft-ietf-quic-tls-27" class="xref">Since draft-ietf-quic-tls-27</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-c.3" class="xref">C.3</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.14.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.4">
-                <p id="section-toc.1-1.14.2.4.1"><a href="#section-c.4" class="xref">C.4</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.14.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.5">
-                <p id="section-toc.1-1.14.2.5.1"><a href="#section-c.5" class="xref">C.5</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.14.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.6">
-                <p id="section-toc.1-1.14.2.6.1"><a href="#section-c.6" class="xref">C.6</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.14.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.7">
-                <p id="section-toc.1-1.14.2.7.1"><a href="#section-c.7" class="xref">C.7</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.14.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.8">
-                <p id="section-toc.1-1.14.2.8.1"><a href="#section-c.8" class="xref">C.8</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.14.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.9">
-                <p id="section-toc.1-1.14.2.9.1"><a href="#section-c.9" class="xref">C.9</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.14.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.10">
-                <p id="section-toc.1-1.14.2.10.1"><a href="#section-c.10" class="xref">C.10</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.14.2.10.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.11">
-                <p id="section-toc.1-1.14.2.11.1"><a href="#section-c.11" class="xref">C.11</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.14.2.11.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.12">
-                <p id="section-toc.1-1.14.2.12.1"><a href="#section-c.12" class="xref">C.12</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.14.2.12.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.13">
-                <p id="section-toc.1-1.14.2.13.1"><a href="#section-c.13" class="xref">C.13</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.14.2.13.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.14">
-                <p id="section-toc.1-1.14.2.14.1"><a href="#section-c.14" class="xref">C.14</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.14.2.14.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.15">
-                <p id="section-toc.1-1.14.2.15.1"><a href="#section-c.15" class="xref">C.15</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.14.2.15.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.16">
-                <p id="section-toc.1-1.14.2.16.1"><a href="#section-c.16" class="xref">C.16</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.14.2.16.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.17">
-                <p id="section-toc.1-1.14.2.17.1"><a href="#section-c.17" class="xref">C.17</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.14.2.17.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.18">
-                <p id="section-toc.1-1.14.2.18.1"><a href="#section-c.18" class="xref">C.18</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.14.2.18.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.19">
-                <p id="section-toc.1-1.14.2.19.1"><a href="#section-c.19" class="xref">C.19</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.14.2.19.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.20">
-                <p id="section-toc.1-1.14.2.20.1"><a href="#section-c.20" class="xref">C.20</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.14.2.20.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.21">
-                <p id="section-toc.1-1.14.2.21.1"><a href="#section-c.21" class="xref">C.21</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.14.2.21.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.22">
-                <p id="section-toc.1-1.14.2.22.1"><a href="#section-c.22" class="xref">C.22</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.14.2.22.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.23">
-                <p id="section-toc.1-1.14.2.23.1"><a href="#section-c.23" class="xref">C.23</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.14.2.23.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.24">
-                <p id="section-toc.1-1.14.2.24.1"><a href="#section-c.24" class="xref">C.24</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.14.2.24.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.25">
-                <p id="section-toc.1-1.14.2.25.1"><a href="#section-c.25" class="xref">C.25</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.14.2.25.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="compact ulEmpty toc" id="section-toc.1-1.14.2.26">
-                <p id="section-toc.1-1.14.2.26.1"><a href="#section-c.26" class="xref">C.26</a>. <a href="#name-since-draft-thomson-quic-tl" class="xref">Since draft-thomson-quic-tls-01</a><a href="#section-toc.1-1.14.2.26.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact ulEmpty 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-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="compact ulEmpty toc" id="section-toc.1-1.16">
-            <p id="section-toc.1-1.16.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.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">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 Early
-Data (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 that 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 that 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 bytes that comprise
-handshake messages.<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 handshake bytes for the current
-encryption level. The encryption level then determines the type of packet that
-the resulting CRYPTO frame is carried in; see <a href="#packet-types-keys" class="xref">Table 1</a>.<a href="#section-4.1.3-5" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-6">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-6" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-8">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.8</a>.
-TLS application data and other message types cannot be carried by QUIC at any
-encryption level; it is an error if they are received from the TLS stack.<a href="#section-4.1.3-8" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-9">When an endpoint receives a QUIC packet containing a CRYPTO frame from the
-network, it proceeds as follows:<a href="#section-4.1.3-9" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-4.1.3-10.1">If the packet uses the current 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-10.1" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-4.1.3-10.2">If the packet is from a previously installed encryption level, it MUST NOT
-contain data that 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-10.2" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-4.1.3-10.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 to TLS.  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-10.3" class="pilcrow">¶</a>
-</li>
-          </ul>
-<p id="section-4.1.3-11">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-11" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-12">The content of CRYPTO frames might either be processed incrementally by TLS or
-buffered until complete messages or flights are available.  TLS is responsible
-for buffering handshake bytes that have arrived in order.  QUIC is responsible
-for buffering handshake bytes that arrive out of order or for encryption levels
-that are not yet ready.  QUIC does not provide any means of flow control for
-CRYPTO frames; see Section 7.5 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-4.1.3-12" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-13">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-13" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-14">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-14" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-15">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-15" 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 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. Solid arrows indicate packets that carry handshake data;
-dashed arrows show where application data can be sent.  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;
-Install tx 0-RTT Keys
-                     0-RTT - - - - - - - -&gt;
-
-                                              Handshake Received
-                                                   Get Handshake
-                     &lt;------------- Initial
-                                           Install rx 0-RTT keys
-                                          Install Handshake keys
-                                                   Get Handshake
-                     &lt;----------- Handshake
-                                           Install tx 1-RTT keys
-                     &lt;- - - - - - - - 1-RTT
-
-Handshake Received (Initial)
-Install Handshake keys
-Handshake Received (Handshake)
-Get Handshake
-                     Handshake -----------&gt;
-Handshake Complete
-Install 1-RTT keys
-                     1-RTT - - - - - - - -&gt;
-
-                                              Handshake Received
-                                              Handshake Complete
-                                           Install rx 1-RTT keys
-</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 incoming packets
-have been processed.  This process varies based on the structure of endpoint
-implementations and the order in which packets arrive; this is intended to
-illustrate the steps involved in a single handshake exchange.<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">Clients MUST NOT offer TLS versions older than 1.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>
-<span class="break"></span><dl class="dlParallel" id="section-4.4-3">
-          <dt id="section-4.4-3.1">Note:</dt>
-          <dd id="section-4.4-3.2">
-  Where servers provide certificates for authentication, the size of
-the certificate chain can consume a large number of bytes.  Controlling the
-size of certificate chains is critical to performance in QUIC as servers are
-limited to sending 3 bytes for every byte received prior to validating the
-client address; see Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.  The size of a
-certificate chain can be managed by limiting the number of names or
-extensions; using keys with small public key representations, like ECDSA; or
-by using certificate compression
-<span>[<a href="#COMPRESS" class="xref">COMPRESS</a>]</span>.<a href="#section-4.4-3.2" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-4.4-4">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-4" class="pilcrow">¶</a></p>
-<p id="section-4.4-5">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-5" 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.1</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="rtt">
-<section id="section-4.6">
-        <h3 id="name-0-rtt">
-<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-0-rtt" class="section-name selfRef">0-RTT</a>
-        </h3>
-<p id="section-4.6-1">The 0-RTT feature in QUIC allows a client to send application data before the
-handshake is complete.  This is made possible by reusing negotiated parameters
-from a previous connection.  To enable this, 0-RTT depends on the client
-remembering critical parameters and providing the server with a TLS session
-ticket that allows the server to recover the same information.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
-<p id="section-4.6-2">This information includes parameters that determine TLS state, as governed by
-<span>[<a href="#TLS13" class="xref">TLS13</a>]</span>, QUIC transport parameters, the chosen application protocol, and any
-information the application protocol might need; see <a href="#app-0rtt" class="xref">Section 4.6.3</a>.  This
-information determines how 0-RTT packets and their contents are formed.<a href="#section-4.6-2" class="pilcrow">¶</a></p>
-<p id="section-4.6-3">To ensure that the same information is available to both endpoints, all
-information used to establish 0-RTT comes from the same connection.  Endpoints
-cannot selectively disregard information that might alter the sending or
-processing of 0-RTT.<a href="#section-4.6-3" class="pilcrow">¶</a></p>
-<p id="section-4.6-4"><span>[<a href="#TLS13" class="xref">TLS13</a>]</span> sets a limit of 7 days on the time between the original connection
-and any attempt to use 0-RTT.  There are other constraints on 0-RTT usage,
-notably those caused by the potential exposure to replay attack; see <a href="#replay" class="xref">Section 9.2</a>.<a href="#section-4.6-4" class="pilcrow">¶</a></p>
-<div id="enable-0rtt">
-<section id="section-4.6.1">
-          <h4 id="name-enabling-0-rtt">
-<a href="#section-4.6.1" class="section-number selfRef">4.6.1. </a><a href="#name-enabling-0-rtt" class="section-name selfRef">Enabling 0-RTT</a>
-          </h4>
-<p id="section-4.6.1-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 TLS max_early_data_size parameter is not
-used in QUIC.  The amount of data that the client can send in 0-RTT is
-controlled by the initial_max_data transport parameter supplied by the server.<a href="#section-4.6.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.6.1-2">Servers MUST NOT send the early_data extension with a max_early_data_size field
-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-2" class="pilcrow">¶</a></p>
-<p id="section-4.6.1-3">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 application data in 0-RTT packets.<a href="#section-4.6.1-3" class="pilcrow">¶</a></p>
-<p id="section-4.6.1-4">A client that attempts 0-RTT might also provide an address validation token if
-the server has sent a NEW_TOKEN frame; see Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-4.6.1-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="accepting-and-rejecting-0-rtt">
-<section id="section-4.6.2">
-          <h4 id="name-accepting-and-rejecting-0-r">
-<a href="#section-4.6.2" class="section-number selfRef">4.6.2. </a><a href="#name-accepting-and-rejecting-0-r" class="section-name selfRef">Accepting and Rejecting 0-RTT</a>
-          </h4>
-<p id="section-4.6.2-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.6.2-1" class="pilcrow">¶</a></p>
-<p id="section-4.6.2-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.6.2-2" class="pilcrow">¶</a></p>
-<p id="section-4.6.2-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.6.2-3" class="pilcrow">¶</a></p>
-<p id="section-4.6.2-4">A client MAY reattempt 0-RTT if it receives a Retry or Version Negotiation
-packet.  These packets do not signify rejection of 0-RTT.<a href="#section-4.6.2-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="app-0rtt">
-<section id="section-4.6.3">
-          <h4 id="name-validating-0-rtt-configurat">
-<a href="#section-4.6.3" class="section-number selfRef">4.6.3. </a><a href="#name-validating-0-rtt-configurat" class="section-name selfRef">Validating 0-RTT Configuration</a>
-          </h4>
-<p id="section-4.6.3-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.6.3-1" class="pilcrow">¶</a></p>
-<p id="section-4.6.3-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.6.3-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="helloretryrequest">
-<section id="section-4.7">
-        <h3 id="name-helloretryrequest">
-<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-helloretryrequest" class="section-name selfRef">HelloRetryRequest</a>
-        </h3>
-<p id="section-4.7-1">The HelloRetryRequest message (see Section 4.1.4 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>) can be used to
-request that a client provide new information, such as a key share, or to
-validate some characteristic of the client.  From the perspective of QUIC,
-HelloRetryRequest is not differentiated from other cryptographic handshake
-messages that are carried in Initial packets. Although it is in principle
-possible to use this feature for address verification, QUIC implementations
-SHOULD instead use the Retry feature; see Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="tls-errors">
-<section id="section-4.8">
-        <h3 id="name-tls-errors">
-<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-tls-errors" class="section-name selfRef">TLS Errors</a>
-        </h3>
-<p id="section-4.8-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.8-1" class="pilcrow">¶</a></p>
-<p id="section-4.8-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.8-2" class="pilcrow">¶</a></p>
-<p id="section-4.8-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.8-3" class="pilcrow">¶</a></p>
-<p id="section-4.8-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.8-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="discarding-unused-keys">
-<section id="section-4.9">
-        <h3 id="name-discarding-unused-keys">
-<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-discarding-unused-keys" class="section-name selfRef">Discarding Unused Keys</a>
-        </h3>
-<p id="section-4.9-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.9-1" class="pilcrow">¶</a></p>
-<p id="section-4.9-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.9-2" class="pilcrow">¶</a></p>
-<p id="section-4.9-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.9-3" class="pilcrow">¶</a></p>
-<p id="section-4.9-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.9-4" class="pilcrow">¶</a></p>
-<div id="discarding-initial-keys">
-<section id="section-4.9.1">
-          <h4 id="name-discarding-initial-keys">
-<a href="#section-4.9.1" class="section-number selfRef">4.9.1. </a><a href="#name-discarding-initial-keys" class="section-name selfRef">Discarding Initial Keys</a>
-          </h4>
-<p id="section-4.9.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.9.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.9.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.9.1-2" class="pilcrow">¶</a></p>
-<p id="section-4.9.1-3">This results in abandoning loss recovery state for the Initial encryption level
-and ignoring any outstanding Initial packets.<a href="#section-4.9.1-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="discarding-handshake-keys">
-<section id="section-4.9.2">
-          <h4 id="name-discarding-handshake-keys">
-<a href="#section-4.9.2" class="section-number selfRef">4.9.2. </a><a href="#name-discarding-handshake-keys" class="section-name selfRef">Discarding Handshake Keys</a>
-          </h4>
-<p id="section-4.9.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.9.2-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="discarding-0-rtt-keys">
-<section id="section-4.9.3">
-          <h4 id="name-discarding-0-rtt-keys">
-<a href="#section-4.9.3" class="section-number selfRef">4.9.3. </a><a href="#name-discarding-0-rtt-keys" class="section-name selfRef">Discarding 0-RTT Keys</a>
-          </h4>
-<p id="section-4.9.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.9.3-1" class="pilcrow">¶</a></p>
-<p id="section-4.9.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.9.3-2" class="pilcrow">¶</a></p>
-<p id="section-4.9.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.9.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 <span>[<a href="#AEAD" class="xref">AEAD</a>]</span> negotiated by TLS.<a href="#section-5-1" class="pilcrow">¶</a></p>
-<p id="section-5-2">QUIC packets have varying protections depending on their type:<a href="#section-5-2" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-5-3.1">Version Negotiation packets have no cryptographic protection.<a href="#section-5-3.1" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-5-3.2">Retry packets use AEAD_AES_128_GCM to provide protection against accidental
-modification or insertion by off-path adversaries; see
-<a href="#retry-integrity" class="xref">Section 5.8</a>.<a href="#section-5-3.2" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-5-3.3">Initial packets use AEAD_AES_128_GCM with keys derived from the Destination
-Connection ID field of the first Initial packet sent by the client; see
-<a href="#initial-secrets" class="xref">Section 5.2</a>.<a href="#section-5-3.3" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-5-3.4">All other packets have strong cryptographic protections for confidentiality
-and integrity, using keys and algorithms negotiated by TLS.<a href="#section-5-3.4" class="pilcrow">¶</a>
-</li>
-      </ul>
-<p id="section-5-4">This section describes how packet protection is applied to Handshake packets,
-0-RTT packets, and 1-RTT packets. The same packet protection process is applied
-to Initial packets. However, as it is trivial to determine the keys used for
-Initial packets, these packets are not considered to have confidentiality or
-integrity protection. Retry packets use a fixed key and so similarly lack
-confidentiality and integrity protection.<a href="#section-5-4" 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 apply the packet protection process, but use a secret derived
-from the Destination Connection ID field from the client's first Initial
-packet.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
-<p id="section-5.2-2">This secret is determined by using HKDF-Extract (see Section 2.2 of
-<span>[<a href="#HKDF" class="xref">HKDF</a>]</span>) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899
-and a IKM of the Destination Connection ID field. This produces an intermediate
-pseudorandom key (PRK) that is used to derive two separate secrets for sending
-and receiving.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
-<p id="section-5.2-3">The secret used by clients to construct Initial packets uses the PRK and the
-label "client in" as input to the HKDF-Expand-Label function to produce a 32
-byte secret; packets constructed by the server use the same process with the
-label "server in".  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">This process in pseudocode is:<a href="#section-5.2-4" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-5.2-5">
-<pre>
-initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899
-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-5" class="pilcrow">¶</a>
-</div>
-<p id="section-5.2-6">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-6" class="pilcrow">¶</a></p>
-<p id="section-5.2-7">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
-recognizes only one version of QUIC from seeing or modifying the contents of
-packets from future versions.<a href="#section-5.2-7" class="pilcrow">¶</a></p>
-<p id="section-5.2-8">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-8" class="pilcrow">¶</a></p>
-<p id="section-5.2-9">The secrets used for constructing 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-9" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-5.2-10">
-          <dt id="section-5.2-10.1">Note:</dt>
-          <dd id="section-5.2-10.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-10.2" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-5.2-11"><a href="#test-vectors" class="xref">Appendix A</a> contains sample Initial packets.<a href="#section-5.2-11" 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 Authenticated Encryption with Associated Data (AEAD; see <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 cipher
-suite, the AEAD_AES_128_GCM function is used.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
-<p id="section-5.3-2">QUIC can use any of the cipher suites defined in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> with the exception
-of TLS_AES_128_CCM_8_SHA256.  A cipher suite MUST NOT be negotiated unless a
-header protection scheme is defined for the cipher suite.  This document defines
-a header protection scheme for all cipher suites defined in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> aside
-from TLS_AES_128_CCM_8_SHA256.  These cipher suites have a 16-byte
-authentication tag and produce an output 16 bytes larger than their input.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-5.3-3">
-          <dt id="section-5.3-3.1">Note:</dt>
-          <dd id="section-5.3-3.2">
-  An endpoint MUST NOT reject a ClientHello that offers a cipher suite that it
-does not support, or it would be impossible to deploy a new cipher suite.
-This also applies to TLS_AES_128_CCM_8_SHA256.<a href="#section-5.3-3.2" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-5.3-4">When constructing packets, the AEAD function is applied prior to applying
-header protection; see <a href="#header-protect" class="xref">Section 5.4</a>. The unprotected packet header is part
-of the associated data (A). When processing packets, an endpoint first
-removes the header protection.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
-<p id="section-5.3-5">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-5" class="pilcrow">¶</a></p>
-<p id="section-5.3-6">The associated data, A, for the AEAD is the contents of the QUIC header,
-starting from the first byte of either the short or long header, up to and
-including the unprotected packet number.<a href="#section-5.3-6" class="pilcrow">¶</a></p>
-<p id="section-5.3-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-5.3-8">The output ciphertext, C, of the AEAD is transmitted in place of P.<a href="#section-5.3-8" class="pilcrow">¶</a></p>
-<p id="section-5.3-9">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-9" 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 separately from 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 that 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 (..),
-  Length (i),
-  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 cipher suite can be used with QUIC, a header protection algorithm
-MUST be specified for the AEAD used with that cipher suite.  This document
-defines algorithms for AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM (all
-these AES AEADs are defined in <span>[<a href="#AEAD" class="xref">AEAD</a>]</span>), and AEAD_CHACHA20_POLY1305
-(defined in <span>[<a href="#CHACHA" class="xref">CHACHA</a>]</span>).  Prior to TLS selecting a cipher suite, 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
-cipher suites 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 in electronic code-book (ECB) mode. AEAD_AES_256_GCM uses
-256-bit AES in ECB mode.  AES is defined in <span>[<a href="#AES" class="xref">AES</a>]</span>.<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.1</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>
-<span class="break"></span><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 before the handshake is complete is
-limited to sending data.  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>
-<span class="break"></span><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>
-<p id="section-5.7-8">A client generally receives 1-RTT keys at the same time as the handshake
-completes.  Even if it has 1-RTT secrets, a client MUST NOT process
-incoming 1-RTT protected packets before the TLS handshake is complete.<a href="#section-5.7-8" 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 0xccce187ed09a09d05728155a6cb96be1.<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 0xe54930f97f2136f0530a8c1c.<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 0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c 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>
-<span class="break"></span><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 Length field 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 Length. 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.8</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 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>
-<span class="break"></span><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 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="minimum-key-update-frequency">
-<section id="section-6.6">
-        <h3 id="name-minimum-key-update-frequenc">
-<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-minimum-key-update-frequenc" class="section-name selfRef">Minimum 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. <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> does not specify a limit for
-AEAD_AES_128_CCM, but the analysis in <a href="#ccm-bounds" class="xref">Appendix B</a> shows that a limit of 2^23
-packets can be used to obtain the same confidentiality protection as the limits
-specified in TLS.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
-<p id="section-6.6-2">The usage limits defined in TLS 1.3 exist for protection against attacks
-on confidentiality and apply to successful applications of AEAD protection. The
-integrity protections in authenticated encryption also depend on limiting the
-number of attempts to forge packets. TLS achieves this by closing connections
-after any record fails an authentication check. In comparison, QUIC ignores any
-packet that cannot be authenticated, allowing multiple forgery attempts.<a href="#section-6.6-2" class="pilcrow">¶</a></p>
-<p id="section-6.6-3">Endpoints MUST count the number of received packets that fail authentication for
-each set of keys.  If the number of packets that fail authentication with the
-same key exceeds a limit that is specific to the AEAD in use, the endpoint MUST
-stop using those keys.  Endpoints MUST initiate a key update before reaching
-this limit.  If a key update is not possible, the endpoint MUST immediately
-close the connection.  Applying a limit reduces the probability that an attacker
-is able to successfully forge a packet; see <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span> and <span>[<a href="#ROBUST" class="xref">ROBUST</a>]</span>.<a href="#section-6.6-3" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-6.6-4">
-          <dt id="section-6.6-4.1">Note:</dt>
-          <dd id="section-6.6-4.2">
-  Due to the way that header protection protects the Key Phase, packets that are
-discarded are likely to have an even distribution of both Key Phase values.
-This means that packets that fail authentication will often use the packet
-protection keys from the next key phase.  It is therefore necessary to also
-track the number of packets that fail authentication with the next set of
-packet protection keys.  To avoid exhaustion of both sets of keys, it might be
-necessary to initiate two key updates in succession.<a href="#section-6.6-4.2" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-6.6-5">For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on
-the number of packets that fail authentication is 2^36.  Note that the analysis
-in <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span> supports a higher limit for the AEAD_AES_128_GCM and
-AEAD_AES_256_GCM, but this specification recommends a lower limit.  For
-AEAD_AES_128_CCM, the limit on the number of packets that fail authentication
-is 2^23.5; see <a href="#ccm-bounds" class="xref">Appendix B</a>.<a href="#section-6.6-5" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-6.6-6">
-          <dt id="section-6.6-6.1">Note:</dt>
-          <dd id="section-6.6-6.2">
-  These limits were originally calculated using assumptions about the
-limits on TLS record size. The maximum size of a TLS record is 2^14 bytes.
-In comparison, QUIC packets can be up to 2^16 bytes.  However, it is
-expected that QUIC packets will generally be smaller than TLS records.
-Where packets might be larger than 2^14 bytes in length, smaller limits might
-be needed.<a href="#section-6.6-6.2" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-6.6-7">Any TLS cipher suite that is specified for use with QUIC MUST define limits on
-the use of the associated AEAD function that preserves margins for
-confidentiality and integrity. That is, limits MUST be specified for the number
-of packets that can be authenticated and for the number of packets that can fail
-authentication.  Providing a reference to any analysis upon which values are
-based - and any assumptions used in that analysis - allows limits to be adapted
-to varying usage conditions.<a href="#section-6.6-7" 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 that 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">Certain aspects of the TLS handshake are different when used with QUIC.<a href="#section-8-1" class="pilcrow">¶</a></p>
-<p id="section-8-2">QUIC also requires additional features from TLS.  In addition to negotiation of
-cryptographic parameters, the TLS handshake carries and authenticates values for
-QUIC transport parameters.<a href="#section-8-2" 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
-(<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.2 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.8</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.8</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">
-<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>
-<span class="break"></span><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.  Specifically, to enable a
-server to efficiently recover state that is used in connection establishment
-and address validation.  These MUST NOT be used to communicate application
-semantics between endpoints; clients MUST treat them as opaque values.  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 times
-as many bytes as the number of bytes it has received (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 that 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 tried 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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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="HKDF">[HKDF]</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" class="refDate">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="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-08-17" class="refDate">17 August 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-08-17" class="refDate">17 August 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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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="CCM-ANALYSIS">[CCM-ANALYSIS]</dt>
-        <dd>
-<span class="refAuthor">Jonsson, J.</span>, <span class="refTitle">"On the Security of CTR + CBC-MAC"</span>, <span class="seriesInfo">DOI 10.1007/3-540-36492-7_7</span>, <span class="seriesInfo">Selected Areas in Cryptography pp. 76-93</span>, <time datetime="2003" class="refDate">2003</time>, <span>&lt;<a href="https://doi.org/10.1007/3-540-36492-7_7">https://doi.org/10.1007/3-540-36492-7_7</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="COMPRESS">[COMPRESS]</dt>
-        <dd>
-<span class="refAuthor">Ghedini, A.</span><span class="refAuthor"> and V. Vasiliev</span>, <span class="refTitle">"TLS Certificate Compression"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tls-certificate-compression-10</span>, <time datetime="2020-01-06" class="refDate">6 January 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-certificate-compression-10.txt">http://www.ietf.org/internet-drafts/draft-ietf-tls-certificate-compression-10.txt</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" class="refDate">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" class="refDate">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" class="refDate">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-08-17" class="refDate">17 August 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" class="refDate">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" class="refDate">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>
-<dt id="ROBUST">[ROBUST]</dt>
-      <dd>
-<span class="refAuthor">Fischlin, M.</span><span class="refAuthor">, Günther, F.</span><span class="refAuthor">, and C. Janson</span>, <span class="refTitle">"Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3"</span>, <time datetime="2020-05-16" class="refDate">16 May 2020</time>, <span>&lt;<a href="https://eprint.iacr.org/2020/718">https://eprint.iacr.org/2020/718</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>
-<span class="break"></span><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)
-    = 1e7e7764529715b1e0ddc8e9753c6157
-      6769605187793ed366f8bbf8c9e986eb
-</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)
-    = 0088119288f1d866733ceeed15ff9d50
-      902cf82952eee27e9d4d4918ea371d87
-
-key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
-    = 175257a31eb09dea9366d8bb79ad80ba
-
-iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
-    = 6b26114b9cba2b63a9e8dd4f
-
-hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
-    = 9ddd12c994c0698b89374a9c077a3077
-</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)
-    = 006f881359244dd9ad1acf85f595bad6
-      7c13f9f5586f5e64e1acae1d9ea8f616
-
-key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
-    = 149d0b1662ab871fbe63c49b5e655a5d
-
-iv  = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
-    = bab2b12a4c76016ace47856d
-
-hp  = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
-    = c0c499a65a60024a18a250974ea01dfa
-</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>
-060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
-04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
-616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
-04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
-baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
-0d0010000e0403050306030203080408 050806002d00020101001c00024001ff
-a500320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
-75300901100f088394c8f03e51570806 048000ffff
-</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>
-c3ff00001d088394c8f03e5157080000449e00000002
-</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 = fb66bc6a93032b50dd8973972d149421
-
-mask = AES-ECB(hp, sample)[0..4]
-     = 1e9cdb9909
-
-header[0] ^= mask[0] &amp; 0x0f
-     = cd
-header[18..21] ^= mask[1..4]
-     = 9cdb990b
-header = cdff00001d088394c8f03e5157080000449e9cdb990b
-</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>
-cdff00001d088394c8f03e5157080000 449e9cdb990bfb66bc6a93032b50dd89
-73972d149421874d3849e3708d71354e a33bcdc356f3ea6e2a1a1bd7c3d14003
-8d3e784d04c30a2cdb40c32523aba2da fe1c1bf3d27a6be38fe38ae033fbb071
-3c1c73661bb6639795b42b97f77068ea d51f11fbf9489af2501d09481e6c64d4
-b8551cd3cea70d830ce2aeeec789ef55 1a7fbe36b3f7e1549a9f8d8e153b3fac
-3fb7b7812c9ed7c20b4be190ebd89956 26e7f0fc887925ec6f0606c5d36aa81b
-ebb7aacdc4a31bb5f23d55faef5c5190 5783384f375a43235b5c742c78ab1bae
-0a188b75efbde6b3774ed61282f9670a 9dea19e1566103ce675ab4e21081fb58
-60340a1e88e4f10e39eae25cd685b109 29636d4f02e7fad2a5a458249f5c0298
-a6d53acbe41a7fc83fa7cc01973f7a74 d1237a51974e097636b6203997f921d0
-7bc1940a6f2d0de9f5a11432946159ed 6cc21df65c4ddd1115f86427259a196c
-7148b25b6478b0dc7766e1c4d1b1f515 9f90eabc61636226244642ee148b464c
-9e619ee50a5e3ddc836227cad938987c 4ea3c1fa7c75bbf88d89e9ada642b2b8
-8fe8107b7ea375b1b64889a4e9e5c38a 1c896ce275a5658d250e2d76e1ed3a34
-ce7e3a3f383d0c996d0bed106c2899ca 6fc263ef0455e74bb6ac1640ea7bfedc
-59f03fee0e1725ea150ff4d69a7660c5 542119c71de270ae7c3ecfd1af2c4ce5
-51986949cc34a66b3e216bfe18b347e6 c05fd050f85912db303a8f054ec23e38
-f44d1c725ab641ae929fecc8e3cefa56 19df4231f5b4c009fa0c0bbc60bc75f7
-6d06ef154fc8577077d9d6a1d2bd9bf0 81dc783ece60111bea7da9e5a9748069
-d078b2bef48de04cabe3755b197d52b3 2046949ecaa310274b4aac0d008b1948
-c1082cdfe2083e386d4fd84c0ed0666d 3ee26c4515c4fee73433ac703b690a9f
-7bf278a77486ace44c489a0c7ac8dfe4 d1a58fb3a730b993ff0f0d61b4d89557
-831eb4c752ffd39c10f6b9f46d8db278 da624fd800e4af85548a294c1518893a
-8778c4f6d6d73c93df200960104e062b 388ea97dcf4016bced7f62b4f062cb6c
-04c20693d9a0e3b74ba8fe74cc012378 84f40d765ae56a51688d985cf0ceaef4
-3045ed8c3f0c33bced08537f6882613a cd3b08d665fce9dd8aa73171e2d3771a
-61dba2790e491d413d93d987e2745af2 9418e428be34941485c93447520ffe23
-1da2304d6a0fd5d07d08372202369661 59bef3cf904d722324dd852513df39ae
-030d8173908da6364786d3c1bfcb19ea 77a63b25f1e7fc661def480c5d00d444
-56269ebd84efd8e3a8b2c257eec76060 682848cbf5194bc99e49ee75e4d0d254
-bad4bfd74970c30e44b65511d4ad0e6e c7398e08e01307eeeea14e46ccd87cf3
-6b285221254d8fc6a6765c524ded0085 dca5bd688ddf722e2c0faf9d0fb2ce7a
-0c3f2cee19ca0ffba461ca8dc5d2c817 8b0762cf67135558494d2a96f1a139f0
-edb42d2af89a9c9122b07acbc29e5e72 2df8615c343702491098478a389c9872
-a10b0c9875125e257c7bfdf27eef4060 bd3d00f4c14fd3e3496c38d3c5d1a566
-8c39350effbc2d16ca17be4ce29f02ed 969504dda2a8c6b9ff919e693ee79e09
-089316e7d1d89ec099db3b2b268725d8 88536a4b8bf9aee8fb43e82a4d919d48
-1802771a449b30f3fa2289852607b660
-</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>
-02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
-88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
-0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
-020304
-</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>
-c1ff00001d0008f067a5502a4262b50040740001
-</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 = 823a5d3a1207c86ee49132824f046524
-mask   = abaaf34fdc
-header = caff00001d0008f067a5502a4262b5004074aaf2
-</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>
-c7ff00001d0008f067a5502a4262b500 4075fb12ff07823a5d24534d906ce4c7
-6782a2167e3479c0f7f6395dc2c91676 302fe6d70bb7cbeb117b4ddb7d173498
-44fd61dae200b8338e1b932976b61d91 e64a02e9e0ee72e3a6f63aba4ceeeec5
-be2f24f2d86027572943533846caa13e 6f163fb257473dcca25396e88724f1e5
-d964dedee9b633
-</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>
-ffff00001d0008f067a5502a4262b574 6f6b656ed16926d81f6f9ca2953a8aa4
-575e1e49
-</pre><a href="#section-a.4-2" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="chacha20-poly1305-short-header-packet">
-<section id="section-a.5">
-        <h2 id="name-chacha20-poly1305-short-hea">
-<a href="#section-a.5" class="section-number selfRef">A.5. </a><a href="#name-chacha20-poly1305-short-hea" class="section-name selfRef">ChaCha20-Poly1305 Short Header Packet</a>
-        </h2>
-<p id="section-a.5-1">This example shows some of the steps required to protect a packet with
-a short header.  This example uses AEAD_CHACHA20_POLY1305.<a href="#section-a.5-1" class="pilcrow">¶</a></p>
-<p id="section-a.5-2">In this example, TLS produces an application write secret from which a server
-uses HKDF-Expand-Label to produce four values: a key, an IV, a header
-protection key, and the secret that will be used after keys are updated (this
-last value is not used further in this example).<a href="#section-a.5-2" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-a.5-3">
-<pre>
-secret
-    = 9ac312a7f877468ebe69422748ad00a1
-      5443f18203a07d6060f688f30f21632b
-
-key = HKDF-Expand-Label(secret, "quic key", _, 32)
-    = c6d98ff3441c3fe1b2182094f69caa2e
-      d4b716b65488960a7a984979fb23e1c8
-
-iv  = HKDF-Expand-Label(secret, "quic iv", _, 12)
-    = e0459b3474bdd0e44a41c144
-
-hp  = HKDF-Expand-Label(secret, "quic hp", _, 32)
-    = 25a282b9e82f06f21f488917a4fc8f1b
-      73573685608597d0efcb076b0ab7a7a4
-
-ku  = HKDF-Expand-Label(secret, "quic ku", _, 32)
-    = 1223504755036d556342ee9361d25342
-      1a826c9ecdf3c7148684b36b714881f9
-</pre><a href="#section-a.5-3" class="pilcrow">¶</a>
-</div>
-<p id="section-a.5-4">The following shows the steps involved in protecting a minimal packet with an
-empty Destination Connection ID. This packet contains a single PING frame (that
-is, a payload of just 0x01) and has a packet number of 654360564. In this
-example, using a packet number of length 3 (that is, 49140 is encoded) avoids
-having to pad the payload of the packet; PADDING frames would be needed if the
-packet number is encoded on fewer octets.<a href="#section-a.5-4" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-a.5-5">
-<pre>
-pn                 = 654360564 (decimal)
-nonce              = e0459b3474bdd0e46d417eb0
-unprotected header = 4200bff4
-payload plaintext  = 01
-payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb
-</pre><a href="#section-a.5-5" class="pilcrow">¶</a>
-</div>
-<p id="section-a.5-6">The resulting ciphertext is the minimum size possible. One byte is skipped to
-produce the sample for header protection.<a href="#section-a.5-6" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-a.5-7">
-<pre>
-sample = 5e5cd55c41f69080575d7999c25a5bfb
-mask   = aefefe7d03
-header = 4cfe4189
-</pre><a href="#section-a.5-7" class="pilcrow">¶</a>
-</div>
-<p id="section-a.5-8">The protected packet is the smallest possible packet size of 21 bytes.<a href="#section-a.5-8" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-a.5-9">
-<pre>
-packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb
-</pre><a href="#section-a.5-9" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="ccm-bounds">
-<section id="section-appendix.b">
-      <h2 id="name-analysis-of-limits-on-aead_">
-<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-analysis-of-limits-on-aead_" class="section-name selfRef">Analysis of Limits on AEAD_AES_128_CCM Usage</a>
-      </h2>
-<p id="section-appendix.b-1"><span>[<a href="#TLS13" class="xref">TLS13</a>]</span> and <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span> do not specify limits on usage for
-AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires limits on
-use that ensure that both confidentiality and integrity are preserved. This
-section documents that analysis.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
-<p id="section-appendix.b-2"><span>[<a href="#CCM-ANALYSIS" class="xref">CCM-ANALYSIS</a>]</span> is used as the basis of this
-analysis. The results of that analysis are used to derive usage limits that are
-based on those chosen in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
-<p id="section-appendix.b-3">This analysis uses symbols for multiplication (*), division (/), and
-exponentiation (^), plus parentheses for establishing precedence. The following
-symbols are also used:<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-appendix.b-4">
-        <dt id="section-appendix.b-4.1">t:</dt>
-        <dd id="section-appendix.b-4.2">
-  The size of the authentication tag in bits. For this cipher, t is 128.<a href="#section-appendix.b-4.2" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-<dt id="section-appendix.b-4.3">n:</dt>
-        <dd id="section-appendix.b-4.4">
-  The size of the block function in bits. For this cipher, n is 128.<a href="#section-appendix.b-4.4" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-<dt id="section-appendix.b-4.5">l:</dt>
-        <dd id="section-appendix.b-4.6">
-  The number of blocks in each packet (see below).<a href="#section-appendix.b-4.6" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-<dt id="section-appendix.b-4.7">q:</dt>
-        <dd id="section-appendix.b-4.8">
-  The number of genuine packets created and protected by endpoints. This value
-is the bound on the number of packets that can be protected before updating
-keys.<a href="#section-appendix.b-4.8" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-<dt id="section-appendix.b-4.9">v:</dt>
-        <dd id="section-appendix.b-4.10">
-  The number of forged packets that endpoints will accept. This value is the
-bound on the number of forged packets that an endpoint can reject before
-updating keys.<a href="#section-appendix.b-4.10" class="pilcrow">¶</a>
-</dd>
-      <dd class="break"></dd>
-</dl>
-<p id="section-appendix.b-5">The analysis of AEAD_AES_128_CCM relies on a count of the number of block
-operations involved in producing each message. For simplicity, and to match the
-analysis of other AEAD functions in <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span>, this analysis assumes a
-packet length of 2^10 blocks and a packet size limit of 2^14.<a href="#section-appendix.b-5" class="pilcrow">¶</a></p>
-<p id="section-appendix.b-6">For AEAD_AES_128_CCM, the total number of block cipher operations is the sum
-of: the length of the associated data in blocks, the length of the ciphertext
-in blocks, the length of the plaintext in blocks, plus 1. In this analysis,
-this is simplified to a value of twice the length of the packet in blocks (that
-is, <code>2l = 2^11</code>). This simplification is based on the packet containing all of
-the associated data and ciphertext. This results in a negligible 1 to 3 block
-overestimation of the number of operations.<a href="#section-appendix.b-6" class="pilcrow">¶</a></p>
-<div id="confidentiality-limits">
-<section id="section-b.1">
-        <h2 id="name-confidentiality-limits">
-<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-confidentiality-limits" class="section-name selfRef">Confidentiality Limits</a>
-        </h2>
-<p id="section-b.1-1">For confidentiality, Theorem 2 in <span>[<a href="#CCM-ANALYSIS" class="xref">CCM-ANALYSIS</a>]</span> establishes that an attacker
-gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of
-no more than:<a href="#section-b.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-b.1-2">
-<pre>
-(2l * q)^2 / 2^n
-</pre><a href="#section-b.1-2" class="pilcrow">¶</a>
-</div>
-<p id="section-b.1-3">For a target advantage of 2^-60, which matches that used by <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>, this
-results in the relation:<a href="#section-b.1-3" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-b.1-4">
-<pre>
-q &lt;= 2^23
-</pre><a href="#section-b.1-4" class="pilcrow">¶</a>
-</div>
-<p id="section-b.1-5">That is, endpoints cannot protect more than 2^23 packets with the same set of
-keys without causing an attacker to gain a larger advantage than the target of
-2^-60.<a href="#section-b.1-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="integrity-limits">
-<section id="section-b.2">
-        <h2 id="name-integrity-limits">
-<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-integrity-limits" class="section-name selfRef">Integrity Limits</a>
-        </h2>
-<p id="section-b.2-1">For integrity, Theorem 1 in <span>[<a href="#CCM-ANALYSIS" class="xref">CCM-ANALYSIS</a>]</span> establishes that an attacker
-gains an advantage over an ideal PRP of no more than:<a href="#section-b.2-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-b.2-2">
-<pre>
-v / 2^t + (2l * (v + q))^2 / 2^n
-</pre><a href="#section-b.2-2" class="pilcrow">¶</a>
-</div>
-<p id="section-b.2-3">The goal is to limit this advantage to 2^-57, to match the target in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>.
-As <code>t</code> and <code>n</code> are both 128, the first term is negligible relative to the
-second, so that term can be removed without a significant effect on the result.
-This produces the relation:<a href="#section-b.2-3" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-b.2-4">
-<pre>
-v + q &lt;= 2^24.5
-</pre><a href="#section-b.2-4" class="pilcrow">¶</a>
-</div>
-<p id="section-b.2-5">Using the previously-established value of 2^23 for <code>q</code> and rounding, this leads
-to an upper limit on <code>v</code> of 2^23.5. That is, endpoints cannot attempt to
-authenticate more than 2^23.5 packets with the same set of keys without causing
-an attacker to gain a larger advantage than the target of 2^-57.<a href="#section-b.2-5" class="pilcrow">¶</a></p>
-</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="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-tls-28">
-<section id="section-c.1">
-        <h2 id="name-since-draft-ietf-quic-tls-2">
-<a href="#section-c.1" class="section-number selfRef">C.1. </a><a href="#name-since-draft-ietf-quic-tls-2" class="section-name selfRef">Since draft-ietf-quic-tls-28</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.1-1.1">Defined limits on the number of packets that can be protected with a single
-key and limits on the number of packets that can fail authentication (#3619,
-#3620)<a href="#section-c.1-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.1-1.2">Update Initial salt, Retry keys, and samples (#3711)<a href="#section-c.1-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-27">
-<section id="section-c.2">
-        <h2 id="name-since-draft-ietf-quic-tls-27">
-<a href="#section-c.2" class="section-number selfRef">C.2. </a><a href="#name-since-draft-ietf-quic-tls-27" class="section-name selfRef">Since draft-ietf-quic-tls-27</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.2-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-c.2-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.2">Prohibit the use of the compatibility mode from TLS 1.3 (#3594, #3595)<a href="#section-c.2-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-26">
-<section id="section-c.3">
-        <h2 id="name-since-draft-ietf-quic-tls-26">
-<a href="#section-c.3" class="section-number selfRef">C.3. </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-c.3-1.1">No changes<a href="#section-c.3-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-25">
-<section id="section-c.4">
-        <h2 id="name-since-draft-ietf-quic-tls-25">
-<a href="#section-c.4" class="section-number selfRef">C.4. </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-c.4-1.1">No changes<a href="#section-c.4-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-24">
-<section id="section-c.5">
-        <h2 id="name-since-draft-ietf-quic-tls-24">
-<a href="#section-c.5" class="section-number selfRef">C.5. </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-c.5-1.1">
-            <p id="section-c.5-1.1.1">Rewrite key updates (#3050)<a href="#section-c.5-1.1.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.5-1.1.2.1">Allow but don't recommend deferring key updates (#2792, #3263)<a href="#section-c.5-1.1.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.5-1.1.2.2">More completely define received behavior (#2791)<a href="#section-c.5-1.1.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.5-1.1.2.3">Define the label used with HKDF-Expand-Label (#3054)<a href="#section-c.5-1.1.2.3" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-23">
-<section id="section-c.6">
-        <h2 id="name-since-draft-ietf-quic-tls-23">
-<a href="#section-c.6" class="section-number selfRef">C.6. </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-c.6-1.1">
-            <p id="section-c.6-1.1.1">Key update text update (#3050):<a href="#section-c.6-1.1.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.6-1.1.2.1">Recommend constant-time key replacement (#2792)<a href="#section-c.6-1.1.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.6-1.1.2.2">Provide explicit labels for key update key derivation (#3054)<a href="#section-c.6-1.1.2.2" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.6-1.2">Allow first Initial from a client to span multiple packets (#2928, #3045)<a href="#section-c.6-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.3">PING can be sent at any encryption level (#3034, #3035)<a href="#section-c.6-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-22">
-<section id="section-c.7">
-        <h2 id="name-since-draft-ietf-quic-tls-22">
-<a href="#section-c.7" class="section-number selfRef">C.7. </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-c.7-1.1">Update the salt used for Initial secrets (#2887, #2980)<a href="#section-c.7-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-21">
-<section id="section-c.8">
-        <h2 id="name-since-draft-ietf-quic-tls-21">
-<a href="#section-c.8" class="section-number selfRef">C.8. </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-c.8-1.1">No changes<a href="#section-c.8-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-20">
-<section id="section-c.9">
-        <h2 id="name-since-draft-ietf-quic-tls-20">
-<a href="#section-c.9" class="section-number selfRef">C.9. </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-c.9-1.1">Mandate the use of the QUIC transport parameters extension (#2528, #2560)<a href="#section-c.9-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.2">Define handshake completion and confirmation; define clearer rules when it
-encryption keys should be discarded (#2214, #2267, #2673)<a href="#section-c.9-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-18">
-<section id="section-c.10">
-        <h2 id="name-since-draft-ietf-quic-tls-1">
-<a href="#section-c.10" class="section-number selfRef">C.10. </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-c.10-1.1">Increased the set of permissible frames in 0-RTT (#2344, #2355)<a href="#section-c.10-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.2">Transport parameter extension is mandatory (#2528, #2560)<a href="#section-c.10-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-17">
-<section id="section-c.11">
-        <h2 id="name-since-draft-ietf-quic-tls-17">
-<a href="#section-c.11" class="section-number selfRef">C.11. </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-c.11-1.1">Endpoints discard initial keys as soon as handshake keys are available (#1951,
-#2045)<a href="#section-c.11-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.2">Use of ALPN or equivalent is mandatory (#2263, #2284)<a href="#section-c.11-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-14">
-<section id="section-c.12">
-        <h2 id="name-since-draft-ietf-quic-tls-14">
-<a href="#section-c.12" class="section-number selfRef">C.12. </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-c.12-1.1">Update the salt used for Initial secrets (#1970)<a href="#section-c.12-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.2">Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)<a href="#section-c.12-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.3">
-            <p id="section-c.12-1.3.1">Change header protection<a href="#section-c.12-1.3.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.12-1.3.2.1">Sample from a fixed offset (#1575, #2030)<a href="#section-c.12-1.3.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.12-1.3.2.2">Cover part of the first byte, including the key phase (#1322, #2006)<a href="#section-c.12-1.3.2.2" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.12-1.4">
-            <p id="section-c.12-1.4.1">TLS provides an AEAD and KDF function (#2046)<a href="#section-c.12-1.4.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.12-1.4.2.1">Clarify that the TLS KDF is used with TLS (#1997)<a href="#section-c.12-1.4.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.12-1.4.2.2">Change the labels for calculation of QUIC keys (#1845, #1971, #1991)<a href="#section-c.12-1.4.2.2" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.12-1.5">Initial keys are discarded once Handshake keys are available (#1951, #2045)<a href="#section-c.12-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-13">
-<section id="section-c.13">
-        <h2 id="name-since-draft-ietf-quic-tls-13">
-<a href="#section-c.13" class="section-number selfRef">C.13. </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-c.13-1.1">Updated to TLS 1.3 final (#1660)<a href="#section-c.13-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-12">
-<section id="section-c.14">
-        <h2 id="name-since-draft-ietf-quic-tls-12">
-<a href="#section-c.14" class="section-number selfRef">C.14. </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-c.14-1.1">
-            <p id="section-c.14-1.1.1">Changes to integration of the TLS handshake (#829, #1018, #1094, #1165, #1190,
-#1233, #1242, #1252, #1450)<a href="#section-c.14-1.1.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.14-1.1.2.1">The cryptographic handshake uses CRYPTO frames, not stream 0<a href="#section-c.14-1.1.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.14-1.1.2.2">QUIC packet protection is used in place of TLS record protection<a href="#section-c.14-1.1.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.14-1.1.2.3">Separate QUIC packet number spaces are used for the handshake<a href="#section-c.14-1.1.2.3" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.14-1.1.2.4">Changed Retry to be independent of the cryptographic handshake<a href="#section-c.14-1.1.2.4" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.14-1.1.2.5">Limit the use of HelloRetryRequest to address TLS needs (like key shares)<a href="#section-c.14-1.1.2.5" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.14-1.2">Changed codepoint of TLS extension (#1395, #1402)<a href="#section-c.14-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-11">
-<section id="section-c.15">
-        <h2 id="name-since-draft-ietf-quic-tls-11">
-<a href="#section-c.15" class="section-number selfRef">C.15. </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-c.15-1.1">Encrypted packet numbers.<a href="#section-c.15-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-10">
-<section id="section-c.16">
-        <h2 id="name-since-draft-ietf-quic-tls-10">
-<a href="#section-c.16" class="section-number selfRef">C.16. </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-c.16-1.1">No significant changes.<a href="#section-c.16-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-09">
-<section id="section-c.17">
-        <h2 id="name-since-draft-ietf-quic-tls-0">
-<a href="#section-c.17" class="section-number selfRef">C.17. </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-c.17-1.1">Cleaned up key schedule and updated the salt used for handshake packet
-protection (#1077)<a href="#section-c.17-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-08">
-<section id="section-c.18">
-        <h2 id="name-since-draft-ietf-quic-tls-08">
-<a href="#section-c.18" class="section-number selfRef">C.18. </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-c.18-1.1">Specify value for max_early_data_size to enable 0-RTT (#942)<a href="#section-c.18-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.2">Update key derivation function (#1003, #1004)<a href="#section-c.18-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-07">
-<section id="section-c.19">
-        <h2 id="name-since-draft-ietf-quic-tls-07">
-<a href="#section-c.19" class="section-number selfRef">C.19. </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-c.19-1.1">Handshake errors can be reported with CONNECTION_CLOSE (#608, #891)<a href="#section-c.19-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-05">
-<section id="section-c.20">
-        <h2 id="name-since-draft-ietf-quic-tls-05">
-<a href="#section-c.20" class="section-number selfRef">C.20. </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-c.20-1">No significant changes.<a href="#section-c.20-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-04">
-<section id="section-c.21">
-        <h2 id="name-since-draft-ietf-quic-tls-04">
-<a href="#section-c.21" class="section-number selfRef">C.21. </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-c.21-1.1">Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)<a href="#section-c.21-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-03">
-<section id="section-c.22">
-        <h2 id="name-since-draft-ietf-quic-tls-03">
-<a href="#section-c.22" class="section-number selfRef">C.22. </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-c.22-1">No significant changes.<a href="#section-c.22-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-02">
-<section id="section-c.23">
-        <h2 id="name-since-draft-ietf-quic-tls-02">
-<a href="#section-c.23" class="section-number selfRef">C.23. </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-c.23-1.1">Updates to match changes in transport draft<a href="#section-c.23-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-01">
-<section id="section-c.24">
-        <h2 id="name-since-draft-ietf-quic-tls-01">
-<a href="#section-c.24" class="section-number selfRef">C.24. </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-c.24-1.1">Use TLS alerts to signal TLS errors (#272, #374)<a href="#section-c.24-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.2">Require ClientHello to fit in a single packet (#338)<a href="#section-c.24-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.3">The second client handshake flight is now sent in the clear (#262, #337)<a href="#section-c.24-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.4">The QUIC header is included as AEAD Associated Data (#226, #243, #302)<a href="#section-c.24-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.5">Add interface necessary for client address validation (#275)<a href="#section-c.24-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.6">Define peer authentication (#140)<a href="#section-c.24-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.7">Require at least TLS 1.3 (#138)<a href="#section-c.24-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.8">Define transport parameters as a TLS extension (#122)<a href="#section-c.24-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.9">Define handling for protected packets before the handshake completes (#39)<a href="#section-c.24-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.10">Decouple QUIC version and ALPN (#12)<a href="#section-c.24-1.10" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-tls-00">
-<section id="section-c.25">
-        <h2 id="name-since-draft-ietf-quic-tls-00">
-<a href="#section-c.25" class="section-number selfRef">C.25. </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-c.25-1.1">Changed bit used to signal key phase<a href="#section-c.25-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.2">Updated key phase markings during the handshake<a href="#section-c.25-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.3">Added TLS interface requirements section<a href="#section-c.25-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.4">Moved to use of TLS exporters for key derivation<a href="#section-c.25-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.5">Moved TLS error code definitions into this document<a href="#section-c.25-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-thomson-quic-tls-01">
-<section id="section-c.26">
-        <h2 id="name-since-draft-thomson-quic-tl">
-<a href="#section-c.26" class="section-number selfRef">C.26. </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-c.26-1.1">Adopted as base for draft-ietf-quic-tls<a href="#section-c.26-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.26-1.2">Updated authors/editors list<a href="#section-c.26-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.26-1.3">Added status note<a href="#section-c.26-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="#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:<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-appendix.d-2.1">Adam Langley<a href="#section-appendix.d-2.1" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.2">Alessandro Ghedini<a href="#section-appendix.d-2.2" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.3">Christian Huitema<a href="#section-appendix.d-2.3" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.4">Christopher Wood<a href="#section-appendix.d-2.4" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.5">David Schinazi<a href="#section-appendix.d-2.5" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.6">Dragana Damjanovic<a href="#section-appendix.d-2.6" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.7">Eric Rescorla<a href="#section-appendix.d-2.7" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.8">Felix Guenther<a href="#section-appendix.d-2.8" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.9">Ian Swett<a href="#section-appendix.d-2.9" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.10">Jana Iyengar<a href="#section-appendix.d-2.10" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.11">
-          <p id="section-appendix.d-2.11.1">        <span class="contact-name"><span class="non-ascii">奥 一穂</span> (<span class="ascii">Kazuho Oku</span>)</span><a href="#section-appendix.d-2.11.1" class="pilcrow">¶</a></p>
-</li>
-        <li class="normal" id="section-appendix.d-2.12">Marten Seemann<a href="#section-appendix.d-2.12" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.13">Martin Duke<a href="#section-appendix.d-2.13" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.14">Mike Bishop<a href="#section-appendix.d-2.14" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.15">
-          <p id="section-appendix.d-2.15.1">        <span class="contact-name">Mikkel Fahnøe Jørgensen</span><a href="#section-appendix.d-2.15.1" class="pilcrow">¶</a></p>
-</li>
-        <li class="normal" id="section-appendix.d-2.16">Nick Banks<a href="#section-appendix.d-2.16" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.17">Nick Harper<a href="#section-appendix.d-2.17" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.18">Roberto Peon<a href="#section-appendix.d-2.18" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.19">Rui Paulo<a href="#section-appendix.d-2.19" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.20">Ryan Hamilton<a href="#section-appendix.d-2.20" class="pilcrow">¶</a>
-</li>
-        <li class="normal" id="section-appendix.d-2.21">Victor Vasiliev<a href="#section-appendix.d-2.21" 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">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/split-initial-close/draft-ietf-quic-tls.txt b/split-initial-close/draft-ietf-quic-tls.txt
deleted file mode 100644
index fadc4dc138..0000000000
--- a/split-initial-close/draft-ietf-quic-tls.txt
+++ /dev/null
@@ -1,3528 +0,0 @@
-
-
-
-
-QUIC                                                     M. Thomson, Ed.
-Internet-Draft                                                   Mozilla
-Intended status: Standards Track                          S. Turner, Ed.
-Expires: 18 February 2021                                          sn3rd
-                                                          17 August 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), 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 18 February 2021.
-
-Copyright Notice
-
-   Copyright (c) 2020 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021                [Page 1]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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  . . . . . . . . . . . . . . . . . . . . . .   5
-   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  . . . . . . . . . . . . . . . . . . . .  16
-     4.4.  Peer Authentication . . . . . . . . . . . . . . . . . . .  17
-     4.5.  Session Resumption  . . . . . . . . . . . . . . . . . . .  17
-     4.6.  0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . .  18
-       4.6.1.  Enabling 0-RTT  . . . . . . . . . . . . . . . . . . .  19
-       4.6.2.  Accepting and Rejecting 0-RTT . . . . . . . . . . . .  19
-       4.6.3.  Validating 0-RTT Configuration  . . . . . . . . . . .  20
-     4.7.  HelloRetryRequest . . . . . . . . . . . . . . . . . . . .  20
-     4.8.  TLS Errors  . . . . . . . . . . . . . . . . . . . . . . .  20
-     4.9.  Discarding Unused Keys  . . . . . . . . . . . . . . . . .  21
-       4.9.1.  Discarding Initial Keys . . . . . . . . . . . . . . .  21
-       4.9.2.  Discarding Handshake Keys . . . . . . . . . . . . . .  22
-       4.9.3.  Discarding 0-RTT Keys . . . . . . . . . . . . . . . .  22
-   5.  Packet Protection . . . . . . . . . . . . . . . . . . . . . .  22
-     5.1.  Packet Protection Keys  . . . . . . . . . . . . . . . . .  23
-     5.2.  Initial Secrets . . . . . . . . . . . . . . . . . . . . .  24
-     5.3.  AEAD Usage  . . . . . . . . . . . . . . . . . . . . . . .  25
-     5.4.  Header Protection . . . . . . . . . . . . . . . . . . . .  26
-       5.4.1.  Header Protection Application . . . . . . . . . . . .  26
-       5.4.2.  Header Protection Sample  . . . . . . . . . . . . . .  28
-       5.4.3.  AES-Based Header Protection . . . . . . . . . . . . .  30
-       5.4.4.  ChaCha20-Based Header Protection  . . . . . . . . . .  30
-     5.5.  Receiving Protected Packets . . . . . . . . . . . . . . .  30
-     5.6.  Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . .  31
-     5.7.  Receiving Out-of-Order Protected Frames . . . . . . . . .  31
-
-
-
-Thomson & Turner        Expires 18 February 2021                [Page 2]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-     5.8.  Retry Packet Integrity  . . . . . . . . . . . . . . . . .  33
-   6.  Key Update  . . . . . . . . . . . . . . . . . . . . . . . . .  34
-     6.1.  Initiating a Key Update . . . . . . . . . . . . . . . . .  35
-     6.2.  Responding to a Key Update  . . . . . . . . . . . . . . .  36
-     6.3.  Timing of Receive Key Generation  . . . . . . . . . . . .  37
-     6.4.  Sending with Updated Keys . . . . . . . . . . . . . . . .  38
-     6.5.  Receiving with Different Keys . . . . . . . . . . . . . .  38
-     6.6.  Minimum Key Update Frequency  . . . . . . . . . . . . . .  39
-     6.7.  Key Update Error Code . . . . . . . . . . . . . . . . . .  40
-   7.  Security of Initial Messages  . . . . . . . . . . . . . . . .  40
-   8.  QUIC-Specific Adjustments to the TLS Handshake  . . . . . . .  41
-     8.1.  Protocol Negotiation  . . . . . . . . . . . . . . . . . .  41
-     8.2.  QUIC Transport Parameters Extension . . . . . . . . . . .  42
-     8.3.  Removing the EndOfEarlyData Message . . . . . . . . . . .  42
-     8.4.  Prohibit TLS Middlebox Compatibility Mode . . . . . . . .  43
-   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  43
-     9.1.  Session Linkability . . . . . . . . . . . . . . . . . . .  43
-     9.2.  Replay Attacks with 0-RTT . . . . . . . . . . . . . . . .  43
-     9.3.  Packet Reflection Attack Mitigation . . . . . . . . . . .  44
-     9.4.  Header Protection Analysis  . . . . . . . . . . . . . . .  45
-     9.5.  Header Protection Timing Side-Channels  . . . . . . . . .  46
-     9.6.  Key Diversity . . . . . . . . . . . . . . . . . . . . . .  46
-   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
-   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  47
-     11.1.  Normative References . . . . . . . . . . . . . . . . . .  47
-     11.2.  Informative References . . . . . . . . . . . . . . . . .  48
-   Appendix A.  Sample Packet Protection . . . . . . . . . . . . . .  50
-     A.1.  Keys  . . . . . . . . . . . . . . . . . . . . . . . . . .  50
-     A.2.  Client Initial  . . . . . . . . . . . . . . . . . . . . .  51
-     A.3.  Server Initial  . . . . . . . . . . . . . . . . . . . . .  53
-     A.4.  Retry . . . . . . . . . . . . . . . . . . . . . . . . . .  54
-     A.5.  ChaCha20-Poly1305 Short Header Packet . . . . . . . . . .  54
-   Appendix B.  Analysis of Limits on AEAD_AES_128_CCM Usage . . . .  56
-     B.1.  Confidentiality Limits  . . . . . . . . . . . . . . . . .  57
-     B.2.  Integrity Limits  . . . . . . . . . . . . . . . . . . . .  57
-   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  57
-     C.1.  Since draft-ietf-quic-tls-28  . . . . . . . . . . . . . .  57
-     C.2.  Since draft-ietf-quic-tls-27  . . . . . . . . . . . . . .  58
-     C.3.  Since draft-ietf-quic-tls-26  . . . . . . . . . . . . . .  58
-     C.4.  Since draft-ietf-quic-tls-25  . . . . . . . . . . . . . .  58
-     C.5.  Since draft-ietf-quic-tls-24  . . . . . . . . . . . . . .  58
-     C.6.  Since draft-ietf-quic-tls-23  . . . . . . . . . . . . . .  58
-     C.7.  Since draft-ietf-quic-tls-22  . . . . . . . . . . . . . .  58
-     C.8.  Since draft-ietf-quic-tls-21  . . . . . . . . . . . . . .  59
-     C.9.  Since draft-ietf-quic-tls-20  . . . . . . . . . . . . . .  59
-     C.10. Since draft-ietf-quic-tls-18  . . . . . . . . . . . . . .  59
-     C.11. Since draft-ietf-quic-tls-17  . . . . . . . . . . . . . .  59
-     C.12. Since draft-ietf-quic-tls-14  . . . . . . . . . . . . . .  59
-
-
-
-Thomson & Turner        Expires 18 February 2021                [Page 3]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-     C.13. Since draft-ietf-quic-tls-13  . . . . . . . . . . . . . .  60
-     C.14. Since draft-ietf-quic-tls-12  . . . . . . . . . . . . . .  60
-     C.15. Since draft-ietf-quic-tls-11  . . . . . . . . . . . . . .  60
-     C.16. Since draft-ietf-quic-tls-10  . . . . . . . . . . . . . .  60
-     C.17. Since draft-ietf-quic-tls-09  . . . . . . . . . . . . . .  60
-     C.18. Since draft-ietf-quic-tls-08  . . . . . . . . . . . . . .  60
-     C.19. Since draft-ietf-quic-tls-07  . . . . . . . . . . . . . .  60
-     C.20. Since draft-ietf-quic-tls-05  . . . . . . . . . . . . . .  61
-     C.21. Since draft-ietf-quic-tls-04  . . . . . . . . . . . . . .  61
-     C.22. Since draft-ietf-quic-tls-03  . . . . . . . . . . . . . .  61
-     C.23. Since draft-ietf-quic-tls-02  . . . . . . . . . . . . . .  61
-     C.24. Since draft-ietf-quic-tls-01  . . . . . . . . . . . . . .  61
-     C.25. Since draft-ietf-quic-tls-00  . . . . . . . . . . . . . .  61
-     C.26. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . .  62
-   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  62
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  63
-
-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.
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021                [Page 4]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-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.
-
-             +-------------+------------+--------------+---------+
-   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 Early Data (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:
-
-
-
-Thomson & Turner        Expires 18 February 2021                [Page 5]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  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 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
-
-
-
-Thomson & Turner        Expires 18 February 2021                [Page 6]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   Application Data may appear only in the Early Data and Application
-   Data levels.  Handshake and Alert messages may appear in any level.
-
-   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 18 February 2021                [Page 7]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 that 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 18 February 2021                [Page 8]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 that 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 18 February 2021                [Page 9]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 18 February 2021               [Page 10]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 bytes that comprise handshake messages.
-
-   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 handshake bytes for the current encryption level.  The encryption
-   level then determines the type of packet that the resulting CRYPTO
-   frame is carried in; see Table 1.
-
-   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.
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 11]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-   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.8.  TLS application data and other message types
-   cannot be carried by QUIC at any encryption level; it 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 uses the current 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 that 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 to TLS.  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.
-
-   The content of CRYPTO frames might either be processed incrementally
-   by TLS or buffered until complete messages or flights are available.
-   TLS is responsible for buffering handshake bytes that have arrived in
-   order.  QUIC is responsible for buffering handshake bytes that arrive
-   out of order or for encryption levels that are not yet ready.  QUIC
-   does not provide any means of flow control for CRYPTO frames; see
-   Section 7.5 of [QUIC-TRANSPORT].
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 12]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-4.1.4.  Encryption Level Changes
-
-   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
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 13]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-   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.  Solid arrows indicate packets that carry handshake data;
-   dashed arrows show where application data can be sent.  Each arrow is
-   tagged with the encryption level used for that transmission.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 14]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   Client                                                    Server
-   ======                                                    ======
-
-   Get Handshake
-                        Initial ------------->
-   Install tx 0-RTT Keys
-                        0-RTT - - - - - - - ->
-
-                                                 Handshake Received
-                                                      Get Handshake
-                        <------------- Initial
-                                              Install rx 0-RTT keys
-                                             Install Handshake keys
-                                                      Get Handshake
-                        <----------- Handshake
-                                              Install tx 1-RTT keys
-                        <- - - - - - - - 1-RTT
-
-   Handshake Received (Initial)
-   Install Handshake keys
-   Handshake Received (Handshake)
-   Get Handshake
-                        Handshake ----------->
-   Handshake Complete
-   Install 1-RTT keys
-                        1-RTT - - - - - - - ->
-
-                                                 Handshake Received
-                                                 Handshake Complete
-                                              Install rx 1-RTT keys
-
-             Figure 5: Interaction Summary between QUIC and TLS
-
-   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 incoming packets have been processed.  This process varies
-   based on the structure of endpoint implementations and the order in
-   which packets arrive; this is intended to illustrate the steps
-   involved in a single handshake exchange.
-
-4.2.  TLS Version
-
-   This document describes how TLS 1.3 [TLS13] is used with QUIC.
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 15]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-   Clients MUST NOT offer TLS versions older than 1.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.
-
-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.
-
-   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.
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 16]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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]).
-
-   Note:  Where servers provide certificates for authentication, the
-      size of the certificate chain can consume a large number of bytes.
-      Controlling the size of certificate chains is critical to
-      performance in QUIC as servers are limited to sending 3 bytes for
-      every byte received prior to validating the client address; see
-      Section 8.1 of [QUIC-TRANSPORT].  The size of a certificate chain
-      can be managed by limiting the number of names or extensions;
-      using keys with small public key representations, like ECDSA; or
-      by using certificate compression [COMPRESS].
-
-   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.
-
-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.
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 17]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.1 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.  0-RTT
-
-   The 0-RTT feature in QUIC allows a client to send application data
-   before the handshake is complete.  This is made possible by reusing
-   negotiated parameters from a previous connection.  To enable this,
-   0-RTT depends on the client remembering critical parameters and
-   providing the server with a TLS session ticket that allows the server
-   to recover the same information.
-
-   This information includes parameters that determine TLS state, as
-   governed by [TLS13], QUIC transport parameters, the chosen
-   application protocol, and any information the application protocol
-   might need; see Section 4.6.3.  This information determines how 0-RTT
-   packets and their contents are formed.
-
-   To ensure that the same information is available to both endpoints,
-   all information used to establish 0-RTT comes from the same
-   connection.  Endpoints cannot selectively disregard information that
-   might alter the sending or processing of 0-RTT.
-
-   [TLS13] sets a limit of 7 days on the time between the original
-   connection and any attempt to use 0-RTT.  There are other constraints
-   on 0-RTT usage, notably those caused by the potential exposure to
-   replay attack; see Section 9.2.
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 18]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-4.6.1.  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 TLS
-   max_early_data_size parameter is not used in QUIC.  The amount of
-   data that 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 field 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 application data in 0-RTT
-   packets.
-
-   A client that attempts 0-RTT might also provide an address validation
-   token if the server has sent a NEW_TOKEN frame; see Section 8.1 of
-   [QUIC-TRANSPORT].
-
-4.6.2.  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 reattempt 0-RTT if it receives a Retry or Version
-   Negotiation packet.  These packets do not signify rejection of 0-RTT.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 19]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-4.6.3.  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.
-
-4.7.  HelloRetryRequest
-
-   The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be
-   used to request that a client provide new information, such as a key
-   share, or to validate some characteristic of the client.  From the
-   perspective of QUIC, HelloRetryRequest is not differentiated from
-   other cryptographic handshake messages that are carried in Initial
-   packets.  Although it is in principle possible to use this feature
-   for address verification, QUIC implementations SHOULD instead use the
-   Retry feature; see Section 8.1 of [QUIC-TRANSPORT].
-
-4.8.  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.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 20]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.9.  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.
-
-   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.9.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.
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 21]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.9.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.9.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.
-
-   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 [AEAD] negotiated by TLS.
-
-   QUIC packets have varying protections depending on their type:
-
-   *  Version Negotiation packets have no cryptographic protection.
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 22]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  Retry packets use AEAD_AES_128_GCM to provide protection against
-      accidental modification or insertion by off-path adversaries; see
-      Section 5.8.
-
-   *  Initial packets use AEAD_AES_128_GCM with keys derived from the
-      Destination Connection ID field of the first Initial packet sent
-      by the client; see Section 5.2.
-
-   *  All other packets have strong cryptographic protections for
-      confidentiality and integrity, using keys and algorithms
-      negotiated by TLS.
-
-   This section describes how packet protection is applied to Handshake
-   packets, 0-RTT packets, and 1-RTT packets.  The same packet
-   protection process is applied to Initial packets.  However, as it is
-   trivial to determine the keys used for Initial packets, these packets
-   are not considered to have confidentiality or integrity protection.
-   Retry packets use a fixed key and so similarly lack confidentiality
-   and integrity protection.
-
-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.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 23]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-5.2.  Initial Secrets
-
-   Initial packets apply the packet protection process, but use a secret
-   derived from the Destination Connection ID field from the client's
-   first Initial packet.
-
-   This secret is determined by using HKDF-Extract (see Section 2.2 of
-   [HKDF]) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and
-   a IKM of the Destination Connection ID field.  This produces an
-   intermediate pseudorandom key (PRK) that is used to derive two
-   separate secrets for sending and receiving.
-
-   The secret used by clients to construct Initial packets uses the PRK
-   and the label "client in" as input to the HKDF-Expand-Label function
-   to produce a 32 byte secret; packets constructed by the server use
-   the same process with the label "server in".  The hash function for
-   HKDF when deriving initial secrets and keys is SHA-256 [SHA].
-
-   This process in pseudocode is:
-
-   initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899
-   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 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.
-
-   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 recognizes only 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.
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 24]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   The secrets used for constructing 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 sample Initial packets.
-
-5.3.  AEAD Usage
-
-   The Authenticated Encryption with Associated Data (AEAD; see [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 cipher suite, the AEAD_AES_128_GCM
-   function is used.
-
-   QUIC can use any of the cipher suites defined in [TLS13] with the
-   exception of TLS_AES_128_CCM_8_SHA256.  A cipher suite MUST NOT be
-   negotiated unless a header protection scheme is defined for the
-   cipher suite.  This document defines a header protection scheme for
-   all cipher suites defined in [TLS13] aside from
-   TLS_AES_128_CCM_8_SHA256.  These cipher suites 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 cipher
-      suite that it does not support, or it would be impossible to
-      deploy a new cipher suite.  This also applies to
-      TLS_AES_128_CCM_8_SHA256.
-
-   When constructing packets, the AEAD function is applied prior to
-   applying header protection; see Section 5.4.  The unprotected packet
-   header is part of the associated data (A).  When processing packets,
-   an endpoint first removes the header protection.
-
-   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.
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 25]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   The associated data, A, for the AEAD is the contents of the QUIC
-   header, starting from the first byte of 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].
-
-   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 separately from 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.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 26]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   The output of this algorithm is a 5-byte mask that 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.
-
-   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 18 February 2021               [Page 27]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 (..),
-     Length (i),
-     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 cipher suite can be used with QUIC, a header protection
-   algorithm MUST be specified for the AEAD used with that cipher suite.
-   This document defines algorithms for AEAD_AES_128_GCM,
-   AEAD_AES_128_CCM, AEAD_AES_256_GCM (all these AES AEADs are defined
-   in [AEAD]), and AEAD_CHACHA20_POLY1305 (defined in [CHACHA]).  Prior
-   to TLS selecting a cipher suite, 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 18 February 2021               [Page 28]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 cipher suites 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 18 February 2021               [Page 29]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 in electronic
-   code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES in ECB mode.
-   AES is defined in [AES].
-
-   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 18 February 2021               [Page 30]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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.1), 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 18 February 2021               [Page 31]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 before the handshake is
-   complete is limited to sending data.  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.
-
-   A client generally receives 1-RTT keys at the same time as the
-   handshake completes.  Even if it has 1-RTT secrets, a client MUST NOT
-   process incoming 1-RTT protected packets before the TLS handshake is
-   complete.
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 32]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-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.
-
-   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
-      0xccce187ed09a09d05728155a6cb96be1.
-
-   *  The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c.
-
-   *  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
-   0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c 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 Length field contains the length in bytes of
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 33]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-      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 Length.  The presence of
-      this field mitigates an off-path attacker's ability to inject a
-      Retry packet.
-
-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.8).
-
-   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
-   [].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 34]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-      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
-
-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 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
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 35]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 36]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-   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.
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 37]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-   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
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 38]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.  Minimum 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.  [TLS13]
-   does not specify a limit for AEAD_AES_128_CCM, but the analysis in
-   Appendix B shows that a limit of 2^23 packets can be used to obtain
-   the same confidentiality protection as the limits specified in TLS.
-
-   The usage limits defined in TLS 1.3 exist for protection against
-   attacks on confidentiality and apply to successful applications of
-   AEAD protection.  The integrity protections in authenticated
-   encryption also depend on limiting the number of attempts to forge
-   packets.  TLS achieves this by closing connections after any record
-   fails an authentication check.  In comparison, QUIC ignores any
-   packet that cannot be authenticated, allowing multiple forgery
-   attempts.
-
-   Endpoints MUST count the number of received packets that fail
-   authentication for each set of keys.  If the number of packets that
-   fail authentication with the same key exceeds a limit that is
-   specific to the AEAD in use, the endpoint MUST stop using those keys.
-   Endpoints MUST initiate a key update before reaching this limit.  If
-   a key update is not possible, the endpoint MUST immediately close the
-   connection.  Applying a limit reduces the probability that an
-   attacker is able to successfully forge a packet; see [AEBounds] and
-   [ROBUST].
-
-   Note:  Due to the way that header protection protects the Key Phase,
-      packets that are discarded are likely to have an even distribution
-      of both Key Phase values.  This means that packets that fail
-      authentication will often use the packet protection keys from the
-      next key phase.  It is therefore necessary to also track the
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 39]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-      number of packets that fail authentication with the next set of
-      packet protection keys.  To avoid exhaustion of both sets of keys,
-      it might be necessary to initiate two key updates in succession.
-
-   For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305,
-   the limit on the number of packets that fail authentication is 2^36.
-   Note that the analysis in [AEBounds] supports a higher limit for the
-   AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification
-   recommends a lower limit.  For AEAD_AES_128_CCM, the limit on the
-   number of packets that fail authentication is 2^23.5; see Appendix B.
-
-   Note:  These limits were originally calculated using assumptions
-      about the limits on TLS record size.  The maximum size of a TLS
-      record is 2^14 bytes.  In comparison, QUIC packets can be up to
-      2^16 bytes.  However, it is expected that QUIC packets will
-      generally be smaller than TLS records.  Where packets might be
-      larger than 2^14 bytes in length, smaller limits might be needed.
-
-   Any TLS cipher suite that is specified for use with QUIC MUST define
-   limits on the use of the associated AEAD function that preserves
-   margins for confidentiality and integrity.  That is, limits MUST be
-   specified for the number of packets that can be authenticated and for
-   the number of packets that can fail authentication.  Providing a
-   reference to any analysis upon which values are based - and any
-   assumptions used in that analysis - allows limits to be adapted to
-   varying usage conditions.
-
-6.7.  Key Update Error Code
-
-   The KEY_UPDATE_ERROR error code (0xE) is used to signal errors
-   related to key updates.
-
-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.
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 40]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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 that 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
-
-   Certain aspects of the TLS handshake are different when used with
-   QUIC.
-
-   QUIC also requires additional features from TLS.  In addition to
-   negotiation of cryptographic parameters, the TLS handshake carries
-   and authenticates values for QUIC transport parameters.
-
-8.1.  Protocol Negotiation
-
-   QUIC requires that the cryptographic handshake provide authenticated
-   protocol negotiation.  TLS uses Application Layer Protocol
-   Negotiation ([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.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS
-   alert (QUIC error code 0x178; see Section 4.8) 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
-   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.
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 41]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-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.8).
-
-   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.
-
-   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.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 42]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-
-   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.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 43]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   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.
-      Specifically, to enable a server to efficiently recover state that
-      is used in connection establishment and address validation.  These
-      MUST NOT be used to communicate application semantics between
-      endpoints; clients MUST treat them as opaque values.  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.
-
-   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 times as many bytes as the number
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 44]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   of bytes it has received (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 that 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 18 February 2021               [Page 45]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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 tried 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 18 February 2021               [Page 46]
-
-Internet-Draft          Using TLS to Secure QUIC             August 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>.
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 47]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   [HKDF]     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>.
-
-   [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, 17 August 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, 17
-              August 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>.
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 48]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   [CCM-ANALYSIS]
-              Jonsson, J., "On the Security of CTR + CBC-MAC",
-              DOI 10.1007/3-540-36492-7_7, Selected Areas in
-              Cryptography pp. 76-93, 2003,
-              <https://doi.org/10.1007/3-540-36492-7_7>.
-
-   [COMPRESS] Ghedini, A. and V. Vasiliev, "TLS Certificate
-              Compression", Work in Progress, Internet-Draft, draft-
-              ietf-tls-certificate-compression-10, 6 January 2020,
-              <http://www.ietf.org/internet-drafts/draft-ietf-tls-
-              certificate-compression-10.txt>.
-
-   [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.
-
-   [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, 17 August 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>.
-
-   [ROBUST]   Fischlin, M., Günther, F., and C. Janson, "Robust
-              Channels: Handling Unreliable Networks in the Record
-              Layers of QUIC and DTLS 1.3", 16 May 2020,
-              <https://eprint.iacr.org/2020/718>.
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 49]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-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:
-
-   initial_secret = HKDF-Extract(initial_salt, cid)
-       = 1e7e7764529715b1e0ddc8e9753c6157
-         6769605187793ed366f8bbf8c9e986eb
-
-   The secrets for protecting client packets are:
-
-   client_initial_secret
-       = HKDF-Expand-Label(initial_secret, "client in", _, 32)
-       = 0088119288f1d866733ceeed15ff9d50
-         902cf82952eee27e9d4d4918ea371d87
-
-   key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
-       = 175257a31eb09dea9366d8bb79ad80ba
-
-   iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
-       = 6b26114b9cba2b63a9e8dd4f
-
-   hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
-       = 9ddd12c994c0698b89374a9c077a3077
-
-   The secrets for protecting server packets are:
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 50]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   server_initial_secret
-       = HKDF-Expand-Label(initial_secret, "server in", _, 32)
-       = 006f881359244dd9ad1acf85f595bad6
-         7c13f9f5586f5e64e1acae1d9ea8f616
-
-   key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
-       = 149d0b1662ab871fbe63c49b5e655a5d
-
-   iv  = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
-       = bab2b12a4c76016ace47856d
-
-   hp  = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
-       = c0c499a65a60024a18a250974ea01dfa
-
-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:
-
-   060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
-   04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
-   616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
-   04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
-   baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
-   0d0010000e0403050306030203080408 050806002d00020101001c00024001ff
-   a500320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
-   75300901100f088394c8f03e51570806 048000ffff
-
-   The unprotected header includes the connection ID and a 4-byte packet
-   number encoding for a packet number of 2:
-
-   c3ff00001d088394c8f03e5157080000449e00000002
-
-   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:
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 51]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   sample = fb66bc6a93032b50dd8973972d149421
-
-   mask = AES-ECB(hp, sample)[0..4]
-        = 1e9cdb9909
-
-   header[0] ^= mask[0] & 0x0f
-        = cd
-   header[18..21] ^= mask[1..4]
-        = 9cdb990b
-   header = cdff00001d088394c8f03e5157080000449e9cdb990b
-
-   The resulting protected packet is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 52]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   cdff00001d088394c8f03e5157080000 449e9cdb990bfb66bc6a93032b50dd89
-   73972d149421874d3849e3708d71354e a33bcdc356f3ea6e2a1a1bd7c3d14003
-   8d3e784d04c30a2cdb40c32523aba2da fe1c1bf3d27a6be38fe38ae033fbb071
-   3c1c73661bb6639795b42b97f77068ea d51f11fbf9489af2501d09481e6c64d4
-   b8551cd3cea70d830ce2aeeec789ef55 1a7fbe36b3f7e1549a9f8d8e153b3fac
-   3fb7b7812c9ed7c20b4be190ebd89956 26e7f0fc887925ec6f0606c5d36aa81b
-   ebb7aacdc4a31bb5f23d55faef5c5190 5783384f375a43235b5c742c78ab1bae
-   0a188b75efbde6b3774ed61282f9670a 9dea19e1566103ce675ab4e21081fb58
-   60340a1e88e4f10e39eae25cd685b109 29636d4f02e7fad2a5a458249f5c0298
-   a6d53acbe41a7fc83fa7cc01973f7a74 d1237a51974e097636b6203997f921d0
-   7bc1940a6f2d0de9f5a11432946159ed 6cc21df65c4ddd1115f86427259a196c
-   7148b25b6478b0dc7766e1c4d1b1f515 9f90eabc61636226244642ee148b464c
-   9e619ee50a5e3ddc836227cad938987c 4ea3c1fa7c75bbf88d89e9ada642b2b8
-   8fe8107b7ea375b1b64889a4e9e5c38a 1c896ce275a5658d250e2d76e1ed3a34
-   ce7e3a3f383d0c996d0bed106c2899ca 6fc263ef0455e74bb6ac1640ea7bfedc
-   59f03fee0e1725ea150ff4d69a7660c5 542119c71de270ae7c3ecfd1af2c4ce5
-   51986949cc34a66b3e216bfe18b347e6 c05fd050f85912db303a8f054ec23e38
-   f44d1c725ab641ae929fecc8e3cefa56 19df4231f5b4c009fa0c0bbc60bc75f7
-   6d06ef154fc8577077d9d6a1d2bd9bf0 81dc783ece60111bea7da9e5a9748069
-   d078b2bef48de04cabe3755b197d52b3 2046949ecaa310274b4aac0d008b1948
-   c1082cdfe2083e386d4fd84c0ed0666d 3ee26c4515c4fee73433ac703b690a9f
-   7bf278a77486ace44c489a0c7ac8dfe4 d1a58fb3a730b993ff0f0d61b4d89557
-   831eb4c752ffd39c10f6b9f46d8db278 da624fd800e4af85548a294c1518893a
-   8778c4f6d6d73c93df200960104e062b 388ea97dcf4016bced7f62b4f062cb6c
-   04c20693d9a0e3b74ba8fe74cc012378 84f40d765ae56a51688d985cf0ceaef4
-   3045ed8c3f0c33bced08537f6882613a cd3b08d665fce9dd8aa73171e2d3771a
-   61dba2790e491d413d93d987e2745af2 9418e428be34941485c93447520ffe23
-   1da2304d6a0fd5d07d08372202369661 59bef3cf904d722324dd852513df39ae
-   030d8173908da6364786d3c1bfcb19ea 77a63b25f1e7fc661def480c5d00d444
-   56269ebd84efd8e3a8b2c257eec76060 682848cbf5194bc99e49ee75e4d0d254
-   bad4bfd74970c30e44b65511d4ad0e6e c7398e08e01307eeeea14e46ccd87cf3
-   6b285221254d8fc6a6765c524ded0085 dca5bd688ddf722e2c0faf9d0fb2ce7a
-   0c3f2cee19ca0ffba461ca8dc5d2c817 8b0762cf67135558494d2a96f1a139f0
-   edb42d2af89a9c9122b07acbc29e5e72 2df8615c343702491098478a389c9872
-   a10b0c9875125e257c7bfdf27eef4060 bd3d00f4c14fd3e3496c38d3c5d1a566
-   8c39350effbc2d16ca17be4ce29f02ed 969504dda2a8c6b9ff919e693ee79e09
-   089316e7d1d89ec099db3b2b268725d8 88536a4b8bf9aee8fb43e82a4d919d48
-   1802771a449b30f3fa2289852607b660
-
-A.3.  Server Initial
-
-   The server sends the following payload in response, including an ACK
-   frame, a CRYPTO frame, and no PADDING frames:
-
-   02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
-   88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
-   0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
-   020304
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 53]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   The header from the server includes a new connection ID and a 2-byte
-   packet number encoding for a packet number of 1:
-
-   c1ff00001d0008f067a5502a4262b50040740001
-
-   As a result, after protection, the header protection sample is taken
-   starting from the third protected octet:
-
-   sample = 823a5d3a1207c86ee49132824f046524
-   mask   = abaaf34fdc
-   header = caff00001d0008f067a5502a4262b5004074aaf2
-
-   The final protected packet is then:
-
-   c7ff00001d0008f067a5502a4262b500 4075fb12ff07823a5d24534d906ce4c7
-   6782a2167e3479c0f7f6395dc2c91676 302fe6d70bb7cbeb117b4ddb7d173498
-   44fd61dae200b8338e1b932976b61d91 e64a02e9e0ee72e3a6f63aba4ceeeec5
-   be2f24f2d86027572943533846caa13e 6f163fb257473dcca25396e88724f1e5
-   d964dedee9b633
-
-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:
-
-   ffff00001d0008f067a5502a4262b574 6f6b656ed16926d81f6f9ca2953a8aa4
-   575e1e49
-
-A.5.  ChaCha20-Poly1305 Short Header Packet
-
-   This example shows some of the steps required to protect a packet
-   with a short header.  This example uses AEAD_CHACHA20_POLY1305.
-
-   In this example, TLS produces an application write secret from which
-   a server uses HKDF-Expand-Label to produce four values: a key, an IV,
-   a header protection key, and the secret that will be used after keys
-   are updated (this last value is not used further in this example).
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 54]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   secret
-       = 9ac312a7f877468ebe69422748ad00a1
-         5443f18203a07d6060f688f30f21632b
-
-   key = HKDF-Expand-Label(secret, "quic key", _, 32)
-       = c6d98ff3441c3fe1b2182094f69caa2e
-         d4b716b65488960a7a984979fb23e1c8
-
-   iv  = HKDF-Expand-Label(secret, "quic iv", _, 12)
-       = e0459b3474bdd0e44a41c144
-
-   hp  = HKDF-Expand-Label(secret, "quic hp", _, 32)
-       = 25a282b9e82f06f21f488917a4fc8f1b
-         73573685608597d0efcb076b0ab7a7a4
-
-   ku  = HKDF-Expand-Label(secret, "quic ku", _, 32)
-       = 1223504755036d556342ee9361d25342
-         1a826c9ecdf3c7148684b36b714881f9
-
-   The following shows the steps involved in protecting a minimal packet
-   with an empty Destination Connection ID.  This packet contains a
-   single PING frame (that is, a payload of just 0x01) and has a packet
-   number of 654360564.  In this example, using a packet number of
-   length 3 (that is, 49140 is encoded) avoids having to pad the payload
-   of the packet; PADDING frames would be needed if the packet number is
-   encoded on fewer octets.
-
-   pn                 = 654360564 (decimal)
-   nonce              = e0459b3474bdd0e46d417eb0
-   unprotected header = 4200bff4
-   payload plaintext  = 01
-   payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb
-
-   The resulting ciphertext is the minimum size possible.  One byte is
-   skipped to produce the sample for header protection.
-
-   sample = 5e5cd55c41f69080575d7999c25a5bfb
-   mask   = aefefe7d03
-   header = 4cfe4189
-
-   The protected packet is the smallest possible packet size of 21
-   bytes.
-
-   packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 55]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-Appendix B.  Analysis of Limits on AEAD_AES_128_CCM Usage
-
-   [TLS13] and [AEBounds] do not specify limits on usage for
-   AEAD_AES_128_CCM.  However, any AEAD that is used with QUIC requires
-   limits on use that ensure that both confidentiality and integrity are
-   preserved.  This section documents that analysis.
-
-   [CCM-ANALYSIS] is used as the basis of this analysis.  The results of
-   that analysis are used to derive usage limits that are based on those
-   chosen in [TLS13].
-
-   This analysis uses symbols for multiplication (*), division (/), and
-   exponentiation (^), plus parentheses for establishing precedence.
-   The following symbols are also used:
-
-   t:  The size of the authentication tag in bits.  For this cipher, t
-      is 128.
-
-   n:  The size of the block function in bits.  For this cipher, n is
-      128.
-
-   l:  The number of blocks in each packet (see below).
-
-   q:  The number of genuine packets created and protected by endpoints.
-      This value is the bound on the number of packets that can be
-      protected before updating keys.
-
-   v:  The number of forged packets that endpoints will accept.  This
-      value is the bound on the number of forged packets that an
-      endpoint can reject before updating keys.
-
-   The analysis of AEAD_AES_128_CCM relies on a count of the number of
-   block operations involved in producing each message.  For simplicity,
-   and to match the analysis of other AEAD functions in [AEBounds], this
-   analysis assumes a packet length of 2^10 blocks and a packet size
-   limit of 2^14.
-
-   For AEAD_AES_128_CCM, the total number of block cipher operations is
-   the sum of: the length of the associated data in blocks, the length
-   of the ciphertext in blocks, the length of the plaintext in blocks,
-   plus 1.  In this analysis, this is simplified to a value of twice the
-   length of the packet in blocks (that is, "2l = 2^11").  This
-   simplification is based on the packet containing all of the
-   associated data and ciphertext.  This results in a negligible 1 to 3
-   block overestimation of the number of operations.
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 56]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-B.1.  Confidentiality Limits
-
-   For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an
-   attacker gains a distinguishing advantage over an ideal pseudorandom
-   permutation (PRP) of no more than:
-
-   (2l * q)^2 / 2^n
-
-   For a target advantage of 2^-60, which matches that used by [TLS13],
-   this results in the relation:
-
-   q <= 2^23
-
-   That is, endpoints cannot protect more than 2^23 packets with the
-   same set of keys without causing an attacker to gain a larger
-   advantage than the target of 2^-60.
-
-B.2.  Integrity Limits
-
-   For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an
-   attacker gains an advantage over an ideal PRP of no more than:
-
-   v / 2^t + (2l * (v + q))^2 / 2^n
-
-   The goal is to limit this advantage to 2^-57, to match the target in
-   [TLS13].  As "t" and "n" are both 128, the first term is negligible
-   relative to the second, so that term can be removed without a
-   significant effect on the result.  This produces the relation:
-
-   v + q <= 2^24.5
-
-   Using the previously-established value of 2^23 for "q" and rounding,
-   this leads to an upper limit on "v" of 2^23.5.  That is, endpoints
-   cannot attempt to authenticate more than 2^23.5 packets with the same
-   set of keys without causing an attacker to gain a larger advantage
-   than the target of 2^-57.
-
-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-tls-28
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 57]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  Defined limits on the number of packets that can be protected with
-      a single key and limits on the number of packets that can fail
-      authentication (#3619, #3620)
-
-   *  Update Initial salt, Retry keys, and samples (#3711)
-
-C.2.  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)
-
-C.3.  Since draft-ietf-quic-tls-26
-
-   *  No changes
-
-C.4.  Since draft-ietf-quic-tls-25
-
-   *  No changes
-
-C.5.  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)
-
-C.6.  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)
-
-C.7.  Since draft-ietf-quic-tls-22
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 58]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  Update the salt used for Initial secrets (#2887, #2980)
-
-C.8.  Since draft-ietf-quic-tls-21
-
-   *  No changes
-
-C.9.  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)
-
-C.10.  Since draft-ietf-quic-tls-18
-
-   *  Increased the set of permissible frames in 0-RTT (#2344, #2355)
-
-   *  Transport parameter extension is mandatory (#2528, #2560)
-
-C.11.  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)
-
-C.12.  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)
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 59]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  Initial keys are discarded once Handshake keys are available
-      (#1951, #2045)
-
-C.13.  Since draft-ietf-quic-tls-13
-
-   *  Updated to TLS 1.3 final (#1660)
-
-C.14.  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
-
-      -  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)
-
-C.15.  Since draft-ietf-quic-tls-11
-
-   *  Encrypted packet numbers.
-
-C.16.  Since draft-ietf-quic-tls-10
-
-   *  No significant changes.
-
-C.17.  Since draft-ietf-quic-tls-09
-
-   *  Cleaned up key schedule and updated the salt used for handshake
-      packet protection (#1077)
-
-C.18.  Since draft-ietf-quic-tls-08
-
-   *  Specify value for max_early_data_size to enable 0-RTT (#942)
-
-   *  Update key derivation function (#1003, #1004)
-
-C.19.  Since draft-ietf-quic-tls-07
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 60]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  Handshake errors can be reported with CONNECTION_CLOSE (#608,
-      #891)
-
-C.20.  Since draft-ietf-quic-tls-05
-
-   No significant changes.
-
-C.21.  Since draft-ietf-quic-tls-04
-
-   *  Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
-
-C.22.  Since draft-ietf-quic-tls-03
-
-   No significant changes.
-
-C.23.  Since draft-ietf-quic-tls-02
-
-   *  Updates to match changes in transport draft
-
-C.24.  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)
-
-C.25.  Since draft-ietf-quic-tls-00
-
-   *  Changed bit used to signal key phase
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 61]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  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
-
-C.26.  Since draft-thomson-quic-tls-01
-
-   *  Adopted as base for draft-ietf-quic-tls
-
-   *  Updated authors/editors list
-
-   *  Added status note
-
-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
-
-   *  Felix Guenther
-
-   *  Ian Swett
-
-   *  Jana Iyengar
-
-   *  奥 一穂 (Kazuho Oku)
-
-   *  Marten Seemann
-
-   *  Martin Duke
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 62]
-
-Internet-Draft          Using TLS to Secure QUIC             August 2020
-
-
-   *  Mike Bishop
-
-   *  Mikkel Fahnøe Jørgensen
-
-   *  Nick Banks
-
-   *  Nick Harper
-
-   *  Roberto Peon
-
-   *  Rui Paulo
-
-   *  Ryan Hamilton
-
-   *  Victor Vasiliev
-
-Authors' Addresses
-
-   Martin Thomson (editor)
-   Mozilla
-
-   Email: mt@lowentropy.net
-
-
-   Sean Turner (editor)
-   sn3rd
-
-   Email: sean@sn3rd.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner        Expires 18 February 2021               [Page 63]
diff --git a/split-initial-close/draft-ietf-quic-transport.html b/split-initial-close/draft-ietf-quic-transport.html
deleted file mode 100644
index b10a19b39f..0000000000
--- a/split-initial-close/draft-ietf-quic-transport.html
+++ /dev/null
@@ -1,11130 +0,0 @@
-<!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.47.0" 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 {
-  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 {
-  max-width: 100%;
-  margin: 0 0 1em;
-  border-collapse: collapse;
-}
-table.right {
-  margin-left: auto;
-}
-table.center {
-  margin-left: auto;
-  margin-right: auto;
-}
-table.left {
-  margin-right: auto;
-}
-thead, tbody {
-  border: 1px solid var(--line-color);
-}
-th, td {
-  text-align: left;
-  vertical-align: top;
-  padding: 5px 10px;
-}
-th {
-  background-color: var(--line-color);
-}
-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 {
-  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;
-}
-
-/* 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">August 2020</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Iyengar &amp; Thomson</td>
-<td class="center">Expires 18 February 2021</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-08-17" class="published">17 August 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="2021-02-18">18 February 2021</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 18 February 2021.<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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-overview" class="xref">Overview</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty 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-flow-control" class="xref">Flow Control</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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-increasing-flow-control-lim" class="xref">Increasing Flow Control Limits</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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>
-              <li class="toc ulEmpty compact" 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-flow-control-performance" class="xref">Flow Control Performance</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty 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-connections" class="xref">Connections</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty 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-connection-id" class="xref">Connection ID</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty 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-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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty 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-required-operations-on-conn" class="xref">Required Operations on Connections</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty 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>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty 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-cryptographic-and-transport" class="xref">Cryptographic and Transport Handshake</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty 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-address-validation" class="xref">Address Validation</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty 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-connection-migration" class="xref">Connection Migration</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty 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-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="toc ulEmpty 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-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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-idle-timeout" class="xref">Idle Timeout</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-10.1.1" class="xref">10.1.1</a>.  <a href="#name-liveness-testing" class="xref">Liveness Testing</a><a href="#section-toc.1-1.10.2.1.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" id="section-toc.1-1.10.2.1.2.2">
-                    <p id="section-toc.1-1.10.2.1.2.2.1"><a href="#section-10.1.2" class="xref">10.1.2</a>.  <a href="#name-deferring-idle-timeout" class="xref">Deferring Idle Timeout</a><a href="#section-toc.1-1.10.2.1.2.2.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" 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-immediate-close" class="xref">Immediate Close</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.10.2.2.2.1">
-                    <p id="section-toc.1-1.10.2.2.2.1.1"><a href="#section-10.2.1" class="xref">10.2.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.2.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" 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-stateless-reset" class="xref">Stateless Reset</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-detecting-a-stateless-reset" class="xref">Detecting a Stateless Reset</a><a href="#section-toc.1-1.10.2.3.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" id="section-toc.1-1.10.2.3.2.2">
-                    <p id="section-toc.1-1.10.2.3.2.2.1"><a href="#section-10.3.2" class="xref">10.3.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.3.2.2.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" id="section-toc.1-1.10.2.3.2.3">
-                    <p id="section-toc.1-1.10.2.3.2.3.1"><a href="#section-10.3.3" class="xref">10.3.3</a>.  <a href="#name-looping" class="xref">Looping</a><a href="#section-toc.1-1.10.2.3.2.3.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" 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-closing-and-draining-connec" class="xref">Closing and Draining Connection States</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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-limiting-ranges-by-tracking" class="xref">Limiting Ranges by Tracking ACK Frames</a><a href="#section-toc.1-1.13.2.2.2.4.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" 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-measuring-and-reporting-hos" class="xref">Measuring and Reporting Host Delay</a><a href="#section-toc.1-1.13.2.2.2.5.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" 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-ack-frames-and-packet-prote" class="xref">ACK Frames and Packet Protection</a><a href="#section-toc.1-1.13.2.2.2.6.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" 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-padding-frames-consume-cong" class="xref">PADDING Frames Consume Congestion Window</a><a href="#section-toc.1-1.13.2.2.2.7.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-initial-packet-size" class="xref">Initial Packet Size</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-path-maximum-transmission-u" class="xref">Path Maximum Transmission Unit</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.14.2.2.2.1">
-                    <p id="section-toc.1-1.14.2.2.2.1.1"><a href="#section-14.2.1" class="xref">14.2.1</a>.  <a href="#name-handling-of-icmp-messages-b" class="xref">Handling of ICMP Messages by PMTUD</a><a href="#section-toc.1-1.14.2.2.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-dplpmtud-and-initial-connec" class="xref">DPLPMTUD and Initial Connectivity</a><a href="#section-toc.1-1.14.2.3.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" id="section-toc.1-1.14.2.3.2.2">
-                    <p id="section-toc.1-1.14.2.3.2.2.1"><a href="#section-14.3.2" class="xref">14.3.2</a>.  <a href="#name-validating-the-quic-path-wi" class="xref">Validating the QUIC Path with DPLPMTUD</a><a href="#section-toc.1-1.14.2.3.2.2.1" class="pilcrow">¶</a></p>
-</li>
-                  <li class="toc ulEmpty compact" id="section-toc.1-1.14.2.3.2.3">
-                    <p id="section-toc.1-1.14.2.3.2.3.1"><a href="#section-14.3.3" class="xref">14.3.3</a>.  <a href="#name-handling-of-icmp-messages-by" class="xref">Handling of ICMP Messages by DPLPMTUD</a><a href="#section-toc.1-1.14.2.3.2.3.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.14.2.4">
-                <p id="section-toc.1-1.14.2.4.1"><a href="#section-14.4" class="xref">14.4</a>.  <a href="#name-sending-quic-pmtu-probes" class="xref">Sending QUIC PMTU Probes</a><a href="#section-toc.1-1.14.2.4.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" id="section-toc.1-1.14.2.4.2.1">
-                    <p id="section-toc.1-1.14.2.4.2.1.1"><a href="#section-14.4.1" class="xref">14.4.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.4.2.1.1" class="pilcrow">¶</a></p>
-</li>
-                </ul>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-frames" class="xref">PADDING Frames</a><a href="#section-toc.1-1.19.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">PING Frames</a><a href="#section-toc.1-1.19.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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-frames" class="xref">RESET_STREAM Frames</a><a href="#section-toc.1-1.19.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">STOP_SENDING Frames</a><a href="#section-toc.1-1.19.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">CRYPTO Frames</a><a href="#section-toc.1-1.19.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">NEW_TOKEN Frames</a><a href="#section-toc.1-1.19.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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-frames" class="xref">MAX_DATA Frames</a><a href="#section-toc.1-1.19.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">MAX_STREAM_DATA Frames</a><a href="#section-toc.1-1.19.2.10.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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-frames" class="xref">DATA_BLOCKED Frames</a><a href="#section-toc.1-1.19.2.12.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">STREAM_DATA_BLOCKED Frames</a><a href="#section-toc.1-1.19.2.13.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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-frames" class="xref">NEW_CONNECTION_ID Frames</a><a href="#section-toc.1-1.19.2.15.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">RETIRE_CONNECTION_ID Frames</a><a href="#section-toc.1-1.19.2.16.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">PATH_CHALLENGE Frames</a><a href="#section-toc.1-1.19.2.17.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-frames" class="xref">PATH_RESPONSE Frames</a><a href="#section-toc.1-1.19.2.18.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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-frames" class="xref">HANDSHAKE_DONE Frames</a><a href="#section-toc.1-1.19.2.20.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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-error-codes" class="xref">Error Codes</a><a href="#section-toc.1-1.20.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-transport-error-codes" class="xref">Transport Error Codes</a><a href="#section-toc.1-1.20.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.20.2.2">
-                <p id="section-toc.1-1.20.2.2.1"><a href="#section-20.2" class="xref">20.2</a>.  <a href="#name-application-protocol-error-" class="xref">Application Protocol Error Codes</a><a href="#section-toc.1-1.20.2.2.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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-types-registry" class="xref">QUIC Frame Types Registry</a><a href="#section-toc.1-1.22.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact" 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="toc ulEmpty compact">
-<li class="toc ulEmpty compact" 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-28</a><a href="#section-toc.1-1.26.2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-27</a><a href="#section-toc.1-1.26.2.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-26</a><a href="#section-toc.1-1.26.2.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-25</a><a href="#section-toc.1-1.26.2.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-24</a><a href="#section-toc.1-1.26.2.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-23</a><a href="#section-toc.1-1.26.2.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-22</a><a href="#section-toc.1-1.26.2.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-21" class="xref">Since draft-ietf-quic-transport-21</a><a href="#section-toc.1-1.26.2.8.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-20" class="xref">Since draft-ietf-quic-transport-20</a><a href="#section-toc.1-1.26.2.9.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-1" class="xref">Since draft-ietf-quic-transport-19</a><a href="#section-toc.1-1.26.2.10.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-18" class="xref">Since draft-ietf-quic-transport-18</a><a href="#section-toc.1-1.26.2.11.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-17" class="xref">Since draft-ietf-quic-transport-17</a><a href="#section-toc.1-1.26.2.12.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-16" class="xref">Since draft-ietf-quic-transport-16</a><a href="#section-toc.1-1.26.2.13.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-15" class="xref">Since draft-ietf-quic-transport-15</a><a href="#section-toc.1-1.26.2.14.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-14" class="xref">Since draft-ietf-quic-transport-14</a><a href="#section-toc.1-1.26.2.15.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-13" class="xref">Since draft-ietf-quic-transport-13</a><a href="#section-toc.1-1.26.2.16.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-12" class="xref">Since draft-ietf-quic-transport-12</a><a href="#section-toc.1-1.26.2.17.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-11" class="xref">Since draft-ietf-quic-transport-11</a><a href="#section-toc.1-1.26.2.18.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-10" class="xref">Since draft-ietf-quic-transport-10</a><a href="#section-toc.1-1.26.2.19.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-0" class="xref">Since draft-ietf-quic-transport-09</a><a href="#section-toc.1-1.26.2.20.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-08" class="xref">Since draft-ietf-quic-transport-08</a><a href="#section-toc.1-1.26.2.21.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-07" class="xref">Since draft-ietf-quic-transport-07</a><a href="#section-toc.1-1.26.2.22.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-06" class="xref">Since draft-ietf-quic-transport-06</a><a href="#section-toc.1-1.26.2.23.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-05" class="xref">Since draft-ietf-quic-transport-05</a><a href="#section-toc.1-1.26.2.24.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-04" class="xref">Since draft-ietf-quic-transport-04</a><a href="#section-toc.1-1.26.2.25.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-03" class="xref">Since draft-ietf-quic-transport-03</a><a href="#section-toc.1-1.26.2.26.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-02" class="xref">Since draft-ietf-quic-transport-02</a><a href="#section-toc.1-1.26.2.27.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-01" class="xref">Since draft-ietf-quic-transport-01</a><a href="#section-toc.1-1.26.2.28.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" 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-ietf-quic-transport-00" class="xref">Since draft-ietf-quic-transport-00</a><a href="#section-toc.1-1.26.2.29.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="toc ulEmpty compact" id="section-toc.1-1.26.2.30">
-                <p id="section-toc.1-1.26.2.30.1"><a href="#section-c.30" class="xref">C.30</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.30.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-</li>
-          <li class="toc ulEmpty compact" 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="toc ulEmpty compact" 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="overview">
-<section id="section-1">
-      <h2 id="name-overview">
-<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-overview" class="section-name selfRef">Overview</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 establishes a connection, which is a stateful interaction between a client
-and server. The primary purpose of a connection is to support the structured
-exchange of data by an application protocol.<a href="#section-1-3" class="pilcrow">¶</a></p>
-<p id="section-1-4">Streams are means by which an application protocol exchanges information.
-Streams are ordered sequences of bytes. Two types of stream can be created:
-bidirectional streams, which allow both endpoints to send data; and
-unidirectional streams, which allow a single endpoint to send. A credit-based
-scheme is used to limit stream creation and to bound the amount of data that
-can be sent.<a href="#section-1-4" class="pilcrow">¶</a></p>
-<p id="section-1-5">The QUIC handshake combines negotiation of cryptographic and transport
-parameters.  The handshake is structured to permit the exchange of application
-data as soon as possible.  This includes an option for clients to send data
-immediately (0-RTT), which might require prior communication to enable.<a href="#section-1-5" class="pilcrow">¶</a></p>
-<p id="section-1-6">QUIC connections are not strictly bound to a single network path.  Connection
-migration uses connection identifiers to allow connections to transfer to a new
-network path.<a href="#section-1-6" class="pilcrow">¶</a></p>
-<p id="section-1-7">Frames are used in QUIC to communicate between endpoints.  One or more frames
-are assembled into packets.  QUIC authenticates all packets and encrypts as much
-as is practical.  QUIC packets are carried in UDP datagrams to better facilitate
-deployment in existing systems and networks.<a href="#section-1-7" class="pilcrow">¶</a></p>
-<p id="section-1-8">Once established, multiple options are provided for connection termination.
-Applications can manage a graceful shutdown, endpoints can negotiate a timeout
-period, errors can cause immediate connection teardown, and a stateless
-mechanism provides for termination of connections after one endpoint has lost
-state.<a href="#section-1-8" 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>
-<span class="break"></span><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 that initiates 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 that accepts a QUIC connection.<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, 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 identifier that is used to identify a QUIC connection at an endpoint.
-Each endpoint selects one or more Connection IDs for its peer to include in
-packets sent towards the endpoint.  This value is opaque to the peer.<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 custom 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>
-<span class="break"></span><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 with the length described by
-?, as above<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,
-with the length described by ?, as above<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">This document uses network byte order (that is, big endian) values.  Fields
-are placed starting from the high-order bits of each byte.<a href="#section-1.3-5" class="pilcrow">¶</a></p>
-<p id="section-1.3-6">By convention, individual fields reference a complex field by using the name of
-the complex field.<a href="#section-1.3-6" class="pilcrow">¶</a></p>
-<p id="section-1.3-7">For example:<a href="#section-1.3-7" 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-8.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.<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 two least significant 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">The stream space for each type begins at the minimum value (0x0 through 0x3
-respectively); successive streams of each type 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>
-</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.  An implementation uses information provided
-by the application to determine how to allocate resources to active streams.<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 that 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 the send or receive side causes the stream
-to open in both directions.<a href="#section-3-2" class="pilcrow">¶</a></p>
-<p id="section-3-3">These state machines shown in this section 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 are not 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-3" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-3-4">
-        <dt id="section-3-4.1">Note:</dt>
-        <dd id="section-3-4.2">
-  In some cases, a single event or action can cause a transition through
-multiple states.  For instance, sending STREAM with a FIN bit set can cause
-two state transitions for a sending stream: from the Ready state to the Send
-state, and from the Send state to the Data Sent state.<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 a 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 frame 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 a 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 has already been received when a
-RESET_STREAM is received (that is, in 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 a STREAM or STREAM_DATA_BLOCKED frame
-for a stream in the "Reset Sent" state or any terminal state, that is, after
-sending a RESET_STREAM frame.  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 MAY
-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>
-<span class="break"></span><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 a STOP_SENDING frame 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, an endpoint MAY defer sending the RESET_STREAM frame until
-the packets containing outstanding data are acknowledged or declared lost.  If
-any outstanding data is declared lost, the endpoint SHOULD send a RESET_STREAM
-frame instead of retransmitting the data.<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">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-6" class="pilcrow">¶</a></p>
-<p id="section-3.5-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-3.5-8">An endpoint that wishes to terminate both directions of a bidirectional stream
-can terminate one direction by sending a RESET_STREAM frame, and it can
-encourage prompt termination in the opposite direction by sending a STOP_SENDING
-frame.<a href="#section-3.5-8" 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 limit-based flow-control scheme where a receiver advertises the
-limit of total bytes it is prepared to receive on a given stream or 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">Senders MUST not send data in excess of either limit.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
-<p id="section-4.1-4">A receiver sets initial limits 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 larger limits.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
-<p id="section-4.1-5">A receiver can advertise a larger limit for a stream by sending a
-MAX_STREAM_DATA frame with the corresponding stream ID. 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 href="#section-4.1-5" class="pilcrow">¶</a></p>
-<p id="section-4.1-6">A receiver can advertise a larger limit 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-6" class="pilcrow">¶</a></p>
-<p id="section-4.1-7">Once a receiver advertises a limit for the connection or a stream, it MAY
-advertise a smaller limit, but this has no effect.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
-<p id="section-4.1-8">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-8" class="pilcrow">¶</a></p>
-<p id="section-4.1-9">A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase
-flow control limits.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
-<p id="section-4.1-10">If a sender has sent data up to the limit, 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.1</a>), the receiver might close the connection even when
-the sender has data that 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-10" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="fc-credit">
-<section id="section-4.2">
-        <h3 id="name-increasing-flow-control-lim">
-<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-increasing-flow-control-lim" class="section-name selfRef">Increasing Flow Control Limits</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 MAY 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.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
-<p id="section-4.3-3">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-3" 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">The final size of a stream is always signaled to the recipient.  The final size
-is the sum of the Offset and Length fields of a STREAM frame with a FIN flag,
-noting that these fields might be implicit.  Alternatively, the Final Size field
-of a RESET_STREAM frame carries this value.  This ensures that all ways that a
-stream can be closed result in the number of bytes on the stream being reliably
-transmitted.  This guarantees that both endpoints agree on how much flow control
-credit was consumed by the stream.<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>).  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.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>. Subsequent limits are advertised using
-MAX_STREAMS frames; see <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.2</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 not to send STREAMS_BLOCKED frames.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="flow-control-performance">
-<section id="section-4.6">
-        <h3 id="name-flow-control-performance">
-<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-flow-control-performance" class="section-name selfRef">Flow Control Performance</a>
-        </h3>
-<p id="section-4.6-1">An endpoint that is unable to ensure that a peer has flow control credit on the
-order of the current BDP will have receive throughput limited by flow control.
-Lost packets can cause gaps in the receive buffer, delaying the application
-from consuming data and freeing up flow control window.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
-<p id="section-4.6-2">Sending timely updates of flow control limits can improve performance.
-Sending packets only to provide flow control updates can increase network
-load and adversely affect performance. Sending flow control updates along with
-other frames, such as ACK frames, reduces the cost of those updates.<a href="#section-4.6-2" 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">A QUIC connection is shared state between a client and a server.<a href="#section-5-1" class="pilcrow">¶</a></p>
-<p id="section-5-2">Each connection starts with a handshake phase, during which the two endpoints
-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-2" class="pilcrow">¶</a></p>
-<p id="section-5-3">An application protocol can use the connection during the handshake phase with
-some limitations.  0-RTT allows application data to be sent by a client before
-receiving a response from the server.  However, 0-RTT provides no protection
-against replay attacks; see Section 9.2 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.  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 of
-trading some security guarantees for reduced latency.<a href="#section-5-3" class="pilcrow">¶</a></p>
-<p id="section-5-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-4" class="pilcrow">¶</a></p>
-<p id="section-5-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-5" 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) do not 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 that will allow packets with that connection ID to
-be routed back to the endpoint and to be 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
-demonstrate that the packet is in response to a packet sent by the client.<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 detecting when
-NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer to the same value.  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.3.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 be unable to
-respond 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.3</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 that lack strong integrity protection, such as Initial, Retry,
-or Version Negotiation, MAY be discarded. An endpoint MUST generate a
-connection error if processing the contents of these packets prior to
-discovering an error resulted in changes to connection state that
-cannot be reverted.<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 do not 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 indicates an unsupported version but is large
-enough to initiate a new connection for any supported version, the server
-SHOULD send a Version Negotiation packet as described in <a href="#send-vn" class="xref">Section 6.1</a>.  A server
-MAY limit the number of packets to which it responds with a Version Negotiation
-packet.  Servers MUST drop smaller 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.  These packets are processed using the
-selected connection; otherwise, 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 when the client address changes SHOULD indicate migration
-is not supported using the disable_active_migration transport parameter.  The
-disable_active_migration transport parameter does not prohibit connection
-migration after a client has acted on a preferred_address 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="required-operations-on-connections">
-<section id="section-5.3">
-        <h3 id="name-required-operations-on-conn">
-<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-required-operations-on-conn" class="section-name selfRef">Required Operations on Connections</a>
-        </h3>
-<p id="section-5.3-1">There are certain operations that 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.3-1" class="pilcrow">¶</a></p>
-<p id="section-5.3-2">When implementing the client role, applications need to be able to:<a href="#section-5.3-2" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-5.3-3.1">open a connection, which begins the exchange described in <a href="#handshake" class="xref">Section 7</a>;<a href="#section-5.3-3.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-3.2">enable Early Data when available; and<a href="#section-5.3-3.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-3.3">be informed when Early Data has been accepted or rejected by a server.<a href="#section-5.3-3.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-5.3-4">When implementing the server role, applications need to be able to:<a href="#section-5.3-4" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-5.3-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.3-5.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-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.3-5.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-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.3-5.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-5.3-6">In either role, applications need to be able to:<a href="#section-5.3-6" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-5.3-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.3-7.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-7.2">control resource allocation of various types, including flow control and the
-number of permitted streams of each type;<a href="#section-5.3-7.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-7.3">identify whether the handshake has completed successfully or is still ongoing;<a href="#section-5.3-7.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-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.1</a>); and<a href="#section-5.3-7.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-5.3-7.5">immediately close (<a href="#immediate-close" class="xref">Section 10.2</a>) the connection.<a href="#section-5.3-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 allows a server to indicate that it does not support
-the version the client used.  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 UDP datagram they send to the largest of the minimum
-datagram sizes from 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, and<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<a href="#section-7-3.1.2.4" 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 verifies 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 offsets 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"><a href="#fig-hs" class="xref">Figure 4</a> shows a simplified handshake and the exchange of packets and frames
-that are used to advance the handshake.  Exchange of application data during the
-handshake is enabled where possible, shown with a '*'.  Once completed,
-endpoints are able to exchange application data.<a href="#section-7-6" class="pilcrow">¶</a></p>
-<span id="name-simplified-quic-handshake"></span><div id="fig-hs">
-<figure id="figure-4">
-        <div class="artwork art-text alignLeft art-drawing" id="section-7-7.1">
-<pre>
-Client                                               Server
-
-Initial (CRYPTO)
-0-RTT (*)              ----------&gt;
-                                           Initial (CRYPTO)
-                                         Handshake (CRYPTO)
-                       &lt;----------                1-RTT (*)
-Handshake (CRYPTO)
-1-RTT (*)              ----------&gt;
-                       &lt;---------- 1-RTT (HANDSHAKE_DONE,*)
-
-1-RTT (*)              &lt;=========&gt;                1-RTT (*)
-</pre>
-</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
-<a href="#name-simplified-quic-handshake" class="selfRef">Simplified QUIC Handshake</a>
-        </figcaption></figure>
-</div>
-<p id="section-7-8">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-8" 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 5</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">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 (subject to limits
-inherent to the protocol, such as congestion control or anti-amplification).
-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-5">
-          <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]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]
-</pre>
-</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure 5</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 6</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-6">
-          <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]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1]
-</pre>
-</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure 6</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 used by both endpoints. 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. After processing
-the first Initial packet, each endpoint sets the Destination Connection ID
-field in subsequent packets it sends to the value of the Source Connection ID
-field that it received.<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.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
-<p id="section-7.2-4">The Destination Connection ID field from the first Initial packet sent by a
-client is used to determine packet protection keys for Initial packets.  These
-keys change after receiving a Retry packet; see Section 5.2 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
-<p id="section-7.2-5">The client populates the Source Connection ID field with a value of its choosing
-and sets the Source Connection ID Length field to indicate the length.<a href="#section-7.2-5" class="pilcrow">¶</a></p>
-<p id="section-7.2-6">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-6" class="pilcrow">¶</a></p>
-<p id="section-7.2-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-7.2-8">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 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-8" class="pilcrow">¶</a></p>
-<p id="section-7.2-9">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-9" 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.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
-<p id="section-7.3-4">An endpoint MUST treat absence of the initial_source_connection_id transport
-parameter from either endpoint or absence of the
-original_destination_connection_id transport parameter from the server as a
-connection error of type TRANSPORT_PARAMETER_ERROR.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
-<p id="section-7.3-5">An endpoint MUST treat the following as a connection error of type
-TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:<a href="#section-7.3-5" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-7.3-6.1">absence of the retry_source_connection_id transport parameter from the server
-after receiving a Retry packet,<a href="#section-7.3-6.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-7.3-6.2">presence of the retry_source_connection_id transport parameter when no Retry
-packet was received, or<a href="#section-7.3-6.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-7.3-6.3">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-6.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-7.3-7">If a zero-length connection ID is selected, the corresponding transport
-parameter is included with a zero-length value.<a href="#section-7.3-7" class="pilcrow">¶</a></p>
-<p id="section-7.3-8"><a href="#fig-auth-cid" class="xref">Figure 7</a> shows the connection IDs (with DCID=Destination Connection ID,
-SCID=Source Connection ID) 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-8" class="pilcrow">¶</a></p>
-<span id="name-use-of-connection-ids-in-a-"></span><div id="fig-auth-cid">
-<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;- 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-" class="selfRef">Use of Connection IDs in a Handshake</a>
-          </figcaption></figure>
-</div>
-<p id="section-7.3-10"><a href="#fig-auth-cid-retry" class="xref">Figure 8</a> shows a similar handshake that includes a Retry packet.<a href="#section-7.3-10" class="pilcrow">¶</a></p>
-<span id="name-use-of-connection-ids-in-a-h"></span><div id="fig-auth-cid-retry">
-<figure id="figure-8">
-          <div class="artwork art-text alignLeft" id="section-7.3-11.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-8" class="selfRef">Figure 8</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-12">In both cases (<a href="#fig-auth-cid" class="xref">Figure 7</a> and <a href="#fig-auth-cid-retry" class="xref">Figure 8</a>), the client sets the
-value of the initial_source_connection_id transport parameter to <code>C1</code>.<a href="#section-7.3-12" class="pilcrow">¶</a></p>
-<p id="section-7.3-13">When the handshake does not include a Retry (<a href="#fig-auth-cid" class="xref">Figure 7</a>), the server sets
-original_destination_connection_id to <code>S1</code> and initial_source_connection_id to
-<code>S3</code>. In this case, the server does not include a retry_source_connection_id
-transport parameter.<a href="#section-7.3-13" class="pilcrow">¶</a></p>
-<p id="section-7.3-14">When the handshake includes a Retry (<a href="#fig-auth-cid-retry" class="xref">Figure 8</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>.<a href="#section-7.3-14" class="pilcrow">¶</a></p>
-<p id="section-7.3-15">Each endpoint validates transport parameters set by the peer. The client
-confirms that the retry_source_connection_id transport parameter is absent if it
-did not process a Retry packet.<a href="#section-7.3-15" 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 that each parameter defines; 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 values 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>
-<p id="section-7.4-9">Application Layer Protocol Negotiation (ALPN; see <span>[<a href="#ALPN" class="xref">ALPN</a>]</span>) allows
-clients to offer multiple application protocols during connection
-establishment. The transport parameters that a client includes during the
-handshake apply to all application protocols that the client offers. Application
-protocols can recommend values for transport parameters, such as the initial
-flow control limits. However, application protocols that set constraints on
-values for transport parameters could make it impossible for a client to offer
-multiple application protocols if these constraints conflict.<a href="#section-7.4-9" 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">Using 0-RTT depends on both client and server using protocol parameters that
-were negotiated from a previous connection.  To enable 0-RTT, 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.  This
-information is stored with any information required by the application
-protocol or cryptographic handshake; see Section 4.6 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-7.4.1-1" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-2">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.  Not all transport parameters are remembered, as some do not apply to
-future connections or they have no effect on use of 0-RTT.<a href="#section-7.4.1-2" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-3">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-3" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-4">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-4" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-5">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-5" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-6">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-6" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-7.4.1-7.1">active_connection_id_limit<a href="#section-7.4.1-7.1" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-7.4.1-7.2">initial_max_data<a href="#section-7.4.1-7.2" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-7.4.1-7.3">initial_max_stream_data_bidi_local<a href="#section-7.4.1-7.3" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-7.4.1-7.4">initial_max_stream_data_bidi_remote<a href="#section-7.4.1-7.4" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-7.4.1-7.5">initial_max_stream_data_uni<a href="#section-7.4.1-7.5" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-7.4.1-7.6">initial_max_streams_bidi<a href="#section-7.4.1-7.6" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-7.4.1-7.7">initial_max_streams_uni<a href="#section-7.4.1-7.7" class="pilcrow">¶</a>
-</li>
-          </ul>
-<p id="section-7.4.1-8">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-8" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-9">A server MAY store and recover the previously sent values of the
-max_idle_timeout, max_udp_payload_size, and disable_active_migration parameters
-and reject 0-RTT if it selects smaller values. Lowering the values of these
-parameters while also accepting 0-RTT data could degrade the performance of the
-connection. Specifically, lowering the max_udp_payload_size could result in
-dropped packets leading to worse performance compared to rejecting 0-RTT data
-outright.<a href="#section-7.4.1-9" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-10">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-10" class="pilcrow">¶</a></p>
-<p id="section-7.4.1-11">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-11" 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
-out-of-order CRYPTO frames. 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 ensures that an endpoint cannot be 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">Additionally, a server MAY consider the client address valididated if the
-client uses a connection ID chosen by the server and the connection ID contains
-at least 64 bits of entropy.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
-<p id="section-8.1-3">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-3" class="pilcrow">¶</a></p>
-<p id="section-8.1-4">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. A client that sends padded datagrams allows the server to send more
-data prior to completing address validation.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
-<p id="section-8.1-5">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
-6.2 of <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>). Specifically, the client MUST send an Initial packet
-in a UDP datagram that contains at least 1200 bytes if it does not have
-Handshake keys, and otherwise send a Handshake packet.<a href="#section-8.1-5" class="pilcrow">¶</a></p>
-<p id="section-8.1-6">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-6" class="pilcrow">¶</a></p>
-<p id="section-8.1-7">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-7" 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.2</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 9</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-9">
-            <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-9" class="selfRef">Figure 9</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.  In a future connection, the client includes this token in Initial
-packets to provide address validation.  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.  A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry
-packets differently, and validate the latter more strictly.  If the validation
-succeeds, the server SHOULD then allow the handshake to proceed.<a href="#section-8.1.3-10" class="pilcrow">¶</a></p>
-<span class="break"></span><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 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>
-</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">Attackers could replay tokens to use servers as amplifiers in DDoS attacks. To
-protect against such attacks, servers MUST ensure that replay of tokens is
-prevented or limited. 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; 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>) 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 can be both sent to (PATH_CHALLENGE) and
-received from (PATH_RESPONSE) 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 include PATH_CHALLENGE and PATH_RESPONSE frames that are used
-for path validation with other frames.  In particular, an endpoint can pad a
-packet carrying a PATH_CHALLENGE for Path Maximum Transfer Unit (PMTU)
-discovery (see <a href="#pmtud" class="xref">Section 14.2.1</a>), or an endpoint can include 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 frame. 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>
-</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">If the peer sent the disable_active_migration transport parameter, an endpoint
-also MUST NOT send packets (including probing packets; see <a href="#probing" class="xref">Section 9.1</a>) from a
-different local address to the address the peer used during the handshake. An
-endpoint that has sent this transport parameter, but detects that a peer has
-nonetheless migrated to a different remote address 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 frame 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">To establish reachability on the new path, an endpoint initiates path
-validation (<a href="#migrate-validate" class="xref">Section 8.2</a>) on the new path.  An endpoint MAY defer path
-validation until after a peer sends the next non-probing frame to its new
-address.<a href="#section-9.2-5" class="pilcrow">¶</a></p>
-<p id="section-9.2-6">Path validation is necessary to verify reachability of a peer on a new network
-path.  Acknowledgments cannot be used for path validation as they contain
-insufficient entropy and might be spoofed.  No method is provided to establish
-return reachability, as endpoints independently determine reachability on each
-direction of a path.<a href="#section-9.2-6" 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 above, 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.  Additionally, 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, thus containing migrations initiated by the attacker
-injecting a single packet.<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>
-</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">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-2" class="pilcrow">¶</a></p>
-<p id="section-9.3.3-3">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-3" class="pilcrow">¶</a></p>
-<p id="section-9.3.3-4">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-4" class="pilcrow">¶</a></p>
-<p id="section-9.3.3-5">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-5" class="pilcrow">¶</a></p>
-<p id="section-9.3.3-6">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-6" class="pilcrow">¶</a></p>
-<p id="section-9.3.3-7">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-7" 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 Appendices 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 6.2.1 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 would allow 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 associate
-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 do not 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 when the client has
-not initiated a migration to that address, 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
-addresses provided by the server and initiate path validation (see
-<a href="#migrate-validate" class="xref">Section 8.2</a>).  A client constructs packets 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 packet containing a PATH_RESPONSE frame as per
-<a href="#migrate-validate" class="xref">Section 8.2</a>.  The server MUST send non-probing packets 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 packets received at the server's preferred address have a different source
-address than observed from the client during the handshake, 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
-Connection ID field.  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 Connection ID field, 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.1</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.2</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.3</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="idle-timeout">
-<section id="section-10.1">
-        <h3 id="name-idle-timeout">
-<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-idle-timeout" class="section-name selfRef">Idle Timeout</a>
-        </h3>
-<p id="section-10.1-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.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
-<p id="section-10.1-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.2</a>) if it abandons the connection prior to the effective
-value.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
-<p id="section-10.1-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.1-3" class="pilcrow">¶</a></p>
-<p id="section-10.1-4">To avoid excessively small idle timeout periods, endpoints MUST increase the
-idle timeout period to be at least three times the current Probe Timeout (PTO).<a href="#section-10.1-4" class="pilcrow">¶</a></p>
-<div id="liveness-testing">
-<section id="section-10.1.1">
-          <h4 id="name-liveness-testing">
-<a href="#section-10.1.1" class="section-number selfRef">10.1.1. </a><a href="#name-liveness-testing" class="section-name selfRef">Liveness Testing</a>
-          </h4>
-<p id="section-10.1.1-1">An endpoint that sends packets close to the effective timeout risks having
-them be discarded at the peer, since the idle timeout period might have expired
-at the peer before these packets arrive.<a href="#section-10.1.1-1" class="pilcrow">¶</a></p>
-<p id="section-10.1.1-2">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.2 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.1.1-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="defer-idle">
-<section id="section-10.1.2">
-          <h4 id="name-deferring-idle-timeout">
-<a href="#section-10.1.2" class="section-number selfRef">10.1.2. </a><a href="#name-deferring-idle-timeout" class="section-name selfRef">Deferring Idle Timeout</a>
-          </h4>
-<p id="section-10.1.2-1">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.1.2-1" class="pilcrow">¶</a></p>
-<p id="section-10.1.2-2">An implementation of QUIC might provide applications with an option to defer an
-idle timeout.  This facility could be used when the application wishes to avoid
-losing state that has been associated with an open connection, but does not
-expect to exchange application data for some time.  With this option, an
-endpoint could send a PING frame (<a href="#frame-ping" class="xref">Section 19.2</a>) periodically, which will cause
-the peer to restart its idle timeout period.  Sending a packet containing a PING
-frame restarts the idle timeout for this endpoint also if this is the first
-ack-eliciting packet sent since receiving a packet.  Sending a PING frame causes
-the peer to respond with an acknowledgment, which also restarts the idle
-timeout for the endpoint.<a href="#section-10.1.2-2" class="pilcrow">¶</a></p>
-<p id="section-10.1.2-3">Application protocols that use QUIC SHOULD provide guidance on when deferring an
-idle timeout is appropriate.  Unnecessary sending of PING frames could have a
-detrimental effect on performance.<a href="#section-10.1.2-3" class="pilcrow">¶</a></p>
-<p id="section-10.1.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 30 seconds is necessary to prevent
-the majority of middleboxes from losing state for UDP flows
-<span>[<a href="#GATEWAY" class="xref">GATEWAY</a>]</span>.<a href="#section-10.1.2-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="immediate-close">
-<section id="section-10.2">
-        <h3 id="name-immediate-close">
-<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-immediate-close" class="section-name selfRef">Immediate Close</a>
-        </h3>
-<p id="section-10.2-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.2-1" class="pilcrow">¶</a></p>
-<p id="section-10.2-2">After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the
-closing state.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
-<p id="section-10.2-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.2-3" class="pilcrow">¶</a></p>
-<p id="section-10.2-4">An endpoint is allowed to drop the packet protection keys when entering the
-closing period (<a href="#draining" class="xref">Section 10.4</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 limit the
-cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
-cumulative size of the packets that cause those packets to be sent.  To minimize
-the state that an endpoint maintains for a closing connection, endpoints MAY
-send the exact same packet.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-10.2-5">
-          <dt id="section-10.2-5.1">Note:</dt>
-          <dd id="section-10.2-5.2">
-  Allowing retransmission of a closing packet is an exception to the requirement
-that a new packet number be used for each packet in <a href="#packet-numbers" class="xref">Section 12.3</a>.
-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.2-5.2" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-10.2-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.2-6" class="pilcrow">¶</a></p>
-<p id="section-10.2-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.2-7" class="pilcrow">¶</a></p>
-<p id="section-10.2-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.  When the application
-closes the connection, a CONNECTION_CLOSE frame with an appropriate error code
-will be used to signal closure.<a href="#section-10.2-8" class="pilcrow">¶</a></p>
-<div id="immediate-close-hs">
-<section id="section-10.2.1">
-          <h4 id="name-immediate-close-during-the-">
-<a href="#section-10.2.1" class="section-number selfRef">10.2.1. </a><a href="#name-immediate-close-during-the-" class="section-name selfRef">Immediate Close During the Handshake</a>
-          </h4>
-<p id="section-10.2.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.2.1-1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-10.2.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.2.1-2.1" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-10.2.1-2.2">A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be assured that
-the server has accepted 0-RTT.  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.2.1-2.2" class="pilcrow">¶</a>
-</li>
-            <li class="normal" id="section-10.2.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.2.1-2.3" class="pilcrow">¶</a>
-</li>
-          </ul>
-<p id="section-10.2.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.2.1-3" class="pilcrow">¶</a></p>
-<p id="section-10.2.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.2.1-4" class="pilcrow">¶</a></p>
-<p id="section-10.2.1-5">An endpoint can send a CONNECTION_CLOSE frame in an Initial packet.  This might
-be 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.2.1-5" class="pilcrow">¶</a></p>
-<p id="section-10.2.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.2.1-6" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="stateless-reset">
-<section id="section-10.3">
-        <h3 id="name-stateless-reset">
-<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-stateless-reset" class="section-name selfRef">Stateless Reset</a>
-        </h3>
-<p id="section-10.3-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.3-1" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3-2" class="pilcrow">¶</a></p>
-<p id="section-10.3-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 do not
-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.3-3" class="pilcrow">¶</a></p>
-<p id="section-10.3-4">An endpoint that receives packets that it cannot process sends a packet in the
-following layout:<a href="#section-10.3-4" class="pilcrow">¶</a></p>
-<span id="name-stateless-reset-packet"></span><div id="fig-stateless-reset">
-<figure id="figure-10">
-          <div class="artwork art-text alignLeft" id="section-10.3-5.1">
-<pre>
-Stateless Reset {
-  Fixed Bits (2) = 1,
-  Unpredictable Bits (38..),
-  Stateless Reset Token (128),
-}
-</pre>
-</div>
-<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
-<a href="#name-stateless-reset-packet" class="selfRef">Stateless Reset Packet</a>
-          </figcaption></figure>
-</div>
-<p id="section-10.3-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.3-6" class="pilcrow">¶</a></p>
-<p id="section-10.3-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 are set to values that SHOULD be indistinguishable
-from random.  The last 16 bytes of the datagram contain a Stateless Reset Token.<a href="#section-10.3-7" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3-8" class="pilcrow">¶</a></p>
-<p id="section-10.3-9">The resulting 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 achieve that end, the endpoint SHOULD pad all packets it
-sends to at least 22 bytes longer than the minimum connection ID that it might
-request the peer to include in packets that the peer sends.  This ensures that
-any stateless reset sent by the peer is indistinguishable from a valid packet
-sent to the endpoint.  An endpoint that sends a stateless reset in response to a
-packet that is 43 bytes or shorter SHOULD send a stateless reset that is one
-byte shorter than the packet it responds to.<a href="#section-10.3-9" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3-10" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3.3</a> describes additional limits on stateless reset size.<a href="#section-10.3-11" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3-12" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3-13" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3-14" class="pilcrow">¶</a></p>
-<p id="section-10.3-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.3-15" class="pilcrow">¶</a></p>
-<p id="section-10.3-16">Using a randomized connection ID results in two problems:<a href="#section-10.3-16" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-10.3-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.3.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.3-17.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-10.3-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.3-17.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-<p id="section-10.3-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.3-18" class="pilcrow">¶</a></p>
-<div id="detecting-a-stateless-reset">
-<section id="section-10.3.1">
-          <h4 id="name-detecting-a-stateless-reset">
-<a href="#section-10.3.1" class="section-number selfRef">10.3.1. </a><a href="#name-detecting-a-stateless-reset" class="section-name selfRef">Detecting a Stateless Reset</a>
-          </h4>
-<p id="section-10.3.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.3.1-1" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.1-2" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.1-3" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.1-4" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.1-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="reset-token">
-<section id="section-10.3.2">
-          <h4 id="name-calculating-a-stateless-res">
-<a href="#section-10.3.2" class="section-number selfRef">10.3.2. </a><a href="#name-calculating-a-stateless-res" class="section-name selfRef">Calculating a Stateless Reset Token</a>
-          </h4>
-<p id="section-10.3.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.3.2-1" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.2-2" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.2-3" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.2-4" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.2-5" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.2-6" class="pilcrow">¶</a></p>
-<p id="section-10.3.2-7">Note that Stateless Reset packets do not have any cryptographic protection.<a href="#section-10.3.2-7" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="reset-looping">
-<section id="section-10.3.3">
-          <h4 id="name-looping">
-<a href="#section-10.3.3" class="section-number selfRef">10.3.3. </a><a href="#name-looping" class="section-name selfRef">Looping</a>
-          </h4>
-<p id="section-10.3.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.3.3-1" class="pilcrow">¶</a></p>
-<p id="section-10.3.3-2">An endpoint MUST ensure that every Stateless Reset that it sends is smaller than
-the packet that 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.3.3-2" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.3-3" class="pilcrow">¶</a></p>
-<p id="section-10.3.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.3.3-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="draining">
-<section id="section-10.4">
-        <h3 id="name-closing-and-draining-connec">
-<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-closing-and-draining-connec" class="section-name selfRef">Closing and Draining Connection States</a>
-        </h3>
-<p id="section-10.4-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.4-1" class="pilcrow">¶</a></p>
-<p id="section-10.4-2">An endpoint enters a closing period after initiating an immediate close;
-<a href="#immediate-close" class="xref">Section 10.2</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.2</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.4-2" class="pilcrow">¶</a></p>
-<p id="section-10.4-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.4-3" class="pilcrow">¶</a></p>
-<p id="section-10.4-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.4-4" class="pilcrow">¶</a></p>
-<p id="section-10.4-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 to 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.4-5" class="pilcrow">¶</a></p>
-<p id="section-10.4-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.4-6" class="pilcrow">¶</a></p>
-<p id="section-10.4-7">The draining and closing periods do not apply when a stateless reset
-(<a href="#stateless-reset" class="xref">Section 10.3</a>) is sent.<a href="#section-10.4-7" class="pilcrow">¶</a></p>
-<p id="section-10.4-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.4-8" class="pilcrow">¶</a></p>
-<p id="section-10.4-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.4-9" class="pilcrow">¶</a></p>
-</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.3</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-specific protocol errors are signaled using the CONNECTION_CLOSE
-frame with a frame type of 0x1d.  Errors that are specific to the transport,
-including all those described in this document, are carried in the
-CONNECTION_CLOSE frame with a frame type of 0x1c.<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.3</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">QUIC packets have different levels of cryptographic protection based on the
-type of packet. 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 protections that are provided.<a href="#section-12.1-1" class="pilcrow">¶</a></p>
-<p id="section-12.1-2">Version Negotiation packets have no cryptographic protection; see
-<span>[<a href="#QUIC-INVARIANTS" class="xref">QUIC-INVARIANTS</a>]</span>.<a href="#section-12.1-2" class="pilcrow">¶</a></p>
-<p id="section-12.1-3">Retry packets use an authenticated encryption with associated data function
-(AEAD; <span>[<a href="#AEAD" class="xref">AEAD</a>]</span>) to protect against accidental modification.<a href="#section-12.1-3" class="pilcrow">¶</a></p>
-<p id="section-12.1-4">Initial packets use an AEAD, the keys for which are derived using a value that
-is visible on the wire. Initial packets therefore do not have effective
-confidentiality protection. Initial protection exists to ensure that the sender
-of the packet is on the network path. Any entity that receives an Initial packet
-from a client can recover the keys that will allow them to both read the
-contents of the packet and generate Initial packets that will be successfully
-authenticated at either endpoint.<a href="#section-12.1-4" class="pilcrow">¶</a></p>
-<p id="section-12.1-5">All other packets are protected with keys derived from the cryptographic
-handshake.  The cryptographic handshake ensures that only the communicating
-endpoints receive the corresponding keys for Handshake, 0-RTT, and 1-RTT
-packets.  Packets protected with 0-RTT and 1-RTT keys have strong
-confidentiality and integrity protection.<a href="#section-12.1-5" class="pilcrow">¶</a></p>
-<p id="section-12.1-6">The Packet Number field that appears in some packet types has alternative
-confidentiality protection that is applied as part of header protection; see
-Section 5.4 of <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-6" 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 that 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.4.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 include multiple frames
-in a single packet if they are to be sent at the same encryption level, instead
-of coalescing multiple packets at the same encryption level.<a href="#section-12.2-3" class="pilcrow">¶</a></p>
-<p id="section-12.2-4">Receivers MAY route based on the information in the first packet contained in a
-UDP datagram.  Senders MUST NOT coalesce QUIC packets with different connection
-IDs 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 (<a href="#packet-0rtt" class="xref">Section 17.2.3</a>) and 1-RTT
-(<a href="#short-header" class="xref">Section 17.3</a>) encrypted packets 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 that 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 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.3</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 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 11</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-11">
-          <div class="artwork art-text alignLeft" id="section-12.4-2.1">
-<pre>
-Packet Payload {
-  Frame (8..) ...,
-}
-</pre>
-</div>
-<figcaption><a href="#figure-11" class="selfRef">Figure 11</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-12">
-          <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-12" class="selfRef">Figure 12</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">Pkts</th>
-              <th class="text-left" rowspan="1" colspan="1">Spec</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>
-              <td class="text-left" rowspan="1" colspan="1">NP</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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1">NC</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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="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>
-              <td class="text-left" rowspan="1" colspan="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>
-              <td class="text-left" rowspan="1" colspan="1">F</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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1">P</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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1">P</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>
-              <td class="text-left" rowspan="1" colspan="1">P</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>
-              <td class="text-left" rowspan="1" colspan="1"> </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>
-              <td class="text-left" rowspan="1" colspan="1"> </td>
-            </tr>
-          </tbody>
-        </table>
-</div>
-<p id="section-12.4-8">The "Pkts" column in <a href="#frame-types" class="xref">Table 3</a> 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>
-<span class="break"></span><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">
-  Only a CONNECTION_CLOSE frame of type 0x1c can 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.  An endpoint MUST treat receipt of
-a frame in a packet type that is not permitted as a connection error of type
-PROTOCOL_VIOLATION.<a href="#section-12.4-10" class="pilcrow">¶</a></p>
-<p id="section-12.4-11">The "Spec" column in  <a href="#frame-types" class="xref">Table 3</a> summarizes any special rules governing the
-processing or generation of the frame type, as indicated by the following
-characters:<a href="#section-12.4-11" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-12.4-12">
-          <dt id="section-12.4-12.1">N:</dt>
-          <dd id="section-12.4-12.2">
-  Packets containing only frames with this marking are not ack-eliciting; see
-<a href="#generating-acks" class="xref">Section 13.2</a>.<a href="#section-12.4-12.2" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-12.4-12.3">C:</dt>
-          <dd id="section-12.4-12.4">
-  Packets containing only frames with this marking do not count toward bytes
-in flight for congestion control purposes; see <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.<a href="#section-12.4-12.4" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-12.4-12.5">P:</dt>
-          <dd id="section-12.4-12.6">
-  Packets containing only frames with this marking can be used to probe new
-network paths during connection migration; see <a href="#probing" class="xref">Section 9.1</a>.<a href="#section-12.4-12.6" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-12.4-12.7">F:</dt>
-          <dd id="section-12.4-12.8">
-  The content of frames with this marking are flow controlled; see
-<a href="#flow-control" class="xref">Section 4</a>.<a href="#section-12.4-12.8" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-12.4-13">The "Pkts" and "Spec" columns in  <a href="#frame-types" class="xref">Table 3</a> do not form part of the IANA
-registry; see <a href="#iana-frames" class="xref">Section 22.3</a>.<a href="#section-12.4-13" class="pilcrow">¶</a></p>
-<p id="section-12.4-14">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-14" class="pilcrow">¶</a></p>
-<p id="section-12.4-15">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-15" class="pilcrow">¶</a></p>
-<p id="section-12.4-16">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-16" 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 sends 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 including
-as many frames as possible in each QUIC packet.  A sender MAY wait for a short
-period of time to collect 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 included in a single QUIC packet, loss of that packet blocks all those
-streams from making progress.  Implementations are advised to include 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 include 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 delay an endpoint
-communicated 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
-6.2 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 that 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 the guidance offered above. However, an implementation
-should only deviate from these requirements after careful consideration of the
-performance implications of a change, for connections made by the endpoint and
-for other users of the network.<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 send an ACK frame 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 include an ACK frame with outgoing
-frames.<a href="#section-13.2.1-7" class="pilcrow">¶</a></p>
-<p id="section-13.2.1-8">A receiver MUST NOT send an ack-eliciting frame in all packets that would
-otherwise be non-ack-eliciting, to avoid an infinite feedback loop of
-acknowledgements.<a href="#section-13.2.1-8" 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 trade-off.<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 6 of
-<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>. Window-based congestion controllers, such as the one in
-Section 7 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 improve connection throughput on severely asymmetric links
-and reduce the volume of acknowledgment traffic using return path capacity;
-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 acknowledgements for older packets reduces the chance of
-spurious retransmissions 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 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.  Senders can expect
-acknowledgements for most packets, but QUIC does not guarantee receipt of an
-acknowledgment for every packet that the receiver processes.<a href="#section-13.2.3-3" class="pilcrow">¶</a></p>
-<p id="section-13.2.3-4">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.
-Receivers MAY also limit ACK frame size further to preserve space for other
-frames or to limit the capacity that acknowledgments consume.<a href="#section-13.2.3-4" class="pilcrow">¶</a></p>
-<p id="section-13.2.3-5">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.3-5" class="pilcrow">¶</a></p>
-<p id="section-13.2.3-6">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.3-6" class="pilcrow">¶</a></p>
-<p id="section-13.2.3-7">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.3-7" class="pilcrow">¶</a></p>
-<p id="section-13.2.3-8"><a href="#ack-tracking" class="xref">Section 13.2.4</a> describes an exemplary approach for determining what packets
-to acknowledge in each ACK frame.  Though the goal of this algorithm is to
-generate an acknowledgment for every packet that is processed, it is still
-possible for acknowledgments to be lost.<a href="#section-13.2.3-8" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="ack-tracking">
-<section id="section-13.2.4">
-          <h4 id="name-limiting-ranges-by-tracking">
-<a href="#section-13.2.4" class="section-number selfRef">13.2.4. </a><a href="#name-limiting-ranges-by-tracking" class="section-name selfRef">Limiting Ranges by Tracking 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">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 send 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.4-2" class="pilcrow">¶</a></p>
-<p id="section-13.2.4-3">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 retransmissions, but the sender will
-continue making forward progress.<a href="#section-13.2.4-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="host-delay">
-<section id="section-13.2.5">
-          <h4 id="name-measuring-and-reporting-hos">
-<a href="#section-13.2.5" class="section-number selfRef">13.2.5. </a><a href="#name-measuring-and-reporting-hos" class="section-name selfRef">Measuring and Reporting Host Delay</a>
-          </h4>
-<p id="section-13.2.5-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 acknowledgement 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 frame
-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.5-1" class="pilcrow">¶</a></p>
-<p id="section-13.2.5-2">Since the acknowledgement delay is not used for Initial and Handshake
-packets, the ACK Delay field in acknowledgements for those packet types
-SHOULD be set to 0.<a href="#section-13.2.5-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="ack-frames-and-packet-protection">
-<section id="section-13.2.6">
-          <h4 id="name-ack-frames-and-packet-prote">
-<a href="#section-13.2.6" class="section-number selfRef">13.2.6. </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.6-1">ACK frames MUST only be carried in a packet that has the same packet number
-space as the packet being acknowledged; 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.6-1" class="pilcrow">¶</a></p>
-<p id="section-13.2.6-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.6-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="padding-frames-consume-congestion-window">
-<section id="section-13.2.7">
-          <h4 id="name-padding-frames-consume-cong">
-<a href="#section-13.2.7" class="section-number selfRef">13.2.7. </a><a href="#name-padding-frames-consume-cong" class="section-name selfRef">PADDING Frames Consume Congestion Window</a>
-          </h4>
-<p id="section-13.2.7-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.7-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
-acknowledgement 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 resending 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; see <a href="#fc-credit" class="xref">Section 4.2</a>.<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">An IP packet that results in no QUIC packets being processed does not increase
-ECN counts.  A QUIC 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 counts 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
-application data 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
-server's 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 (Section 6 of <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 for only 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">Other methods of probing paths for ECN support are possible, as are different
-marking strategies. Implementations MAY use other methods defined in RFCs; see
-<span>[<a href="#RFC8311" class="xref">RFC8311</a>]</span>. Implementations that use the ECT(1) codepoint need to perform ECN
-validation using ECT(1) counts.<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">Erroneous application of ECN marks in the network can result in degraded
-connection performance.  An endpoint that receives an ACK frame with ECN
-counts therefore validates the counts before using them. It performs this
-validation by comparing newly received counts against those from the last
-successfully processed ACK frame. Any increase in ECN counts is validated
-based on the markings that were applied to packets that are newly
-acknowledged in the ACK frame.<a href="#section-13.4.2.2-1" class="pilcrow">¶</a></p>
-<p id="section-13.4.2.2-2">If an ACK frame newly acknowledges a packet that the endpoint sent with either
-ECT(0) or ECT(1) codepoints set, ECN validation fails if ECN counts are not
-present in the ACK frame.  This check detects a network element that zeroes out
-ECN bits or a peer that is unable to access ECN markings.<a href="#section-13.4.2.2-2" class="pilcrow">¶</a></p>
-<p id="section-13.4.2.2-3">ECN validation fails if the sum of the increase in ECT(0) and ECN-CE counts is
-less than the number of newly acknowledged packets that were originally sent
-with an ECT(0) marking.  Similarly, ECN validation fails if the sum of the
-increases to ECT(1) and ECN-CE counts is less than the number of newly
-acknowledged packets sent with an ECT(1) marking.  These checks can detect
-removal of ECN markings in the network.<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 ECN-CE
-counts to be greater than the number of packets acknowledged in an ACK frame.
-This is why counts are permitted to be larger than might be accounted for by
-newly acknowledged packets.<a href="#section-13.4.2.2-4" class="pilcrow">¶</a></p>
-<p id="section-13.4.2.2-5">ECN validation MAY fail if the total count for an ECT(0) or ECT(1) marking
-exceeds the total number of packets sent with the corresponding marking.   In
-particular, an endpoint that never applies a particular marking can fail
-validation when a non-zero count for the corresponding marking is received.
-This check can detect when packets are marked ECT(0) or ECT(1) in the network.<a href="#section-13.4.2.2-5" class="pilcrow">¶</a></p>
-<p id="section-13.4.2.2-6">Processing ECN counts out of order can result in validation failure.  An
-endpoint SHOULD skip ECN validation on an ACK frame that does not increase the
-largest acknowledged packet number.<a href="#section-13.4.2.2-6" 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 headers.<a href="#section-14-1" class="pilcrow">¶</a></p>
-<p id="section-14-2">QUIC depends upon a minimum IP packet size of at least 1280 bytes.  This is the
-IPv6 minimum size (<span>[<a href="#IPv6" class="xref">IPv6</a>]</span>) and is also supported by most modern IPv4
-networks.  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 href="#section-14-2" class="pilcrow">¶</a></p>
-<p id="section-14-3">The QUIC maximum packet size is the largest size of QUIC packet that can be sent
-across a network path using a single packet. Any maximum packet size larger than
-1200 bytes can be discovered using Path Maximum Transmission Unit Discovery
-(PMTUD; see <a href="#pmtud" class="xref">Section 14.2.1</a>) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD;
-see <a href="#dplpmtud" class="xref">Section 14.3</a>).<a href="#section-14-3" class="pilcrow">¶</a></p>
-<p id="section-14-4">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 the
-maximum packet size. A sender can avoid exceeding this limit, 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 the
-smallest allowed maximum packet size of 1200 bytes.<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>
-<div id="initial-size">
-<section id="section-14.1">
-        <h3 id="name-initial-packet-size">
-<a href="#section-14.1" class="section-number selfRef">14.1. </a><a href="#name-initial-packet-size" class="section-name selfRef">Initial Packet Size</a>
-        </h3>
-<p id="section-14.1-1">A client MUST expand the payload of all UDP datagrams carrying Initial packets
-to at least the smallest allowed maximum packet size (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 Path Maximum
-Transmission Unit (PMTU).  This 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.1-1" class="pilcrow">¶</a></p>
-<p id="section-14.1-2">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.1-2" class="pilcrow">¶</a></p>
-<p id="section-14.1-3">A server MUST discard an Initial packet that is carried in a UDP datagram with a
-payload that is less than the smallest allowed maximum packet size of 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.2.1</a>.<a href="#section-14.1-3" class="pilcrow">¶</a></p>
-<p id="section-14.1-4">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.1-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="path-maximum-transmission-unit">
-<section id="section-14.2">
-        <h3 id="name-path-maximum-transmission-u">
-<a href="#section-14.2" class="section-number selfRef">14.2. </a><a href="#name-path-maximum-transmission-u" class="section-name selfRef">Path Maximum Transmission Unit</a>
-        </h3>
-<p id="section-14.2-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.2-1" class="pilcrow">¶</a></p>
-<p id="section-14.2-2">An endpoint SHOULD use DPLPMTUD (<a href="#dplpmtud" class="xref">Section 14.3</a>) or PMTUD (<a href="#pmtud" class="xref">Section 14.2.1</a>) to determine
-whether the path to a destination will support a desired maximum packet size
-without fragmentation.  In the absence of these mechanisms, QUIC endpoints
-SHOULD NOT send IP packets larger than the smallest allowed maximum packet size.<a href="#section-14.2-2" class="pilcrow">¶</a></p>
-<p id="section-14.2-3">Both DPLPMTUD and PMTUD send IP packets that are larger than the current maximum
-packet size, referred to as PMTU probes.  All QUIC packets that are not sent in
-a PMTU probe 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.2-3" class="pilcrow">¶</a></p>
-<p id="section-14.2-4">If a QUIC endpoint determines that the PMTU between any pair of local and remote
-IP addresses has fallen below the smallest allowed maximum packet size of 1200
-bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU
-probes or those containing CONNECTION_CLOSE frames, on the affected path.  An
-endpoint MAY terminate the connection if an alternative path cannot be found.<a href="#section-14.2-4" class="pilcrow">¶</a></p>
-<p id="section-14.2-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.2-5" class="pilcrow">¶</a></p>
-<p id="section-14.2-6">A QUIC implementation MAY be more conservative in computing the maximum packet
-size to allow for unknown tunnel overheads or IP header options/extensions.<a href="#section-14.2-6" class="pilcrow">¶</a></p>
-<div id="pmtud">
-<section id="section-14.2.1">
-          <h4 id="name-handling-of-icmp-messages-b">
-<a href="#section-14.2.1" class="section-number selfRef">14.2.1. </a><a href="#name-handling-of-icmp-messages-b" class="section-name selfRef">Handling of ICMP Messages by PMTUD</a>
-          </h4>
-<p id="section-14.2.1-1">Path Maximum Transmission Unit Discovery (PMTUD; <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-1" class="pilcrow">¶</a></p>
-<p id="section-14.2.1-2">An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below
-the minimum QUIC packet size.<a href="#section-14.2.1-2" class="pilcrow">¶</a></p>
-<p id="section-14.2.1-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.1-3" class="pilcrow">¶</a></p>
-<p id="section-14.2.1-4">QUIC endpoints using PMTUD 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 (see
-Section 4.6.1 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>).  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.  The endpoint SHOULD ignore all ICMP messages that fail
-validation.<a href="#section-14.2.1-4" class="pilcrow">¶</a></p>
-<p id="section-14.2.1-5">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.1-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="dplpmtud">
-<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">Datagram Packetization Layer PMTU Discovery (DPLPMTUD;
-<span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>) relies on tracking loss or
-acknowledgment of QUIC packets that are carried in PMTU probes.  PMTU probes for
-DPLPMTUD that use the PADDING frame implement "Probing using padding data", as
-defined in Section 4.1 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>.<a href="#section-14.3-1" class="pilcrow">¶</a></p>
-<p id="section-14.3-2">Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1 of
-<span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>) to be consistent with the minimum QUIC packet size. The
-MIN_PLPMTU is the same as the BASE_PMTU.<a href="#section-14.3-2" class="pilcrow">¶</a></p>
-<p id="section-14.3-3">QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD
-MPS) for each combination of local and remote IP addresses.<a href="#section-14.3-3" class="pilcrow">¶</a></p>
-<div id="dplpmtud-and-initial-connectivity">
-<section id="section-14.3.1">
-          <h4 id="name-dplpmtud-and-initial-connec">
-<a href="#section-14.3.1" class="section-number selfRef">14.3.1. </a><a href="#name-dplpmtud-and-initial-connec" class="section-name selfRef">DPLPMTUD and Initial Connectivity</a>
-          </h4>
-<p id="section-14.3.1-1">From the perspective of DPLPMTUD, QUIC is an acknowledged packetization layer
-(PL). A sender can therefore enter the DPLPMTUD BASE state when the QUIC
-connection handshake has been completed.<a href="#section-14.3.1-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="validating-the-quic-path-with-dplpmtud">
-<section id="section-14.3.2">
-          <h4 id="name-validating-the-quic-path-wi">
-<a href="#section-14.3.2" class="section-number selfRef">14.3.2. </a><a href="#name-validating-the-quic-path-wi" class="section-name selfRef">Validating the QUIC Path with DPLPMTUD</a>
-          </h4>
-<p id="section-14.3.2-1">QUIC provides an acknowledged PL, therefore a sender does not implement the
-DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section
-5.2 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>.<a href="#section-14.3.2-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="handling-of-icmp-messages-by-dplpmtud">
-<section id="section-14.3.3">
-          <h4 id="name-handling-of-icmp-messages-by">
-<a href="#section-14.3.3" class="section-number selfRef">14.3.3. </a><a href="#name-handling-of-icmp-messages-by" class="section-name selfRef">Handling of ICMP Messages by DPLPMTUD</a>
-          </h4>
-<p id="section-14.3.3-1">An endpoint using DPLPMTUD requires the validation of any received ICMP Packet
-Too Big (PTB) message before using the PTB information, as defined in Section
-4.6 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>.  In addition to UDP port validation, QUIC validates an
-ICMP message by using other PL information (e.g., validation of connection IDs
-in the quoted packet of any received ICMP message).<a href="#section-14.3.3-1" class="pilcrow">¶</a></p>
-<p id="section-14.3.3-2">The considerations for processing ICMP messages described in <a href="#pmtud" class="xref">Section 14.2.1</a> also
-apply if these messages are used by DPLPMTUD.<a href="#section-14.3.3-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="sending-quic-pmtu-probes">
-<section id="section-14.4">
-        <h3 id="name-sending-quic-pmtu-probes">
-<a href="#section-14.4" class="section-number selfRef">14.4. </a><a href="#name-sending-quic-pmtu-probes" class="section-name selfRef">Sending QUIC PMTU Probes</a>
-        </h3>
-<p id="section-14.4-1">PMTU probes are ack-eliciting packets.<a href="#section-14.4-1" class="pilcrow">¶</a></p>
-<p id="section-14.4-2">Endpoints could limit the content of PMTU probes to PING and PADDING frames as
-packets that are larger than the current maximum packet size are more likely to
-be dropped by the network.   Loss of a QUIC packet that is carried in a PMTU
-probe is therefore not a reliable indication of congestion and SHOULD NOT
-trigger a congestion control reaction; see Section 3, Bullet 7 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>.
-However, PMTU probes consume congestion window, which could delay subsequent
-transmission by an application.<a href="#section-14.4-2" class="pilcrow">¶</a></p>
-<div id="pmtu-probes-src-cid">
-<section id="section-14.4.1">
-          <h4 id="name-pmtu-probes-containing-sour">
-<a href="#section-14.4.1" class="section-number selfRef">14.4.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.4.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 probes to route any resulting ICMP messages (<a href="#pmtud" class="xref">Section 14.2.1</a>) back to the correct
-endpoint.  However, only long header packets (<a href="#long-header" class="xref">Section 17.2</a>) contain the
-Source Connection ID field, and long header packets are not decrypted or
-acknowledged by the peer once the handshake is complete.<a href="#section-14.4.1-1" class="pilcrow">¶</a></p>
-<p id="section-14.4.1-2">One way to construct a PMTU probe is to coalesce (see <a href="#packet-coalesce" class="xref">Section 12.2</a>) a
-packet with a long header, such as a Handshake or 0-RTT packet
-(<a href="#long-header" class="xref">Section 17.2</a>), with a short header packet in a single UDP datagram.  If the
-resulting PMTU probe reaches the endpoint, the packet with the long header will
-be ignored, but the short header packet will be acknowledged.  If the PMTU probe
-causes an ICMP message to be sent, the first part of the probe will be quoted in
-that message.  If the Source Connection ID field is within the quoted portion of
-the probe, that could be used for routing or validation of the ICMP message.<a href="#section-14.4.1-2" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-14.4.1-3">
-            <dt id="section-14.4.1-3.1">Note:</dt>
-            <dd id="section-14.4.1-3.2">
-  The purpose of using a packet with a long header is only to ensure that the
-quoted packet contained in the ICMP message contains a Source Connection ID
-field.  This packet does not need to be a valid packet and it can be sent even
-if there is no current use for packets of that type.<a href="#section-14.4.1-3.2" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-</dl>
-</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 from 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">Versions (<a href="#versions" class="xref">Section 15</a>) and error codes (<a href="#error-codes" class="xref">Section 20</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
-only 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">Prior to receiving an acknowledgement for a packet number space, the full packet
-number MUST be included.<a href="#section-17.1-3" class="pilcrow">¶</a></p>
-<p id="section-17.1-4">After an acknowledgement is received for a packet number space, 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-4" class="pilcrow">¶</a></p>
-<p id="section-17.1-5">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-5" class="pilcrow">¶</a></p>
-<p id="section-17.1-6">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-6" class="pilcrow">¶</a></p>
-<p id="section-17.1-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-17.1-8">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-8" 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-13">
-          <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),
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..160),
-  Source Connection ID Length (8),
-  Source Connection ID (0..160),
-}
-</pre>
-</div>
-<figcaption><a href="#figure-13" class="selfRef">Figure 13</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>
-<span class="break"></span><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 the version of QUIC that 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">Destination Connection ID 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 Destination Connection ID
-Length field, which indicates the length of this field.
-<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">Source Connection ID 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 Source Connection ID Length field,
-which indicates the length of this field. <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, Destination and Source Connection ID lengths, 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>
-<span class="break"></span><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 that 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 is protected
-using header protection; see 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-14">
-            <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,
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..2040),
-  Source Connection ID Length (8),
-  Source Connection ID (0..2040),
-  Supported Version (32) ...,
-}
-</pre>
-</div>
-<figcaption><a href="#figure-14" class="selfRef">Figure 14</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
-that 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 is not acknowledged.  It is only sent in response
-to a packet that indicates an unsupported version; see <a href="#server-pkt-handling" class="xref">Section 5.2.2</a>.<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-15">
-            <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),
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..160),
-  Source Connection ID 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-15" class="selfRef">Figure 15</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; see <a href="#long-header" class="xref">Section 17.2</a>.  The first byte contains the Reserved and
-Packet Number Length bits; see also <a href="#long-header" class="xref">Section 17.2</a>.  Between the Source
-Connection ID and Length fields, there are two additional fields specific to
-the Initial packet.<a href="#section-17.2.2-3" class="pilcrow">¶</a></p>
-<span class="break"></span><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; see <a href="#validate-handshake" class="xref">Section 8.1</a>.<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 of type 0x1c 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.9.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.4 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; see <a href="#long-header" class="xref">Section 17.2</a>.  The first byte contains
-the Reserved and Packet Number Length bits; see <a href="#long-header" class="xref">Section 17.2</a>.  A 0-RTT packet
-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-16">
-            <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),
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..160),
-  Source Connection ID 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-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.  New packet numbers MUST be
-used for any new packets that are sent; as described in <a href="#retry-continue" class="xref">Section 17.2.5.3</a>,
-reusing packet numbers could compromise packet protection.<a href="#section-17.2.3-5" class="pilcrow">¶</a></p>
-<p id="section-17.2.3-6">A client only receives acknowledgments for its 0-RTT packets once the handshake
-is complete.<a href="#section-17.2.3-6" class="pilcrow">¶</a></p>
-<p id="section-17.2.3-7">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-7" class="pilcrow">¶</a></p>
-<p id="section-17.2.3-8">A server SHOULD treat a violation of remembered limits (<a href="#zerortt-parameters" class="xref">Section 7.4.1</a>)
-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-8" 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; see <a href="#long-header" class="xref">Section 17.2</a>.  The first byte contains
-the Reserved and Packet Number Length bits; see <a href="#long-header" class="xref">Section 17.2</a>.  It is used
-to carry cryptographic handshake messages and acknowledgments 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-17">
-            <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),
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..160),
-  Source Connection ID Length (8),
-  Source Connection ID (0..160),
-  Length (i),
-  Packet Number (8..32),
-  Packet Payload (..),
-}
-</pre>
-</div>
-<figcaption><a href="#figure-17" class="selfRef">Figure 17</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
-of type 0x1c. 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-18">
-            <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),
-  Destination Connection ID Length (8),
-  Destination Connection ID (0..160),
-  Source Connection ID Length (8),
-  Source Connection ID (0..160),
-  Retry Token (..),
-  Retry Integrity Tag (128),
-}
-</pre>
-</div>
-<figcaption><a href="#figure-18" class="selfRef">Figure 18</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 18</a>) does not contain any protected
-fields.  The value in the Unused field is set to an arbitrary value by the
-server; a client MUST ignore these bits.  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>
-<span class="break"></span><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="retry-continue">
-<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 included 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. In particular, 0-RTT packets contain confidential
-information that will most likely be retransmitted on receiving a Retry packet.
-The keys used to protect these new 0-RTT packets will not change as a result of
-responding to a Retry packet. However, the data sent in these packets could be
-different than what was sent earlier. Sending these new packets with the same
-packet number is likely to compromise the packet protection for those packets
-because the same key and nonce could be used to protect different content.<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 that 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-19">
-          <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-19" class="selfRef">Figure 19</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>
-<span class="break"></span><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 20</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-20">
-        <div class="artwork art-text alignLeft" id="section-18-2.1">
-<pre>
-Transport Parameters {
-  Transport Parameter (..) ...,
-}
-</pre>
-</div>
-<figcaption><a href="#figure-20" class="selfRef">Figure 20</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 21</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-21">
-        <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-21" class="selfRef">Figure 21</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 is 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>
-<span class="break"></span><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.1</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.3</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.3</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;
-see <a href="#packet-size" class="xref">Section 14</a>.  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 acknowledgement 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 acknowledgement 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>) on the address
-being used during the handshake.  When a peer sets this transport parameter,
-an endpoint MUST NOT use a new local address when sending to the address that
-the peer used during the handshake.  This transport parameter does not
-prohibit connection migration after a client has acted on a preferred_address
-transport parameter.  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>.  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 preferred_address transport parameter contains an address and port for
-both IP version 4 and 6.  The four-byte IPv4 Address field is followed by the
-associated two-byte IPv4 Port field.  This is followed by a 16-byte IPv6
-Address field and two-byte IPv6 Port field.  After address and port pairs,
-a Connection ID Length field describes the length of the following Connection
-ID field.  Finally, a 16-byte Stateless Reset Token field includes the
-stateless reset token associated with the connection ID.  The format of this
-transport parameter is shown in <a href="#fig-preferred-address" class="xref">Figure 22</a>.<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 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 sent alongside 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.36" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-18.2-4.37"></dt>
-          <dd id="section-18.2-4.38">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.38" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<span id="name-preferred-address-format"></span><div id="fig-preferred-address">
-<figure id="figure-22">
-          <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),
-  Connection ID Length (8),
-  Connection ID (..),
-  Stateless Reset Token (128),
-}
-</pre>
-</div>
-<figcaption><a href="#figure-22" class="selfRef">Figure 22</a>:
-<a href="#name-preferred-address-format" class="selfRef">Preferred Address format</a>
-          </figcaption></figure>
-</div>
-<span class="break"></span><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-frames">
-<a href="#section-19.1" class="section-number selfRef">19.1. </a><a href="#name-padding-frames" class="section-name selfRef">PADDING Frames</a>
-        </h3>
-<p id="section-19.1-1">A 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">PADDING frames are formatted as shown in <a href="#padding-format" class="xref">Figure 23</a>, which shows that
-PADDING frames have 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>
-<span id="name-padding-frame-format"></span><div id="padding-format">
-<figure id="figure-23">
-          <div class="artwork art-text alignLeft" id="section-19.1-3.1">
-<pre>
-PADDING Frame {
-  Type (i) = 0x00,
-}
-</pre>
-</div>
-<figcaption><a href="#figure-23" class="selfRef">Figure 23</a>:
-<a href="#name-padding-frame-format" class="selfRef">PADDING Frame Format</a>
-          </figcaption></figure>
-</div>
-</section>
-</div>
-<div id="frame-ping">
-<section id="section-19.2">
-        <h3 id="name-ping-frames">
-<a href="#section-19.2" class="section-number selfRef">19.2. </a><a href="#name-ping-frames" class="section-name selfRef">PING Frames</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.<a href="#section-19.2-1" class="pilcrow">¶</a></p>
-<p id="section-19.2-2">PING frames are formatted as shown in <a href="#ping-format" class="xref">Figure 24</a>, which shows that PING
-frames have no content.<a href="#section-19.2-2" class="pilcrow">¶</a></p>
-<span id="name-ping-frame-format"></span><div id="ping-format">
-<figure id="figure-24">
-          <div class="artwork art-text alignLeft" id="section-19.2-3.1">
-<pre>
-PING Frame {
-  Type (i) = 0x01,
-}
-</pre>
-</div>
-<figcaption><a href="#figure-24" class="selfRef">Figure 24</a>:
-<a href="#name-ping-frame-format" class="selfRef">PING Frame Format</a>
-          </figcaption></figure>
-</div>
-<p id="section-19.2-4">The receiver of a PING frame simply needs to acknowledge the packet containing
-this frame.<a href="#section-19.2-4" class="pilcrow">¶</a></p>
-<p id="section-19.2-5">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; see
-<a href="#defer-idle" class="xref">Section 10.1.2</a>.<a href="#section-19.2-5" 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
-reneging for 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">ACK frames are formatted as shown in <a href="#ack-format" class="xref">Figure 25</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-25">
-          <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-25" class="selfRef">Figure 25</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>
-<span class="break"></span><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 encoding the acknowledgement delay in
-microseconds; see <a href="#host-delay" class="xref">Section 13.2.5</a>. It is decoded by multiplying the
-value in the field by 2 to the power of the ack_delay_exponent transport
-parameter sent by the sender of the ACK frame; see
-<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>. Compared to simply expressing
-the delay as an integer, this encoding allows for a larger range of
-values within the same number of bytes, at the cost of lower resolution.<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 that 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 26</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-26">
-            <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-26" class="selfRef">Figure 26</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>
-<span class="break"></span><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">When present, there are 3 ECN counts, as shown in <a href="#ecn-count-format" class="xref">Figure 27</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-27">
-            <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-27" class="selfRef">Figure 27</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>
-<span class="break"></span><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-frames">
-<a href="#section-19.4" class="section-number selfRef">19.4. </a><a href="#name-reset_stream-frames" class="section-name selfRef">RESET_STREAM Frames</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">RESET_STREAM frames are formatted as shown in <a href="#fig-reset-stream" class="xref">Figure 28</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-28">
-          <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-28" class="selfRef">Figure 28</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>
-<span class="break"></span><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.2</a>) that 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; see <a href="#final-size" class="xref">Section 4.4</a>.<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-frames">
-<a href="#section-19.5" class="section-number selfRef">19.5. </a><a href="#name-stop_sending-frames" class="section-name selfRef">STOP_SENDING Frames</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">STOP_SENDING frames are formatted as shown in <a href="#fig-stop-sending" class="xref">Figure 29</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-29">
-          <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-29" class="selfRef">Figure 29</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>
-<span class="break"></span><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.2</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-frames">
-<a href="#section-19.6" class="section-number selfRef">19.6. </a><a href="#name-crypto-frames" class="section-name selfRef">CRYPTO Frames</a>
-        </h3>
-<p id="section-19.6-1">A 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">CRYPTO frames are formatted as shown in <a href="#fig-crypto" class="xref">Figure 30</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-30">
-          <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-30" class="selfRef">Figure 30</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>
-<span class="break"></span><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-frames">
-<a href="#section-19.7" class="section-number selfRef">19.7. </a><a href="#name-new_token-frames" class="section-name selfRef">NEW_TOKEN Frames</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">NEW_TOKEN frames are formatted as shown in <a href="#fig-new-token" class="xref">Figure 31</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-31">
-          <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-31" class="selfRef">Figure 31</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>
-<span class="break"></span><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 Type field takes the form 0b00001XXX (or the set of values from 0x08 to
-0x0f).  The three low-order bits of the frame type determine 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">STREAM frames are formatted as shown in <a href="#fig-stream" class="xref">Figure 32</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-32">
-          <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-32" class="selfRef">Figure 32</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>
-<span class="break"></span><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-frames">
-<a href="#section-19.9" class="section-number selfRef">19.9. </a><a href="#name-max_data-frames" class="section-name selfRef">MAX_DATA Frames</a>
-        </h3>
-<p id="section-19.9-1">A 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">MAX_DATA frames are formatted as shown in <a href="#fig-max-data" class="xref">Figure 33</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-33">
-          <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-33" class="selfRef">Figure 33</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 field:<a href="#section-19.9-4" class="pilcrow">¶</a></p>
-<span class="break"></span><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.  This includes violations of remembered
-limits in Early Data; 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-frames">
-<a href="#section-19.10" class="section-number selfRef">19.10. </a><a href="#name-max_stream_data-frames" class="section-name selfRef">MAX_STREAM_DATA Frames</a>
-        </h3>
-<p id="section-19.10-1">A 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">MAX_STREAM_DATA frames are formatted as shown in <a href="#fig-max-stream-data" class="xref">Figure 34</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-34">
-          <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-34" class="selfRef">Figure 34</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>
-<span class="break"></span><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.  This includes violations
-of remembered limits in Early Data; 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">A MAX_STREAMS frame (type=0x12 or 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">MAX_STREAMS frames are formatted as shown in <a href="#fig-max-streams" class="xref">Figure 35</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-35">
-          <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-35" class="selfRef">Figure 35</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 field:<a href="#section-19.11-4" class="pilcrow">¶</a></p>
-<span class="break"></span><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 that state a
-lower stream limit than an endpoint has previously received.  MAX_STREAMS frames
-that 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.  This includes violations of
-remembered limits in Early Data; see <a href="#zerortt-parameters" class="xref">Section 7.4.1</a>.<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-frames">
-<a href="#section-19.12" class="section-number selfRef">19.12. </a><a href="#name-data_blocked-frames" class="section-name selfRef">DATA_BLOCKED Frames</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 do so 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">DATA_BLOCKED frames are formatted as shown in <a href="#fig-data-blocked" class="xref">Figure 36</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-36">
-          <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-36" class="selfRef">Figure 36</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 field:<a href="#section-19.12-4" class="pilcrow">¶</a></p>
-<span class="break"></span><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-frames">
-<a href="#section-19.13" class="section-number selfRef">19.13. </a><a href="#name-stream_data_blocked-frames" class="section-name selfRef">STREAM_DATA_BLOCKED Frames</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 do so 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">STREAM_DATA_BLOCKED frames are formatted as shown in
-<a href="#fig-stream-data-blocked" class="xref">Figure 37</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-37">
-          <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-37" class="selfRef">Figure 37</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>
-<span class="break"></span><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 that is blocked due to flow
-control.<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 is used to indicate 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">STREAMS_BLOCKED frames are formatted as shown in <a href="#fig-streams-blocked" class="xref">Figure 38</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-38">
-          <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-38" class="selfRef">Figure 38</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 field:<a href="#section-19.14-5" class="pilcrow">¶</a></p>
-<span class="break"></span><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-frames">
-<a href="#section-19.15" class="section-number selfRef">19.15. </a><a href="#name-new_connection_id-frames" class="section-name selfRef">NEW_CONNECTION_ID Frames</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">NEW_CONNECTION_ID frames are formatted as shown in <a href="#fig-new-connection-id" class="xref">Figure 39</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-39">
-          <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-39" class="selfRef">Figure 39</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>
-<span class="break"></span><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, encoded as a
-variable-length integer; 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.3</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 handle
-receiving the same NEW_CONNECTION_ID frame multiple times.<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-frames">
-<a href="#section-19.16" class="section-number selfRef">19.16. </a><a href="#name-retire_connection_id-frames" class="section-name selfRef">RETIRE_CONNECTION_ID Frames</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">RETIRE_CONNECTION_ID frames are formatted as shown in
-<a href="#fig-retire-connection-id" class="xref">Figure 40</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-40">
-          <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-40" class="selfRef">Figure 40</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 field:<a href="#section-19.16-5" class="pilcrow">¶</a></p>
-<span class="break"></span><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
-PROTOCOL_VIOLATION.<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-frames">
-<a href="#section-19.17" class="section-number selfRef">19.17. </a><a href="#name-path_challenge-frames" class="section-name selfRef">PATH_CHALLENGE Frames</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">PATH_CHALLENGE frames are formatted as shown in <a href="#fig-path-challenge" class="xref">Figure 41</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-41">
-          <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-41" class="selfRef">Figure 41</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 field:<a href="#section-19.17-4" class="pilcrow">¶</a></p>
-<span class="break"></span><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">Including 64 bits of entropy in a PATH_CHALLENGE frame ensures 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-frames">
-<a href="#section-19.18" class="section-number selfRef">19.18. </a><a href="#name-path_response-frames" class="section-name selfRef">PATH_RESPONSE Frames</a>
-        </h3>
-<p id="section-19.18-1">A PATH_RESPONSE frame (type=0x1b) is sent in response to a PATH_CHALLENGE frame.<a href="#section-19.18-1" class="pilcrow">¶</a></p>
-<p id="section-19.18-2">PATH_RESPONSE frames are formatted as shown in <a href="#fig-path-response" class="xref">Figure 42</a>, which is
-identical to the PATH_CHALLENGE frame (<a href="#frame-path-challenge" class="xref">Section 19.17</a>).<a href="#section-19.18-2" class="pilcrow">¶</a></p>
-<span id="name-path_response-frame-format"></span><div id="fig-path-response">
-<figure id="figure-42">
-          <div class="artwork art-text alignLeft" id="section-19.18-3.1">
-<pre>
-PATH_RESPONSE Frame {
-  Type (i) = 0x1b,
-  Data (64),
-}
-</pre>
-</div>
-<figcaption><a href="#figure-42" class="selfRef">Figure 42</a>:
-<a href="#name-path_response-frame-format" class="selfRef">PATH_RESPONSE Frame Format</a>
-          </figcaption></figure>
-</div>
-<p id="section-19.18-4">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-4" 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 have not 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">CONNECTION_CLOSE frames are formatted as shown in <a href="#fig-connection-close" class="xref">Figure 43</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-43">
-          <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-43" class="selfRef">Figure 43</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>
-<span class="break"></span><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 that indicates the reason for
-closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes
-from the space defined in <a href="#transport-error-codes" class="xref">Section 20.1</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.2</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 not to 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; see Section 4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.  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-frames">
-<a href="#section-19.20" class="section-number selfRef">19.20. </a><a href="#name-handshake_done-frames" class="section-name selfRef">HANDSHAKE_DONE Frames</a>
-        </h3>
-<p id="section-19.20-1">The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal confirmation of
-the handshake to the client.<a href="#section-19.20-1" class="pilcrow">¶</a></p>
-<p id="section-19.20-2">HANDSHAKE_DONE frames are formatted as shown in <a href="#handshake-done-format" class="xref">Figure 44</a>, which
-shows that HANDSHAKE_DONE frames have no content.<a href="#section-19.20-2" class="pilcrow">¶</a></p>
-<span id="name-handshake_done-frame-format"></span><div id="handshake-done-format">
-<figure id="figure-44">
-          <div class="artwork art-text alignLeft" id="section-19.20-3.1">
-<pre>
-HANDSHAKE_DONE Frame {
-  Type (i) = 0x1e,
-}
-</pre>
-</div>
-<figcaption><a href="#figure-44" class="selfRef">Figure 44</a>:
-<a href="#name-handshake_done-frame-format" class="selfRef">HANDSHAKE_DONE Frame Format</a>
-          </figcaption></figure>
-</div>
-<p id="section-19.20-4">A HANDSHAKE_DONE 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-4" 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 extension frame types. One
-transport parameter can indicate support for one or more extension frame types.<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 that 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-error-codes">
-<a href="#section-20" class="section-number selfRef">20. </a><a href="#name-error-codes" class="section-name selfRef">Error Codes</a>
-      </h2>
-<p id="section-20-1">QUIC transport error codes and application error codes are 62-bit unsigned
-integers.<a href="#section-20-1" class="pilcrow">¶</a></p>
-<div id="transport-error-codes">
-<section id="section-20.1">
-        <h3 id="name-transport-error-codes">
-<a href="#section-20.1" class="section-number selfRef">20.1. </a><a href="#name-transport-error-codes" class="section-name selfRef">Transport Error Codes</a>
-        </h3>
-<p id="section-20.1-1">This section lists the defined QUIC transport error codes that may be used in a
-CONNECTION_CLOSE frame with a type of 0x1c.  These errors apply to the entire
-connection.<a href="#section-20.1-1" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-20.1-2">
-          <dt id="section-20.1-2.1">NO_ERROR (0x0):</dt>
-          <dd id="section-20.1-2.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.1-2.2" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.3">INTERNAL_ERROR (0x1):</dt>
-          <dd id="section-20.1-2.4">
-  The endpoint encountered an internal error and cannot continue with the
-connection.<a href="#section-20.1-2.4" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.5">CONNECTION_REFUSED (0x2):</dt>
-          <dd id="section-20.1-2.6">
-  The server refused to accept a new connection.<a href="#section-20.1-2.6" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.7">FLOW_CONTROL_ERROR (0x3):</dt>
-          <dd id="section-20.1-2.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.1-2.8" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.9">STREAM_LIMIT_ERROR (0x4):</dt>
-          <dd id="section-20.1-2.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.1-2.10" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.11">STREAM_STATE_ERROR (0x5):</dt>
-          <dd id="section-20.1-2.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.1-2.12" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.13">FINAL_SIZE_ERROR (0x6):</dt>
-          <dd id="section-20.1-2.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.1-2.14" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.15">FRAME_ENCODING_ERROR (0x7):</dt>
-          <dd id="section-20.1-2.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.1-2.16" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.17">TRANSPORT_PARAMETER_ERROR (0x8):</dt>
-          <dd id="section-20.1-2.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.1-2.18" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.19">CONNECTION_ID_LIMIT_ERROR (0x9):</dt>
-          <dd id="section-20.1-2.20">
-  The number of connection IDs provided by the peer exceeds the advertised
-active_connection_id_limit.<a href="#section-20.1-2.20" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.21">PROTOCOL_VIOLATION (0xa):</dt>
-          <dd id="section-20.1-2.22">
-  An endpoint detected an error with protocol compliance that was not covered by
-more specific error codes.<a href="#section-20.1-2.22" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.23">INVALID_TOKEN (0xb):</dt>
-          <dd id="section-20.1-2.24">
-  A server received a client Initial that contained an invalid Token field.<a href="#section-20.1-2.24" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.25">APPLICATION_ERROR (0xc):</dt>
-          <dd id="section-20.1-2.26">
-  The application or application protocol caused the connection to be closed.<a href="#section-20.1-2.26" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.27">CRYPTO_BUFFER_EXCEEDED (0xd):</dt>
-          <dd id="section-20.1-2.28">
-  An endpoint has received more data in CRYPTO frames than it can buffer.<a href="#section-20.1-2.28" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-20.1-2.29">CRYPTO_ERROR (0x1XX):</dt>
-          <dd id="section-20.1-2.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.1-2.30" class="pilcrow">¶</a>
-</dd>
-        <dd class="break"></dd>
-</dl>
-<p id="section-20.1-3">See <a href="#iana-error-codes" class="xref">Section 22.4</a> for details of registering new error codes.<a href="#section-20.1-3" class="pilcrow">¶</a></p>
-<p id="section-20.1-4">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.1-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="app-error-codes">
-<section id="section-20.2">
-        <h3 id="name-application-protocol-error-">
-<a href="#section-20.2" class="section-number selfRef">20.2. </a><a href="#name-application-protocol-error-" class="section-name selfRef">Application Protocol Error Codes</a>
-        </h3>
-<p id="section-20.2-1">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.2-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="#pmtud" class="xref">Section 14.2.1</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.3</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.2</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 a large number 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 frames or 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 of service,
-endpoints that share a static key for stateless reset (see <a href="#reset-token" class="xref">Section 10.3.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">More generally, servers MUST NOT generate a stateless reset if a connection with
-the corresponding connection ID could be active on any endpoint using the same
-static key.<a href="#section-21.9-3" class="pilcrow">¶</a></p>
-<p id="section-21.9-4">In the case of a cluster that uses dynamic load balancing, it is possible that a
-change in load balancer configuration could occur 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 of the packet being routed to the
-correct instance, it is better to send a stateless reset than wait for the
-connection to time out.  However, this is acceptable only if the routing cannot
-be influenced by an attacker.<a href="#section-21.9-4" 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> that 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.  Both types of
-attackers 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 can observe packets.<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 that 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
-salt) 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
-inputs; 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 that 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>
-<span class="break"></span><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 registry 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 the IETF (quic@ietf.org).<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 field:<a href="#section-22.2-3" class="pilcrow">¶</a></p>
-<span class="break"></span><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-types-registry">
-<a href="#section-22.3" class="section-number selfRef">22.3. </a><a href="#name-quic-frame-types-registry" class="section-name selfRef">QUIC Frame Types 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 field:<a href="#section-22.3-3" class="pilcrow">¶</a></p>
-<span class="break"></span><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
-need 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>.  Note
-that the registry does not include the "Pkts" and "Spec" columns from
-<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 regions 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>
-<span class="break"></span><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</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-22</span>, <time datetime="2020-06-10" class="refDate">10 June 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-datagram-plpmtud-22.txt">http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-datagram-plpmtud-22.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" class="refDate">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-08-17" class="refDate">17 August 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-08-17" class="refDate">17 August 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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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="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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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="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" class="refDate">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="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" class="refDate">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="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" class="refDate">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" class="refDate">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="GATEWAY">[GATEWAY]</dt>
-        <dd>
-<span class="refAuthor">Hätönen, S.</span><span class="refAuthor">, Nyrhinen, A.</span><span class="refAuthor">, Eggert, L.</span><span class="refAuthor">, Strowes, S.</span><span class="refAuthor">, Sarolahti, P.</span><span class="refAuthor">, and M. Kojo</span>, <span class="refTitle">"An experimental study of home gateway characteristics"</span>, <span class="seriesInfo">DOI 10.1145/1879141.1879174</span>, <span class="seriesInfo">Proceedings of the 10th annual conference on Internet measurement - IMC '10</span>, <time datetime="2010" class="refDate">2010</time>, <span>&lt;<a href="https://doi.org/10.1145/1879141.1879174">https://doi.org/10.1145/1879141.1879174</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" class="refDate">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="IPv6">[IPv6]</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" class="refDate">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="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-08-17" class="refDate">17 August 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-07</span>, <time datetime="2020-07-08" class="refDate">8 July 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-quic-manageability-07.txt">http://www.ietf.org/internet-drafts/draft-ietf-quic-manageability-07.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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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" class="refDate">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="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" class="refDate">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" class="refDate">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" class="refDate">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 45</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-45">
-        <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 cannot 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-45" class="selfRef">Figure 45</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-28">
-<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-28</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.1-1.1">Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED (#3709,
-#3690, #3694)<a href="#section-c.1-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.1-1.2">Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs (#3703, #3691)<a href="#section-c.1-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.1-1.3">Integrate QUIC-specific language from draft-ietf-tsvwg-datagram-plpmtud
-(#3695, #3702)<a href="#section-c.1-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.1-1.4">disable_active_migration does not apply to the addresses offered in
-server_preferred_address (#3608, #3670)<a href="#section-c.1-1.4" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-27">
-<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-27</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.2-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.2-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.2">Clearer requirements for address validation (#2125, #3327)<a href="#section-c.2-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.3">Security analysis of handshake and migration (#2143, #2387, #2925)<a href="#section-c.2-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.4">The entire payload of a datagram is used when counting bytes for
-mitigating amplification attacks (#3333, #3470)<a href="#section-c.2-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.5">Connection IDs can be used at any time, including in the handshake (#3348,
-#3560, #3438, #3565)<a href="#section-c.2-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.6">Only one ACK should be sent for each instance of reordering (#3357, #3361)<a href="#section-c.2-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.7">Remove text allowing a server to proceed with a bad Retry token (#3396,
-#3398)<a href="#section-c.2-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.8">Ignore active_connection_id_limit with a zero-length connection ID (#3427,
-#3426)<a href="#section-c.2-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.9">Require active_connection_id_limit be remembered for 0-RTT (#3423, #3425)<a href="#section-c.2-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.10">Require ack_delay not be remembered for 0-RTT (#3433, #3545)<a href="#section-c.2-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.11">Redefined max_packet_size to max_udp_datagram_size (#3471, #3473)<a href="#section-c.2-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.12">Guidance on limiting outstanding attempts to retire connection IDs (#3489,
-#3509, #3557, #3547)<a href="#section-c.2-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.13">Restored text on dropping bogus Version Negotiation packets (#3532, #3533)<a href="#section-c.2-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.14">Clarified that largest acknowledged needs to be saved, but not necessarily
-signaled in all cases (#3541, #3581)<a href="#section-c.2-1.14" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.15">Addressed linkability risk with the use of preferred_address (#3559, #3563)<a href="#section-c.2-1.15" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.16">Added authentication of handshake connection IDs (#3439, #3499)<a href="#section-c.2-1.16" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.2-1.17">Opening a stream in the wrong direction is an error (#3527)<a href="#section-c.2-1.17" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-26">
-<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-26</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.3-1.1">Change format of transport parameters to use varints (#3294, #3169)<a href="#section-c.3-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-25">
-<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-25</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.4-1.1">Define the use of CONNECTION_CLOSE prior to establishing connection state
-(#3269, #3297, #3292)<a href="#section-c.4-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.4-1.2">Allow use of address validation tokens after client address changes (#3307,
-#3308)<a href="#section-c.4-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.4-1.3">Define the timer for address validation (#2910, #3339)<a href="#section-c.4-1.3" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-24">
-<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-24</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.5-1.1">Added HANDSHAKE_DONE to signal handshake confirmation (#2863, #3142, #3145)<a href="#section-c.5-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.2">Add integrity check to Retry packets (#3014, #3274, #3120)<a href="#section-c.5-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.3">Specify handling of reordered NEW_CONNECTION_ID frames (#3194, #3202)<a href="#section-c.5-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.4">Require checking of sequence numbers in RETIRE_CONNECTION_ID (#3037, #3036)<a href="#section-c.5-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.5">active_connection_id_limit is enforced (#3193, #3197, #3200, #3201)<a href="#section-c.5-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.6">Correct overflow in packet number decode algorithm (#3187, #3188)<a href="#section-c.5-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.7">Allow use of CRYPTO_BUFFER_EXCEEDED for CRYPTO frame errors (#3258, #3186)<a href="#section-c.5-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.8">Define applicability and scope of NEW_TOKEN (#3150, #3152, #3155, #3156)<a href="#section-c.5-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.9">Tokens from Retry and NEW_TOKEN must be differentiated (#3127, #3128)<a href="#section-c.5-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.10">Allow CONNECTION_CLOSE in response to invalid token (#3168, #3107)<a href="#section-c.5-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.11">Treat an invalid CONNECTION_CLOSE as an invalid frame (#2475, #3230, #3231)<a href="#section-c.5-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.12">Throttle when sending CONNECTION_CLOSE after discarding state (#3095, #3157)<a href="#section-c.5-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.13">Application-variant of CONNECTION_CLOSE can only be sent in 0-RTT or 1-RTT
-packets (#3158, #3164)<a href="#section-c.5-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.14">Advise sending while blocked to avoid idle timeout (#2744, #3266)<a href="#section-c.5-1.14" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.15">Define error codes for invalid frames (#3027, #3042)<a href="#section-c.5-1.15" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.16">Idle timeout is symmetric (#2602, #3099)<a href="#section-c.5-1.16" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.17">Prohibit IP fragmentation (#3243, #3280)<a href="#section-c.5-1.17" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.18">Define the use of provisional registration for all registries (#3109, #3020,
-#3102, #3170)<a href="#section-c.5-1.18" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.5-1.19">Packets on one path must not adjust values for a different path (#2909,
-#3139)<a href="#section-c.5-1.19" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-23">
-<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-23</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.6-1.1">Allow ClientHello to span multiple packets (#2928, #3045)<a href="#section-c.6-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.2">Client Initial size constraints apply to UDP datagram payload (#3053, #3051)<a href="#section-c.6-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.3">
-            <p id="section-c.6-1.3.1">Stateless reset changes (#2152, #2993)<a href="#section-c.6-1.3.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.6-1.3.2.1">tokens need to be compared in constant time<a href="#section-c.6-1.3.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.6-1.3.2.2">detection uses UDP datagrams, not packets<a href="#section-c.6-1.3.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.6-1.3.2.3">tokens cannot be reused (#2785, #2968)<a href="#section-c.6-1.3.2.3" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.6-1.4">Clearer rules for sharing of UDP ports and use of connection IDs when doing so
-(#2844, #2851)<a href="#section-c.6-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.5">A new connection ID is necessary when responding to migration (#2778, #2969)<a href="#section-c.6-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.6">Stronger requirements for connection ID retirement (#3046, #3096)<a href="#section-c.6-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.7">NEW_TOKEN cannot be empty (#2978, #2977)<a href="#section-c.6-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.8">PING can be sent at any encryption level (#3034, #3035)<a href="#section-c.6-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.9">CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)<a href="#section-c.6-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.10">Frame encoding error conditions updated (#3027, #3042)<a href="#section-c.6-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.11">Non-ack-eliciting packets cannot be sent in response to non-ack-eliciting
-packets (#3100, #3104)<a href="#section-c.6-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.6-1.12">Servers have to change connection IDs in Retry (#2837, #3147)<a href="#section-c.6-1.12" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-22">
-<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-22</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.7-1.1">Rules for preventing correlation by connection ID tightened (#2084, #2929)<a href="#section-c.7-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.2">Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, #2541, #2688)<a href="#section-c.7-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.3">Discourage regressions of largest acknowledged in ACK (#2205, #2752)<a href="#section-c.7-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.4">Improved robustness of validation process for ECN counts (#2534, #2752)<a href="#section-c.7-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.5">Require endpoints to ignore spurious migration attempts (#2342, #2893)<a href="#section-c.7-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.6">Transport parameter for disabling migration clarified to allow NAT rebinding
-(#2389, #2893)<a href="#section-c.7-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.7">Document principles for defining new error codes (#2388, #2880)<a href="#section-c.7-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.8">Reserve transport parameters for greasing (#2550, #2873)<a href="#section-c.7-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.9">A maximum ACK delay of 0 is used for handshake packet number spaces (#2646,
-#2638)<a href="#section-c.7-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.10">Improved rules for use of congestion control state on new paths (#2685, #2918)<a href="#section-c.7-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.11">Removed recommendation to coordinate spin for multiple connections that share
-a path (#2763, #2882)<a href="#section-c.7-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-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.7-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.13">Provide guidance around the interface to QUIC as used by application protocols
-(#2805, #2857)<a href="#section-c.7-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.14">Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, #2826)<a href="#section-c.7-1.14" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.15">Tighter rules about processing of rejected 0-RTT packets (#2829, #2840, #2841)<a href="#section-c.7-1.15" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.16">Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)<a href="#section-c.7-1.16" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.17">Cryptographic handshake needs to provide server transport parameter encryption
-(#2920, #2921)<a href="#section-c.7-1.17" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.7-1.18">Moved ACK generation guidance from recovery draft to transport draft (#1860,
-#2916).<a href="#section-c.7-1.18" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-21">
-<section id="section-c.8">
-        <h2 id="name-since-draft-ietf-quic-transport-21">
-<a href="#section-c.8" class="section-number selfRef">C.8. </a><a href="#name-since-draft-ietf-quic-transport-21" class="section-name selfRef">Since draft-ietf-quic-transport-21</a>
-        </h2>
-<ul class="normal">
-<li class="normal" id="section-c.8-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.8-1.1" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-20">
-<section id="section-c.9">
-        <h2 id="name-since-draft-ietf-quic-transport-20">
-<a href="#section-c.9" class="section-number selfRef">C.9. </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.9-1.1">Error codes are encoded as variable-length integers (#2672, #2680)<a href="#section-c.9-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.2">NEW_CONNECTION_ID includes a request to retire old connection IDs (#2645,
-#2769)<a href="#section-c.9-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.3">Tighter rules for generating and explicitly eliciting ACK frames (#2546,
-#2794)<a href="#section-c.9-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.4">Recommend having only one packet per encryption level in a datagram (#2308,
-#2747)<a href="#section-c.9-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.5">More normative language about use of stateless reset (#2471, #2574)<a href="#section-c.9-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.6">Allow reuse of stateless reset tokens (#2732, #2733)<a href="#section-c.9-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.7">Allow, but not require, enforcing non-duplicate transport parameters (#2689,
-#2691)<a href="#section-c.9-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.8">Added an active_connection_id_limit transport parameter (#1994, #1998)<a href="#section-c.9-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.9">max_ack_delay transport parameter defaults to 0 (#2638, #2646)<a href="#section-c.9-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.10">When sending 0-RTT, only remembered transport parameters apply (#2458, #2360,
-#2466, #2461)<a href="#section-c.9-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.11">Define handshake completion and confirmation; define clearer rules when it
-encryption keys should be discarded (#2214, #2267, #2673)<a href="#section-c.9-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.12">Prohibit path migration prior to handshake confirmation (#2309, #2370)<a href="#section-c.9-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.13">PATH_RESPONSE no longer needs to be received on the validated path (#2582,
-#2580, #2579, #2637)<a href="#section-c.9-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.14">PATH_RESPONSE frames are not stored and retransmitted (#2724, #2729)<a href="#section-c.9-1.14" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.9-1.15">Document hack for enabling routing of ICMP when doing PMTU probing (#1243,
-#2402)<a href="#section-c.9-1.15" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-19">
-<section id="section-c.10">
-        <h2 id="name-since-draft-ietf-quic-transport-1">
-<a href="#section-c.10" class="section-number selfRef">C.10. </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.10-1.1">Refine discussion of 0-RTT transport parameters (#2467, #2464)<a href="#section-c.10-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.2">Fewer transport parameters need to be remembered for 0-RTT (#2624, #2467)<a href="#section-c.10-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.3">Spin bit text incorporated (#2564)<a href="#section-c.10-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.4">Close the connection when maximum stream ID in MAX_STREAMS exceeds 2^62 - 1
-(#2499, #2487)<a href="#section-c.10-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.5">New connection ID required for intentional migration (#2414, #2413)<a href="#section-c.10-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.6">Connection ID issuance can be rate-limited (#2436, #2428)<a href="#section-c.10-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.7">The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)<a href="#section-c.10-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-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.10-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.9">CRYPTO frames can be discarded if too much data is buffered (#1834, #2524)<a href="#section-c.10-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.10-1.10">Stateless reset uses a short header packet (#2599, #2600)<a href="#section-c.10-1.10" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-18">
-<section id="section-c.11">
-        <h2 id="name-since-draft-ietf-quic-transport-18">
-<a href="#section-c.11" class="section-number selfRef">C.11. </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.11-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.11-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.2">Added discussion of the use of IPv6 flow labels (#2348, #2399)<a href="#section-c.11-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.3">A connection ID can't be retired in a packet that uses that connection ID
-(#2101, #2420)<a href="#section-c.11-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.4">Idle timeout transport parameter is in milliseconds (from seconds) (#2453,
-#2454)<a href="#section-c.11-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.5">Endpoints are required to use new connection IDs when they use new network
-paths (#2413, #2414)<a href="#section-c.11-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.11-1.6">Increased the set of permissible frames in 0-RTT (#2344, #2355)<a href="#section-c.11-1.6" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-17">
-<section id="section-c.12">
-        <h2 id="name-since-draft-ietf-quic-transport-17">
-<a href="#section-c.12" class="section-number selfRef">C.12. </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.12-1.1">Stream-related errors now use STREAM_STATE_ERROR (#2305)<a href="#section-c.12-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.2">Endpoints discard initial keys as soon as handshake keys are available (#1951,
-#2045)<a href="#section-c.12-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.3">Expanded conditions for ignoring ICMP packet too big messages (#2108, #2161)<a href="#section-c.12-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.4">Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, #2241)<a href="#section-c.12-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.5">Endpoints are permitted to discard malformed initial packets (#2141)<a href="#section-c.12-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.6">Clarified ECN implementation and usage requirements (#2156, #2201)<a href="#section-c.12-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.7">Disable ECN count verification for packets that arrive out of order (#2198,
-#2215)<a href="#section-c.12-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.8">Use Probe Timeout (PTO) instead of RTO (#2206, #2238)<a href="#section-c.12-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.9">Loosen constraints on retransmission of ACK ranges (#2199, #2245)<a href="#section-c.12-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.10">Limit Retry and Version Negotiation to once per datagram (#2259, #2303)<a href="#section-c.12-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.11">Set a maximum value for max_ack_delay transport parameter (#2282, #2301)<a href="#section-c.12-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.12">Allow server preferred address for both IPv4 and IPv6 (#2122, #2296)<a href="#section-c.12-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.13">Corrected requirements for migration to a preferred address (#2146, #2349)<a href="#section-c.12-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.12-1.14">ACK of non-existent packet is illegal (#2298, #2302)<a href="#section-c.12-1.14" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-16">
-<section id="section-c.13">
-        <h2 id="name-since-draft-ietf-quic-transport-16">
-<a href="#section-c.13" class="section-number selfRef">C.13. </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.13-1.1">Stream limits are defined as counts, not maximums (#1850, #1906)<a href="#section-c.13-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.2">Require amplification attack defense after closing (#1905, #1911)<a href="#section-c.13-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.3">Remove reservation of application error code 0 for STOPPING (#1804, #1922)<a href="#section-c.13-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.4">Renumbered frames (#1945)<a href="#section-c.13-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.5">Renumbered transport parameters (#1946)<a href="#section-c.13-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.6">Numeric transport parameters are expressed as varints (#1608, #1947, #1955)<a href="#section-c.13-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.7">Reorder the NEW_CONNECTION_ID frame (#1952, #1963)<a href="#section-c.13-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.8">
-            <p id="section-c.13-1.8.1">Rework the first byte (#2006)<a href="#section-c.13-1.8.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.13-1.8.2.1">Fix the 0x40 bit<a href="#section-c.13-1.8.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.13-1.8.2.2">Change type values for long header<a href="#section-c.13-1.8.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.13-1.8.2.3">Add spin bit to short header (#631, #1988)<a href="#section-c.13-1.8.2.3" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.13-1.8.2.4">Encrypt the remainder of the first byte (#1322)<a href="#section-c.13-1.8.2.4" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.13-1.8.2.5">Move packet number length to first byte<a href="#section-c.13-1.8.2.5" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.13-1.8.2.6">Move ODCIL to first byte of retry packets<a href="#section-c.13-1.8.2.6" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.13-1.8.2.7">Simplify packet number protection (#1575)<a href="#section-c.13-1.8.2.7" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.13-1.9">Allow STOP_SENDING to open a remote bidirectional stream (#1797, #2013)<a href="#section-c.13-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.10">Added mitigation for off-path migration attacks (#1278, #1749, #2033)<a href="#section-c.13-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.11">Don't let the PMTU to drop below 1280 (#2063, #2069)<a href="#section-c.13-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.12">Require peers to replace retired connection IDs (#2085)<a href="#section-c.13-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.13">Servers are required to ignore Version Negotiation packets (#2088)<a href="#section-c.13-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.14">Tokens are repeated in all Initial packets (#2089)<a href="#section-c.13-1.14" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.15">Clarified how PING frames are sent after loss (#2094)<a href="#section-c.13-1.15" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.16">Initial keys are discarded once Handshake are available (#1951, #2045)<a href="#section-c.13-1.16" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.13-1.17">ICMP PTB validation clarifications (#2161, #2109, #2108)<a href="#section-c.13-1.17" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-15">
-<section id="section-c.14">
-        <h2 id="name-since-draft-ietf-quic-transport-15">
-<a href="#section-c.14" class="section-number selfRef">C.14. </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.14-1">Substantial editorial reorganization; no technical changes.<a href="#section-c.14-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-14">
-<section id="section-c.15">
-        <h2 id="name-since-draft-ietf-quic-transport-14">
-<a href="#section-c.15" class="section-number selfRef">C.15. </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.15-1.1">Merge ACK and ACK_ECN (#1778, #1801)<a href="#section-c.15-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.2">Explicitly communicate max_ack_delay (#981, #1781)<a href="#section-c.15-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.3">Validate original connection ID after Retry packets (#1710, #1486, #1793)<a href="#section-c.15-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.4">Idle timeout is optional and has no specified maximum (#1765)<a href="#section-c.15-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-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.15-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.6">Include a Token in all Initial packets (#1649, #1794)<a href="#section-c.15-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.15-1.7">Prevent handshake deadlock (#1764, #1824)<a href="#section-c.15-1.7" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-13">
-<section id="section-c.16">
-        <h2 id="name-since-draft-ietf-quic-transport-13">
-<a href="#section-c.16" class="section-number selfRef">C.16. </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.16-1.1">Streams open when higher-numbered streams of the same type open (#1342, #1549)<a href="#section-c.16-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.2">Split initial stream flow control limit into 3 transport parameters (#1016,
-#1542)<a href="#section-c.16-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.3">All flow control transport parameters are optional (#1610)<a href="#section-c.16-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.4">Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)<a href="#section-c.16-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.5">Permit stateless reset in response to any packet (#1348, #1553)<a href="#section-c.16-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.6">Recommended defense against stateless reset spoofing (#1386, #1554)<a href="#section-c.16-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.7">Prevent infinite stateless reset exchanges (#1443, #1627)<a href="#section-c.16-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.8">Forbid processing of the same packet number twice (#1405, #1624)<a href="#section-c.16-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.9">Added a packet number decoding example (#1493)<a href="#section-c.16-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.10">More precisely define idle timeout (#1429, #1614, #1652)<a href="#section-c.16-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.11">Corrected format of Retry packet and prevented looping (#1492, #1451, #1448,
-#1498)<a href="#section-c.16-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.12">Permit 0-RTT after receiving Version Negotiation or Retry (#1507, #1514,
-#1621)<a href="#section-c.16-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.13">Permit Retry in response to 0-RTT (#1547, #1552)<a href="#section-c.16-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.14">Looser verification of ECN counters to account for ACK loss (#1555, #1481,
-#1565)<a href="#section-c.16-1.14" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.16-1.15">Remove frame type field from APPLICATION_CLOSE (#1508, #1528)<a href="#section-c.16-1.15" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-12">
-<section id="section-c.17">
-        <h2 id="name-since-draft-ietf-quic-transport-12">
-<a href="#section-c.17" class="section-number selfRef">C.17. </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.17-1.1">
-            <p id="section-c.17-1.1.1">Changes to integration of the TLS handshake (#829, #1018, #1094, #1165, #1190,
-#1233, #1242, #1252, #1450, #1458)<a href="#section-c.17-1.1.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.17-1.1.2.1">The cryptographic handshake uses CRYPTO frames, not stream 0<a href="#section-c.17-1.1.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.17-1.1.2.2">QUIC packet protection is used in place of TLS record protection<a href="#section-c.17-1.1.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.17-1.1.2.3">Separate QUIC packet number spaces are used for the handshake<a href="#section-c.17-1.1.2.3" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.17-1.1.2.4">Changed Retry to be independent of the cryptographic handshake<a href="#section-c.17-1.1.2.4" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.17-1.1.2.5">Added NEW_TOKEN frame and Token fields to Initial packet<a href="#section-c.17-1.1.2.5" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.17-1.1.2.6">Limit the use of HelloRetryRequest to address TLS needs (like key shares)<a href="#section-c.17-1.1.2.6" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.17-1.2">Enable server to transition connections to a preferred address (#560, #1251,
-#1373)<a href="#section-c.17-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.17-1.3">Added ECN feedback mechanisms and handling; new ACK_ECN frame (#804, #805,
-#1372)<a href="#section-c.17-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.17-1.4">Changed rules and recommendations for use of new connection IDs (#1258, #1264,
-#1276, #1280, #1419, #1452, #1453, #1465)<a href="#section-c.17-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.17-1.5">Added a transport parameter to disable intentional connection migration
-(#1271, #1447)<a href="#section-c.17-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.17-1.6">Packets from different connection ID can't be coalesced (#1287, #1423)<a href="#section-c.17-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.17-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.17-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.17-1.8">Stateless Reset is now symmetric and subject to size constraints (#466, #1346)<a href="#section-c.17-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.17-1.9">Added frame type extension mechanism (#58, #1473)<a href="#section-c.17-1.9" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-11">
-<section id="section-c.18">
-        <h2 id="name-since-draft-ietf-quic-transport-11">
-<a href="#section-c.18" class="section-number selfRef">C.18. </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.18-1.1">Enable server to transition connections to a preferred address (#560, #1251)<a href="#section-c.18-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.2">Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, #990, #734,
-#1317, #1267, #1079)<a href="#section-c.18-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.3">Packet numbers use a variable-length encoding (#989, #1334)<a href="#section-c.18-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.18-1.4">STREAM frames can now be empty (#1350)<a href="#section-c.18-1.4" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-10">
-<section id="section-c.19">
-        <h2 id="name-since-draft-ietf-quic-transport-10">
-<a href="#section-c.19" class="section-number selfRef">C.19. </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.19-1.1">Swap payload length and packed number fields in long header (#1294)<a href="#section-c.19-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.2">Clarified that CONNECTION_CLOSE is allowed in Handshake packet (#1274)<a href="#section-c.19-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.3">Spin bit reserved (#1283)<a href="#section-c.19-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.4">Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)<a href="#section-c.19-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.5">A more complete connection migration (#1249)<a href="#section-c.19-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.6">Refine opportunistic ACK defense text (#305, #1030, #1185)<a href="#section-c.19-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.7">A Stateless Reset Token isn't mandatory (#818, #1191)<a href="#section-c.19-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.8">Removed implicit stream opening (#896, #1193)<a href="#section-c.19-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.9">An empty STREAM frame can be used to open a stream without sending data (#901,
-#1194)<a href="#section-c.19-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.10">Define stream counts in transport parameters rather than a maximum stream ID
-(#1023, #1065)<a href="#section-c.19-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.11">STOP_SENDING is now prohibited before streams are used (#1050)<a href="#section-c.19-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.12">Recommend including ACK in Retry packets and allow PADDING (#1067, #882)<a href="#section-c.19-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.13">Endpoints now become closing after an idle timeout (#1178, #1179)<a href="#section-c.19-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.19-1.14">Remove implication that Version Negotiation is sent when a packet of the wrong
-version is received (#1197)<a href="#section-c.19-1.14" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-09">
-<section id="section-c.20">
-        <h2 id="name-since-draft-ietf-quic-transport-0">
-<a href="#section-c.20" class="section-number selfRef">C.20. </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.20-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.20-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.20-1.2">A server can now only send 3 packets without validating the client address
-(#38, #1090)<a href="#section-c.20-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.20-1.3">Delivery order of stream data is no longer strongly specified (#252, #1070)<a href="#section-c.20-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.20-1.4">Rework of packet handling and version negotiation (#1038)<a href="#section-c.20-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.20-1.5">Stream 0 is now exempt from flow control until the handshake completes (#1074,
-#725, #825, #1082)<a href="#section-c.20-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.20-1.6">Improved retransmission rules for all frame types: information is
-retransmitted, not packets or frames (#463, #765, #1095, #1053)<a href="#section-c.20-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.20-1.7">Added an error code for server busy signals (#1137)<a href="#section-c.20-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.20-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.20-1.8" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-08">
-<section id="section-c.21">
-        <h2 id="name-since-draft-ietf-quic-transport-08">
-<a href="#section-c.21" class="section-number selfRef">C.21. </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.21-1.1">Clarified requirements for BLOCKED usage (#65,  #924)<a href="#section-c.21-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.2">BLOCKED frame now includes reason for blocking (#452, #924, #927, #928)<a href="#section-c.21-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.3">GAP limitation in ACK Frame (#613)<a href="#section-c.21-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.4">Improved PMTUD description (#614, #1036)<a href="#section-c.21-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.5">Clarified stream state machine (#634, #662, #743, #894)<a href="#section-c.21-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.6">Reserved versions don't need to be generated deterministically (#831, #931)<a href="#section-c.21-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.7">You don't always need the draining period (#871)<a href="#section-c.21-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.8">Stateless reset clarified as version-specific (#930, #986)<a href="#section-c.21-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.9">initial_max_stream_id_x transport parameters are optional (#970, #971)<a href="#section-c.21-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.10">ACK delay assumes a default value during the handshake (#1007, #1009)<a href="#section-c.21-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.21-1.11">Removed transport parameters from NewSessionTicket (#1015)<a href="#section-c.21-1.11" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-07">
-<section id="section-c.22">
-        <h2 id="name-since-draft-ietf-quic-transport-07">
-<a href="#section-c.22" class="section-number selfRef">C.22. </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.22-1.1">The long header now has version before packet number (#926, #939)<a href="#section-c.22-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.2">Rename and consolidate packet types (#846, #822, #847)<a href="#section-c.22-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.3">Packet types are assigned new codepoints and the Connection ID Flag is
-inverted (#426, #956)<a href="#section-c.22-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.4">Removed type for Version Negotiation and use Version 0 (#963, #968)<a href="#section-c.22-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.5">
-            <p id="section-c.22-1.5.1">Streams are split into unidirectional and bidirectional (#643, #656, #720,
-#872, #175, #885)<a href="#section-c.22-1.5.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.22-1.5.2.1">Stream limits now have separate uni- and bi-directional transport parameters
-(#909, #958)<a href="#section-c.22-1.5.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.22-1.5.2.2">Stream limit transport parameters are now optional and default to 0 (#970,
-#971)<a href="#section-c.22-1.5.2.2" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.22-1.6">The stream state machine has been split into read and write (#634, #894)<a href="#section-c.22-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.7">Employ variable-length integer encodings throughout (#595)<a href="#section-c.22-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.8">
-            <p id="section-c.22-1.8.1">Improvements to connection close<a href="#section-c.22-1.8.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.22-1.8.2.1">Added distinct closing and draining states (#899, #871)<a href="#section-c.22-1.8.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.22-1.8.2.2">Draining period can terminate early (#869, #870)<a href="#section-c.22-1.8.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.22-1.8.2.3">Clarifications about stateless reset (#889, #890)<a href="#section-c.22-1.8.2.3" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.22-1.9">Address validation for connection migration (#161, #732, #878)<a href="#section-c.22-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.10">Clearly defined retransmission rules for BLOCKED (#452, #65, #924)<a href="#section-c.22-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.11">negotiated_version is sent in server transport parameters (#710, #959)<a href="#section-c.22-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.22-1.12">Increased the range over which packet numbers are randomized (#864, #850,
-#964)<a href="#section-c.22-1.12" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-06">
-<section id="section-c.23">
-        <h2 id="name-since-draft-ietf-quic-transport-06">
-<a href="#section-c.23" class="section-number selfRef">C.23. </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.23-1.1">Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)<a href="#section-c.23-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.23-1.2">Split error code space between application and transport (#485)<a href="#section-c.23-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.23-1.3">Stateless reset token moved to end (#820)<a href="#section-c.23-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.23-1.4">1-RTT-protected long header types removed (#848)<a href="#section-c.23-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.23-1.5">No acknowledgments during draining period (#852)<a href="#section-c.23-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.23-1.6">Remove "application close" as a separate close type (#854)<a href="#section-c.23-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.23-1.7">Remove timestamps from the ACK frame (#841)<a href="#section-c.23-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.23-1.8">Require transport parameters to only appear once (#792)<a href="#section-c.23-1.8" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-05">
-<section id="section-c.24">
-        <h2 id="name-since-draft-ietf-quic-transport-05">
-<a href="#section-c.24" class="section-number selfRef">C.24. </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.24-1.1">Stateless token is server-only (#726)<a href="#section-c.24-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.2">Refactor section on connection termination (#733, #748, #328, #177)<a href="#section-c.24-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.3">Limit size of Version Negotiation packet (#585)<a href="#section-c.24-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.4">Clarify when and what to ack (#736)<a href="#section-c.24-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.5">Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED<a href="#section-c.24-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.24-1.6">Clarify Keep-alive requirements (#729)<a href="#section-c.24-1.6" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-04">
-<section id="section-c.25">
-        <h2 id="name-since-draft-ietf-quic-transport-04">
-<a href="#section-c.25" class="section-number selfRef">C.25. </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.25-1.1">Introduce STOP_SENDING frame, RESET_STREAM only resets in one direction (#165)<a href="#section-c.25-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.2">Removed GOAWAY; application protocols are responsible for graceful shutdown
-(#696)<a href="#section-c.25-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.3">Reduced the number of error codes (#96, #177, #184, #211)<a href="#section-c.25-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.4">Version validation fields can't move or change (#121)<a href="#section-c.25-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.5">Removed versions from the transport parameters in a NewSessionTicket message
-(#547)<a href="#section-c.25-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.6">Clarify the meaning of "bytes in flight" (#550)<a href="#section-c.25-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.7">Public reset is now stateless reset and not visible to the path (#215)<a href="#section-c.25-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.8">Reordered bits and fields in STREAM frame (#620)<a href="#section-c.25-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.9">Clarifications to the stream state machine (#572, #571)<a href="#section-c.25-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.10">Increased the maximum length of the Largest Acknowledged field in ACK frames
-to 64 bits (#629)<a href="#section-c.25-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.11">truncate_connection_id is renamed to omit_connection_id (#659)<a href="#section-c.25-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.12">CONNECTION_CLOSE terminates the connection like TCP RST (#330, #328)<a href="#section-c.25-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.25-1.13">Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)<a href="#section-c.25-1.13" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-03">
-<section id="section-c.26">
-        <h2 id="name-since-draft-ietf-quic-transport-03">
-<a href="#section-c.26" class="section-number selfRef">C.26. </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.26-1.1">Change STREAM and RESET_STREAM layout<a href="#section-c.26-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.26-1.2">Add MAX_STREAM_ID settings<a href="#section-c.26-1.2" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-02">
-<section id="section-c.27">
-        <h2 id="name-since-draft-ietf-quic-transport-02">
-<a href="#section-c.27" class="section-number selfRef">C.27. </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.27-1.1">The size of the initial packet payload has a fixed minimum (#267, #472)<a href="#section-c.27-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.2">Define when Version Negotiation packets are ignored (#284, #294, #241, #143,
-#474)<a href="#section-c.27-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.3">The 64-bit FNV-1a algorithm is used for integrity protection of unprotected
-packets (#167, #480, #481, #517)<a href="#section-c.27-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.4">Rework initial packet types to change how the connection ID is chosen (#482,
-#442, #493)<a href="#section-c.27-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.5">No timestamps are forbidden in unprotected packets (#542, #429)<a href="#section-c.27-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.6">Cryptographic handshake is now on stream 0 (#456)<a href="#section-c.27-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.7">Remove congestion control exemption for cryptographic handshake (#248, #476)<a href="#section-c.27-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.8">Version 1 of QUIC uses TLS; a new version is needed to use a different
-handshake protocol (#516)<a href="#section-c.27-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.9">STREAM frames have a reduced number of offset lengths (#543, #430)<a href="#section-c.27-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.10">
-            <p id="section-c.27-1.10.1">Split some frames into separate connection- and stream- level frames
-(#443)<a href="#section-c.27-1.10.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.27-1.10.2.1">WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)<a href="#section-c.27-1.10.2.1" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.27-1.10.2.2">BLOCKED split to match WINDOW_UPDATE split (#454)<a href="#section-c.27-1.10.2.2" class="pilcrow">¶</a>
-</li>
-              <li class="normal" id="section-c.27-1.10.2.3">Define STREAM_ID_NEEDED frame (#455)<a href="#section-c.27-1.10.2.3" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.27-1.11">A NEW_CONNECTION_ID frame supports connection migration without linkability
-(#232, #491, #496)<a href="#section-c.27-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.27-1.12">
-            <p id="section-c.27-1.12.1">Transport parameters for 0-RTT are retained from a previous connection (#405,
-#513, #512)<a href="#section-c.27-1.12.1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-c.27-1.12.2.1">A client in 0-RTT no longer required to reset excess streams (#425, #479)<a href="#section-c.27-1.12.2.1" class="pilcrow">¶</a>
-</li>
-            </ul>
-</li>
-          <li class="normal" id="section-c.27-1.13">Expanded security considerations (#440, #444, #445, #448)<a href="#section-c.27-1.13" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-01">
-<section id="section-c.28">
-        <h2 id="name-since-draft-ietf-quic-transport-01">
-<a href="#section-c.28" class="section-number selfRef">C.28. </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.28-1.1">Defined short and long packet headers (#40, #148, #361)<a href="#section-c.28-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.2">Defined a versioning scheme and stable fields (#51, #361)<a href="#section-c.28-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.3">Define reserved version values for "greasing" negotiation (#112, #278)<a href="#section-c.28-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.4">The initial packet number is randomized (#35, #283)<a href="#section-c.28-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.5">Narrow the packet number encoding range requirement (#67, #286, #299, #323,
-#356)<a href="#section-c.28-1.5" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.6">Defined client address validation (#52, #118, #120, #275)<a href="#section-c.28-1.6" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.7">Define transport parameters as a TLS extension (#49, #122)<a href="#section-c.28-1.7" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.8">SCUP and COPT parameters are no longer valid (#116, #117)<a href="#section-c.28-1.8" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.9">Transport parameters for 0-RTT are either remembered from before, or assume
-default values (#126)<a href="#section-c.28-1.9" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.10">The server chooses connection IDs in its final flight (#119, #349, #361)<a href="#section-c.28-1.10" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-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.28-1.11" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.12">Defined a minimum packet size for the initial handshake packet from the client
-(#69, #136, #139, #164)<a href="#section-c.28-1.12" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.13">Path MTU Discovery (#64, #106)<a href="#section-c.28-1.13" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.14">The initial handshake packet from the client needs to fit in a single packet
-(#338)<a href="#section-c.28-1.14" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.15">Forbid acknowledgment of packets containing only ACK and PADDING (#291)<a href="#section-c.28-1.15" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.16">Require that frames are processed when packets are acknowledged (#381, #341)<a href="#section-c.28-1.16" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.17">Removed the STOP_WAITING frame (#66)<a href="#section-c.28-1.17" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.18">Don't require retransmission of old timestamps for lost ACK frames (#308)<a href="#section-c.28-1.18" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.19">Clarified that frames are not retransmitted, but the information in them can
-be (#157, #298)<a href="#section-c.28-1.19" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.20">Error handling definitions (#335)<a href="#section-c.28-1.20" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.21">Split error codes into four sections (#74)<a href="#section-c.28-1.21" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.22">Forbid the use of Public Reset where CONNECTION_CLOSE is possible (#289)<a href="#section-c.28-1.22" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.23">Define packet protection rules (#336)<a href="#section-c.28-1.23" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-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.28-1.24" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.25">Remove stream reservation from state machine (#174, #280)<a href="#section-c.28-1.25" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.26">Only stream 1 does not contribute to connection-level flow control (#204)<a href="#section-c.28-1.26" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.27">Stream 1 counts towards the maximum concurrent stream limit (#201, #282)<a href="#section-c.28-1.27" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.28">Remove connection-level flow control exclusion for some streams (except 1)
-(#246)<a href="#section-c.28-1.28" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.29">RESET_STREAM affects connection-level flow control (#162, #163)<a href="#section-c.28-1.29" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.30">Flow control accounting uses the maximum data offset on each stream, rather
-than bytes received (#378)<a href="#section-c.28-1.30" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.31">Moved length-determining fields to the start of STREAM and ACK (#168, #277)<a href="#section-c.28-1.31" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.32">Added the ability to pad between frames (#158, #276)<a href="#section-c.28-1.32" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.33">Remove error code and reason phrase from GOAWAY (#352, #355)<a href="#section-c.28-1.33" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.34">GOAWAY includes a final stream number for both directions (#347)<a href="#section-c.28-1.34" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.35">Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a consistent
-offset (#249)<a href="#section-c.28-1.35" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.28-1.36">Defined priority as the responsibility of the application protocol (#104,
-#303)<a href="#section-c.28-1.36" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-ietf-quic-transport-00">
-<section id="section-c.29">
-        <h2 id="name-since-draft-ietf-quic-transport-00">
-<a href="#section-c.29" class="section-number selfRef">C.29. </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.29-1.1">Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag<a href="#section-c.29-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.29-1.2">Defined versioning<a href="#section-c.29-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.29-1.3">Reworked description of packet and frame layout<a href="#section-c.29-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.29-1.4">Error code space is divided into regions for each component<a href="#section-c.29-1.4" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.29-1.5">Use big endian for all numeric values<a href="#section-c.29-1.5" class="pilcrow">¶</a>
-</li>
-        </ul>
-</section>
-</div>
-<div id="since-draft-hamilton-quic-transport-protocol-01">
-<section id="section-c.30">
-        <h2 id="name-since-draft-hamilton-quic-t">
-<a href="#section-c.30" class="section-number selfRef">C.30. </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.30-1.1">Adopted as base for draft-ietf-quic-tls<a href="#section-c.30-1.1" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.30-1.2">Updated authors/editors list<a href="#section-c.30-1.2" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.30-1.3">Added IANA Considerations section<a href="#section-c.30-1.3" class="pilcrow">¶</a>
-</li>
-          <li class="normal" id="section-c.30-1.4">Moved Contributors and Acknowledgments to appendices<a href="#section-c.30-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/split-initial-close/draft-ietf-quic-transport.txt b/split-initial-close/draft-ietf-quic-transport.txt
deleted file mode 100644
index 16c471e59e..0000000000
--- a/split-initial-close/draft-ietf-quic-transport.txt
+++ /dev/null
@@ -1,10584 +0,0 @@
-
-
-
-
-QUIC                                                     J. Iyengar, Ed.
-Internet-Draft                                                    Fastly
-Intended status: Standards Track                         M. Thomson, Ed.
-Expires: 18 February 2021                                        Mozilla
-                                                          17 August 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 18 February 2021.
-
-Copyright Notice
-
-   Copyright (c) 2020 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 1]
-
-Internet-Draft           QUIC Transport Protocol             August 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.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
-     1.1.  Document Structure  . . . . . . . . . . . . . . . . . . .   7
-     1.2.  Terms and Definitions . . . . . . . . . . . . . . . . . .   9
-     1.3.  Notational Conventions  . . . . . . . . . . . . . . . . .  10
-   2.  Streams . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
-     2.1.  Stream Types and Identifiers  . . . . . . . . . . . . . .  11
-     2.2.  Sending and Receiving Data  . . . . . . . . . . . . . . .  12
-     2.3.  Stream Prioritization . . . . . . . . . . . . . . . . . .  13
-     2.4.  Required Operations on Streams  . . . . . . . . . . . . .  13
-   3.  Stream States . . . . . . . . . . . . . . . . . . . . . . . .  14
-     3.1.  Sending Stream States . . . . . . . . . . . . . . . . . .  15
-     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  . . . . . . . . . . . . . . . . . . . . . . . .  22
-     4.1.  Data Flow Control . . . . . . . . . . . . . . . . . . . .  23
-     4.2.  Increasing Flow Control Limits  . . . . . . . . . . . . .  24
-     4.3.  Handling Stream Cancellation  . . . . . . . . . . . . . .  25
-     4.4.  Stream Final Size . . . . . . . . . . . . . . . . . . . .  25
-     4.5.  Controlling Concurrency . . . . . . . . . . . . . . . . .  26
-     4.6.  Flow Control Performance  . . . . . . . . . . . . . . . .  27
-   5.  Connections . . . . . . . . . . . . . . . . . . . . . . . . .  27
-     5.1.  Connection ID . . . . . . . . . . . . . . . . . . . . . .  28
-       5.1.1.  Issuing Connection IDs  . . . . . . . . . . . . . . .  29
-       5.1.2.  Consuming and Retiring Connection IDs . . . . . . . .  30
-     5.2.  Matching Packets to Connections . . . . . . . . . . . . .  32
-       5.2.1.  Client Packet Handling  . . . . . . . . . . . . . . .  32
-       5.2.2.  Server Packet Handling  . . . . . . . . . . . . . . .  33
-       5.2.3.  Considerations for Simple Load Balancers  . . . . . .  34
-     5.3.  Required Operations on Connections  . . . . . . . . . . .  34
-   6.  Version Negotiation . . . . . . . . . . . . . . . . . . . . .  35
-     6.1.  Sending Version Negotiation Packets . . . . . . . . . . .  36
-     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 18 February 2021                [Page 2]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-     7.1.  Example Handshake Flows . . . . . . . . . . . . . . . . .  39
-     7.2.  Negotiating Connection IDs  . . . . . . . . . . . . . . .  40
-     7.3.  Authenticating Connection IDs . . . . . . . . . . . . . .  41
-     7.4.  Transport Parameters  . . . . . . . . . . . . . . . . . .  43
-       7.4.1.  Values of Transport Parameters for 0-RTT  . . . . . .  44
-       7.4.2.  New Transport Parameters  . . . . . . . . . . . . . .  46
-     7.5.  Cryptographic Message Buffering . . . . . . . . . . . . .  46
-   8.  Address Validation  . . . . . . . . . . . . . . . . . . . . .  47
-     8.1.  Address Validation During Connection Establishment  . . .  47
-       8.1.1.  Token Construction  . . . . . . . . . . . . . . . . .  48
-       8.1.2.  Address Validation using Retry Packets  . . . . . . .  49
-       8.1.3.  Address Validation for Future Connections . . . . . .  50
-       8.1.4.  Address Validation Token Integrity  . . . . . . . . .  52
-     8.2.  Path Validation . . . . . . . . . . . . . . . . . . . . .  53
-     8.3.  Initiating Path Validation  . . . . . . . . . . . . . . .  54
-     8.4.  Path Validation Responses . . . . . . . . . . . . . . . .  54
-     8.5.  Successful Path Validation  . . . . . . . . . . . . . . .  54
-     8.6.  Failed Path Validation  . . . . . . . . . . . . . . . . .  54
-   9.  Connection Migration  . . . . . . . . . . . . . . . . . . . .  55
-     9.1.  Probing a New Path  . . . . . . . . . . . . . . . . . . .  56
-     9.2.  Initiating Connection Migration . . . . . . . . . . . . .  56
-     9.3.  Responding to Connection Migration  . . . . . . . . . . .  57
-       9.3.1.  Peer Address Spoofing . . . . . . . . . . . . . . . .  58
-       9.3.2.  On-Path Address Spoofing  . . . . . . . . . . . . . .  58
-       9.3.3.  Off-Path Packet Forwarding  . . . . . . . . . . . . .  59
-     9.4.  Loss Detection and Congestion Control . . . . . . . . . .  60
-     9.5.  Privacy Implications of Connection Migration  . . . . . .  61
-     9.6.  Server's Preferred Address  . . . . . . . . . . . . . . .  62
-       9.6.1.  Communicating a Preferred Address . . . . . . . . . .  62
-       9.6.2.  Responding to Connection Migration  . . . . . . . . .  63
-       9.6.3.  Interaction of Client Migration and Preferred
-               Address . . . . . . . . . . . . . . . . . . . . . . .  63
-     9.7.  Use of IPv6 Flow-Label and Migration  . . . . . . . . . .  64
-   10. Connection Termination  . . . . . . . . . . . . . . . . . . .  64
-     10.1.  Idle Timeout . . . . . . . . . . . . . . . . . . . . . .  65
-       10.1.1.  Liveness Testing . . . . . . . . . . . . . . . . . .  65
-       10.1.2.  Deferring Idle Timeout . . . . . . . . . . . . . . .  66
-     10.2.  Immediate Close  . . . . . . . . . . . . . . . . . . . .  66
-       10.2.1.  Immediate Close During the Handshake . . . . . . . .  68
-     10.3.  Stateless Reset  . . . . . . . . . . . . . . . . . . . .  69
-       10.3.1.  Detecting a Stateless Reset  . . . . . . . . . . . .  72
-       10.3.2.  Calculating a Stateless Reset Token  . . . . . . . .  73
-       10.3.3.  Looping  . . . . . . . . . . . . . . . . . . . . . .  74
-     10.4.  Closing and Draining Connection States . . . . . . . . .  74
-   11. Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  76
-     11.1.  Connection Errors  . . . . . . . . . . . . . . . . . . .  76
-     11.2.  Stream Errors  . . . . . . . . . . . . . . . . . . . . .  77
-   12. Packets and Frames  . . . . . . . . . . . . . . . . . . . . .  77
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 3]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-     12.1.  Protected Packets  . . . . . . . . . . . . . . . . . . .  78
-     12.2.  Coalescing Packets . . . . . . . . . . . . . . . . . . .  78
-     12.3.  Packet Numbers . . . . . . . . . . . . . . . . . . . . .  79
-     12.4.  Frames and Frame Types . . . . . . . . . . . . . . . . .  81
-   13. Packetization and Reliability . . . . . . . . . . . . . . . .  85
-     13.1.  Packet Processing  . . . . . . . . . . . . . . . . . . .  85
-     13.2.  Generating Acknowledgements  . . . . . . . . . . . . . .  86
-       13.2.1.  Sending ACK Frames . . . . . . . . . . . . . . . . .  86
-       13.2.2.  Acknowledgement Frequency  . . . . . . . . . . . . .  87
-       13.2.3.  Managing ACK Ranges  . . . . . . . . . . . . . . . .  88
-       13.2.4.  Limiting Ranges by Tracking ACK Frames . . . . . . .  89
-       13.2.5.  Measuring and Reporting Host Delay . . . . . . . . .  90
-       13.2.6.  ACK Frames and Packet Protection . . . . . . . . . .  90
-       13.2.7.  PADDING Frames Consume Congestion Window . . . . . .  90
-     13.3.  Retransmission of Information  . . . . . . . . . . . . .  91
-     13.4.  Explicit Congestion Notification . . . . . . . . . . . .  93
-       13.4.1.  ECN Counts . . . . . . . . . . . . . . . . . . . . .  94
-       13.4.2.  ECN Validation . . . . . . . . . . . . . . . . . . .  94
-   14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . .  96
-     14.1.  Initial Packet Size  . . . . . . . . . . . . . . . . . .  97
-     14.2.  Path Maximum Transmission Unit . . . . . . . . . . . . .  98
-       14.2.1.  Handling of ICMP Messages by PMTUD . . . . . . . . .  98
-     14.3.  Datagram Packetization Layer PMTU Discovery  . . . . . .  99
-       14.3.1.  DPLPMTUD and Initial Connectivity  . . . . . . . . .  99
-       14.3.2.  Validating the QUIC Path with DPLPMTUD . . . . . . . 100
-       14.3.3.  Handling of ICMP Messages by DPLPMTUD  . . . . . . . 100
-     14.4.  Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 100
-       14.4.1.  PMTU Probes Containing Source Connection ID  . . . . 100
-   15. Versions  . . . . . . . . . . . . . . . . . . . . . . . . . . 101
-   16. Variable-Length Integer Encoding  . . . . . . . . . . . . . . 102
-   17. Packet Formats  . . . . . . . . . . . . . . . . . . . . . . . 103
-     17.1.  Packet Number Encoding and Decoding  . . . . . . . . . . 103
-     17.2.  Long Header Packets  . . . . . . . . . . . . . . . . . . 104
-       17.2.1.  Version Negotiation Packet . . . . . . . . . . . . . 107
-       17.2.2.  Initial Packet . . . . . . . . . . . . . . . . . . . 108
-       17.2.3.  0-RTT  . . . . . . . . . . . . . . . . . . . . . . . 110
-       17.2.4.  Handshake Packet . . . . . . . . . . . . . . . . . . 111
-       17.2.5.  Retry Packet . . . . . . . . . . . . . . . . . . . . 112
-     17.3.  Short Header Packets . . . . . . . . . . . . . . . . . . 115
-       17.3.1.  Latency Spin Bit . . . . . . . . . . . . . . . . . . 117
-   18. Transport Parameter Encoding  . . . . . . . . . . . . . . . . 118
-     18.1.  Reserved Transport Parameters  . . . . . . . . . . . . . 118
-     18.2.  Transport Parameter Definitions  . . . . . . . . . . . . 119
-   19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 123
-     19.1.  PADDING Frames . . . . . . . . . . . . . . . . . . . . . 123
-     19.2.  PING Frames  . . . . . . . . . . . . . . . . . . . . . . 123
-     19.3.  ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 124
-       19.3.1.  ACK Ranges . . . . . . . . . . . . . . . . . . . . . 125
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 4]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-       19.3.2.  ECN Counts . . . . . . . . . . . . . . . . . . . . . 127
-     19.4.  RESET_STREAM Frames  . . . . . . . . . . . . . . . . . . 127
-     19.5.  STOP_SENDING Frames  . . . . . . . . . . . . . . . . . . 128
-     19.6.  CRYPTO Frames  . . . . . . . . . . . . . . . . . . . . . 129
-     19.7.  NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 130
-     19.8.  STREAM Frames  . . . . . . . . . . . . . . . . . . . . . 130
-     19.9.  MAX_DATA Frames  . . . . . . . . . . . . . . . . . . . . 132
-     19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 132
-     19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 133
-     19.12. DATA_BLOCKED Frames  . . . . . . . . . . . . . . . . . . 134
-     19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 135
-     19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 135
-     19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 136
-     19.16. RETIRE_CONNECTION_ID Frames  . . . . . . . . . . . . . . 138
-     19.17. PATH_CHALLENGE Frames  . . . . . . . . . . . . . . . . . 139
-     19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 139
-     19.19. CONNECTION_CLOSE Frames  . . . . . . . . . . . . . . . . 140
-     19.20. HANDSHAKE_DONE Frames  . . . . . . . . . . . . . . . . . 141
-     19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 141
-   20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 142
-     20.1.  Transport Error Codes  . . . . . . . . . . . . . . . . . 142
-     20.2.  Application Protocol Error Codes . . . . . . . . . . . . 144
-   21. Security Considerations . . . . . . . . . . . . . . . . . . . 144
-     21.1.  Handshake Denial of Service  . . . . . . . . . . . . . . 144
-     21.2.  Amplification Attack . . . . . . . . . . . . . . . . . . 145
-     21.3.  Optimistic ACK Attack  . . . . . . . . . . . . . . . . . 145
-     21.4.  Slowloris Attacks  . . . . . . . . . . . . . . . . . . . 146
-     21.5.  Stream Fragmentation and Reassembly Attacks  . . . . . . 146
-     21.6.  Stream Commitment Attack . . . . . . . . . . . . . . . . 146
-     21.7.  Peer Denial of Service . . . . . . . . . . . . . . . . . 147
-     21.8.  Explicit Congestion Notification Attacks . . . . . . . . 147
-     21.9.  Stateless Reset Oracle . . . . . . . . . . . . . . . . . 148
-     21.10. Version Downgrade  . . . . . . . . . . . . . . . . . . . 149
-     21.11. Targeted Attacks by Routing  . . . . . . . . . . . . . . 149
-     21.12. Overview of Security Properties  . . . . . . . . . . . . 149
-       21.12.1.  Handshake . . . . . . . . . . . . . . . . . . . . . 150
-       21.12.2.  Protected Packets . . . . . . . . . . . . . . . . . 151
-       21.12.3.  Connection Migration  . . . . . . . . . . . . . . . 152
-   22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 156
-     22.1.  Registration Policies for QUIC Registries  . . . . . . . 156
-       22.1.1.  Provisional Registrations  . . . . . . . . . . . . . 156
-       22.1.2.  Selecting Codepoints . . . . . . . . . . . . . . . . 157
-       22.1.3.  Reclaiming Provisional Codepoints  . . . . . . . . . 158
-       22.1.4.  Permanent Registrations  . . . . . . . . . . . . . . 159
-     22.2.  QUIC Transport Parameter Registry  . . . . . . . . . . . 159
-     22.3.  QUIC Frame Types Registry  . . . . . . . . . . . . . . . 160
-     22.4.  QUIC Transport Error Codes Registry  . . . . . . . . . . 161
-   23. References  . . . . . . . . . . . . . . . . . . . . . . . . . 163
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 5]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-     23.1.  Normative References . . . . . . . . . . . . . . . . . . 163
-     23.2.  Informative References . . . . . . . . . . . . . . . . . 164
-   Appendix A.  Sample Packet Number Decoding Algorithm  . . . . . . 167
-   Appendix B.  Sample ECN Validation Algorithm  . . . . . . . . . . 167
-   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . . 168
-     C.1.  Since draft-ietf-quic-transport-28  . . . . . . . . . . . 168
-     C.2.  Since draft-ietf-quic-transport-27  . . . . . . . . . . . 169
-     C.3.  Since draft-ietf-quic-transport-26  . . . . . . . . . . . 170
-     C.4.  Since draft-ietf-quic-transport-25  . . . . . . . . . . . 170
-     C.5.  Since draft-ietf-quic-transport-24  . . . . . . . . . . . 170
-     C.6.  Since draft-ietf-quic-transport-23  . . . . . . . . . . . 171
-     C.7.  Since draft-ietf-quic-transport-22  . . . . . . . . . . . 172
-     C.8.  Since draft-ietf-quic-transport-21  . . . . . . . . . . . 173
-     C.9.  Since draft-ietf-quic-transport-20  . . . . . . . . . . . 173
-     C.10. Since draft-ietf-quic-transport-19  . . . . . . . . . . . 174
-     C.11. Since draft-ietf-quic-transport-18  . . . . . . . . . . . 174
-     C.12. Since draft-ietf-quic-transport-17  . . . . . . . . . . . 175
-     C.13. Since draft-ietf-quic-transport-16  . . . . . . . . . . . 176
-     C.14. Since draft-ietf-quic-transport-15  . . . . . . . . . . . 177
-     C.15. Since draft-ietf-quic-transport-14  . . . . . . . . . . . 177
-     C.16. Since draft-ietf-quic-transport-13  . . . . . . . . . . . 177
-     C.17. Since draft-ietf-quic-transport-12  . . . . . . . . . . . 178
-     C.18. Since draft-ietf-quic-transport-11  . . . . . . . . . . . 179
-     C.19. Since draft-ietf-quic-transport-10  . . . . . . . . . . . 179
-     C.20. Since draft-ietf-quic-transport-09  . . . . . . . . . . . 180
-     C.21. Since draft-ietf-quic-transport-08  . . . . . . . . . . . 181
-     C.22. Since draft-ietf-quic-transport-07  . . . . . . . . . . . 181
-     C.23. Since draft-ietf-quic-transport-06  . . . . . . . . . . . 182
-     C.24. Since draft-ietf-quic-transport-05  . . . . . . . . . . . 182
-     C.25. Since draft-ietf-quic-transport-04  . . . . . . . . . . . 183
-     C.26. Since draft-ietf-quic-transport-03  . . . . . . . . . . . 183
-     C.27. Since draft-ietf-quic-transport-02  . . . . . . . . . . . 184
-     C.28. Since draft-ietf-quic-transport-01  . . . . . . . . . . . 184
-     C.29. Since draft-ietf-quic-transport-00  . . . . . . . . . . . 186
-     C.30. Since draft-hamilton-quic-transport-protocol-01 . . . . . 187
-   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 187
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 188
-
-1.  Overview
-
-   QUIC is a multiplexed and secure general-purpose transport protocol
-   that provides:
-
-   *  Stream multiplexing
-
-   *  Stream- and connection-level flow control
-
-   *  Low-latency connection establishment
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 6]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  Connection migration and resilience to NAT rebinding
-
-   *  Authenticated and encrypted header and payload
-
-   QUIC establishes a connection, which is a stateful interaction
-   between a client and server.  The primary purpose of a connection is
-   to support the structured exchange of data by an application
-   protocol.
-
-   Streams are means by which an application protocol exchanges
-   information.  Streams are ordered sequences of bytes.  Two types of
-   stream can be created: bidirectional streams, which allow both
-   endpoints to send data; and unidirectional streams, which allow a
-   single endpoint to send.  A credit-based scheme is used to limit
-   stream creation and to bound the amount of data that can be sent.
-
-   The QUIC handshake combines negotiation of cryptographic and
-   transport parameters.  The handshake is structured to permit the
-   exchange of application data as soon as possible.  This includes an
-   option for clients to send data immediately (0-RTT), which might
-   require prior communication to enable.
-
-   QUIC connections are not strictly bound to a single network path.
-   Connection migration uses connection identifiers to allow connections
-   to transfer to a new network path.
-
-   Frames are used in QUIC to communicate between endpoints.  One or
-   more frames are assembled into packets.  QUIC authenticates all
-   packets and encrypts as much as is practical.  QUIC packets are
-   carried in UDP datagrams to better facilitate deployment in existing
-   systems and networks.
-
-   Once established, multiple options are provided for connection
-   termination.  Applications can manage a graceful shutdown, endpoints
-   can negotiate a timeout period, errors can cause immediate connection
-   teardown, and a stateless mechanism provides for termination of
-   connections after one endpoint has lost state.
-
-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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 7]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      -  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:
-
-      -  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].
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 8]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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
-      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 that initiates a QUIC connection.
-
-   Server:  The endpoint that accepts a QUIC connection.
-
-   Address:  When used without qualification, the tuple of IP version,
-      IP address, and UDP port number that represents one end of a
-      network path.
-
-   Connection ID:  An identifier that is used to identify a QUIC
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021                [Page 9]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      connection at an endpoint.  Each endpoint selects one or more
-      Connection IDs for its peer to include in packets sent towards the
-      endpoint.  This value is opaque to the peer.
-
-   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 custom 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
-      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 with the length
-      described by ?, as above
-
-   x (?) = C..D:  Indicates that x has a value in the range from C to D,
-      inclusive, with the length described by ?, as above
-
-   [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)
-
-   This document uses network byte order (that is, big endian) values.
-   Fields are placed starting from the high-order bits of each byte.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 10]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   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.
-
-   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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 11]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 two least significant 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
-
-   The stream space for each type begins at the minimum value (0x0
-   through 0x3 respectively); successive streams of each type 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.
-
-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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 12]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   A QUIC implementation SHOULD provide ways in which an application can
-   indicate the relative priority of streams.  An implementation uses
-   information provided by the application to determine how to allocate
-   resources to active streams.
-
-2.4.  Required Operations on Streams
-
-   There are certain operations that 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:
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 13]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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).
-
-   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 the send or receive side causes the stream to open
-   in both directions.
-
-   These state machines shown in this section 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 are not 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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 14]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Note:  In some cases, a single event or action can cause a transition
-      through multiple states.  For instance, sending STREAM with a FIN
-      bit set can cause two state transitions for a sending stream: from
-      the Ready state to the Send state, and from the Send state to the
-      Data Sent state.
-
-3.1.  Sending Stream States
-
-   Figure 2 shows the states for the part of a stream that sends data to
-   a peer.
-
-          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
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 15]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   The sending part of a 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.
-
-   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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 16]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-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
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 17]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 frame 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 a 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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 18]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   It is possible that all stream data has already been received when a
-   RESET_STREAM is received (that is, in 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 a STREAM or
-   STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or
-   any terminal state, that is, after sending a RESET_STREAM frame.  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 MAY 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 18 February 2021               [Page 19]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021               [Page 20]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021               [Page 21]
-
-Internet-Draft           QUIC Transport Protocol             August 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 a STOP_SENDING frame 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, an endpoint MAY
-   defer sending the RESET_STREAM frame until the packets containing
-   outstanding data are acknowledged or declared lost.  If any
-   outstanding data is declared lost, the endpoint SHOULD send a
-   RESET_STREAM frame instead of retransmitting the data.
-
-   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.
-
-   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 frame, and it can encourage prompt termination in the
-   opposite direction by sending a STOP_SENDING frame.
-
-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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 22]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 limit-based flow-control scheme where a receiver
-   advertises the limit of total bytes it is prepared to receive on a
-   given stream or 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.
-
-   Senders MUST not send data in excess of either limit.
-
-   A receiver sets initial limits 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 larger limits.
-
-   A receiver can advertise a larger limit for a stream by sending a
-   MAX_STREAM_DATA frame with the corresponding stream ID.  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.
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 23]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   A receiver can advertise a larger limit 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.
-
-   Once a receiver advertises a limit for the connection or a stream, it
-   MAY advertise a smaller limit, 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 has sent data up to the limit, 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.1), the
-   receiver might close the connection even when the sender has data
-   that 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.  Increasing Flow Control Limits
-
-   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 MAY 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.
-
-   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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 24]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 25]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   The final size of a stream is always signaled to the recipient.  The
-   final size is the sum of the Offset and Length fields of a STREAM
-   frame with a FIN flag, noting that these fields might be implicit.
-   Alternatively, the Final Size field of a RESET_STREAM frame carries
-   this value.  This ensures that all ways that a stream can be closed
-   result in the number of bytes on the stream being reliably
-   transmitted.  This guarantees that both endpoints agree on how much
-   flow control credit was consumed by the stream.
-
-   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).  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.
-
-   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.
-   Subsequent limits are advertised using MAX_STREAMS frames; see
-   Section 19.11.  Separate limits apply to unidirectional and
-   bidirectional streams.
-
-   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.2.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 26]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 not
-   to send STREAMS_BLOCKED frames.
-
-4.6.  Flow Control Performance
-
-   An endpoint that is unable to ensure that a peer has flow control
-   credit on the order of the current BDP will have receive throughput
-   limited by flow control.  Lost packets can cause gaps in the receive
-   buffer, delaying the application from consuming data and freeing up
-   flow control window.
-
-   Sending timely updates of flow control limits can improve
-   performance.  Sending packets only to provide flow control updates
-   can increase network load and adversely affect performance.  Sending
-   flow control updates along with other frames, such as ACK frames,
-   reduces the cost of those updates.
-
-5.  Connections
-
-   A QUIC connection is shared state between a client and a server.
-
-   Each connection starts with a handshake phase, during which the two
-   endpoints establish a shared secret using the cryptographic handshake
-   protocol [QUIC-TLS] and negotiate the application protocol.  The
-   handshake (Section 7) confirms that both endpoints are willing to
-   communicate (Section 8.1) and establishes parameters for the
-   connection (Section 7.4).
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 27]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   An application protocol can use the connection during the handshake
-   phase with some limitations.  0-RTT allows application data to be
-   sent by a client before receiving a response from the server.
-   However, 0-RTT provides no protection against replay attacks; see
-   Section 9.2 of [QUIC-TLS].  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 of trading 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.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.
-
-   The primary function of a connection ID is to ensure that changes in
-   addressing at lower protocol layers (UDP, IP) do not 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 that will allow packets with that
-   connection ID to be routed back to the endpoint and to be 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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 28]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 demonstrate that the packet is in response to a packet
-   sent by the client.
-
-   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).
-
-5.1.1.  Issuing Connection IDs
-
-   Each Connection ID has an associated sequence number to assist in
-   detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer
-   to the same value.  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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 29]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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
-   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.3.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 be unable to respond 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 30]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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
-   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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 31]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.3) 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.
-
-   Invalid packets that lack strong integrity protection, such as
-   Initial, Retry, or Version Negotiation, MAY be discarded.  An
-   endpoint MUST generate a connection error if processing the contents
-   of these packets prior to discovering an error resulted in changes to
-   connection state that cannot be reverted.
-
-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 do not match an existing
-   connection are discarded.
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 32]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 indicates an unsupported version
-   but is large enough to initiate a new connection for any supported
-   version, the server SHOULD send a Version Negotiation packet as
-   described in Section 6.1.  A server MAY limit the number of packets
-   to which it responds with a Version Negotiation packet.  Servers MUST
-   drop smaller 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.  These packets
-   are processed using the selected connection; otherwise, 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.
-
-   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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 33]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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 when the client address changes SHOULD
-   indicate migration is not supported using the
-   disable_active_migration transport parameter.  The
-   disable_active_migration transport parameter does not prohibit
-   connection migration after a client has acted on a preferred_address
-   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.  Required Operations on Connections
-
-   There are certain operations that 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 Early Data when available; and
-
-   *  be informed when Early Data has been accepted or rejected by a
-      server.
-
-   When implementing the server role, applications need to be able to:
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 34]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  listen for incoming connections, which prepares for the exchange
-      described in Section 7;
-
-   *  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.1);
-      and
-
-   *  immediately close (Section 10.2) the connection.
-
-6.  Version Negotiation
-
-   Version negotiation allows a server to indicate that it does not
-   support the version the client used.  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 UDP datagram they send to
-   the largest of the minimum datagram sizes from all versions they
-   support.  This ensures that the server responds if there is a
-   mutually supported version.
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 35]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   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.]]
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 36]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   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:
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 37]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  authenticated key exchange, where
-
-      -  a server is always authenticated,
-
-      -  a client is optionally authenticated,
-
-      -  every connection produces distinct and unrelated keys, and
-
-      -  keying material is usable for packet protection for both 0-RTT
-         and 1-RTT packets
-
-   *  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 verifies 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 offsets used by CRYPTO frames to ensure ordered
-   delivery of cryptographic handshake data start from zero in each
-   packet number space.
-
-   Figure 4 shows a simplified handshake and the exchange of packets and
-   frames that are used to advance the handshake.  Exchange of
-   application data during the handshake is enabled where possible,
-   shown with a '*'.  Once completed, endpoints are able to exchange
-   application data.
-
-   Client                                               Server
-
-   Initial (CRYPTO)
-   0-RTT (*)              ---------->
-                                              Initial (CRYPTO)
-                                            Handshake (CRYPTO)
-                          <----------                1-RTT (*)
-   Handshake (CRYPTO)
-   1-RTT (*)              ---------->
-                          <---------- 1-RTT (HANDSHAKE_DONE,*)
-
-   1-RTT (*)              <=========>                1-RTT (*)
-
-                    Figure 4: Simplified QUIC Handshake
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 38]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 5 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.
-
-   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 (subject to limits inherent to the protocol, such as
-   congestion control or anti-amplification).  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.
-
-   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]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]
-
-                     Figure 5: Example 1-RTT Handshake
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 39]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Figure 6 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]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1]
-
-                     Figure 6: 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.
-
-   During the handshake, packets with the long header (Section 17.2) are
-   used to establish the connection IDs used by both endpoints.  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.  After processing the first Initial
-   packet, each endpoint sets the Destination Connection ID field in
-   subsequent packets it sends to the value of the Source Connection ID
-   field that it received.
-
-   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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 40]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   The Destination Connection ID field from the first Initial packet
-   sent by a client is used to determine packet protection keys for
-   Initial packets.  These keys change after receiving a Retry packet;
-   see Section 5.2 of [QUIC-TLS].
-
-   The client populates the Source Connection ID field with a value of
-   its choosing and sets the Source Connection ID 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 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.
-
-   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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 41]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 absence of the initial_source_connection_id
-   transport parameter from either endpoint or absence of the
-   original_destination_connection_id transport parameter from the
-   server as a connection error of type TRANSPORT_PARAMETER_ERROR.
-
-   An endpoint MUST treat the following as a connection error of type
-   TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
-
-   *  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.
-
-   If a zero-length connection ID is selected, the corresponding
-   transport parameter is included with a zero-length value.
-
-   Figure 7 shows the connection IDs (with DCID=Destination Connection
-   ID, SCID=Source Connection ID) 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 42]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Client                                                  Server
-
-   Initial: DCID=S1, SCID=C1 ->
-                                     <- Initial: DCID=C1, SCID=S3
-                                ...
-   1-RTT: DCID=S3 ->
-                                                <- 1-RTT: DCID=C1
-
-               Figure 7: Use of Connection IDs in a Handshake
-
-   Figure 8 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 8: Use of Connection IDs in a Handshake with Retry
-
-   In both cases (Figure 7 and Figure 8), the client sets the value of
-   the initial_source_connection_id transport parameter to "C1".
-
-   When the handshake does not include a Retry (Figure 7), the server
-   sets original_destination_connection_id to "S1" and
-   initial_source_connection_id to "S3".  In this case, the server does
-   not include a retry_source_connection_id transport parameter.
-
-   When the handshake includes a Retry (Figure 8), the server sets
-   original_destination_connection_id to "S1",
-   retry_source_connection_id to "S2", and initial_source_connection_id
-   to "S3".
-
-   Each endpoint validates transport parameters set by the peer.  The
-   client confirms that the retry_source_connection_id transport
-   parameter is absent if it did not process a Retry packet.
-
-7.4.  Transport Parameters
-
-   During connection establishment, both endpoints make authenticated
-   declarations of their transport parameters.  Endpoints are required
-   to comply with the restrictions that each parameter defines; the
-   description of each parameter includes rules for its handling.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 43]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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
-   values 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.
-
-   Application Layer Protocol Negotiation (ALPN; see [ALPN]) allows
-   clients to offer multiple application protocols during connection
-   establishment.  The transport parameters that a client includes
-   during the handshake apply to all application protocols that the
-   client offers.  Application protocols can recommend values for
-   transport parameters, such as the initial flow control limits.
-   However, application protocols that set constraints on values for
-   transport parameters could make it impossible for a client to offer
-   multiple application protocols if these constraints conflict.
-
-7.4.1.  Values of Transport Parameters for 0-RTT
-
-   Using 0-RTT depends on both client and server using protocol
-   parameters that were negotiated from a previous connection.  To
-   enable 0-RTT, 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.  This information is
-   stored with any information required by the application protocol or
-   cryptographic handshake; see Section 4.6 of [QUIC-TLS].
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 44]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.  Not all transport
-   parameters are remembered, as some do not apply to future connections
-   or they have no effect on use of 0-RTT.
-
-   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.
-
-   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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 45]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 MAY store and recover the previously sent values of the
-   max_idle_timeout, max_udp_payload_size, and disable_active_migration
-   parameters and reject 0-RTT if it selects smaller values.  Lowering
-   the values of these parameters while also accepting 0-RTT data could
-   degrade the performance of the connection.  Specifically, lowering
-   the max_udp_payload_size could result in dropped packets leading to
-   worse performance compared to rejecting 0-RTT data outright.
-
-   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
-   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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 46]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Implementations MUST support buffering at least 4096 bytes of data
-   received in out-of-order CRYPTO frames.  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.
-
-8.  Address Validation
-
-   Address validation ensures that an endpoint cannot be 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.
-
-   Additionally, a server MAY consider the client address valididated if
-   the client uses a connection ID chosen by the server and the
-   connection ID contains at least 64 bits of entropy.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 47]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.  A client that sends padded datagrams
-   allows the server to send more data prior to completing address
-   validation.
-
-   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 6.2 of [QUIC-RECOVERY]).  Specifically, the client
-   MUST send an Initial packet in a UDP datagram that contains 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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 48]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   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.2) 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 9.
-
-   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, "..."]
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 49]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-                   Figure 9: 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.  In a future connection, the client includes this
-   token in Initial packets to provide address validation.  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.
-
-   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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 50]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   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.  A server SHOULD
-   encode tokens provided with NEW_TOKEN frames and Retry packets
-   differently, and validate the latter more strictly.  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.
-
-   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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 51]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 52]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Attackers could replay tokens to use servers as amplifiers in DDoS
-   attacks.  To protect against such attacks, servers MUST ensure that
-   replay of tokens is prevented or limited.  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; 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)
-   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 can be both sent to
-   (PATH_CHALLENGE) and received from (PATH_RESPONSE) a peer on the
-   path.  Importantly, it validates that the packets received from the
-   migrating endpoint do not carry a spoofed source address.
-
-   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 include PATH_CHALLENGE and PATH_RESPONSE frames that
-   are used for path validation with other frames.  In particular, an
-   endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum
-   Transfer Unit (PMTU) discovery (see Section 14.2.1), or an endpoint
-   can include 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 53]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   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 frame.  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.
-
-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)
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 54]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-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].
-
-   If the peer sent the disable_active_migration transport parameter, an
-   endpoint also MUST NOT send packets (including probing packets; see
-   Section 9.1) from a different local address to the address the peer
-   used during the handshake.  An endpoint that has sent this transport
-   parameter, but detects that a peer has nonetheless migrated to a
-   different remote address 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 55]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-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 frame 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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 56]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   To establish reachability on the new path, an endpoint initiates path
-   validation (Section 8.2) on the new path.  An endpoint MAY defer path
-   validation until after a peer sends the next non-probing frame to its
-   new address.
-
-   Path validation is necessary to verify reachability of a peer on a
-   new network path.  Acknowledgments cannot be used for path validation
-   as they contain insufficient entropy and might be spoofed.  No method
-   is provided to establish return reachability, as endpoints
-   independently determine reachability on each direction of a path.
-
-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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 57]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   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 above,
-   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.  Additionally,
-   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, thus containing migrations initiated by the attacker
-   injecting a single packet.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 58]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-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.
-
-   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 18 February 2021               [Page 59]
-
-Internet-Draft           QUIC Transport Protocol             August 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 Appendices 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 6.2.1 of
-   [QUIC-RECOVERY] and MUST NOT be more aggressive.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 60]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-9.5.  Privacy Implications of Connection Migration
-
-   Using a stable connection ID on multiple network paths would allow 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 associate 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 18 February 2021               [Page 61]
-
-Internet-Draft           QUIC Transport Protocol             August 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 do not 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 when the client has not initiated a migration to that
-   address, 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 18 February 2021               [Page 62]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Once the handshake is confirmed, the client SHOULD select one of the
-   two addresses provided by the server and initiate path validation
-   (see Section 8.2).  A client constructs packets 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 packet containing a
-   PATH_RESPONSE frame as per Section 8.2.  The server MUST send non-
-   probing packets 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 18 February 2021               [Page 63]
-
-Internet-Draft           QUIC Transport Protocol             August 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 packets received at the server's preferred address have a
-   different source address than observed from the client during the
-   handshake, 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 Connection ID field.  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 Connection ID field,
-   and a local secret.
-
-10.  Connection Termination
-
-   An established QUIC connection can be terminated in one of three
-   ways:
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 64]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  idle timeout (Section 10.1)
-
-   *  immediate close (Section 10.2)
-
-   *  stateless reset (Section 10.3)
-
-   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.  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.
-
-   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.2) 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.
-
-   To avoid excessively small idle timeout periods, endpoints MUST
-   increase the idle timeout period to be at least three times the
-   current Probe Timeout (PTO).
-
-10.1.1.  Liveness Testing
-
-   An endpoint that sends packets close to the effective timeout risks
-   having them be discarded at the peer, since the idle timeout period
-   might have expired at the peer 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.2 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.
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 65]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-10.1.2.  Deferring Idle Timeout
-
-   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.
-
-   An implementation of QUIC might provide applications with an option
-   to defer an idle timeout.  This facility could be used when the
-   application wishes to avoid losing state that has been associated
-   with an open connection, but does not expect to exchange application
-   data for some time.  With this option, an endpoint could send a PING
-   frame (Section 19.2) periodically, which will cause the peer to
-   restart its idle timeout period.  Sending a packet containing a PING
-   frame restarts the idle timeout for this endpoint also if this is the
-   first ack-eliciting packet sent since receiving a packet.  Sending a
-   PING frame causes the peer to respond with an acknowledgment, which
-   also restarts the idle timeout for the endpoint.
-
-   Application protocols that use QUIC SHOULD provide guidance on when
-   deferring an idle timeout is appropriate.  Unnecessary sending of
-   PING frames could have a detrimental effect on 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 30 seconds is necessary to prevent the majority of
-   middleboxes from losing state for UDP flows [GATEWAY].
-
-10.2.  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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 66]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   An endpoint is allowed to drop the packet protection keys when
-   entering the closing period (Section 10.4) 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 limit the
-   cumulative size of packets containing a CONNECTION_CLOSE frame to 3
-   times the cumulative size of the packets that cause those packets to
-   be sent.  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 is an exception to
-      the requirement that a new packet number be used for each packet
-      in Section 12.3.  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.
-
-   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.  When the application closes
-   the connection, a CONNECTION_CLOSE frame with an appropriate error
-   code will be used to signal closure.
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 67]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-10.2.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.
-
-   *  A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
-      assured that the server has accepted 0-RTT.  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 can send a CONNECTION_CLOSE frame in an Initial packet.
-   This might be 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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 68]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-10.3.  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 do not 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 10: Stateless Reset Packet
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 69]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 are set to values that
-   SHOULD be indistinguishable from random.  The last 16 bytes of the
-   datagram contain a Stateless Reset Token.
-
-   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).
-
-   The resulting 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 achieve that end,
-   the endpoint SHOULD pad all packets it sends to at least 22 bytes
-   longer than the minimum connection ID that it might request the peer
-   to include in packets that the peer sends.  This ensures that any
-   stateless reset sent by the peer is indistinguishable from a valid
-   packet sent to the endpoint.  An endpoint that sends a stateless
-   reset in response to a packet that is 43 bytes or shorter 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.3.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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 70]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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
-   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.3.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.
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 71]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-10.3.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.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 72]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-10.3.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
-   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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 73]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Note that Stateless Reset packets do not have any cryptographic
-   protection.
-
-10.3.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 that 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
-   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.
-
-10.4.  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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 74]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   An endpoint enters a closing period after initiating an immediate
-   close; Section 10.2.  While closing, an endpoint MUST NOT send
-   packets unless they contain a CONNECTION_CLOSE frame; see
-   Section 10.2 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 to allow for 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.3) 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 75]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-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.3) 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-specific protocol errors are signaled using the
-   CONNECTION_CLOSE frame with a frame type of 0x1d.  Errors that are
-   specific to the transport, including all those described in this
-   document, are carried in the CONNECTION_CLOSE frame with a frame type
-   of 0x1c.
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 76]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   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.3).
-
-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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 77]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-12.1.  Protected Packets
-
-   QUIC packets have different levels of cryptographic protection based
-   on the type of packet.  Details of packet protection are found in
-   [QUIC-TLS]; this section includes an overview of the protections that
-   are provided.
-
-   Version Negotiation packets have no cryptographic protection; see
-   [QUIC-INVARIANTS].
-
-   Retry packets use an authenticated encryption with associated data
-   function (AEAD; [AEAD]) to protect against accidental modification.
-
-   Initial packets use an AEAD, the keys for which are derived using a
-   value that is visible on the wire.  Initial packets therefore do not
-   have effective confidentiality protection.  Initial protection exists
-   to ensure that the sender of the packet is on the network path.  Any
-   entity that receives an Initial packet from a client can recover the
-   keys that will allow them to both read the contents of the packet and
-   generate Initial packets that will be successfully authenticated at
-   either endpoint.
-
-   All other packets are protected with keys derived from the
-   cryptographic handshake.  The cryptographic handshake ensures that
-   only the communicating endpoints receive the corresponding keys for
-   Handshake, 0-RTT, and 1-RTT packets.  Packets protected with 0-RTT
-   and 1-RTT keys have strong confidentiality and integrity protection.
-
-   The Packet Number field that appears in some packet types has
-   alternative confidentiality protection that is applied as part of
-   header protection; see Section 5.4 of [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 that 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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 78]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.4.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
-   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 include multiple frames in a single packet if they
-   are to be sent at the same encryption level, instead of coalescing
-   multiple packets at the same encryption level.
-
-   Receivers MAY route based on the information in the first packet
-   contained in a UDP datagram.  Senders MUST NOT coalesce QUIC packets
-   with different connection IDs 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.
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 79]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   *  Handshake space: All Handshake packets (Section 17.2.4) are in
-      this space.
-
-   *  Application data space: All 0-RTT (Section 17.2.3) and 1-RTT
-      (Section 17.3) encrypted packets 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 that
-   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 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.3) in response to further
-   packets that it receives.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 80]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 much larger round trip times; see
-   Section 9.
-
-   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 11.
-   Version Negotiation, Stateless Reset, and Retry packets do not
-   contain frames.
-
-   Packet Payload {
-     Frame (8..) ...,
-   }
-
-                          Figure 11: 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 12: Generic Frame Layout
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 81]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 18 February 2021               [Page 82]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   +=============+======================+===============+======+======+
-   | Type Value  | Frame Type Name      | Definition    | Pkts | Spec |
-   +=============+======================+===============+======+======+
-   | 0x00        | PADDING              | Section 19.1  | IH01 | NP   |
-   +-------------+----------------------+---------------+------+------+
-   | 0x01        | PING                 | Section 19.2  | IH01 |      |
-   +-------------+----------------------+---------------+------+------+
-   | 0x02 - 0x03 | ACK                  | Section 19.3  | IH_1 | NC   |
-   +-------------+----------------------+---------------+------+------+
-   | 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 | F    |
-   +-------------+----------------------+---------------+------+------+
-   | 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 | P    |
-   +-------------+----------------------+---------------+------+------+
-   | 0x19        | RETIRE_CONNECTION_ID | Section 19.16 | __01 |      |
-   +-------------+----------------------+---------------+------+------+
-   | 0x1a        | PATH_CHALLENGE       | Section 19.17 | __01 | P    |
-   +-------------+----------------------+---------------+------+------+
-   | 0x1b        | PATH_RESPONSE        | Section 19.18 | __01 | P    |
-   +-------------+----------------------+---------------+------+------+
-   | 0x1c - 0x1d | CONNECTION_CLOSE     | Section 19.19 | ih01 |      |
-   +-------------+----------------------+---------------+------+------+
-   | 0x1e        | HANDSHAKE_DONE       | Section 19.20 | ___1 |      |
-   +-------------+----------------------+---------------+------+------+
-
-                           Table 3: Frame Types
-
-   The "Pkts" column in Table 3 lists the types of packets that each
-   frame type could appear in, indicated by the following characters:
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 83]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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:  Only a CONNECTION_CLOSE frame of type 0x1c can 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 receipt of a frame in a packet type that is not
-   permitted as a connection error of type PROTOCOL_VIOLATION.
-
-   The "Spec" column in Table 3 summarizes any special rules governing
-   the processing or generation of the frame type, as indicated by the
-   following characters:
-
-   N:  Packets containing only frames with this marking are not ack-
-      eliciting; see Section 13.2.
-
-   C:  Packets containing only frames with this marking do not count
-      toward bytes in flight for congestion control purposes; see
-      [QUIC-RECOVERY].
-
-   P:  Packets containing only frames with this marking can be used to
-      probe new network paths during connection migration; see
-      Section 9.1.
-
-   F:  The content of frames with this marking are flow controlled; see
-      Section 4.
-
-   The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA
-   registry; see Section 22.3.
-
-   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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 84]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 sends one or more frames in a QUIC packet; see Section 12.4.
-
-   A sender can minimize per-packet bandwidth and computational costs by
-   including as many frames as possible in each QUIC packet.  A sender
-   MAY wait for a short period of time to collect 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.
-
-   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 included in a single QUIC
-   packet, loss of that packet blocks all those streams from making
-   progress.  Implementations are advised to include 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 85]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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
-   include an ACK frame if one has not been sent recently.  Doing so
-   helps with timely loss detection at the peer.
-
-   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 delay
-   an endpoint communicated 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 6.2 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.
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 86]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   An endpoint MUST NOT send a non-ack-eliciting packet in response to a
-   non-ack-eliciting packet, even if there are packet gaps that 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 the guidance offered above.  However, an
-   implementation should only deviate from these requirements after
-   careful consideration of the performance implications of a change,
-   for connections made by the endpoint and for other users of the
-   network.
-
-   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
-   send an ACK frame 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 include an ACK frame with outgoing frames.
-
-   A receiver MUST NOT send an ack-eliciting frame in all packets that
-   would otherwise be non-ack-eliciting, to avoid an infinite feedback
-   loop of acknowledgements.
-
-13.2.2.  Acknowledgement Frequency
-
-   A receiver determines how frequently to send acknowledgements in
-   response to ack-eliciting packets.  This determination involves a
-   trade-off.
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 87]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Endpoints rely on timely acknowledgment to detect loss; see Section 6
-   of [QUIC-RECOVERY].  Window-based congestion controllers, such as the
-   one in Section 7 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 improve connection throughput on severely
-   asymmetric links and reduce the volume of acknowledgment traffic
-   using return path capacity; 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 acknowledgements for older packets reduces
-   the chance of spurious retransmissions caused by losing previously
-   sent ACK frames, at the cost of larger ACK frames.
-
-   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 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.  Senders can expect acknowledgements
-   for most packets, but QUIC does not guarantee receipt of an
-   acknowledgment for every packet that the receiver processes.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 88]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.  Receivers MAY also limit ACK
-   frame size further to preserve space for other frames or to limit the
-   capacity that acknowledgments consume.
-
-   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.
-
-   Section 13.2.4 describes an exemplary approach for determining what
-   packets to acknowledge in each ACK frame.  Though the goal of this
-   algorithm is to generate an acknowledgment for every packet that is
-   processed, it is still possible for acknowledgments to be lost.
-
-13.2.4.  Limiting Ranges by Tracking 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.
-
-   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
-   send a PING or other small ack-eliciting frame occasionally, such as
-   once per round trip, to elicit an ACK from the peer.
-
-   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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 89]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 retransmissions, but the sender will
-   continue making forward progress.
-
-13.2.5.  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
-   acknowledgement delay in the ACK Delay field of an ACK frame; see
-   Section 19.3.  This allows the receiver of the ACK frame 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.
-
-   Since the acknowledgement delay is not used for Initial and Handshake
-   packets, the ACK Delay field in acknowledgements for those packet
-   types SHOULD be set to 0.
-
-13.2.6.  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 acknowledged; 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.
-
-   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.7.  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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 90]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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
-      acknowledgement delay from the largest acknowledged packet, as
-      described in Section 13.2.1.  Delaying the transmission of packets
-      containing ACK frames or resending old ACK frames can cause the
-      peer to generate an inflated RTT sample or unnecessarily disable
-      ECN.
-
-   *  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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 91]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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; see Section 4.2.
-
-   *  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.
-
-   *  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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 92]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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].
-
-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).
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 93]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   An IP packet that results in no QUIC packets being processed does not
-   increase ECN counts.  A QUIC 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 counts 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 application data packet
-   number space will be increased by two.
-
-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 server's preferred address, and on
-   active connection migration to a new path.  Appendix B describes one
-   possible algorithm for testing paths for ECN support.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 94]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 (Section 6 of [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 for only the first ten outgoing packets on a path, or for a
-   period of three RTTs, whichever occurs first.
-
-   Other methods of probing paths for ECN support are possible, as are
-   different marking strategies.  Implementations MAY use other methods
-   defined in RFCs; see [RFC8311].  Implementations that use the ECT(1)
-   codepoint need to perform ECN validation using ECT(1) counts.
-
-13.4.2.2.  Receiving ACK Frames
-
-   Erroneous application of ECN marks in the network can result in
-   degraded connection performance.  An endpoint that receives an ACK
-   frame with ECN counts therefore validates the counts before using
-   them.  It performs this validation by comparing newly received counts
-   against those from the last successfully processed ACK frame.  Any
-   increase in ECN counts is validated based on the markings that were
-   applied to packets that are newly acknowledged in the ACK frame.
-
-   If an ACK frame newly acknowledges a packet that the endpoint sent
-   with either ECT(0) or ECT(1) codepoints set, ECN validation fails if
-   ECN counts are not present in the ACK frame.  This check detects a
-   network element that zeroes out ECN bits or a peer that is unable to
-   access ECN markings.
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 95]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   ECN validation fails if the sum of the increase in ECT(0) and ECN-CE
-   counts is less than the number of newly acknowledged packets that
-   were originally sent with an ECT(0) marking.  Similarly, ECN
-   validation fails if the sum of the increases to ECT(1) and ECN-CE
-   counts is less than the number of newly acknowledged packets sent
-   with an ECT(1) marking.  These checks can detect removal of ECN
-   markings in the network.
-
-   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 ECN-CE counts to be greater than the number of packets
-   acknowledged in an ACK frame.  This is why counts are permitted to be
-   larger than might be accounted for by newly acknowledged packets.
-
-   ECN validation MAY fail if the total count for an ECT(0) or ECT(1)
-   marking exceeds the total number of packets sent with the
-   corresponding marking.  In particular, an endpoint that never applies
-   a particular marking can fail validation when a non-zero count for
-   the corresponding marking is received.  This check can detect when
-   packets are marked ECT(0) or ECT(1) in the network.
-
-   Processing ECN counts out of order can result in validation failure.
-   An endpoint SHOULD skip ECN validation on an ACK frame that does not
-   increase the largest acknowledged packet number.
-
-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.
-
-14.  Packet Size
-
-   The QUIC packet size includes the QUIC header and protected payload,
-   but not the UDP or IP headers.
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 96]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   QUIC depends upon a minimum IP packet size of at least 1280 bytes.
-   This is the IPv6 minimum size ([IPv6]) and is also supported by most
-   modern IPv4 networks.  Assuming the minimum IP header size, this
-   results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252
-   bytes for IPv4.
-
-   The QUIC maximum packet size is the largest size of QUIC packet that
-   can be sent across a network path using a single packet.  Any maximum
-   packet size larger than 1200 bytes can be discovered using Path
-   Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1) or
-   Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see
-   Section 14.3).
-
-   Enforcement of the max_udp_payload_size transport parameter
-   (Section 18.2) might act as an additional limit on the maximum packet
-   size.  A sender can avoid exceeding this limit, 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 the smallest allowed maximum packet size of 1200 bytes.
-
-   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.
-
-14.1.  Initial Packet Size
-
-   A client MUST expand the payload of all UDP datagrams carrying
-   Initial packets to at least the smallest allowed maximum packet size
-   (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 Path Maximum Transmission Unit
-   (PMTU).  This also helps reduce the amplitude of amplification
-   attacks caused by server responses toward an unverified client
-   address; see Section 8.
-
-   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 server MUST discard an Initial packet that is carried in a UDP
-   datagram with a payload that is less than the smallest allowed
-   maximum packet size of 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.2.1.
-
-   The server MUST also limit the number of bytes it sends before
-   validating the address of the client; see Section 8.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 97]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-14.2.  Path Maximum Transmission Unit
-
-   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.
-
-   An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD
-   (Section 14.2.1) to determine whether the path to a destination will
-   support a desired maximum packet size without fragmentation.  In the
-   absence of these mechanisms, QUIC endpoints SHOULD NOT send IP
-   packets larger than the smallest allowed maximum packet size.
-
-   Both DPLPMTUD and PMTUD send IP packets that are larger than the
-   current maximum packet size, referred to as PMTU probes.  All QUIC
-   packets that are not sent in a PMTU probe SHOULD be sized to fit
-   within the maximum packet size to avoid the packet being fragmented
-   or dropped ([RFC8085]).
-
-   If a QUIC endpoint determines that the PMTU between any pair of local
-   and remote IP addresses has fallen below the smallest allowed maximum
-   packet size of 1200 bytes, it MUST immediately cease sending QUIC
-   packets, except for those in PMTU probes or those containing
-   CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY
-   terminate the connection if an alternative path cannot be found.
-
-   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 QUIC implementation MAY be more conservative in computing the
-   maximum packet size to allow for unknown tunnel overheads or IP
-   header options/extensions.
-
-14.2.1.  Handling of ICMP Messages by PMTUD
-
-   Path Maximum Transmission Unit Discovery (PMTUD; [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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 98]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   An endpoint MUST ignore an ICMP message that claims the PMTU has
-   decreased below the minimum QUIC packet size.
-
-   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 using PMTUD 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 (see Section 4.6.1 of [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
-
-   Datagram Packetization Layer PMTU Discovery (DPLPMTUD; [DPLPMTUD])
-   relies on tracking loss or acknowledgment of QUIC packets that are
-   carried in PMTU probes.  PMTU probes for DPLPMTUD that use the
-   PADDING frame implement "Probing using padding data", as defined in
-   Section 4.1 of [DPLPMTUD].
-
-   Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1
-   of [DPLPMTUD]) to be consistent with the minimum QUIC packet size.
-   The MIN_PLPMTU is the same as the BASE_PMTU.
-
-   QUIC endpoints implementing DPLPMTUD maintain a maximum packet size
-   (DPLPMTUD MPS) for each combination of local and remote IP addresses.
-
-14.3.1.  DPLPMTUD and Initial Connectivity
-
-   From the perspective of DPLPMTUD, QUIC is an acknowledged
-   packetization layer (PL).  A sender can therefore enter the DPLPMTUD
-   BASE state when the QUIC connection handshake has been completed.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021               [Page 99]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-14.3.2.  Validating the QUIC Path with DPLPMTUD
-
-   QUIC provides an acknowledged PL, therefore a sender does not
-   implement the DPLPMTUD CONFIRMATION_TIMER while in the
-   SEARCH_COMPLETE state; see Section 5.2 of [DPLPMTUD].
-
-14.3.3.  Handling of ICMP Messages by DPLPMTUD
-
-   An endpoint using DPLPMTUD requires the validation of any received
-   ICMP Packet Too Big (PTB) message before using the PTB information,
-   as defined in Section 4.6 of [DPLPMTUD].  In addition to UDP port
-   validation, QUIC validates an ICMP message by using other PL
-   information (e.g., validation of connection IDs in the quoted packet
-   of any received ICMP message).
-
-   The considerations for processing ICMP messages described in
-   Section 14.2.1 also apply if these messages are used by DPLPMTUD.
-
-14.4.  Sending QUIC PMTU Probes
-
-   PMTU probes are ack-eliciting packets.
-
-   Endpoints could limit the content of PMTU probes to PING and PADDING
-   frames as packets that are larger than the current maximum packet
-   size are more likely to be dropped by the network.  Loss of a QUIC
-   packet that is carried in a PMTU probe is therefore not a reliable
-   indication of congestion and SHOULD NOT trigger a congestion control
-   reaction; see Section 3, Bullet 7 of [DPLPMTUD].  However, PMTU
-   probes consume congestion window, which could delay subsequent
-   transmission by an application.
-
-14.4.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 probes to route any resulting ICMP messages
-   (Section 14.2.1) back to the correct endpoint.  However, only long
-   header packets (Section 17.2) contain the Source Connection ID field,
-   and long header packets are not decrypted or acknowledged by the peer
-   once the handshake is complete.
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 100]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   One way to construct a PMTU probe is to coalesce (see Section 12.2) a
-   packet with a long header, such as a Handshake or 0-RTT packet
-   (Section 17.2), with a short header packet in a single UDP datagram.
-   If the resulting PMTU probe reaches the endpoint, the packet with the
-   long header will be ignored, but the short header packet will be
-   acknowledged.  If the PMTU probe causes an ICMP message to be sent,
-   the first part of the probe will be quoted in that message.  If the
-   Source Connection ID field is within the quoted portion of the probe,
-   that could be used for routing or validation of the ICMP message.
-
-   Note:  The purpose of using a packet with a long header is only to
-      ensure that the quoted packet contained in the ICMP message
-      contains a Source Connection ID field.  This packet does not need
-      to be a valid packet and it can be sent even if there is no
-      current use for packets of that type.
-
-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 from 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.
-
-   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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 101]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   [[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.
-
-          +======+========+=============+=======================+
-          | 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
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 102]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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).
-
-   Versions (Section 15) and error codes (Section 20) 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 only the least significant bits of the
-   packet number.
-
-   The encoded packet number is protected as described in Section 5.4 of
-   [QUIC-TLS].
-
-   Prior to receiving an acknowledgement for a packet number space, the
-   full packet number MUST be included.
-
-   After an acknowledgement is received for a packet number space, 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.
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 103]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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
-
-   Long Header Packet {
-     Header Form (1) = 1,
-     Fixed Bit (1) = 1,
-     Long Packet Type (2),
-     Type-Specific Bits (4),
-     Version (32),
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..160),
-     Source Connection ID Length (8),
-     Source Connection ID (0..160),
-   }
-
-                    Figure 13: 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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 104]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 the version of QUIC that is in use and
-      determines how the rest of the protocol fields are interpreted.
-
-   Destination Connection ID 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.
-
-   Destination Connection ID:  The Destination Connection ID field
-      follows the Destination Connection ID Length field, which
-      indicates the length of this field.  Section 7.2 describes the use
-      of this field in more detail.
-
-   Source Connection ID 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
-      Source Connection ID Length field, which indicates the length of
-      this field.  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:
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 105]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-                   +======+===========+================+
-                   | 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, Destination and Source Connection ID lengths,
-   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
-      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 that 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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 106]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      packet number is protected using header protection; see
-      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:
-
-   Version Negotiation Packet {
-     Header Form (1) = 1,
-     Unused (7),
-     Version (32) = 0,
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..2040),
-     Source Connection ID Length (8),
-     Source Connection ID (0..2040),
-     Supported Version (32) ...,
-   }
-
-                   Figure 14: 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 107]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 that the server supports.
-
-   A Version Negotiation packet is not acknowledged.  It is only sent in
-   response to a packet that indicates an unsupported version; see
-   Section 5.2.2.
-
-   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.
-
-   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),
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..160),
-     Source Connection ID Length (8),
-     Source Connection ID (0..160),
-     Token Length (i),
-     Token (..),
-     Length (i),
-     Packet Number (8..32),
-     Packet Payload (..),
-   }
-
-                         Figure 15: Initial Packet
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 108]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   The Initial packet contains a long header as well as the Length and
-   Packet Number fields; see Section 17.2.  The first byte contains the
-   Reserved and Packet Number Length bits; see also Section 17.2.
-   Between the Source Connection ID 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; see Section 8.1.
-
-   Packet Payload:  The payload of the packet.
-
-   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 of type 0x1c 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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 109]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.9.1 of [QUIC-TLS]) along with any loss recovery and
-   congestion control state; see Section 6.4 of [QUIC-RECOVERY].
-
-   Any data in CRYPTO frames is discarded - and no longer retransmitted
-   - when Initial keys are discarded.
-
-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; see Section 17.2.  The first
-   byte contains the Reserved and Packet Number Length bits; see
-   Section 17.2.  A 0-RTT packet 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),
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..160),
-     Source Connection ID Length (8),
-     Source Connection ID (0..160),
-     Length (i),
-     Packet Number (8..32),
-     Packet Payload (..),
-   }
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 110]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-                          Figure 16: 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.
-   New packet numbers MUST be used for any new packets that are sent; as
-   described in Section 17.2.5.3, reusing packet numbers could
-   compromise packet protection.
-
-   A client only receives acknowledgments for its 0-RTT packets once the
-   handshake is complete.
-
-   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
-   (Section 7.4.1) 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; see Section 17.2.
-   The first byte contains the Reserved and Packet Number Length bits;
-   see Section 17.2.  It is used to carry cryptographic handshake
-   messages and acknowledgments from the server and client.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 111]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Handshake Packet {
-     Header Form (1) = 1,
-     Fixed Bit (1) = 1,
-     Long Packet Type (2) = 2,
-     Reserved Bits (2),
-     Packet Number Length (2),
-     Version (32),
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..160),
-     Source Connection ID Length (8),
-     Source Connection ID (0..160),
-     Length (i),
-     Packet Number (8..32),
-     Packet Payload (..),
-   }
-
-                   Figure 17: 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.
-
-   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 of type 0x1c.  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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 112]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Retry Packet {
-     Header Form (1) = 1,
-     Fixed Bit (1) = 1,
-     Long Packet Type (2) = 3,
-     Unused (4),
-     Version (32),
-     Destination Connection ID Length (8),
-     Destination Connection ID (0..160),
-     Source Connection ID Length (8),
-     Source Connection ID (0..160),
-     Retry Token (..),
-     Retry Integrity Tag (128),
-   }
-
-                          Figure 18: Retry Packet
-
-   A Retry packet (shown in Figure 18) does not contain any protected
-   fields.  The value in the Unused field is set to an arbitrary value
-   by the server; a client MUST ignore these bits.  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.
-
-   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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 113]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   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 included 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.  In particular, 0-RTT packets
-   contain confidential information that will most likely be
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 114]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   retransmitted on receiving a Retry packet.  The keys used to protect
-   these new 0-RTT packets will not change as a result of responding to
-   a Retry packet.  However, the data sent in these packets could be
-   different than what was sent earlier.  Sending these new packets with
-   the same packet number is likely to compromise the packet protection
-   for those packets because the same key and nonce could be used to
-   protect different content.
-
-   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 that uses the short
-   packet header.
-
-   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 19: 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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 115]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      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
-      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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 116]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 117]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 20:
-
-   Transport Parameters {
-     Transport Parameter (..) ...,
-   }
-
-                Figure 20: Sequence of Transport Parameters
-
-   Each transport parameter is encoded as an (identifier, length, value)
-   tuple, as shown in Figure 21:
-
-   Transport Parameter {
-     Transport Parameter ID (i),
-     Transport Parameter Length (i),
-     Transport Parameter Value (..),
-   }
-
-                  Figure 21: 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 is
-   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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 118]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.1).
-      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.3.  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
-      (Section 10.3) 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; see Section 14.  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
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 119]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      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
-      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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 120]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   ack_delay_exponent (0x0a):  The acknowledgement 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 acknowledgement 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) on the address being used
-      during the handshake.  When a peer sets this transport parameter,
-      an endpoint MUST NOT use a new local address when sending to the
-      address that the peer used during the handshake.  This transport
-      parameter does not prohibit connection migration after a client
-      has acted on a preferred_address transport parameter.  This
-      parameter is a zero-length value.
-
-   preferred_address (0x0d):  The server's preferred address is used to
-      effect a change in server address at the end of the handshake, as
-      described in Section 9.6.  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 preferred_address transport parameter contains an address and
-      port for both IP version 4 and 6.  The four-byte IPv4 Address
-      field is followed by the associated two-byte IPv4 Port field.
-      This is followed by a 16-byte IPv6 Address field and two-byte IPv6
-      Port field.  After address and port pairs, a Connection ID Length
-      field describes the length of the following Connection ID field.
-      Finally, a 16-byte Stateless Reset Token field includes the
-      stateless reset token associated with the connection ID.  The
-      format of this transport parameter is shown in Figure 22.
-
-      The Connection ID field and the Stateless Reset Token field
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 121]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      contain an alternative connection ID that has a sequence number of
-      1; see Section 5.1.1.  Having these values sent alongside 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),
-     Connection ID Length (8),
-     Connection ID (..),
-     Stateless Reset Token (128),
-   }
-
-                    Figure 22: Preferred Address format
-
-   active_connection_id_limit (0x0e):  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.
-
-   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.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 122]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 Frames
-
-   A 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.
-
-   PADDING frames are formatted as shown in Figure 23, which shows that
-   PADDING frames have no content.  That is, a PADDING frame consists of
-   the single byte that identifies the frame as a PADDING frame.
-
-   PADDING Frame {
-     Type (i) = 0x00,
-   }
-
-                      Figure 23: PADDING Frame Format
-
-19.2.  PING Frames
-
-   Endpoints can use PING frames (type=0x01) to verify that their peers
-   are still alive or to check reachability to the peer.
-
-   PING frames are formatted as shown in Figure 24, which shows that
-   PING frames have no content.
-
-   PING Frame {
-     Type (i) = 0x01,
-   }
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 123]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-                        Figure 24: PING Frame Format
-
-   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; see Section 10.1.2.
-
-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 reneging for TCP SACKs ([RFC2018]).
-
-   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.
-
-   ACK frames are formatted as shown in Figure 25.
-
-   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 25: ACK Frame Format
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 124]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 encoding the acknowledgement
-      delay in microseconds; see Section 13.2.5.  It is decoded by
-      multiplying the value in the field by 2 to the power of the
-      ack_delay_exponent transport parameter sent by the sender of the
-      ACK frame; see Section 18.2.  Compared to simply expressing the
-      delay as an integer, this encoding allows for a larger range of
-      values within the same number of bytes, at the cost of lower
-      resolution.
-
-   ACK Range Count:  A variable-length integer specifying the number of
-      Gap and ACK Range fields in the frame.
-
-   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 that 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 26.
-
-   ACK Range {
-     Gap (i),
-     ACK Range Length (i),
-   }
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 125]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-                           Figure 26: 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.
-
-   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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 126]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   When present, there are 3 ECN counts, as shown in Figure 27.
-
-   ECN Counts {
-     ECT0 Count (i),
-     ECT1 Count (i),
-     ECN-CE Count (i),
-   }
-
-                        Figure 27: ECN Count Format
-
-   The three ECN Counts are:
-
-   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 Frames
-
-   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.
-
-   RESET_STREAM frames are formatted as shown in Figure 28.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 127]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   RESET_STREAM Frame {
-     Type (i) = 0x04,
-     Stream ID (i),
-     Application Protocol Error Code (i),
-     Final Size (i),
-   }
-
-                    Figure 28: 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.2)
-      that indicates why the stream is being closed.
-
-   Final Size:  A variable-length integer indicating the final size of
-      the stream by the RESET_STREAM sender, in unit of bytes; see
-      Section 4.4.
-
-19.5.  STOP_SENDING Frames
-
-   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.
-
-   STOP_SENDING frames are formatted as shown in Figure 29.
-
-   STOP_SENDING Frame {
-     Type (i) = 0x05,
-     Stream ID (i),
-     Application Protocol Error Code (i),
-   }
-
-                    Figure 29: STOP_SENDING Frame Format
-
-   STOP_SENDING frames contain the following fields:
-
-   Stream ID:  A variable-length integer carrying the Stream ID of the
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 128]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      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.2.
-
-19.6.  CRYPTO Frames
-
-   A 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.
-
-   CRYPTO frames are formatted as shown in Figure 30.
-
-   CRYPTO Frame {
-     Type (i) = 0x06,
-     Offset (i),
-     Length (i),
-     Crypto Data (..),
-   }
-
-                       Figure 30: 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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 129]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 Frames
-
-   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.
-
-   NEW_TOKEN frames are formatted as shown in Figure 31.
-
-   NEW_TOKEN Frame {
-     Type (i) = 0x07,
-     Token Length (i),
-     Token (..),
-   }
-
-                     Figure 31: 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 Type field takes the form 0b00001XXX (or the set of
-   values from 0x08 to 0x0f).  The three low-order bits of the frame
-   type determine the fields that are present in the frame:
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 130]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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.
-
-   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.
-
-   STREAM frames are formatted as shown in Figure 32.
-
-   STREAM Frame {
-     Type (i) = 0x08..0x0f,
-     Stream ID (i),
-     [Offset (i)],
-     [Length (i)],
-     Stream Data (..),
-   }
-
-                       Figure 32: 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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 131]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-19.9.  MAX_DATA Frames
-
-   A 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.
-
-   MAX_DATA frames are formatted as shown in Figure 33.
-
-   MAX_DATA Frame {
-     Type (i) = 0x10,
-     Maximum Data (i),
-   }
-
-                      Figure 33: MAX_DATA Frame Format
-
-   MAX_DATA frames contain the following field:
-
-   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.  This includes violations of remembered limits in Early
-   Data; see Section 7.4.1.
-
-19.10.  MAX_STREAM_DATA Frames
-
-   A 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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 132]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   MAX_STREAM_DATA frames are formatted as shown in Figure 34.
-
-   MAX_STREAM_DATA Frame {
-     Type (i) = 0x11,
-     Stream ID (i),
-     Maximum Stream Data (i),
-   }
-
-                  Figure 34: 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.  This includes violations of remembered limits in
-   Early Data; see Section 7.4.1.
-
-19.11.  MAX_STREAMS Frames
-
-   A MAX_STREAMS frame (type=0x12 or 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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 133]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   MAX_STREAMS frames are formatted as shown in Figure 35;
-
-   MAX_STREAMS Frame {
-     Type (i) = 0x12..0x13,
-     Maximum Streams (i),
-   }
-
-                    Figure 35: MAX_STREAMS Frame Format
-
-   MAX_STREAMS frames contain the following field:
-
-   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 that
-   state a lower stream limit than an endpoint has previously received.
-   MAX_STREAMS frames that 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.  This includes violations of remembered limits in Early
-   Data; see Section 7.4.1.
-
-   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 Frames
-
-   A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
-   to send data, but is unable to do so 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.
-
-   DATA_BLOCKED frames are formatted as shown in Figure 36.
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 134]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   DATA_BLOCKED Frame {
-     Type (i) = 0x14,
-     Maximum Data (i),
-   }
-
-                    Figure 36: DATA_BLOCKED Frame Format
-
-   DATA_BLOCKED frames contain the following field:
-
-   Maximum Data:  A variable-length integer indicating the connection-
-      level limit at which blocking occurred.
-
-19.13.  STREAM_DATA_BLOCKED Frames
-
-   A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
-   wishes to send data, but is unable to do so 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.
-
-   STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37.
-
-   STREAM_DATA_BLOCKED Frame {
-     Type (i) = 0x15,
-     Stream ID (i),
-     Maximum Stream Data (i),
-   }
-
-                Figure 37: STREAM_DATA_BLOCKED Frame Format
-
-   STREAM_DATA_BLOCKED frames contain the following fields:
-
-   Stream ID:  A variable-length integer indicating the stream that is
-      blocked due to flow control.
-
-   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 is used to
-   indicate reaching the unidirectional stream limit.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 135]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-   STREAMS_BLOCKED frames are formatted as shown in Figure 38.
-
-   STREAMS_BLOCKED Frame {
-     Type (i) = 0x16..0x17,
-     Maximum Streams (i),
-   }
-
-                  Figure 38: STREAMS_BLOCKED Frame Format
-
-   STREAMS_BLOCKED frames contain the following field:
-
-   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 Frames
-
-   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.
-
-   NEW_CONNECTION_ID frames are formatted as shown in Figure 39.
-
-   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 39: 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, encoded as a variable-length integer; see
-      Section 5.1.1.
-
-   Retire Prior To:  A variable-length integer indicating which
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 136]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      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.3.
-
-   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 handle receiving the same
-   NEW_CONNECTION_ID frame multiple times.
-
-   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.
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 137]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 Frames
-
-   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).
-
-   Retiring a connection ID invalidates the stateless reset token
-   associated with that connection ID.
-
-   RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40.
-
-   RETIRE_CONNECTION_ID Frame {
-     Type (i) = 0x19,
-     Sequence Number (i),
-   }
-
-                Figure 40: RETIRE_CONNECTION_ID Frame Format
-
-   RETIRE_CONNECTION_ID frames contain the following field:
-
-   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 PROTOCOL_VIOLATION.
-
-   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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 138]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-19.17.  PATH_CHALLENGE Frames
-
-   Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
-   reachability to the peer and for path validation during connection
-   migration.
-
-   PATH_CHALLENGE frames are formatted as shown in Figure 41.
-
-   PATH_CHALLENGE Frame {
-     Type (i) = 0x1a,
-     Data (64),
-   }
-
-                   Figure 41: PATH_CHALLENGE Frame Format
-
-   PATH_CHALLENGE frames contain the following field:
-
-   Data:  This 8-byte field contains arbitrary data.
-
-   Including 64 bits of entropy in a PATH_CHALLENGE frame ensures 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 Frames
-
-   A PATH_RESPONSE frame (type=0x1b) is sent in response to a
-   PATH_CHALLENGE frame.
-
-   PATH_RESPONSE frames are formatted as shown in Figure 42, which is
-   identical to the PATH_CHALLENGE frame (Section 19.17).
-
-   PATH_RESPONSE Frame {
-     Type (i) = 0x1b,
-     Data (64),
-   }
-
-                   Figure 42: 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.
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 139]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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 have not been explicitly closed, they
-   are implicitly closed when the connection is closed.
-
-   CONNECTION_CLOSE frames are formatted as shown in Figure 43.
-
-   CONNECTION_CLOSE Frame {
-     Type (i) = 0x1c..0x1d,
-     Error Code (i),
-     [Frame Type (i)],
-     Reason Phrase Length (i),
-     Reason Phrase (..),
-   }
-
-                  Figure 43: CONNECTION_CLOSE Frame Format
-
-   CONNECTION_CLOSE frames contain the following fields:
-
-   Error Code:  A variable-length integer error code that indicates the
-      reason for closing this connection.  A CONNECTION_CLOSE frame of
-      type 0x1c uses codes from the space defined in Section 20.1.  A
-      CONNECTION_CLOSE frame of type 0x1d uses codes from the
-      application protocol error code space; see Section 20.2.
-
-   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 not to
-      give details beyond the Error Code.  This SHOULD be a UTF-8
-      encoded string [RFC3629].
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 140]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   The application-specific variant of CONNECTION_CLOSE (type 0x1d) can
-   only be sent using 0-RTT or 1-RTT packets; see Section 4 of
-   [QUIC-TLS].  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 Frames
-
-   The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal
-   confirmation of the handshake to the client.
-
-   HANDSHAKE_DONE frames are formatted as shown in Figure 44, which
-   shows that HANDSHAKE_DONE frames have no content.
-
-   HANDSHAKE_DONE Frame {
-     Type (i) = 0x1e,
-   }
-
-                   Figure 44: HANDSHAKE_DONE Frame Format
-
-   A HANDSHAKE_DONE 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.
-
-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 extension frame types.  One transport parameter can indicate
-   support for one or more extension frame types.
-
-   Extensions that modify or replace core protocol functionality
-   (including frame types) will be difficult to combine with other
-   extensions that 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.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 141]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.  Error Codes
-
-   QUIC transport error codes and application error codes are 62-bit
-   unsigned integers.
-
-20.1.  Transport Error Codes
-
-   This section lists the defined QUIC transport error codes that may be
-   used in a CONNECTION_CLOSE frame with a type of 0x1c.  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
-      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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 142]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-      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 client Initial that
-      contained an invalid Token field.
-
-   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
-      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.
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 143]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-20.2.  Application Protocol Error Codes
-
-   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.1), 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.3),
-   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.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 144]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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.
-
-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.2.
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 145]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-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.
-
-   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 a large number 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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 146]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 frames or 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.
-
-   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.
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 147]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   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 of service, endpoints that share a static key
-   for stateless reset (see Section 10.3.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.
-
-   More generally, servers MUST NOT generate a stateless reset if a
-   connection with the corresponding connection ID could be active on
-   any endpoint using the same static key.
-
-   In the case of a cluster that uses dynamic load balancing, it is
-   possible that a change in load balancer configuration could occur
-   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 of the packet being routed to the
-   correct instance, it is better to send a stateless reset than wait
-   for the connection to time out.  However, this is acceptable only if
-   the routing cannot be influenced by an attacker.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 148]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-21.10.  Version Downgrade
-
-   This document defines QUIC Version Negotiation packets in Section 6
-   that 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.  Both types of attackers can also
-   transmit arbitrary packets.
-
-   Properties of the handshake, protected packets, and connection
-   migration are considered separately.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 149]
-
-Internet-Draft           QUIC Transport Protocol             August 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 can observe packets.
-
-   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 that 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 18 February 2021              [Page 150]
-
-Internet-Draft           QUIC Transport Protocol             August 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 salt)
-   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 inputs; 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 18 February 2021              [Page 151]
-
-Internet-Draft           QUIC Transport Protocol             August 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 that 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 18 February 2021              [Page 152]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021              [Page 153]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021              [Page 154]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021              [Page 155]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021              [Page 156]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021              [Page 157]
-
-Internet-Draft           QUIC Transport Protocol             August 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 18 February 2021              [Page 158]
-
-Internet-Draft           QUIC Transport Protocol             August 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 registry 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 the IETF (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 field:
-
-   Parameter Name:  A short mnemonic for the parameter.
-
-   The initial contents of this registry are shown in Table 6.
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 159]
-
-Internet-Draft           QUIC Transport Protocol             August 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 Types Registry
-
-   IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
-   "QUIC" heading.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 160]
-
-Internet-Draft           QUIC Transport Protocol             August 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 field:
-
-   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 need to describe the format and assigned
-   semantics of any fields in the frame.
-
-   The initial contents of this registry are tabulated in Table 3.  Note
-   that the registry does not include the "Pkts" and "Spec" columns from
-   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 regions 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 18 February 2021              [Page 161]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   +======+===========================+================+===============+
-   |Value | Error                     | Description    | Specification |
-   +======+===========================+================+===============+
-   | 0x0  | NO_ERROR                  | No error       | Section 20    |
-   +------+---------------------------+----------------+---------------+
-   | 0x1  | INTERNAL_ERROR            | Implementation | Section 20    |
-   |      |                           | error          |               |
-   +------+---------------------------+----------------+---------------+
-   | 0x2  | CONNECTION_REFUSED        |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 18 February 2021              [Page 162]
-
-Internet-Draft           QUIC Transport Protocol             August 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-22, 10 June 2020,
-              <http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-
-              datagram-plpmtud-22.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, 17 August 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, 17 August
-              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 18 February 2021              [Page 163]
-
-Internet-Draft           QUIC Transport Protocol             August 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>.
-
-   [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
-
-   [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>.
-
-   [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>.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 164]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   [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>.
-
-   [EARLY-DESIGN]
-              Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2
-              December 2013, <https://goo.gl/dMVtFi>.
-
-   [GATEWAY]  Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
-              Sarolahti, P., and M. Kojo, "An experimental study of home
-              gateway characteristics", DOI 10.1145/1879141.1879174,
-              Proceedings of the 10th annual conference on Internet
-              measurement - IMC '10, 2010,
-              <https://doi.org/10.1145/1879141.1879174>.
-
-   [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>.
-
-   [IPv6]     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>.
-
-   [QUIC-INVARIANTS]
-              Thomson, M., "Version-Independent Properties of QUIC",
-              Work in Progress, Internet-Draft, draft-ietf-quic-
-              invariants-latest, 17 August 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-07, 8 July 2020,
-              <http://www.ietf.org/internet-drafts/draft-ietf-quic-
-              manageability-07.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>.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 165]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   [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>.
-
-   [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>.
-
-   [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>.
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 166]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-Appendix A.  Sample Packet Number Decoding Algorithm
-
-   The pseudo-code in Figure 45 shows how an implementation can decode
-   packet numbers after header protection has been removed.
-
-   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 cannot 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 45: 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.
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 167]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   To start testing a path, the ECN state is set to "testing" and
-   existing ECN counts are remembered as a baseline.
-
-   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-28
-
-   *  Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED
-      (#3709, #3690, #3694)
-
-   *  Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs
-      (#3703, #3691)
-
-   *  Integrate QUIC-specific language from draft-ietf-tsvwg-datagram-
-      plpmtud (#3695, #3702)
-
-   *  disable_active_migration does not apply to the addresses offered
-      in server_preferred_address (#3608, #3670)
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 168]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-C.2.  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)
-
-   *  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)
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 169]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-C.3.  Since draft-ietf-quic-transport-26
-
-   *  Change format of transport parameters to use varints (#3294,
-      #3169)
-
-C.4.  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)
-
-C.5.  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)
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 170]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-   *  Packets on one path must not adjust values for a different path
-      (#2909, #3139)
-
-C.6.  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)
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 171]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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.7.  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)
-
-   *  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)
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 172]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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.8.  Since draft-ietf-quic-transport-21
-
-   *  Connection ID lengths are now one octet, but limited in version 1
-      to 20 octets of length (#2736, #2749)
-
-C.9.  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)
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 173]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-C.10.  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.11.  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)
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 174]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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.12.  Since draft-ietf-quic-transport-17
-
-   *  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)
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 175]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  Corrected requirements for migration to a preferred address
-      (#2146, #2349)
-
-   *  ACK of non-existent packet is illegal (#2298, #2302)
-
-C.13.  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)
-
-   *  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)
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 176]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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.14.  Since draft-ietf-quic-transport-15
-
-   Substantial editorial reorganization; no technical changes.
-
-C.15.  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.16.  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)
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 177]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-   *  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.17.  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)
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 178]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-   *  Stateless Reset is now symmetric and subject to size constraints
-      (#466, #1346)
-
-   *  Added frame type extension mechanism (#58, #1473)
-
-C.18.  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.19.  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)
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 179]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-   *  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.20.  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)
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 180]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-C.21.  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)
-
-   *  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.22.  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)
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 181]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-   *  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.23.  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.24.  Since draft-ietf-quic-transport-05
-
-   *  Stateless token is server-only (#726)
-
-   *  Refactor section on connection termination (#733, #748, #328,
-      #177)
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 182]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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.25.  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)
-
-   *  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.26.  Since draft-ietf-quic-transport-03
-
-   *  Change STREAM and RESET_STREAM layout
-
-   *  Add MAX_STREAM_ID settings
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 183]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-C.27.  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)
-
-   *  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.28.  Since draft-ietf-quic-transport-01
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 184]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-   *  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)
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 185]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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)
-
-   *  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.29.  Since draft-ietf-quic-transport-00
-
-   *  Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 186]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  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.30.  Since draft-hamilton-quic-transport-protocol-01
-
-   *  Adopted as base for draft-ietf-quic-tls
-
-   *  Updated authors/editors list
-
-   *  Added IANA Considerations section
-
-   *  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
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 187]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   *  Ian Swett
-
-   *  Igor Lubashev
-
-   *  奥 一穂 (Kazuho Oku)
-
-   *  Lucas Pardue
-
-   *  Magnus Westerlund
-
-   *  Marten Seemann
-
-   *  Martin Duke
-
-   *  Mike Bishop
-
-   *  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
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 188]
-
-Internet-Draft           QUIC Transport Protocol             August 2020
-
-
-   Martin Thomson (editor)
-   Mozilla
-
-   Email: mt@lowentropy.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Iyengar & Thomson       Expires 18 February 2021              [Page 189]
diff --git a/split-initial-close/index.html b/split-initial-close/index.html
deleted file mode 100644
index 964ae8446d..0000000000
--- a/split-initial-close/index.html
+++ /dev/null
@@ -1,107 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>quicwg/base-drafts split-initial-close 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 split-initial-close branch of <a href="https://github.com/quicwg/base-drafts/tree/split-initial-close">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-split-initial-close">
-      <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/split-initial-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/split-initial-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="./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/split-initial-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/split-initial-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="./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/split-initial-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/split-initial-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="./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/split-initial-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/split-initial-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="./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/split-initial-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/split-initial-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="./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/split-initial-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/split-initial-close/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>