Lines Matching +full:flow +full:- +full:controlled
1 Flow Control
4 Introduction to QUIC Flow Control
5 ---------------------------------
7 QUIC flow control acts at both connection and stream levels. At any time,
8 transmission of stream data could be prevented by connection-level flow control,
9 by stream-level flow control, or both. Flow control uses a credit-based model in
10 which the relevant flow control limit is expressed as the maximum number of
14 It is important to note that both connection and stream-level flow control
15 relate only to the transmission of QUIC stream data. QUIC flow control at stream
18 again, this still only counts as one byte for the purposes of flow control. Note
25 believe we have exhausted our flow control credit whereas the peer believes we
27 advancing us more flow control credit.)
29 QUIC flow control at connection level is based on the sum of all the logical
32 Connection-level flow control is controlled by the `MAX_DATA` frame;
33 stream-level flow control is controlled by the `MAX_STREAM_DATA` frame.
38 our connection-level credit, and a conformant QUIC implementation can choose to
40 purposes: to enhance flow control performance, and as a debugging aid.
43 Note that it follows from the above that the CRYPTO-frame stream is not subject
44 to flow control.
46 Note that flow control and congestion control are completely separate
54 | |<-- credit| -->| |
55 | <-|- threshold -|----->| |
56 ----------------->
61 - **Controlled bytes** refers to any byte which counts for purposes of flow
62 control. A controlled byte is any byte of application data in a STREAM frame
65 - (RX side only) **Retirement**, which refers to where we dequeue one or more
66 controlled bytes from a QUIC stream and hand them to the application, meaning
69 Retirement is an important factor in our RX flow control design, as we want
73 - (RX side only) The **Retired Watermark** (RWM), the total number of retired
74 controlled bytes since the beginning of the connection or stream.
76 - The **Spent Watermark** (SWM), which is the number of controlled bytes we have
78 amount of flow control budget which has been spent. It is a monotonic value
82 - The **Credit Watermark** (CWM), which is the number of bytes which have
86 - The available **credit**, which is always simply the difference between
89 - (RX side only) The **threshold**, which is how close we let the RWM
93 - (RX side only) The **window size**, which is the amount by which we or a peer
100 - If the available credit is zero, the TX side is blocked due to a lack of
103 - If any circumstance occurs which would cause the SWM to exceed the CWM,
104 a flow control protocol violation has occurred and the connection
107 Connection-Level Flow Control - TX Side
108 ---------------------------------------
110 TX side flow control is exceptionally simple. It can be modelled as the
113 ---> event: On TX (numBytes)
114 ---> event: On TX Window Updated (numBytes)
115 <--- event: On TX Blocked
116 Get TX Window() -> numBytes
119 `numBytes` is the total number of controlled bytes we sent in the packet (i.e.,
121 value is added to the TX-side SWM value. Note that this may be zero, though
130 number of controlled bytes we are allowed to send since the start of the
137 number of controlled bytes we are allowed to send). This value is reduced by the
144 non-zero to zero. This always occurs during processing of an On TX event. (This
148 We must not exceed the flow control limits, else the peer may terminate the
151 An initial connection-level credit is communicated by the peer in the
155 Stream-Level Flow Control - TX Side
156 -----------------------------------
158 Stream-level flow control works exactly the same as connection-level flow
169 Note that the number of controlled bytes we can send in a stream is limited by
170 both connection and stream-level flow control; thus the number of controlled
172 Window function on the connection-level and stream-level state machines,
175 Connection-Level Flow Control - RX Side
176 ---------------------------------------
178 ---> event: On RX Controlled Bytes (numBytes) [internal event]
179 ---> event: On Retire Controlled Bytes (numBytes)
180 <--- event: Increase Window (numBytes)
181 <--- event: Flow Control Error
183 RX side connection-level flow control provides an indication of when to generate
184 `MAX_DATA` frames to bump the peer's connection-level transmission credit. It is
187 The state machine receives On RX Controlled Bytes events from stream-level flow
189 a stream-level flow controller whenever we receive any controlled bytes.
190 `numBytes` is the number of controlled bytes we received. (This event is
191 generated by stream-level flow control as retransmitted stream data must be
192 counted only once, and the stream-level flow control is therefore in the best
193 position to determine how many controlled bytes (i.e., new, non-retransmitted
196 If we receive more controlled bytes than we authorized, the state machine emits
197 the Flow Control Error event. The connection should be terminated with a
201 should be advanced more flow control credit (i.e., when the CWM should be
205 The state machine is passed the On Retire Controlled bytes event when one or
206 more controlled bytes are dequeued from any stream and passed to the
209 The state machine uses the cadence of the On Retire Controlled Bytes events it
210 receives to determine when to increase the flow control window. Thus, the On
211 Retire Controlled Bytes event should be sent to the state machine when
212 processing of the received controlled bytes has been *completed* (i.e., passed
215 Stream-Level Flow Control - RX Side
216 -----------------------------------
218 RX-side stream-level flow control works similarly to RX-side connection-level
219 flow control. There are a few differences:
221 - There is no On RX Controlled Bytes event.
223 - The On Retire Controlled Bytes event may optionally pass the same event
224 to a connection-level flow controller (an implementation decision), as these
227 - An additional event is added, which replaces the On RX Controlled Bytes event:
229 ---> event: On RX Stream Frame (offsetPlusLength, isFin)
236 This event is used to generate the internal On RX Controlled Bytes event to
237 the connection-level flow controller. It is also used by stream-level flow
238 control to determine if flow control limits are violated by the peer.
244 remember if they have already counted a specific controlled byte in a STREAM
245 frame, which may after all duplicate some of the controlled bytes in a
249 ----------------
251 For RX flow control we must determine our window size. This is the value we add
259 The common algorithm is a so-called auto-tuning approach in which the rate of
263 size is doubled, up to an implementation-chosen maximum window size.
265 Auto-tuning occurs in 'epochs'. At the end of each auto-tuning epoch, a decision
266 is made on whether to double the window size, and a new auto-tuning epoch is
269 For more information on auto-tuning, see [Flow control in
271 and [QUIC Flow