bundle path_repsonse and ack_mp #239
Conversation
| non-probing frames on a path in "Validating" state, as it has no | ||
| guarantee that packets will actually reach the peer. | ||
| guarantee that packets will actually reach the peer, with an exception | ||
| of the ACK_MP frame. An endhost MAY bundle the ACK_MP frame with the |
There was a problem hiding this comment.
IIUC, this text builds on the fact that ACK_MP is a non-probing frame (because ACK is a non-probing frame), and states that even though ACK_MP is a non-probing frame it can be sent in a probe packet.
I wonder if it would be less confusing to simply state that ACK_MP is a probing frame?
There was a problem hiding this comment.
@kazuho I agree with you. I think making ACK_MP a probing frame is the easiest fix.
Co-authored-by: Kazuho Oku <[email protected]>
Co-authored-by: Kazuho Oku <[email protected]>
| PATH_RESPONSE frame; in this case it is RECOMMENDED to consider | ||
| the acknowledgement information as opportunistic and repeat | ||
| the acknowledged packet ranges in the next ACK_MP frame. |
There was a problem hiding this comment.
Not sure if this needs to be called out explicitly. ACKs are always opportunistic in QUIC, as ACK frames are not ack-eliciting.
Section 13.2.4 of RFC 9000 defines how to prune old ACK ranges, and I don't think we need to do anything special here.
|
replace by PR #276 |
fixes #226