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

Server SHOULD send full-sized datagrams until the path is validated #4188

Merged
merged 25 commits into from Oct 15, 2020
Merged

Server SHOULD send full-sized datagrams until the path is validated #4188

Changes from 1 commit
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
6e76817
server sends full-size datagrams until the path is validated
kazuho Oct 8, 2020
1214c15
Update draft-ietf-quic-transport.md
kazuho Oct 8, 2020
78500d1
Update draft-ietf-quic-transport.md
kazuho Oct 8, 2020
5727b87
Update draft-ietf-quic-transport.md
kazuho Oct 8, 2020
56569b9
wordwrap
kazuho Oct 8, 2020
8ec73e1
update back reference to cover padding
kazuho Oct 9, 2020
97b8798
reduce the recommendation of padding to Initial packets only; restric…
kazuho Oct 9, 2020
bd089c9
Drop "unless the client address is validated", merging the requirements.
kazuho Oct 9, 2020
271010c
Update draft-ietf-quic-transport.md
kazuho Oct 9, 2020
a3351be
Update draft-ietf-quic-transport.md
kazuho Oct 9, 2020
0410b60
when to pad is independent from path validation
kazuho Oct 14, 2020
6e0fe53
at most once is likely enough
kazuho Oct 14, 2020
681c02e
Update draft-ietf-quic-transport.md
kazuho Oct 14, 2020
34ad874
servers MUST pad Initial packets carrying CRYPTO frames
kazuho Oct 14, 2020
c30347b
wordwrap
kazuho Oct 14, 2020
67e49f8
pad Initial with CRYPTO frames -> pad ack-eliciting Initial
kazuho Oct 14, 2020
3518d54
editorial
ianswett Oct 15, 2020
a51ad56
@martinthomson's suggestion with tweaks
kazuho Oct 15, 2020
1bb33b1
Update draft-ietf-quic-transport.md
kazuho Oct 15, 2020
3f875ca
Update draft-ietf-quic-transport.md
kazuho Oct 15, 2020
e3a596f
revert changes to the address validation section, as server-side requ…
kazuho Oct 15, 2020
c550cb4
editorial
janaiyengar Oct 15, 2020
adbe600
wordwrap
kazuho Oct 15, 2020
8f5dff7
Update draft-ietf-quic-recovery.md
kazuho Oct 15, 2020
b1ab5f8
Update draft-ietf-quic-recovery.md
kazuho Oct 15, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1923,7 +1923,7 @@ packets that are all discarded.
Clients MUST and servers SHOULD ensure that UDP datagrams containing Initial
packets have UDP payloads of at least 1200 bytes, adding PADDING frames as
necessary. A client that sends padded datagrams allows the server to send more
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be better to limit the scope and say servers SHOULD pad Initial packets that carry crypto data.

The problem of padding all Initial packets is that ACK-only Initial packets consume full MTU, when the send window is still controlled by the amplification limit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think making a carve-out for ACK-only packets sounds attractive, but it could result in the client sending an Initial, getting it acknowledged, but not receiving the server's Initial. Then things get complex to reason about.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that the special rules for ACK-only is enough to justify an exception. I could tolerate non-ack-eliciting packets being exempt from this padding rule, but it seems unnecessary. We already have one exception.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Endpoints that don't coalesce are already trading performance for simplicity. The added sacrifice here isn't that large.

  1. Clients: if it only receives an Initial, padding is critical to raising the amplification limit. If it gets a Handshake packet too, it will momentarily send a Handshake ACK that will allow it to free the Initial context and get the cwnd back.

  2. Servers: If the client has a valid Retry or NEW_TOKEN token, there is no amplification limit. So the performance penalty only applies to a non-coalescing server when:
    (a) There is no token, AND the Initial padding causes the handshake flight to go over the amplification limit.
    (b) The initial padding causes the handshake flight to go over the initial cwnd.
    I find it hard to believe a server deeply concerned about these losses would not coalesce packets for other reasons.

data prior to completing address validation. Endpoints using UDP datagrams of
data prior to completing address validation. Endpoints sending UDP datagrams of
at least 1200 bytes ensures that the handshake progresses only if the path is
capable of handling QUIC traffic; see {{packet-size}}.

Expand Down