From d7e236ea69b9cdb71c9794e0e6d494f3d9e9f149 Mon Sep 17 00:00:00 2001 From: wesley-eddy <88058718+wesley-eddy@users.noreply.github.com> Date: Wed, 3 Jul 2024 09:52:05 -0400 Subject: [PATCH] Update draft-welzl-iccrg-pacing.md Co-authored-by: Michael Welzl --- draft-welzl-iccrg-pacing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-welzl-iccrg-pacing.md b/draft-welzl-iccrg-pacing.md index 650fb0e..a9858a2 100644 --- a/draft-welzl-iccrg-pacing.md +++ b/draft-welzl-iccrg-pacing.md @@ -125,7 +125,7 @@ Pacing in QUIC stacks commonly involves: 3. Details of the actual pacing algorithm (e.g. granularity of bursts allowed, etc.). -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.. +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. 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 acheive 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.