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

Loosen the MUST requirement to close if an unsent packet is acknowledged #565

Merged
merged 1 commit into from
Jun 9, 2017
Merged

Loosen the MUST requirement to close if an unsent packet is acknowledged #565

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 1 addition & 1 deletion draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1590,7 +1590,7 @@ frames. A receiver MAY send timestamps for non-retransmittable packets.
A receiver MUST not send timestamps in unprotected packets.

A sender MAY intentionally skip packet numbers to introduce entropy into the
connection, to avoid opportunistic acknowledgement attacks. The sender MUST
connection, to avoid opportunistic acknowledgement attacks. The sender SHOULD
Copy link
Contributor

Choose a reason for hiding this comment

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

It could also say "The sender MUST close the connection if a packet it knows is unsent is acknowledged." Which keeps the must, but does not require unlimited 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.

@mcmanus, @siyengar, does Ian's suggestion work better?

Copy link
Contributor

Choose a reason for hiding this comment

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

"it knows" isn't really verifiable in any normative sense - it pretty much means SHOULD. prefer SHOULD.

Copy link

Choose a reason for hiding this comment

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

Generally I worry with a SHOULD no-one will end up implementing it because people will realize that it requires maintaining a lot of state. I like the spirit of Ian's wording but it's super confusing. SHOULD seems like the right thing here. I think if we acknowledge why it is a SHOULD it might convince more people to implement it along with a suggestion of how to implement it.

For example a sender could implement this by keeping track of all the packets sent and by advancing a smallest ackable packet periodically.

Copy link
Contributor

Choose a reason for hiding this comment

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

The wording could also be "SHOULD close a connection when receiving an ACK for a packet that has not been sent unless the packet is older that oldest retransmittable packet in which case the ackowledgement of that packet should be ignored."

Copy link
Contributor

Choose a reason for hiding this comment

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

But the retransmission queue may be sparse -- you don't necessarily know whether a packet no longer there was never sent or was simply already acknowledged.

SHOULD is supposed to have an explanation of why you might not. You SHOULD do this if you detect it, but you're not required to maintain enough state to detect it 100% of the time.

Copy link
Contributor

Choose a reason for hiding this comment

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

@MikeBishop I think I agree but isn't

But the retransmission queue may be sparse -- you don't necessarily know whether a packet no longer there was never sent or was simply already acknowledged.

a good reason for SHOULD?

close the connection if an unsent packet number is acknowledged. The format of
the ACK frame is efficient at expressing blocks of missing packets; skipping
packet numbers between 1 and 255 effectively provides up to 8 bits of efficient
Expand Down