"SHOULD be acknowledged"

[kazuho]

Current Multipath draft is unclear regarding if the newly added frames are ack-eliciting.

For background, QUIC v1 define ack-eliciting frames and non-ack-eliciting frames. Ack-eliciting frames are required to be acknowledged at least once within max-ack-delay. All frames, regardless of them being ack-eliciting or non-ack-eliciting, are recommended to be acknowledged at least once. (RFC 9000 section 13.2.1).

Looking at the multipath draft, for the ACK_MP frame, we state that it is "an extension of the ACK frame," (section 8.1), so probably it implies that ACK_MP is non-ack-eliciting. Fine.

For PATH_ABANDON and PATH_STATUS, we state that the "SHOULD be acknowledged."

PATH_ABANDON frames SHOULD be acknowledged. If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. (section 8.2)

PATH_STATUS frames SHOULD be acknowledged. If a packet containing a PATH_STATUS frame is considered lost, the peer should only repeat it if it was the last status sent for that path -- as indicated by the sequence number. (section 8.3)

What does these statements mean? Considering that they are SHOULD without maximum delay, do they imply that PATH_ABANDON and PATH_STATUS are non-ack-eliciting frames? Or do they mean that these frames fall into a new category other than ack-eliciting or non-ack-eliciting frames?

[kazuho]

My take would be that these frames are meant to be ack-eliciting.

IMO they have to be, because they transmit information, and when the information are deemed lost, they have to be retransmit (unless the sender has other ways to learn that the peer no longer needs the information; see RFC 900 section 13.3).

[huitema]

@kazuho They should be treated much like for example the MAX_DATA or MAX_STREAM_DATA frames: they should be acknowledged, but if the packet carrying them is lost, they should only be repeated if they were the last such frame sent on the path.