Script updating gh-pages from f9e4fda. [ci skip]

draft-welzl-iccrg-pacing.html

@@ -1322,7 +1322,7 @@ <h3 id="name-quic-bbr-implementations">
             <p id="section-4.3-3.3.1">Details of the actual pacing algorithm (e.g. granularity of bursts allowed, etc.).<a href="#section-4.3-3.3.1" class="pilcrow">¶</a></p>
 </li>
         </ol>
-<p id="section-4.3-4">Examples of different approaches to dealing with these challenges in ways that work on multiple operating systems and hardware platforms can be found in open source QUIC stacks, such as Google "quiche" and Meta "mvfst", that provide examples for some of the concepts discussed below.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
+<p id="section-4.3-4">Examples of different approaches to dealing with these challenges in ways that work on multiple operating systems and hardware platforms can be found in open source QUIC stacks, such as Google's QUIC implementation and Meta's "mvfst". These provide examples for some of the concepts discussed below.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
 <p id="section-4.3-5">Unlike TCP implementations that typically run within the operating system kernel, QUIC implementations more typically run in user space and are thus faced with more challenges regarding timing and coupling with the underlying protocol stack and hardware needed to achieve pacing.  For instance, if an application trying to do pacing is running on a highly loaded system, it may often "wake up late" and miss the times that it intends to pace packets.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
 <p id="section-4.3-6">When a large amount of data needs to be sent, pacing naively could result in an excessive number of timers to be managed and adjusted along with all of the other timers that the QUIC stack and rest of the application require.  The Hashed Hierarchical Timing Wheel <span>[<a href="#VL87" class="cite xref">VL87</a>]</span> provides one approach for such cases, but implementations may also simply schedule the next send event based on the current pacing rate, and then schedule subsequent events as needed, rather than adjusting timers for them.  In any case, typically a pacing algorithm should allow for some amount of burstiness, in order to efficiently use the hardware as well as to be responsive for bursty (but low overall rate) applications, and to avoid excessive timer management.<a href="#section-4.3-6" class="pilcrow">¶</a></p>
 <p id="section-4.3-7">Pacing can be done based on different approaches such as a token-based or tokenless algorithm.  For instance, a tokenless algorithm (e.g. as used in mvfst) might compute a regular interval time and batch size (number of packets) to be released every interval and achieve the pacing rate.  This allows specific future transmissions to be scheduled.  In contrast, a token-based algorithm accumulates tokens to permit transmission based on the pacing rate, using a "leaky bucket" to control bursts.  In this case the size of bursts may be more granular, depending on how much time has elapsed between evaluations.<a href="#section-4.3-7" class="pilcrow">¶</a></p>

draft-welzl-iccrg-pacing.txt

@@ -308,9 +308,9 @@ Table of Contents
 
    Examples of different approaches to dealing with these challenges in
    ways that work on multiple operating systems and hardware platforms
-   can be found in open source QUIC stacks, such as Google "quiche" and
-   Meta "mvfst", that provide examples for some of the concepts
-   discussed below.
+   can be found in open source QUIC stacks, such as Google's QUIC
+   implementation and Meta's "mvfst".  These provide examples for some
+   of the concepts discussed below.
 
    Unlike TCP implementations that typically run within the operating
    system kernel, QUIC implementations more typically run in user space