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

Allow alternate restarts after idle #2187

Merged
merged 7 commits into from Dec 18, 2018
Merged

Allow alternate restarts after idle #2187

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
6df0e3a
Allow alternate restarts after idle
janaiyengar Dec 14, 2018
b866ed6
restructure
janaiyengar Dec 15, 2018
2133100
Update draft-ietf-quic-recovery.md
martinthomson Dec 18, 2018
2bbc1ff
Update draft-ietf-quic-recovery.md
martinthomson Dec 18, 2018
6fdb947
more changes
janaiyengar Dec 18, 2018
adfc4a0
becomes
janaiyengar Dec 18, 2018
1053a1f
simpler
janaiyengar Dec 18, 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
6 changes: 3 additions & 3 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -964,9 +964,9 @@ in Linux (3.11 onwards).

## Sending data after an idle period

A sender is considered idle if it has no bytes in flight. A sender can become
idle when it is application limited and has no data to send, or when it marks
packets as lost (and therefore not in flight).
A sender becomes idle if it has no bytes in flight. A sender can become idle
when it is application limited and has no data to send, or when it marks packets
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
when it is application limited and has no data to send, or when it marks packets
when it is application limited and has no data to send, or when it marks all packets

as lost (and therefore not in flight).
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
as lost (and therefore not in flight).
as lost, and therefore not in flight.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can this also happen when all packets are acknowledged? I'm not sure what the preferred behavior is in that case. But the current text now properly captures the "my last PTO was acked and everything else was declared lost."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that is a fine case ... this is what we've always had, the RTO text was incorrect. Basically the sender goes idle as soon as bytes in flight goes to 0. Maybe that's all we need to say. I've removed more text to make this clearer.


A sender's congestion window MUST not increase while it is idle.

Expand Down