Lines Matching +full:frame +full:- +full:number
12 ----------------------
26 QUIC_CFQ *cfq; /* QUIC Control Frame Queue */
29 QUIC_TXFC *conn_txfc; /* QUIC Connection-Level TX Flow Controller */
30 QUIC_RXFC *conn_rxfc; /* QUIC Connection-Level RX Flow Controller */
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
132 The packetiser will attempt to maximise the number of bytes in a packet.
151 the per-packet information recorded by the TXPIM to track which frames are
168 The packetiser interacts with connection and stream-level TXFC and RXFC
176 future. Currently, congestion control is a no-op.
179 -------
185 QUIC supports a number of different packets. The combination of packets of
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
241 has a minimum size of a certain number of bytes. This does not need to be
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
259 Frames are taken from [RFC 9000 12.4 Frames and Frame Types].
262 |------|-----------------------|---------|---------|---------|---------|---------|---------|-------…
302 | :---: | --- |
305 | 0 | Valid in 0-RTT packets|
306 | 1 | Valid in 1-RTT packets|
313 | :---: | --- |
314 | N | Not ack-eliciting. |
321 frame and a _stream_ frame would qualify for neither the `C` or `N` markings.
325 - Do we need the distinction between 0-rtt and 1-rtt when both are in
326 the Application Data number space?
327 - 0-RTT packets can morph into 1-RTT packets and this needs to be handled by
330 ### Frame Type Prioritisation
332 The frame types listed above are reordered below in the order of priority with
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
378 the second column, which specifies the retransmission strategy for each frame
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.
392 Thus we wait until the end before adding the PING frame as we may end up
393 adding other ACK-eliciting frames and not need to add it. There is never
394 a need to add more than one PING frame. If we have been asked to ensure
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
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
442 have serialized all other frame types, we can reserve the rest of the packet
443 for any `STREAM` frames. Since all `STREAM` frames are ACK-eliciting, if we
444 have any `STREAM` frame to send at all, it cancels any need for any `PING`
445 frame, and may be able to partially or wholly obviate our need for any
449 - `MAX_STREAM_DATA`, `STREAM_DATA_BLOCKED`: Stream-level flow control. These
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
481 just above that of `CRYPTO` frames. The `CONNECTION_CLOSE` frame has higher
484 - `ACK`: `ACK` frames are critical to avoid needless retransmissions by our peer.
485 They can also potentially become large if a large number of ACK ranges needs
489 such as connection-level flow control. However, we reserve the right to adapt
491 to limit the size of the ACK frame if its size would be otherwise excessive.
492 This ensures that the high priority of the ACK frame does not starve the
502 stream-level flow control frames, RESET_STREAM and STOP_SENDING frames to
504 accounted to those streams for budgeting purposes. If the total number of bytes
507 Otherwise, there are a number of strategies we could employ. We can categorise
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
566 in a fixed priority order; i.e., first there could be a `STOP_SENDING` frame
567 for one stream, then a `STREAM` frame for another, then another `STOP_SENDING`
568 frame for another stream, etc.)
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
610 frame if necessary). However, these packets need not be reserved exclusively
618 /* Generate normal packets containing most frame types. */
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
651 frame sent in an Initial packet, etc.
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