Re: [quicwg/base-drafts] Prohibit PADDING in response to ACK (#3104)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Some editorial suggestions, including improving the existing text.

> @@ -3061,14 +3061,15 @@ of doing so.
 
 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.
+one ACK-frame-only packet in response to receiving an ACK-eliciting packet

Maybe we should shorten this to "ACK-only packet" or even "ACK packet" and then define it at the beginning of the document?

> @@ -3061,14 +3061,15 @@ of doing so.
 
 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.
+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, or only an ACK and PADDING frame,
+in response to a non-ACK-eliciting packet (one containing only ACK and/or

I'd remove the "one containing only ACK and/or PADDING frames)" now that it's well defined.

> @@ -3061,14 +3061,15 @@ of doing so.
 
 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.
+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

```suggestion
.  An endpoint MUST NOT
```

-- 
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/3104#pullrequestreview-302968984