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

Jump to bottom

Minimum packet size #69

Closed
ianswett opened this issue Dec 3, 2016 · 3 comments
Closed

Minimum packet size #69

ianswett opened this issue Dec 3, 2016 · 3 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@ianswett
Copy link
Contributor

ianswett commented Dec 3, 2016

Issue #64 brought up PTUMD, which brought up the issue of minimum packet size.

Stateless rejects require the CHLO to fit into one packet, so the minimum should be specified with that in mind.

#64 also brought up the issue of downgrade attacks, and given the vast majority of paths permit 1200 bytes, we should be able to agree on a reasonable(ie: >1k) minimum size.
@martinduke
Copy link
Contributor

I fully support a relatively large minimum packet size for QUIC. It massively mitigates the downside of some MTU-based attacks.

@martinduke
Copy link
Contributor

The other question here is, "what do we do if the reported path MTU is less than the minimum?" I think the answer is to simply ignore the lower MTU and keep sending big packets, even if that causes fragmentation. The alternative is to have an ICMP packet that can force TCP failover.

@janaiyengar janaiyengar added the needs-discussion An issue that needs more discussion before we can resolve it. label Jan 14, 2017
@mnot mnot added the design An issue that affects the design of the protocol; resolution requires consensus. label Jan 19, 2017
@mnot mnot changed the title Specify the minimum packet size required for QUIC Minimum packet size Jan 20, 2017
@mnot
Copy link
Member

mnot commented Jan 26, 2017

As discussed in Tokyo, resolved as part of #64 / PR #106

@mnot mnot closed this as completed Jan 26, 2017
@mnot mnot added notify-consensus and removed needs-discussion An issue that needs more discussion before we can resolve it. labels Jan 26, 2017
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Apr 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@mnot @janaiyengar @ianswett @martinduke