Hi Eric, On Wed, 2021-01-06 at 15:01 +0000, Lucas Pardue wrote: > 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: > > ---------------------------------------------------------------------- > > > > > > == 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).
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
smime.p7s
Description: S/MIME cryptographic signature
