Up to two full-sized datagrams, not packets #2915
Conversation
Now that the PTO retransmits Initial and Handshake data, it's possible and likely desirable to bundle multiple QUIC packets in a single datagram. This change makes it clear that is allowed.
| to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration | ||
| due to a single packet loss. | ||
| to two full sized datagrams containing ack-eliciting packets, to avoid an | ||
| expensive consecutive PTO expiration due to a single lost datagram. | ||
|
|
There was a problem hiding this comment.
Where is that limit of two specified? Here? Why?
There was a problem hiding this comment.
If you send 1, it might be lost. Ideally, fewer is better, so the question of 1 or 2 was left to implementers.
There was a problem hiding this comment.
I mean, there is no limit to coalescing AFAIK, so the limit of two here seems arbitrary, albeit probably very sensible.
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.12.2
There was a problem hiding this comment.
There's no limit of 2 packets in a datagram here and I don't think there's one elsewhere?
There was a problem hiding this comment.
An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets,
I read that as it MAY NOT send more than two, but it MAY send less.
There was a problem hiding this comment.
Ah, I am confusing UDP datagrams and packets.
Co-Authored-By: MikkelFJ <mikkelfj@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Now that the PTO retransmits Initial and Handshake data, it's possible and likely desirable to bundle multiple QUIC packets in a single datagram. This change makes it clear that is allowed.