Lines Matching refs:is
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
17 this does not count retransmissions; thus, if a byte is sent, lost, and sent
19 that the total number of logical bytes sent on a given stream is equivalent to
20 the current “length” of the stream. In essence, the relevant quantity is
24 (It is essential that this be determined correctly, as deadlock may occur if we
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.
37 example, a peer is not allowed to wait until we send `DATA_BLOCKED` to increase
41 However, their implementation is not critical.
43 Note that it follows from the above that the CRYPTO-frame stream is not subject
62 control. A controlled byte is any byte of application data in a STREAM frame
63 payload, the first time it is sent (retransmissions do not count).
69 Retirement is an important factor in our RX flow control design, as we want
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
83 been authorized for transmission so far. This count is a cumulative count
84 since the start of the connection or stream and thus is also monotonic.
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
91 CWM. The threshold is relative to (i.e., subtracted from) the CWM.
93 - (RX side only) The **window size**, which is the amount by which we or a peer
95 CWM is calculated as the SWM plus the window size (note that it added to the
100 - If the available credit is zero, the TX side is blocked due to a lack of
110 TX side flow control is exceptionally simple. It can be modelled as the
118 The On TX event is passed to the state machine whenever we send a packet.
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
122 there is no need to pass the event in this case.
124 The On TX Window Updated event is passed to the state machine whenever we have
125 our CWM increased. In other words, it is passed whenever we receive a `MAX_DATA`
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
132 Update event is passed to the state machine with a value lower than that passed
136 The Get TX Window function returns our credit value (that is, it returns the
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
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
145 event is intended to assist in deciding when to generate `DATA_BLOCKED`
151 An initial connection-level credit is communicated by the peer in the
169 Note that the number of controlled bytes we can send in a stream is limited by
171 bytes we can send is the lesser value of the values returned by the Get TX
184 `MAX_DATA` frames to bump the peer's connection-level transmission credit. It is
188 controllers. Callers do not pass the event themselves. The event is generated by
190 `numBytes` is the number of controlled bytes we received. (This event is
192 counted only once, and the stream-level flow control is therefore in the best
202 bumped). `numBytes` is the new CWM value, and is monotonic with regard to all
205 The state machine is passed the On Retire Controlled bytes event when one or
221 - There is no On RX Controlled Bytes event.
227 - An additional event is added, which replaces the On RX Controlled Bytes event:
231 This event should be passed to the state machine when a STREAM frame is
232 received. The `offsetPlusLength` argument is the sum of the offset field of
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
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
260 window consumption (i.e., the rate at which RWM approaches CWM after CWM is
261 bumped) is measured and compared to the measured connection RTT. If the time it
263 size is doubled, up to an implementation-chosen maximum window size.
266 is made on whether to double the window size, and a new auto-tuning epoch is
