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

kMaxDatagramSize should use the PMTU rather than be fixed #3041

Closed
janaiyengar opened this issue Sep 17, 2019 · 2 comments · Fixed by #3167
Closed

kMaxDatagramSize should use the PMTU rather than be fixed #3041

janaiyengar opened this issue Sep 17, 2019 · 2 comments · Fixed by #3167
Assignees
@ianswett
Labels
-recovery design An issue that affects the design of the protocol; resolution requires consensus.

Comments

@janaiyengar
Copy link
Contributor

kMaxDatagramSize is currently set to the minimum packet size of 1200 bytes. It should be set instead to the max packet size used by the connection, which is discussed in Section 14.1 of the transport draft.

(Issue raised by Timo Völker on the mailing list.)
@janaiyengar janaiyengar added design An issue that affects the design of the protocol; resolution requires consensus. -recovery labels Sep 17, 2019
@ianswett
Copy link
Contributor

ianswett commented Sep 17, 2019 •
edited
Loading

My reading is that this value is the actual max packet size used in the connection, it's just not clear from the explanation. kInitialWindow and kMinimumWindow are also per-connection fields defined directly below.
https://tools.ietf.org/html/draft-ietf-quic-recovery-23#appendix-B.1

There is one potential detail, which is if the MTU increases after the handshake, do the min CWND and Reno behavior change accordingly? I think it's simpler to reason about them not changing, but I can see both arguments and in the end I don't think it'll matter that much.

@nibanks
Copy link
Member

nibanks commented Sep 17, 2019

WinQuic uses the currently calculated path MTU instead a constant kMaxDatagramSize.

@martinthomson martinthomson changed the title kMaxDatagramSize should use the maximum packet size of the connection kMaxDatagramSize should use the PMTU rather than be fixed Oct 15, 2019
@janaiyengar janaiyengar self-assigned this Oct 15, 2019
ianswett added a commit that referenced this issue Oct 29, 2019
@ianswett
kMaxDatagramSize -> max_datagram_size
f436b81 
Clarifies that this is the maximum datagram size currently in use on the connection.

Fixes #3041
@ianswett ianswett assigned ianswett and unassigned janaiyengar Oct 29, 2019
@ianswett ianswett mentioned this issue Oct 29, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ianswett ianswett

Labels
-recovery design An issue that affects the design of the protocol; resolution requires consensus.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

kMaxDatagramSize -> max_datagram_size quicwg/base-drafts
3 participants
@janaiyengar @ianswett @nibanks