Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

A pacing algorithm #3630

Merged
merged 13 commits into from May 18, 2020
Merged

A pacing algorithm #3630

Changes from 1 commit
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
f001162
A pacing algorithm
martinthomson May 1, 2020
561df07
Forgot to include smoothed_rtt in the description
martinthomson May 1, 2020
a4b888e
Reword rationale somewhat
martinthomson May 1, 2020
b776f4d
Using suggestions to edit
martinthomson May 12, 2020
37eaf7e
Add a blank line
martinthomson May 12, 2020
7579140
Shorter figure line
martinthomson May 13, 2020
7ddcd1d
Trying to thread the needle
martinthomson May 14, 2020
954f037
Fix
martinthomson May 14, 2020
dbc8ffc
under-utilization
martinthomson May 14, 2020
819f4d0
Some editorial rearrangement
martinthomson May 14, 2020
42a1dd8
Some improvements from Ian
martinthomson May 17, 2020
b0a1b1c
ack-clocking
martinthomson May 18, 2020
a320b54
Reword ack-clocking again
martinthomson May 18, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 6 additions & 6 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -897,15 +897,15 @@ congestion window, which is recommended to be the minimum of
max_datagram_size is the current maximum size of a datagram for the connection,
not including UDP or IP overhead.

Endpoints can implement pacing as they choose, as long as the total number of
bytes sent over any interval, `t[n] - t[m]`, does not exceed a small multiple,
`N`, of maximum value of the congestion window, `cwnd`, over that same period.
Allowing for bursts produces the following relation for the total number of
bytes sent over any interval:
Endpoints can implement pacing as they choose, as long as the rate of bytes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is all too much prescription. I suggest you move this up above the previous paragraph, and lead into the burst paragraphs like so:

"Endpoints can implement pacing as they choose. A perfectly paced sender spreads bytes 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. More precisely, pacing rate = N * congestion_window / smoothed_rtt, where using a small N (for example, 1.25) protects the sender from short-term variations in round-trip time or from scheduler delays.

Further 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. Sending multiple packets into the network without any delay ..."

sent over any interval, `t[n] - t[m]`, does not exceed a small multiple, `N`,
of maximum value of the congestion window, `congestion_window`, averaged over
the round trip time estimate, `smoothed_rtt`. Allowing for bursts produces the
following relation for the total number of bytes sent over any interval:

~~~
sent@t[n] - sent@t[m]
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
<= N * cwnd * (t[m] - t[n]) / RTT
<= N * congestion_window * (t[m] - t[n]) / smoothed_rtt
+ min(10 * max_datagram_size,
max(2 * max_datagram_size, 14720))
~~~
Expand Down