Re: [quicwg/base-drafts] MUST ACK each ack-eliciting packet once (#3092)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> +Every packet SHOULD be acknowledged at least once, and ack-eliciting packets
+MUST be acknowledged at least once within the maximum ack delay. An endpoint

No, it doesn't, because you have no guarantee that you received every ACK the peer sent.  This requires the peer to put every packet into an ACK frame sent in at least one packet; there's no requirement to ensure that it's delivered reliably to the peer.  Thus, if you haven't received an ACK, that doesn't mean the peer didn't received the packet anyway.  It could be delayed and still in transit, or the ACK might have been lost.

That said, there's no actual difference between "MUST ack every packet, but not reliably" and "SHOULD ack every packet" from the other side's point of view.  This is something that could be bench-tested on an implementation, but can't be ascertained about the peer over a lossy network.

> @@ -3007,25 +3007,26 @@ guidance offered below seeks to strike this balance.
 
 ### Sending ACK Frames {#sending-acknowledgements}
 
+Every packet SHOULD be acknowledged at least once, and ack-eliciting packets
+MUST be acknowledged at least once within the maximum ack delay. An endpoint
+communicates its maximum delay using the max_ack_delay transport parameter;
+see {{transport-parameter-definitions}}.  max_ack_delay declares an explicit

It's probably correct to start the sentence with a lower-case letter, since this is a literal name of a protocol element, but it looks weird.  Consider rephrasing to avoid the question.

-- 
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/3092#pullrequestreview-306812844