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

Better duplicate detection #3696

Merged
merged 7 commits into from May 27, 2020
Merged

Better duplicate detection #3696

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
927fe39
Better duplicate detection
martinthomson May 26, 2020
9f8038d
Remove migration from the example
martinthomson May 26, 2020
0f6ca28
Rewording to avoid potential confusion
martinthomson May 26, 2020
d90c544
Tweaking
martinthomson May 26, 2020
081f95f
Rewrap
martinthomson May 26, 2020
cbb0b2b
remove unnecessary sentence
martinthomson May 26, 2020
4d1bee3
plurals
martinthomson May 27, 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: 5 additions & 4 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -3209,10 +3209,11 @@ protection for the reasons described in Section 9.3 of {{QUIC-TLS}}.
Endpoints that track individual packets for the purposes of detecting duplicates
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
might accumulate excessive state. The data required for detecting duplicates
Copy link
Member

Choose a reason for hiding this comment

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

Would it be possible for us to recommend tracking ranges? For example, it might be a good idea to state like: For the purposes of detecting duplicates, endpoints might track individual packets or ranges of consecutive packet numbers, though tracking individual packets might accumulate excessive state.

Copy link
Member Author

Choose a reason for hiding this comment

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

I considered that, but I don't feel like a recommendation is necessary. It's the natural implementation strategy because of how we structured ACK frames, so there is enough bias there. But it crosses somewhat over from "here are the pitfalls" into "here is how you build a stack" too much for me.

Copy link
Member

Choose a reason for hiding this comment

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

Thank you for elaborating. This works for me.

martinthomson marked this conversation as resolved.
Show resolved Hide resolved
can be limited by maintaining a minimum packet number below which all packets
are immediately dropped. In setting a minimum packet number endpoints might
need to account for large variations in round trip time that could significantly
delay packets, especially when a peer probes a different network path; see
{{migration}}.
are immediately dropped. Endpoints that use a minimum packet number need to
ensure that any value does not cause delayed packets to be dropped. Any minimum
Copy link
Contributor

Choose a reason for hiding this comment

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

This doesn't apply to arbitrarily delayed packets, otherwise every minimum value will be too high.

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 I'd drop this sentence.

Copy link
Member Author

Choose a reason for hiding this comment

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

This was the entire point of the issue though.

needs to account for large variations in round trip time, which includes the
possibility that a peer might probe a network path with a much longer round trip
time; see {{migration}}.

Packet number encoding at a sender and decoding at a receiver are described in
{{packet-encoding}}.
Expand Down