Lines Matching +full:side +full:- +full:by +full:- +full:side
5 ---------------------------------
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
14 It is important to note that both connection and stream-level flow control
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.
35 The `DATA_BLOCKED` and `STREAM_DATA_BLOCKED` frames defined by RFC 9000 are less
38 our connection-level credit, and a conformant QUIC implementation can choose to
43 Note that it follows from the above that the CRYPTO-frame stream is not subject
54 | |<-- credit| -->| |
55 | <-|- threshold -|----->| |
56 ----------------->
61 - **Controlled bytes** refers to any byte which counts for purposes of flow
65 - (RX side only) **Retirement**, which refers to where we dequeue one or more
73 - (RX side only) The **Retired Watermark** (RWM), the total number of retired
76 - The **Spent Watermark** (SWM), which is the number of controlled bytes we have
77 sent (for the TX side) or received (for the RX side). This represents the
79 and never decreases. On the RX side, such bytes have not necessarily been
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
90 get to the CWM before we choose to extend the peer more credit by bumping the
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,
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
121 value is added to the TX-side SWM value. Note that this may be zero, though
137 number of controlled bytes we are allowed to send). This value is reduced by the
138 On TX event and increased by the On TX Window Updated event. In fact, it is
143 value which would be returned by the Get TX Window function changes from
144 non-zero to zero. This always occurs during processing of an On TX event. (This
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
159 control for the TX side.
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
171 bytes we can send is the lesser value of the values returned by the Get TX
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
185 somewhat more involved than the TX side.
187 The state machine receives On RX Controlled Bytes events from stream-level flow
188 controllers. Callers do not pass the event themselves. The event is generated by
189 a stream-level flow controller whenever we receive any controlled bytes.
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
203 previous Increase Window events emitted by the state machine.
215 Stream-Level Flow Control - RX Side
216 -----------------------------------
218 RX-side stream-level flow control works similarly to RX-side connection-level
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)
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.
249 ----------------
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