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

[Magnus Westerlund <[e-mail]>]

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 <[e-mail]>
> 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