Lines Matching +full:rx +full:- +full:tx
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.
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
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
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
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
118 The On TX event is passed to the state machine whenever we send a packet.
121 value is added to the TX-side SWM value. Note that this may be zero, though
124 The On TX Window Updated event is passed to the state machine whenever we have
129 The On TX Window Updated event expresses the CWM (that is, the cumulative
131 connection), thus it is monotonic and may never regress. If an On TX Window
136 The Get TX Window function returns our credit value (that is, it returns the
138 On TX event and increased by the On TX Window Updated event. In fact, it is
139 simply the difference between the last On TX Window Updated value and the sum of
140 the `numBytes` arguments of all On TX events so far; it is that simple.
142 The On TX Blocked event is emitted at the time of any edge transition where the
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.
161 The On TX Window Updated event occurs in response to the `MAX_STREAM_DATA`
166 The On TX Blocked event can be used to decide when to generate
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
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
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)
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
242 reason this event is used instead of a `On RX (numBytes)` style event is that
248 RX Window Sizing
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