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

CONNECTION_CLOSE is non-ack-eliciting #3098

Merged
merged 5 commits into from Oct 31, 2019
Merged

CONNECTION_CLOSE is non-ack-eliciting #3098

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e9f4ada
CONNECTION_CLOSE is non-ack-eliciting
kazuho Oct 16, 2019
f7eed75
@ianswett's suggestions
kazuho Oct 16, 2019
ca86dd1
Update draft-ietf-quic-recovery.md
kazuho Oct 22, 2019
c1be511
Update draft-ietf-quic-transport.md
kazuho Oct 22, 2019
af7a876
wordwrap
kazuho Oct 22, 2019
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
7 changes: 4 additions & 3 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -123,7 +123,8 @@ In-flight:

Ack-eliciting Frames:

: All frames besides ACK or PADDING are considered ack-eliciting.
: All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered
ack-eliciting.

Ack-eliciting Packets:

Expand Down Expand Up @@ -167,8 +168,8 @@ of frames contained in a packet affect recovery and congestion control logic:
performance of the QUIC handshake and use shorter timers for
acknowledgement.

* Packets that contain only ACK frames do not count toward congestion control
limits and are not considered in-flight.
* Packets containing frames besides ACK or CONNECTION_CLOSE frames count toward
congestion control limits and are considered in-flight.

* PADDING frames cause packets to contribute toward bytes in flight without
directly causing an acknowledgment to be sent.
Expand Down
19 changes: 10 additions & 9 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -192,8 +192,9 @@ QUIC packet:

Ack-eliciting Packet:

: A QUIC packet that contains frames other than ACK and PADDING. These cause a
recipient to send an acknowledgment (see {{sending-acknowledgements}}).
: A QUIC packet that contains frames other than ACK, PADDING, and
CONNECTION_CLOSE. These cause a recipient to send an acknowledgment (see
Copy link
Contributor

Choose a reason for hiding this comment

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

If you bundle a CONNECTION_CLOSE with other frames, it's still not ack ack-eliciting, is it?

Copy link
Contributor

Choose a reason for hiding this comment

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

It would be, but it wouldn't really matter because the connection will close.

{{sending-acknowledgements}}).

Endpoint:

Expand Down Expand Up @@ -2351,11 +2352,11 @@ current Probe Timeout (PTO).

Each endpoint advertises its own idle timeout to its peer. An endpoint
restarts any timer it maintains when a packet from its peer is received and
processed successfully. The timer is also restarted when sending a packet
containing frames other than ACK or PADDING (an ack-eliciting packet; see
{{QUIC-RECOVERY}}), but only if no other ack-eliciting packets have been sent
since last receiving a packet. Restarting when sending packets ensures that
connections do not prematurely time out when initiating new activity.
processed successfully. The timer is also restarted when sending an
ack-eliciting packet (see {{QUIC-RECOVERY}}), but only if no other ack-eliciting
packets have been sent since last receiving a packet. Restarting when sending
packets ensures that connections do not prematurely time out when initiating new
activity.

The value for an idle timeout can be asymmetric. The value advertised by an
endpoint is only used to determine whether the connection is live at that
Expand Down Expand Up @@ -2992,8 +2993,8 @@ valid frames? -->
## Generating Acknowledgements {#generating-acks}

Endpoints acknowledge all packets they receive and process. However, only
ack-eliciting packets (see {{QUIC-RECOVERY}}) trigger the sending of an ACK
frame. Packets that are not ack-eliciting are only acknowledged when an ACK
ack-eliciting packets cause an ACK frame to be sent within the maximum ack
delay. Packets that are not ack-eliciting are only acknowledged when an ACK
frame is sent for other reasons.

When sending a packet for any reason, an endpoint should attempt to bundle an
Expand Down