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

[Gorry Fairhurst <[e-mail]>]

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