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

MUST pace or limit bursts to 10 packets #3106

Merged
merged 3 commits into from
Oct 17, 2019
Merged

MUST pace or limit bursts to 10 packets #3106

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a7ad371
MUST pace or limit bursts to 10 packets
ianswett Oct 17, 2019
dc891d8
Merge branch 'master' into ianswett-limit-bursts
ianswett Oct 17, 2019
8aa3f26
Update draft-ietf-quic-recovery.md
ianswett Oct 17, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -753,6 +753,12 @@ delivery of ACK frames is important for efficient loss recovery. Packets
containing only ACK frames should therefore not be paced, to avoid delaying
their delivery to the peer.

Sending multiple packets into the network without any delay between them
creates a packet burst that might cause short-term congestion and losses.
Implementations MUST either use pacing or limit such bursts to minimum
ianswett marked this conversation as resolved.
Show resolved Hide resolved
of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same
as the recommended initial congestion window.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry again late here... To we recommend a fixed value of 10 packets or do we recommend to have the burst limit the same as the initial window? E.g. if we decide in future to increase our recommendation for the initial window, should that also increase the recommendation for the burst limit? I guess to be really smart about this, you would need to say that you set the burst but initial window but decrease if you see tail loss in the initial burst (but that might be an overkill).

Copy link
Member

Choose a reason for hiding this comment

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

Or you could say that there are different initial window and burst limits, which is probably OK. I don't think that we need to be that smart though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point. We could swap the sentence and say "same as the initial congestion window, which is recommended to be ..." if you think it's preferable. But I'm also not sure it matters much.

Copy link
Member

Choose a reason for hiding this comment

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

I think that explicitly saying "Initial congestion window" here as the primary target of the MUST requirement would be better.

Copy link
Contributor

Choose a reason for hiding this comment

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

Fine for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

PR created, PTAL: #3160

As an example of a well-known and publicly available implementation of a flow
pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
in Linux (3.11 onwards).
Expand All @@ -773,13 +779,6 @@ and not fully utilize the congestion window due to this delay. A sender
should not consider itself application limited if it would have fully
utilized the congestion window without pacing delay.

Sending multiple packets into the network without any delay between them
creates a packet burst that might cause short-term congestion and losses.
Implementations SHOULD either use pacing or reduce their congestion window
to limit such bursts to minimum of 10 * kMaxDatagramSize and
max(2* kMaxDatagramSize, 14720)), the same as the recommended initial
congestion window.

A sender MAY implement alternative mechanisms to update its congestion window
after periods of under-utilization, such as those proposed for TCP in
{{?RFC7661}}.
Expand Down