Subject: [quicwg/base-drafts] Éric Vyncke's Recovery Comment 1 (#4588)

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Jan 2021 06:57:53 -0800

Éric Vyncke said:

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4588

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 07 Jan 2021 01:24:02 -0800

I did respond to Eric with the following: 

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 confidence 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 bulk 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 application 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? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4588#issuecomment-755993922

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 08 Jan 2021 09:29:58 -0800

I don't see a comment about the recovery draft here, so I think we can probably close with no action. 

I think we need some deployment experience before considering a BCP but that is tangential to the work on the base-draft deliverables IMO.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4588#issuecomment-756895215

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Jan 2021 00:08:29 -0800

I'm reading this as "close with no action".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4588#issuecomment-758483139

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 Jan 2021 00:45:44 -0800

I agree with @gloinul's response. So, yes, no action.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4588#issuecomment-758502341

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Jan 2021 01:44:09 -0800

Closed #4588.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4588#event-4194932745