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

MAY send 1 packet entering recovery #3443

Merged
merged 5 commits into from Mar 5, 2020
Merged

MAY send 1 packet entering recovery #3443

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
ecb7a76
MAY send 1 packet entering recovery
ianswett Feb 9, 2020
998a43f
Update pseudocode
ianswett Feb 9, 2020
02c2190
Update draft-ietf-quic-recovery.md
ianswett Feb 9, 2020
d7fabb0
Jana's suggestion
ianswett Feb 12, 2020
40ed461
Merge branch 'master' into ianswett-send-one-packet
janaiyengar Feb 28, 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
9 changes: 9 additions & 0 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -706,6 +706,13 @@ The recovery period limits congestion window reduction to once per round trip.
During recovery, the congestion window remains unchanged irrespective of new
losses or increases in the ECN-CE counter.

When entering recovery, a single packet MAY be sent even if bytes 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.

If it is possible to enter recovery before amplification mitigation is no longer needed, sending a packet upon entering recovery might contradict amp. rules.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, but the amplification factor is a MUST and this is a MAY, so I think the MUST wins here?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure. It depends on what you read first. It's like that NATO test with two pages of questions and instructions, the first stating to read everything first, the last stating the all other questions need not be answered. Why gives those entries priority over other entries?

now exceeds the recently reduced congestion window. This speeds up loss
recovery if the data in the lost packet is retransmitted and is similar to TCP
as described in Section 5 of {{?RFC6675}}. If further packets are lost while
the sender is in recovery, sending any packets in response MUST obey the
congestion window limit.

## Ignoring Loss of Undecryptable Packets

During the handshake, some packet protection keys might not be
Expand Down Expand Up @@ -1402,6 +1409,8 @@ window.
congestion_window *= kLossReductionFactor
congestion_window = max(congestion_window, kMinimumWindow)
ssthresh = congestion_window
// A packet can be sent to speed up loss recovery.
MaybeSendOnePacket()
~~~


Expand Down