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

ECN verification 3RTT period #4132

Closed
tatsuhiro-t opened this issue Sep 22, 2020 · 1 comment · Fixed by #4160
Closed

ECN verification 3RTT period #4132

tatsuhiro-t opened this issue Sep 22, 2020 · 1 comment · Fixed by #4160
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing

Comments

@tatsuhiro-t
Copy link
Contributor

https://tools.ietf.org/html/draft-ietf-quic-transport-30#section-13.4.2.1 and https://tools.ietf.org/html/draft-ietf-quic-transport-30#appendix-B describe ECN validation and they say :

To reduce the chances of misinterpreting congestive loss as packets
dropped by a faulty network element, an endpoint could set the ECT(0)
codepoint for only the first ten outgoing packets on a path, or for a
period of three RTTs, whichever occurs first.

Initial PTO timeout is also 3RTT. If client does not get ACK for its first flight Initial, after 3RTT later, it resends Initial without ECT set because client is now in "UNKNOWN" state.
If the first client Initial is really lost, ECN validation fails.

It seems to me that it would be better to lengthen timeout or ensure enough packets are sent not limited by the timeout?
@larseggert larseggert added this to Triage in Late Stage Processing via automation Sep 22, 2020
@ianswett ianswett added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Sep 22, 2020
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Sep 22, 2020
@marten-seemann
Copy link
Contributor

It seems like this particular problem was introduced by reducing the initial RTT from 500ms to 333ms (in #3823).

martinthomson added a commit that referenced this issue Sep 24, 2020
@martinthomson
Validate ECN for up to 3 PTO
fd871c3 
I tried to just make a note here saying "if you don't send many packets,
you won't send many packets", but then decided that 3PTO is probably
more sensible.  As it is, 3 RTT is the value that the PTO is initialized
to (validation almost always happens on a new path).  And the loss of a
single packet just doesn't cut it.  Even 3 packets (the first packet,
plus two on PTO, assuming two are sent on PTO) is not that strong, but
at least it isn't insanely tight.

Closes #4132.
@martinthomson martinthomson mentioned this issue Sep 24, 2020
Merged
Late Stage Processing automation moved this from Editorial Issues to Issue Handled Sep 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Validate ECN for up to 3 PTO quicwg/base-drafts
4 participants
@larseggert @tatsuhiro-t @marten-seemann @ianswett