Lines Matching +full:frame +full:- +full:number
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
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
16 level counts the total number of logical bytes sent on a given stream. Note that
19 that the total number of logical bytes sent on a given stream is equivalent to
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
39 never generate either of these frame types.) These frames rather serve two
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
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
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
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 ---------------------------------------
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.,
120 the number of bytes of STREAM frame payload which are not retransmissions). This
121 value is added to the TX-side SWM value. Note that this may be zero, though
126 frame, with the integer value contained in that frame (or when we receive the
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
151 An initial connection-level credit is communicated by the peer in the
153 `MAX_DATA` frame.
155 Stream-Level Flow Control - TX Side
156 -----------------------------------
158 Stream-level flow control works exactly the same as connection-level flow
162 frame, or based on the relevant transport parameter
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
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)
231 This event should be passed to the state machine when a STREAM frame is
233 the STREAM frame and the length of the frame's payload in bytes. The isFin
234 argument should specify whether the STREAM frame had the FIN flag set.
237 the connection-level flow controller. It is also used by stream-level flow
245 frame, which may after all duplicate some of the controlled bytes in a
246 previous STREAM frame).
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