-
Notifications
You must be signed in to change notification settings - Fork 131
feat: Send and process ACK-ECN #1678
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
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1678 +/- ##
==========================================
+ Coverage 93.13% 93.16% +0.03%
==========================================
Files 117 119 +2
Lines 36342 36635 +293
==========================================
+ Hits 33846 34130 +284
- Misses 2496 2505 +9 ☔ View full report in Codecov by Sentry. |
Making this a draft PR again until I can add some tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what my review is worth, this looks good to me.
@KershawChang @martinthomson when you have a chance, please review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, this looks good to me.
Pull request was converted to draft
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting there for sure. No CC response, but sending and receiving is useful.
Happening with #1689 @martinthomson. |
@martinthomson thanks for the detailed review. I think I fixed most things, see the review responses on a few things where I was unclear. We probably need to implement something like https://datatracker.ietf.org/doc/html/rfc9000#section-a.4; the current disablement based on a fixed number of lost packets on a path is obviously bad, because eventually we will exceed that number. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
If this makes ngtcp2 happy, refactor into separate PR.
Signed-off-by: Lars Eggert <[email protected]>
@KershawChang @martinthomson this is - yet again - ready for review. |
Co-authored-by: Max Inden <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Max Inden <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Max Inden <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Martin Thomson <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Martin Thomson <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Martin Thomson <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Martin Thomson <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Martin Thomson <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Co-authored-by: Martin Thomson <[email protected]> Signed-off-by: Lars Eggert <[email protected]>
Minor other tweaks.
The remaining bits from #1495
The remaining todo item after this PR is to actually act on incoming CE marks, i.e., trigger a congestion control action.