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.

Sign up for GitHub

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

Restarting from idle #2023

Merged
merged 5 commits into from Nov 20, 2018
Merged

Restarting from idle #2023

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4149b3c
Restarting from idle
ianswett Nov 20, 2018
75482c7
Update draft-ietf-quic-recovery.md
ianswett Nov 20, 2018
5d9203f
Update draft-ietf-quic-recovery.md
ianswett Nov 20, 2018
2fde7b9
Update draft-ietf-quic-recovery.md
janaiyengar Nov 20, 2018
d776217
Update draft-ietf-quic-recovery.md
ianswett Nov 20, 2018
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
14 changes: 8 additions & 6 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -1042,18 +1042,20 @@ in Linux (3.11 onwards).

## Resumption from idle
ianswett marked this conversation as resolved.
Show resolved Hide resolved

A connection is idle if bytes in flight is 0 and there is nothing retransmittable
to send. In order to limit the size of bursts sent into the network, the
behavior when restarting from idle depends upon whether pacing is used.
A connection is idle if bytes in flight is 0 and there is nothing
Copy link
Contributor

Choose a reason for hiding this comment

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

"if there are no bytes in flight"

retransmittable to send. In order to limit the size of bursts sent into the
network, the behavior when restarting from idle depends upon whether pacing is
used.

If pacing is used, the connection should limit the initial burst of packets to
Copy link
Contributor

Choose a reason for hiding this comment

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

"If the sender uses pacing"

no more than the initial congestion window and subsequent packets SHOULD be paced.
The congestion window does not change while the connection is idle.
no more than the initial congestion window and subsequent packets SHOULD be
paced. The congestion window does not change while the connection is idle.
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this initial burst bit is necessary. All you need to say is that if the sender uses pacing, the cwnd does not need to be reduced. How about "A sender that uses pacing can retain its congestion window through an idle period."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the goal is to reduce bursts, I think we need to advocate for limiting the burst of a paced connection to nothing larger than the restarting window of an unpaced connection.


If pacing is not used, the congestion window SHOULD be reset to the minimum of
Copy link
Contributor

Choose a reason for hiding this comment

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

"If the sender does not use pacing"

the current congestion window and the initial congestion window. If the
slow start threshold is larger than the congestion window, the congestion window
will grow back to the congestion window prior to idle via slow start.
will grow back to the congestion window prior to idle via slow start. This
recommendation is based on Section 4.1 of {{?RFC5681}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

Similarly, I would reduce this to a sentence and remove the sentence about slow start. I'm ok with leaving the ref to 5681 in here, but I would like to remove it in a later PR and replace it with more text explaining the rationale directly (instead of pointing to 5681).

For now, how about "A sender that does not use pacing SHOULD reset its congestion window to the minimum of the current congestion window and the initial congestion window. This recommendation is based on Section 4.1 of {{?RFC5681}}."

Copy link
Contributor

Choose a reason for hiding this comment

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

Can't comment on @janaiyengar's other comment for some reason. But my suggestion is only to decay exponentially, not to aggressively grow the window from where at landed.


## Pseudocode
Copy link
Contributor

Choose a reason for hiding this comment

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

How about slowly reducing the current window thorugh exponential decay down to initial window? Otherwise e.g. video might get quite chunky as buffers fill and the connection idles. But of course other connetions might have taken the bandwidth meanwhile, so it might not be a good idea after all, depending on decay speed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know of a best practice for doing what you're describing, so unless you can find one in a TCP RFC or elsewhere, I'm hesitant to recommend it.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK

Copy link
Contributor

Choose a reason for hiding this comment

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

FYI: I have not read this paper, except the abstract, but it seems to touch upon the current text (no my suggestion) related to pacing packets on idle restart https://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.pdf

Copy link
Contributor

Choose a reason for hiding this comment

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

Again, only abstract read, ,but it speaks of decaying the cwnd on idle.
https://tools.ietf.org/html/rfc2861

Copy link
Contributor Author

Choose a reason for hiding this comment

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

5681 obsoletes 2581, but makes no mention of 2861. I'll let @janaiyengar decide what to do here.

Copy link
Contributor

Choose a reason for hiding this comment

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

RFC 2861 describes how to do this exponentially, but that was always considered too aggressive and resulted in folks turning it off in real deployments. The new one is RFC 7661, which reduces the cwnd once to max(cwnd/2, IW) and ssthresh to max(ssthresh, 3/4 x cwnd). We could use these reductions here, though 7661 is an experimental RFC, since it has gone through TCPM review.


Expand Down