Subject: Éric Vyncke's No Objection on draft-ietf-quic-recovery-33: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 06 Jan 2021 05:31:34 -0800

É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).

-- Abstract --
Should the QUIC version be specified ?

-- Section 1 --
Suggest to specify version 1 for the 2nd sentence.

This (too?) short introduction would benefit by mentioning UDP transport.

== 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'.

Also, s/8 byte overhead/8-byte overhead/ ?

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 Jan 2021 15:01:58 +0000

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.

> https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

https://github.com/quicwg/base-drafts/issues/4588

> Should the QUIC version be specified ?

https://github.com/quicwg/base-drafts/issues/4589

> This (too?) short introduction would benefit by mentioning UDP transport.

https://github.com/quicwg/base-drafts/issues/4590

> The above text looks ambiguous to me especially with the ',' before

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 7 Jan 2021 09:22:59 +0000

Hi Eric,

> > https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

I thought the buffering and forwarding behaviors of the network devices is
primarily an IP + DSCP dependent thing, not really taking the upper layer
protocol into account. And for QUIC that identification chain where it is
explicit stops with UDP. For a third party seeing an IP/UDP packets where the
few bits that can be used to idenitify it as QUIC packet is no guarantee for it
being QUIC. If you are flow aware and happens to see the long header packets you
might have higher confidencience that this is QUIC and not something else. 

But my perspective is that IP packet buffering has been done to what suits TCP
well with significant downside to other protocols being carried over IP unless
an DSCP has been used to request a different forwarding behavior and possibly
thus a different buffering scheme. 

However, I think the buffering and forwarding behavior should not be QUIC
specific in anyway. I think it is also dependent on the applicaiton(s) being run
over QUIC. For example a background buld download service may use quic but want
to run in scavenger class and with a congestion control behavior that attempts
to avoid building any queues (Ledbat style). While another application might be
a highly latency sensitive real-time applciation that would prefer L4S style
behavior and a corresponding congestion control. 

Thus, I don't think it is on QUIC level we should define buffering and
forwarding behaviors, they should be defined more for IP level so that it can be
independent from the protocol. 

Interested to determine if you have more input on these aspects? 

Cheers

Magnus