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

Some more explanation on ECN validation #3767

Closed
wants to merge 1 commit into from
Closed

Some more explanation on ECN validation #3767

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
8 changes: 7 additions & 1 deletion draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3816,11 +3816,17 @@ marking strategies. Implementations MAY use other methods defined in RFCs; see
{{?RFC8311}}. Implementations that use the ECT(1) codepoint need to perform ECN
validation using ECT(1) counts.

If not all out-going packets are sent with the same codepoint, the sender has to
remember which packets were sent with which codepoint in order to perform the
validation steps in the next section.


#### Receiving ACK Frames {#ecn-ack}

An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits MUST
use the following steps on receiving an ACK frame to validate ECN.
use the following steps on receiving an ACK frame to validate ECN. In order to
perform these checks, the endpoint has to remember the values of each ECN Count
from the last ACK frame to calucate the increase since the last ACK.
Comment on lines +3827 to +3829
Copy link
Member

Choose a reason for hiding this comment

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

This seems to repeat the above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, this sentence is about remembering the ECN counts in the last ACK frame. The previous sentence was about remembering with marking a packet had when it was sent out.

I agree that all this was already implied and clear to me before but given #3733 I tried to make it explicit.


* If this ACK frame newly acknowledges a packet that the endpoint sent with
either ECT(0) or ECT(1) codepoints set, and if no ECN feedback is present in
Expand Down