-
Notifications
You must be signed in to change notification settings - Fork 208
Closed
Labels
-transportdesignAn issue that affects the design of the protocol; resolution requires consensus.An issue that affects the design of the protocol; resolution requires consensus.has-consensusAn issue that the Chairs have determined has consensus, by canvassing the mailing list.An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Description
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14 only says that padding is done by PADDING frame. https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14
But it looks like it is a common practice to add 0 or garbage outside QUIC packet to fill remaining UDP packet payload to expand packet size.
If it is a good practice (and/or recommended), I think draft should say something about it.
It might slightly simplify the implementation.
Padding in this way has different properties than PADDING frame; for example, it does not contribute to in-flight bytes.
Metadata
Metadata
Assignees
Labels
-transportdesignAn issue that affects the design of the protocol; resolution requires consensus.An issue that affects the design of the protocol; resolution requires consensus.has-consensusAn issue that the Chairs have determined has consensus, by canvassing the mailing list.An issue that the Chairs have determined has consensus, by canvassing the mailing list.