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

Does the amplification limit apply to PTO packets? #3413

Closed
martinthomson opened this issue Feb 4, 2020 · 3 comments · Fixed by #3539
Closed

Does the amplification limit apply to PTO packets? #3413

martinthomson opened this issue Feb 4, 2020 · 3 comments · Fixed by #3539
Assignees
Labels
-transport editorial

Comments

@martinthomson
Copy link
Member

@martinthomson martinthomson commented Feb 4, 2020

From @gorryfair in #3214, this is not a nit:

Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have
received.

So, let me understand - does that include retransmissions? or is this constrain within the PTO or something?

I think that the intent was that the server limit its sending, including PTO.

@mnot mnot added this to Triage in Late Stage Processing Feb 5, 2020
@larseggert larseggert added the design label Feb 5, 2020
@project-bot project-bot bot moved this from Triage to Design Issues in Late Stage Processing Feb 5, 2020
@larseggert
Copy link
Member

@larseggert larseggert commented Feb 5, 2020

Discussed in ZRH. Proposed resolution is "yes".

@larseggert larseggert added the editorial label Feb 5, 2020
@project-bot project-bot bot moved this from Design Issues to Editorial Issues in Late Stage Processing Feb 5, 2020
@larseggert larseggert removed the design label Feb 5, 2020
@ekr
Copy link
Collaborator

@ekr ekr commented Feb 5, 2020

Repeating what I said earlier: it's not clear to me that not being able to arm the PTO timer when at the limit implies that PTO packets count against the amplification limit. The reason is that you could have already armed the PTO timer at the time you hit the limit. E.g., you might be streaming 0.5RTT and so send Initial, Handshake, arm timer, 0.5RTT.

@ianswett ianswett self-assigned this Mar 22, 2020
@ianswett
Copy link
Contributor

@ianswett ianswett commented Mar 22, 2020

@ekr the PTO should be updated when an ack-eliciting packet is sent, since the right edge moves, so that case should already be handled correctly. I'll write an editorial PR to try to make all this extra clear.

Actually, the PTO section already has "A sender computes its PTO timer every time an ack-eliciting packet is sent."

Late Stage Processing automation moved this from Editorial Issues to Text Incorporated Mar 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial
Projects
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

4 participants