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 2 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
Original file line number Diff line number Diff line change
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
that late arriving packets on the connection are discarded, such as closing the
UDP port, an abbreviated draining period can allow for faster resource recovery.
Copy link
Contributor

Choose a reason for hiding this comment

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

(i) Closing the "port" makes no sense, you probably meant to say "socket".
(ii) Closing the port doesn't ensure that they;re discarded -- this can result in an ICMP message being generated in response. Perhaps say something like "to ensure that late-arriving packets on the connection do not create QUIC state, such as by closing the UDP socket"

Servers that retain an open port for accepting new connections SHOULD NOT exit
the draining period early.
Copy link
Contributor

Choose a reason for hiding this comment

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

This sentence is good.


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

Expand Down