Lines Matching +full:flow +full:- +full:controller
9 The packetiser also deals with the flow and congestion controllers.
12 ----------------------
29 QUIC_TXFC *conn_txfc; /* QUIC Connection-Level TX Flow Controller */
30 QUIC_RXFC *conn_rxfc; /* QUIC Connection-Level RX Flow Controller */
31 const OSSL_CC_METHOD *cc_method; /* QUIC Congestion Controller */
32 OSSL_CC_DATA *cc_data; /* QUIC Congestion Controller Instance */
37 * Injected dependencies - crypto streams.
39 * Note: There is no crypto stream for the 0-RTT EL.
40 * crypto[QUIC_PN_SPACE_APP] is the 1-RTT crypto stream.
52 ----------
77 ------------
82 - SSTREAM: manages application stream data for transmission.
83 - QUIC_STREAM_MAP: Maps stream IDs to QUIC_STREAM objects and tracks which
85 - Crypto streams for each EL other than 0-RTT (each is one SSTREAM).
86 - CFQ: queried for generic control frames
87 - QTX: record layer which completed packets are written to.
88 - TXPIM: logs information about transmitted packets, provides information to
90 - FIFD: notified of transmitted packets.
91 - ACKM: loss detector.
92 - Connection and stream-level TXFC and RXFC instances.
93 - Congestion controller (not needed for MVP).
113 The crypto streams for each EL (other than 0-RTT, which does not have a crypto
151 the per-packet information recorded by the TXPIM to track which frames are
166 ### Flow Control
168 The packetiser interacts with connection and stream-level TXFC and RXFC
169 instances. It interacts with RXFC instances to know when to generate flow
175 The packetiser is likely to interact with the congestion controller in the
176 future. Currently, congestion control is a no-op.
179 -------
187 by the record layer. Non-encrypted packets are not handled by the TX Packetiser
198 #### App Data 0-RTT Packet
200 Refer to [RFC 9000 17.2.3 0-RTT].
202 #### App Data 1-RTT Packet
204 Refer to [RFC 9000 17.3.1 1-RTT].
207 ----------------------------
211 - Maximum Datagram Payload Length (MDPL): The maximum number of UDP payload
217 - Maximum Packet Length (MPL): The maximum size of a fully encrypted
221 - Maximum Plaintext Payload Length (MPPL): The maximum number of plaintext
226 - Coalescing MPL (CMPL): The maximum number of bytes left to serialize
231 - Coalescing MPPL (CMPPL): The maximum number of payload bytes we can put in
236 - Remaining CMPPL (RCMPPL): The number of bytes left in a packet whose payload
240 - Minimum Datagram Length (MinDPL): In some cases we must ensure a datagram
245 - Minimum Packet Length (MinPL): The minimum serialized packet length we
250 - Minimum Plaintext Payload Length (MinPPL): The minimum number of bytes
254 - Active Stream: A stream which has data or flow control frames ready for
262 |------|-----------------------|---------|---------|---------|---------|---------|---------|-------…
302 | :---: | --- |
305 | 0 | Valid in 0-RTT packets|
306 | 1 | Valid in 1-RTT packets|
313 | :---: | --- |
314 | N | Not ack-eliciting. |
317 | F | The contents of frames with this marking are flow controlled. |
325 - Do we need the distinction between 0-rtt and 1-rtt when both are in
327 - 0-RTT packets can morph into 1-RTT packets and this needs to be handled by
338 ----------------------------
343 ----------------------------
348 ----------------------------
349 PATH_CHALLENGE -
350 PATH_RESPONSE -
351 ----------------------------
352 ACK - (non-ACK-eliciting)
353 ----------------------------
354 CONNECTION_CLOSE *** (non-ACK-eliciting)
355 ----------------------------
358 ----------------------------
364 ---------------------------- ]
367 ---------------------------- ]
371 ----------------------------
372 PING -
373 ----------------------------
374 PADDING - (non-ACK-eliciting)
377 (See [Frame in Flight Manager](quic-fifm.md) for information on the meaning of
381 - `PADDING`: For obvious reasons, this frame type is the lowest priority. We only
383 have been asked to ensure a non-zero MinPL but have not yet met that minimum.
385 - `PING`: The `PING` frame is encoded as a single byte. It is used to make a packet
386 ACK-eliciting if it would not otherwise be ACK-eliciting. Therefore we only
389 a. we have been asked to ensure the packet is ACK-eliciting, and
390 b. we do not have any other ACK-eliciting frames in the packet.
393 adding other ACK-eliciting frames and not need to add it. There is never
395 the packet is ACK-eliciting and we do not know for sure up front if we will
396 add any other ACK-eliciting packet, we must reserve one byte of our CMPPL
398 add an ACK-eliciting frame earlier. For example:
400 - We have been asked to ensure a packet is ACK-eliciting and the CMPPL is
402 - We allocate 999 bytes for non-PING frames.
403 - While adding non-PING frames, we add a STREAM frame, which is
404 ACK-eliciting, therefore the PING frame reservation is cancelled
405 and we increase our allocation for non-PING frames to 1000 bytes.
407 - `HANDSHAKE_DONE`: This is a single byte frame with no data which is used to
412 - `MAX_DATA`, `DATA_BLOCKED`: These manage connection-level flow control. They
414 are also critical to ensuring the timely expansion of the connection-level
415 flow control window. Thus there is a performance reason to include them in
420 - `MAX_STREAMS`, `STREAMS_BLOCKED`: Similar to the frames above for
421 connection-level flow control, but controls rate at which new streams are
424 - `STREAM`: This is the bread and butter of a QUIC packet, and contains
425 application-level stream data. As such these frames can usually be expected to
428 - there are many streams, and
429 - several of those streams have much more data waiting to be sent than
435 application-signalled prioritisation of specific streams. We discuss
443 for any `STREAM` frames. Since all `STREAM` frames are ACK-eliciting, if we
449 - `MAX_STREAM_DATA`, `STREAM_DATA_BLOCKED`: Stream-level flow control. These
450 contain only a stream ID and integer value used for flow control, so they are
456 - `RESET_STREAM`, `STOP_SENDING`: These terminate a given stream ID and thus are
458 higher priority than both `STREAM` frames and the stream-level flow control
461 - `NEW_CONNECTION_ID`, `RETIRE_CONNECTION_ID`: These are critical for connection
465 - `PATH_CHALLENGE`, `PATH_RESPONSE`: Used during connection migration, these
468 - `CRYPTO`: These frames generate the logical crypto stream, which is a logical
472 `CRYPTO` frames outcompete all application stream-related frames if need be,
476 - `CONNECTION_CLOSE`, `NEW_TOKEN`: The `CONNECTION_CLOSE` frame can contain a
477 user-specified reason string. The `NEW_TOKEN` frame contains an opaque token
484 - `ACK`: `ACK` frames are critical to avoid needless retransmissions by our peer.
489 such as connection-level flow control. However, we reserve the right to adapt
502 stream-level flow control frames, RESET_STREAM and STOP_SENDING frames to
510 - **Intrapacket muxing (IRPM)**. When the data available to send across all
514 - **Interpacket muxing (IXPM).** When the data available to send across all
523 one another for the purposes of head-of-line blocking. By contrast, with IXPM,
530 - A round robin (RR) strategy in which the frame scheduler switches to
533 - A sequential (SEQ) strategy in which a stream keeps being transmitted
536 The SEQ strategy does not appear to be suitable for general-purpose
541 does not seem like a suitable choice for an application-agnostic QUIC
550 different values of `n` poses no non-trivial implementation concerns, so it is
561 or `STOP_SENDING` frames, followed by stream-level flow control frames if
579 - **Padded Initial Datagrams.**
585 - **Token in Initial Packets.**
590 - **Anti-amplification Limit.** Sometimes a lower MDPL may be imposed due to
591 anti-amplification limits. (Only a concern for servers, so not relevant to
598 anti-amplification implementations appear to be rare.
600 - **MTU Probes.** These packets have a precisely crafted size for the purposes
605 - **Path/Migration Probes.** These packets are sent to verify a new path
608 - **ACK Manager Probes.** Packets produced because the ACK manager has
609 requested a probe be sent. These MUST be made ACK-eliciting (using a PING
632 A QUIC connection progresses through Initial, Handshake, 0-RTT and 1-RTT
641 The following EL-specific resources exist:
643 - The crypto stream, a bidirectional byte stream abstraction provided
645 Handshake and 1-RTT ELs. (`CRYPTO` frames are prohibited in 0-RTT packets,
646 which is to say the 0-RTT EL has no crypto stream of its own.)
648 - Packet number spaces and acknowledgements. The 0-RTT and 1-RTT ELs
655 - Let E be the set of ELs which are not discarded and for which `pending(el)` is
659 - Determine if we are limited by anti-amplification restrictions.
662 - For each EL in E, construct a packet bearing in mind the Remaining CMPPL
671 - Send the datagram.
675 The TX packetiser decides when to tell the QRL to initiate a TX-side key update.
694 [RFC 9000 2.3 Stream Prioritization]: https://datatracker.ietf.org/doc/html/rfc9000#section-2.3
695 [RFC 9000 4.1 Data Flow Control]: https://datatracker.ietf.org/doc/html/rfc9000#section-4.1
696 [RFC 9000 10.3 Stateless Reset]: https://datatracker.ietf.org/doc/html/rfc9000#section-10.3
697 [RFC 9000 12.2 Coalescing Packets]: https://datatracker.ietf.org/doc/html/rfc9000#section-12.2
698 [RFC 9000 12.4 Frames and Frame Types]: https://datatracker.ietf.org/doc/html/rfc9000#section-12.4
699 …000 13.3 Retransmission of Information]: https://datatracker.ietf.org/doc/html/rfc9000#section-13.3
700 [RFC 9000 17.1 Packet Formats]: https://datatracker.ietf.org/doc/html/rfc9000#section-17
701 …00 17.2.1 Version Negotiation Packet]: https://datatracker.ietf.org/doc/html/rfc9000#section-17.2.1
702 [RFC 9000 17.2.2 Initial Packet]: https://datatracker.ietf.org/doc/html/rfc9000#section-17.2.2
703 [RFC 9000 17.2.3 0-RTT]: https://datatracker.ietf.org/doc/html/rfc9000#section-17.2.3
704 [RFC 9000 17.2.4 Handshake Packet]: https://datatracker.ietf.org/doc/html/rfc9000#section-17.2.4
705 [RFC 9000 17.2.5 Retry Packet]: https://datatracker.ietf.org/doc/html/rfc9000#section-17.2.5
706 [RFC 9000 17.3.1 1-RTT]: https://datatracker.ietf.org/doc/html/rfc9000#section-17.3.1