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

Tweaks for the draining period #870

Merged
merged 3 commits into from Oct 25, 2017
Merged

Tweaks for the draining period #870

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5eca32c
Tweaks for the draining period
martinthomson Oct 13, 2017
9ead474
Stateless reset works for early exit too
martinthomson Oct 13, 2017
cc9d717
Editorial tweak
martinthomson Oct 25, 2017
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
24 changes: 17 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1522,20 +1522,30 @@ from its peer. These packets might have been sent prior to receiving any close
signal, or they might be retransmissions of packets for which acknowledgments
were lost.

The draining period persists for three times the current Retransmission Timeout
(RTO) interval as defined in {{QUIC-RECOVERY}}. During this period, new packets
can be acknowledged, but no new application data can be sent on the connection.
The draining period exists to ensure that delayed or reordered packets are
properly discarded. This state SHOULD persist for three times the current
Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}. During
this period no new application data can be sent on the connection.

Different treatment is given to packets that are received while a connection is
in the draining period depending on how the connection was closed.

An endpoint that is in a draining period MUST NOT send packets unless they
contain a CONNECTION_CLOSE or APPLICATION_CLOSE frame.
in the draining period depending on how the connection was closed. An endpoint
that is in a draining period MUST NOT send packets unless they contain a
CONNECTION_CLOSE or APPLICATION_CLOSE frame.

Once the draining period has ended, an endpoint SHOULD discard per-connection
state. This results in new packets on the connection being discarded. An
endpoint MAY send a stateless reset in response to any further incoming packets.

An endpoint MAY exit the draining period earlier if it can guarantee that its
peer is also draining. Receiving a CONNECTION_CLOSE or APPLICATION_CLOSE frame
is sufficient confirmation, as is receiving a stateless reset. However,
disposing of connection state could result in delayed or reordered packets to be
handled poorly. For endpoints that have some alternative means to ensure that
late-arriving packets on the connection do not create QUIC state, such as by
closing the UDP socket, an abbreviated draining period can allow for faster
resource recovery. Servers that retain an open port for accepting new
connections SHOULD NOT exit the draining period early.

The draining period does not apply when a stateless reset ({{stateless-reset}})
is sent.

Expand Down