Re: [quicwg/base-drafts] Move Generating Acknowledgements to Transport (#2916)

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.



>  ### Sending ACK Frames
 
-An endpoint sends ACK frames to acknowledge packets it has received and
-processed.
+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.

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.


> @@ -3020,9 +3059,34 @@ This ensures an acknowledgment is sent at least once per RTT when packets
 needing acknowledgement are received.  The sender can use the receiver's
 `max_ack_delay` value in determining timeouts for timer-based retransmission.
 
-Strategies and implications of the frequency of generating acknowledgments are
-discussed in more detail in {{QUIC-RECOVERY}}.
+### Managing ACK Ranges
+
+When an ACK frame is sent, one or more ranges of acknowledged packets are
+included.  Including older packets reduces the chance of spurious retransmits
+caused by losing previously sent ACK frames, at the cost of larger ACK frames.
+
+ACK frames SHOULD always acknowledge the most recently received packets, and the
+more out-of-order the packets are, the more important it is to send an updated
+ACK frame quickly, to prevent the peer from declaring a packet as lost and
+spuriously retransmitting the frames it contains.
+
+Below is one recommended approach for determining what packets to include in an

"Below" is a little imprecise.  Is this the next section, or next several sections?

```suggestion
{{ack-tracking}} and {{ack-limiting}} describe an exemplary approach for determining what packets to acknowledge in each
```

>  
+### Receiver Tracking of ACK Frames

```suggestion
### Receiver Tracking of ACK Frames {#ack-tracking}
```

>  
+### Receiver Tracking of ACK Frames
+
+When a packet containing an ACK frame is sent, the largest acknowledged in that
+frame may be saved.  When a packet containing an ACK frame is acknowledged, the
+receiver can stop acknowledging packets less than or equal to the largest
+acknowledged in the sent ACK frame.
+
+In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT
+of reordering. In cases with ACK frame loss and reordering, this approach does
+not guarantee that every acknowledgement is seen by the sender before it is no
+longer included in the ACK frame. Packets could be received out of order and
+all subsequent ACK frames containing them could be lost. In this case, the
+loss recovery algorithm could cause spurious retransmits, but the sender will
+continue making forward progress.
 
 ### Limiting ACK Ranges

```suggestion
### Limiting ACK Ranges {#ack-limiting}
```

> +### Measuring and Reporting Host Delay {#host-delay}
+
+An endpoint measures the delays intentionally introduced between when an
+ACK-eliciting packet is received and the corresponding acknowledgment is sent.
+The endpoint encodes this delay for the largest acknowledged packet in the Ack
+Delay field of an ACK frame (see {{frame-ack}}). This allows the receiver of the
+ACK to adjust for any intentional delays, which is important for getting a
+better estimate of the path RTT when acknowledgments are delayed. A packet might
+be held in the OS kernel or elsewhere on the host before being processed.  An
+endpoint MUST NOT include delays that is does not control when populating the
+Ack Delay field in an ACK frame.
+
+An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting
+packets.  An endpoint commits to a maximum delay using the max_ack_delay
+transport parameter; see {{transport-parameter-definitions}}.  max_ack_delay
+implies an explicit contract: an endpoint promises to never delay

implies explicit is odd:

```suggestion
declares an explicit contract: an endpoint promises to never delay
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2916#pullrequestreview-286527818