Specify RST-like behavior for CONNECTION_CLOSE. Fixes #330, #328 #705
Conversation
|
lgtm, maybe could use some guidance on how exactly the server could implement such a mechanism, however we can always add that later once we have more implementation experience. |
|
This is not entirely clear to me. If there is a requirement for backing off, but no requirement for replying to a connection close (is there?), then state will just be tied up for no good reason. If you have 100K connections per minute, and you need to hold a connection for 10 minutes to make sure you can back off, well ... |
|
See my email on this topic to the list where I lay out the tradeoffs. |
draft-ietf-quic-transport.md
Outdated
| implementations MUST NOT send any non-closing packets on that connection. If | ||
| additional packets are received after this time, implementations | ||
| SHOULD respond to them by sending either a CONNECTION_CLOSE frame or a | ||
| Public Reset packet, either of which may just be a duplicate of a |
There was a problem hiding this comment.
I recommend that you use CONNECTION_CLOSE here and instead note that an endpoint MAY send a Public Reset instead if it doesn't want to save the state necessary to generate CONNECTION_CLOSE.
There's a sliding scale here:
- maintain full state and generate a new CONNECTION_CLOSE in a new packet
- only keep the packet that holds CONNECTION_CLOSE and retransmit that unmodified
- drop state and rely on Public/Stateless Reset
There was a problem hiding this comment.
I'm happy to revise this if that's the consensus. I was trying to be flexible.
There was a problem hiding this comment.
I agree that 2 and 3 are a sliding scale and that's why SHOULD makes sense to me. I haven't come up with any reasons why option 1 is preferable to 2, so I would not suggest it, but maybe there are some reasons I haven't come up with?
There was a problem hiding this comment.
I agree with Ian that we don't need the endpoint to maintain complete state, so 2 and 3 make sense. I'd suggest that we add a suggestion about how long a peer resends CONNECTION_CLOSE after sending it once (basically how long state should be kept in option (2)), and I propose idle_timeout as a time period that makes sense.
There was a problem hiding this comment.
I think that we should allow all three, though gently discourage 3.
There was a problem hiding this comment.
Whats the argument for allowing 1?
draft-ietf-quic-transport.md
Outdated
| Public Reset packet, either of which may just be a duplicate of a | ||
| previous packet. Implementations SHOULD throttle these responses, for | ||
| instance by exponentially backing off the number of packets which must | ||
| be received before sending a response. |
|
lgtm. I have a non-blocking suggestion in my inline comment. |
|
How's this look? |
|
LGTM. Not a major issue, but the line breaks are at odd places. If you are able to, please format them to 80 cols. |
|
I'd like to merge this. martinthomson@, if you think we should make the text more accommodating, let's do that separately. |
No description provided.