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

Move Generating Acknowledgements to Transport #2916

Merged
merged 22 commits into from Sep 11, 2019
Merged

Move Generating Acknowledgements to Transport #2916

Changes from 1 commit
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
812ced0
Move Generating Acknowledgements to Transport
ianswett Jul 21, 2019
f8fc854
Move, don't just remove the text
ianswett Jul 21, 2019
cfab7ed
Remove the "Crypto Handshake Data" section
ianswett Jul 21, 2019
4ac701e
Stop referencing QUIC Transport
ianswett Jul 21, 2019
862bcd3
Remove obsolete text
ianswett Jul 21, 2019
f364aab
Stop referencing host-delay in Recovery
ianswett Jul 21, 2019
50f2a55
Fix CircleCI (hopefully)
ianswett Jul 21, 2019
eed60b2
Update draft-ietf-quic-recovery.md
ianswett Jul 21, 2019
67ece93
Update draft-ietf-quic-transport.md
janaiyengar Aug 27, 2019
6ff4cc0
Update draft-ietf-quic-transport.md
janaiyengar Aug 27, 2019
1a07dcd
Update draft-ietf-quic-transport.md
janaiyengar Aug 27, 2019
ce3c950
Update draft-ietf-quic-transport.md
janaiyengar Aug 27, 2019
d77285c
Update draft-ietf-quic-transport.md
janaiyengar Aug 27, 2019
19df215
Addresses comments and some text rework
janaiyengar Sep 11, 2019
55f1ad9
re-adding (with some rework) text that was dropped inadvertently
janaiyengar Sep 11, 2019
d60f633
rebase cleanup
janaiyengar Sep 11, 2019
17196dc
Update draft-ietf-quic-transport.md
ianswett Sep 11, 2019
02bbcdf
Update draft-ietf-quic-transport.md
ianswett Sep 11, 2019
35a6072
Update draft-ietf-quic-transport.md
ianswett Sep 11, 2019
ac3e437
Update draft-ietf-quic-transport.md
ianswett Sep 11, 2019
6910bce
Reflow a line
ianswett Sep 11, 2019
5a8af76
moving text around a bit and mt's comment
janaiyengar Sep 11, 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
23 changes: 13 additions & 10 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2999,11 +2999,14 @@ An ACK frame SHOULD be sent immediately upon receipt of a second ack-eliciting
packet. Loss detection does not assume that the peer sends an ACK immediately on
receiving a second ack-eliciting packet.
Copy link
Member

Choose a reason for hiding this comment

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

These are both good and useful statements, but they sort of stand awkwardly next to each other as if they are strangers.

An endpoint SHOULD immediately send an ACK frame when two ack-eliciting packets have been received without being acknowledged. Though the algorithms in {{QUIC-RECOVERY}} do not depend on receivers following this guidance, frequent feedback improves loss and congestion response.

I tried to say something about the fact that this also provides some assurances about acknowledgement behaviour that senders could use when innovating with new algorithms, but it ended up being quite hard to do that without distracting too much from the core purpose of the section. Also, the SHOULD got in the way: there is no real assurance, there we have to rely on the fact that this is a good recommendation that most deployments will likely respect.

Copy link
Member

Choose a reason for hiding this comment

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

@ianswett, not planning to do anything about this? I'll merge it now if you think we should just leave this alone.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I want to do another larger pass over this text, but I'd like to keep it as is for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm trying out something -- give me a few minutes

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, a few changes, look at the last commit. I've moved some text around and I think I've captured the spirit of this more clearly.


In order to accelerate loss detection and reduce timeouts, the receiver SHOULD
send an immediate ACK after it receives an out-of-order packet. It could send
immediate ACKs for in-order packets for a period of time that SHOULD NOT exceed
1/8 RTT unless more out-of-order packets arrive. If every packet arrives out-of-
order, then an immediate ACK SHOULD be sent for every received packet.
In order to accelerate loss detection, an endpoint SHOULD immediately send an
ACK frame when it receives an out-of-order packet that is ACK-eliciting. The
endpoint MAY continue sending ACK frames immediately on each subsequently
received packet, but the endpoint SHOULD return to acknowledging every other
packet after a period of 1/8 x RTT, unless more ACK-eliciting packets are
received out of order. If every subsequent ACK-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every received
ACK-eliciting packet.

Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in
the IP header SHOULD be acknowledged immediately, to reduce the peer's response
Expand All @@ -3014,11 +3017,11 @@ ACK frames in response. In this case the receiver can determine whether an
immediate or delayed acknowledgement should be generated after processing
incoming packets.

Acknowledgements of packets carrying CRYPTO frames SHOULD be delayed but
minimally, to complete the handshake with minimal latency. Delaying them allows
the endpoint to bundle any response data with this ACK frame. ACK frames SHOULD
be sent immediately when the crypto stack indicates all data for that packet
number space has been received.
Acknowledgements of packets carrying CRYPTO frames SHOULD be minimally delayed,
to complete the handshake with minimal latency. Delaying them by a small amount,
such as the local timer granularity, allows the endpoint to bundle any data sent
in response with the ACK frame. ACK frames SHOULD be sent immediately when the
crypto stack indicates all data for that packet number space has been received.

Packets containing only ACK frames are not congestion controlled, so there are
limits on how frequently they can be sent. An endpoint MUST NOT send more than
Expand Down