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

Fix to ECN section regarding validation #2113

Merged
merged 8 commits into from Dec 13, 2018
Merged

Fix to ECN section regarding validation #2113

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
239f4c2
Addressing issue that CE marks was not handled in per ECT type check.
gloinul Dec 11, 2018
eb7c2c8
Fixing one unclear sentence.
gloinul Dec 11, 2018
3a72fbd
Clarifies puprose of the validation bullets.
gloinul Dec 11, 2018
3faded4
Added paragraph of conditions when the comparisons should not be perf…
gloinul Dec 11, 2018
e2b6303
Apply suggestions from code review
gloinul Dec 12, 2018
0a2edd0
Removed unnecessary restriction. Added notices that local reference c…
gloinul Dec 12, 2018
43b6f67
Added text on dealing with reordered ACKs.
gloinul Dec 12, 2018
566f72e
Applying Martin Thomson's suggested fixes for restructuring.
gloinul Dec 13, 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
14 changes: 7 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -3019,18 +3019,18 @@ frame is received:

* The increase in ECT(0) and ECT(1) counters MUST be at least the number of QUIC
packets newly acknowledged that were sent with the corresponding codepoint
minus the increase in the CE counter. This detects network remarking
between ECT(0) and ECT(1).
minus the increase in the CE counter. This detects network remarking between
ECT(0) and ECT(1).

* The total increase in ECT(0), ECT(1), and CE counters reported in the ACK
frame MUST be at least the total number of QUIC packets newly acknowledged in
this ACK frame. This detects if the network remark ECT(0), ECT(1) or CE to
this ACK frame. This detects if the network changes ECT(0), ECT(1) or CE to
Not-ECT.

If a sender receives an ACK that contains no new acknowledgments, for example
due to reordering of the ACKs, then ECN counter comparison SHOULD NOT be
performed. If the sender does not have state to determine if a particular PSN
is newly acknowledged or not, then the comparison SHOULD NOT be performed.
If the sender does not have state to determine if a particular packet number is
newly acknowledged or not, then the comparison SHOULD NOT be performed. By the
Copy link
Member

Choose a reason for hiding this comment

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

Is this really a SHOULD NOT? If the sender doesn't have that state, it CANNOT perform that check. That's not a 2119 keyword, unfortunately :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, I will rewrite this as non 2119 terms basically stating to not perform the comparison.

It is a bit like the formulation in RFC 3550:
"Note that if R is zero, the
percentage of senders is never greater than S/(S+R), and the
implementation must avoid division by zero."

end of the verification process the local reference counter must have be updated
to include the newly acknowledged packets.

gloinul marked this conversation as resolved.
Show resolved Hide resolved
An endpoint could miss acknowledgements for a packet when ACK frames are lost.
It is therefore possible for the total increase in ECT(0), ECT(1), and CE
Expand Down