Subject: [quicwg/base-drafts] QUIC Transport: Flow Control (#3722)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 04 Jun 2020 04:18:37 -0700

Section: Flow Control {#flow-control}
The present text only states the reasons why flow control limits are needed, and resource commitments. It does not yet motivate the use of adding credit when this is needed - which is also an important design consideration for a user of QUIC transport, as it is for http. 
- That is, the section should also state the performance implications of too little credit - i.e. the tradeoff, by explaining:  “Advertising too little credit will cause the stream to become blocked and can limit performance when it constrains  a stream path using a path that has large bandwidth delay product”.

Section: Flow Credit Increments
The following could be taken as a general guidance, when the ID says: “As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent.”
- I do not agree. This appears an optimisation for minimising resource use. It will I expect have a serious negative impact on performance where the path RTT is large, and that case also needs to be mentioned. This is an area where guidance is needed, since the way TCP operates is not described in the RFC series and mistakes in this part of the code can have very serious impacts on the performance and dynamics of applications, as well as the patterns of traffic on the wire.

Section: Flow Credit Increments
The following could be taken as a general guidance, when the ID says: “When a sender receives credit after being blocked, it might be able to send a large amount of data in response, resulting in short-term congestion; see Section 6.9 in {{QUIC-RECOVERY}} for a discussion of how a sender can avoid this congestion.” 
- I think this sentence may be well-intended but can be read as encouraging an unsafe practice. There is considerable latitude in how to design flow control, but read the current words as suggesting that the induced congestion from large updates are actually OK - which I do not think the IETF should say. 
- To me this requires words of caution to avoid the large bursts.

-- 
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/3722

---

From: evolodina <[email-masked]>
Date: Thu, 04 Jun 2020 07:29:37 -0700

> - I do not agree. This appears an optimisation for minimising resource use. It will I expect have a serious negative impact on performance where the path RTT is large, and that case also needs to b…

Even if RTT < 40ms we saw a negative impact of this optimization in our quic implementation

-- 
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/3722#issuecomment-638885306

---

From: ianswett <[email-masked]>
Date: Mon, 08 Jun 2020 14:19:11 -0700

@evolodina Can you clarify what conditions you're testing, as there are are a lot of variables in flow control.

We send flow control updates much less frequently than anytime there's free credit and a packet is already being sent, and very rarely see flow control blockage, despite doing dynamic window tuning on the server side.  So I'd expect if we did more proactive updates with better bundling, it'd only help.

Bundling flow control updates with ACK frames makes a large amount of sense, because ACK frames free up congestion window space and window updates free up flow control.

-- 
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/3722#issuecomment-640892294

---

From: evolodina <[email-masked]>
Date: Thu, 18 Jun 2020 08:16:54 -0700

> @evolodina Can you clarify what conditions you're testing, as there are are a lot of variables in flow control.

@ianswett  We used simply conditions: sender is not app-limited,  we tested FC for different bottleneck links e.g. 100Mbps, 1Gbps and different FC Limits, RTT was between 1ms und 100ms with step 10. We do not used dynamic window tuning as it’s not defined in draft as a MUST.

> So I'd expect if we did more proactive updates with better bundling, it'd only help.

I think it’s an interesting idea to bundle FC updates with ACK frames (if ACK must be sent every other packet). But in the case of bundling, I expect, that ackRatio parameter (e.g. equal to 10) would influence the frequently of FC-updates and thereby QUIC performance. I can implement und explore it in our implementation.

In order to have a possibility to test FC appropriate and provide comparable results, I wish, that the FC algorithm would be better defined in QUIC transport draft e.g. with a pseudocode.

-- 
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/3722#issuecomment-646088295

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jun 2020 18:03:37 -0700

I think that there are things that might be said about this point:

Unlike TCP, QUIC decouples flow control from congestion control.  This can release pressure on having a good flow control algorithm.  An endpoint can use flow control to constrain resource commitments without paying specific attention to tuning the algorithm.  

An endpoint might therefore implement a suboptimal flow control algorithm, up to the point where the BDP starts to approach the resources allocated to receiving data.  As BDP reaches this point, an endpoint needs to provide flow control updates in a timely fashion if it wishes to avoid flow control limiting throughput.  An endpoint that is unable to ensure that a peer has flow control credit in the order of the BDP will have their throughput limited by flow control and not congestion control.

(It's a little more complicated than that, as losses are discovered and repaired over a period larger than an RTT, and then you have to allow for flow control updates being lost.  The real value you need to target is therefore likely to be something more than 9/8 times the BDP.  But I think that gets the idea across.)

-- 
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/3722#issuecomment-648521374

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Jun 2020 00:32:11 -0700

I've just opened an editorial PR that fixes this.  This is based on my previous comments here.

However, I think that we should try to achieve consensus on the views contained therein.  Though the alternative is scary, I want to make sure that we are intentionally choosing not to document "good" flow control algorithms.

-- 
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/3722#issuecomment-650027117