Hi Éric, Thanks for the review. I've captured your comments as issues on the QUIC WG GItHub repository. Links to each are provided as in-line responses.
On Wed, Jan 6, 2021 at 1:31 PM Éric Vyncke via Datatracker <[email protected]> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-quic-recovery-33: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. Even for a non transport > person > like myself, I find the text easy to read. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > Does the QUIC WG intend to have a BCP-like document on how network devices > on > the path should handle buffers? E.g., QUIC ressembles a lot to TCP so > nodes can > apply back pressure with mechanisms similar to RED (but, AFAIK, RED is > mainly > applied to TCP traffic so not to QUIC/UDP). > https://github.com/quicwg/base-drafts/issues/4588 > -- Abstract -- > Should the QUIC version be specified ? > https://github.com/quicwg/base-drafts/issues/4589 > -- Section 1 -- > Suggest to specify version 1 for the 2nd sentence. > > This (too?) short introduction would benefit by mentioning UDP transport. > https://github.com/quicwg/base-drafts/issues/4590 > == NITS == > > -- Section 7.2 -- > "Endpoints SHOULD use an initial congestion > window of 10 times the maximum datagram size (max_datagram_size), > limited to the larger of 14720 bytes or twice the maximum datagram > size. " > > The above text looks ambiguous to me especially with the ',' before > 'limited'. > https://github.com/quicwg/base-drafts/issues/4591 > Also, s/8 byte overhead/8-byte overhead/ ? > https://github.com/quicwg/base-drafts/issues/4592 Cheers, Lucas On behalf of QUIC WG Chairs
