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.

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

Exception in ECN detection when ACK loss happens #1555

Merged
merged 7 commits into from
Jul 14, 2018

Conversation

gloinul
Copy link
Contributor

@gloinul gloinul commented Jul 12, 2018

Adding an exception to the ECN detection to handle ACK loss if that occurs.

Fixes Issue #1481

@@ -1738,6 +1738,14 @@ network, an endpoint verifies the following when an ACK_ECN frame is received:

* The increase in ECT(0) and ECT(1) counters MUST be no greater than the number
of packets newly acknowledged that were sent with the corresponding codepoint.

* If the increase in the ECT(0), ECT(1) and CE counters are greater than the
number of newly ACKed packets, and received ACK's smallest acknowledged or
Copy link
Contributor

Choose a reason for hiding this comment

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

I would just say "ACK's smallest acknowledged" and drop "or gap indicated packet number"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Implemented.


* If the increase in the ECT(0), ECT(1) and CE counters are greater than the
number of newly ACKed packets, and received ACK's smallest acknowledged or
gap indicated packet number is larger than previously largest acknowledged
Copy link
Contributor

Choose a reason for hiding this comment

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

How about: "...larger than the previous largest acknowledged, then it's likely acknowledgements were missed, and the above comparison MUST NOT be performed."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Implemented

@@ -1739,6 +1739,13 @@ network, an endpoint verifies the following when an ACK_ECN frame is received:
* The increase in ECT(0) and ECT(1) counters MUST be no greater than the number
of packets newly acknowledged that were sent with the corresponding codepoint.

* If the increase in the ECT(0), ECT(1) and CE counters are greater than the
number of newly ACKed packets, and received ACK's smallest acknowledged is
Copy link
Contributor

Choose a reason for hiding this comment

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

ACKed -> acknowledged
received -> the received

then it's likely acknowledgements were missed, and the above comparison
MUST NOT be performed. Instead a new comparision point is stored by the
sender so that only changes after this point will be used in the future
comaparisions.
Copy link
Contributor

Choose a reason for hiding this comment

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

Mikkel's right, comaparisons -> comparisons

@@ -1739,6 +1739,14 @@ network, an endpoint verifies the following when an ACK_ECN frame is received:
* The increase in ECT(0) and ECT(1) counters MUST be no greater than the number
of packets newly acknowledged that were sent with the corresponding codepoint.

* If the increase in the ECT(0), ECT(1) and CE counters are greater than
the number of newly acknowledged packets, and the received ACK's
smallest acknowledged is larger than the previous largest acknowledged,
Copy link
Member

Choose a reason for hiding this comment

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

As I pointed out, this isn't ideal and will lead to ECN being disabled in some cases. I don't know how much we are going to want to worry about that though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants