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

[Nick Banks <[e-mail]>]

nibanks commented on this pull request.



>  
-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
-one ACK-frame-only packet in response to receiving an ACK-eliciting packet
-(one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT
-send a packet containing only an ACK frame in response to a non-ACK-eliciting
-packet (one containing only ACK and/or PADDING frames), even if there are
-packet gaps which precede the received packet. Limiting ACK frames avoids an
-infinite feedback loop of acknowledgements, which could prevent the connection
-from ever becoming idle. However, the endpoint acknowledges non-ACK-eliciting
-packets when it sends an ACK frame.
+A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT
+estimate or the value it indicates in the `max_ack_delay` transport parameter.
+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.

Does this text `SHOULD NOT exceed the current RTT estimate` mean the peer could/should use a min of the max_ack_delay and the current RTT when computing probe timeouts?
```
PTO = smoothed_rtt + max(4*rttvar, kGranularity) + min(max_ack_delay, smoothed_rtt)
```

-- 
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-287036888