1Glossary of QUIC Terms 2====================== 3 4**ACKM:** ACK Manager. Responsible for tracking packets in flight and generating 5notifications when they are lost, or when they are successfully delivered. 6 7**Active Stream:** A stream which has data or control frames ready for 8transmission. Active stream status is managed by the QSM. 9 10**AEC:** Application error code. An error code provided by a local or remote 11application to be signalled as an error code value by QUIC. See QUIC RFCs 12(`STOP_SENDING`, `RESET_STREAM`, `CONNECTION_CLOSE`). 13 14**APL:** API Personality Layer. The QUIC API Personality Layer lives in 15`quic_impl.c` and implements the libssl API personality (`SSL_read`, etc.) in 16terms of an underlying `QUIC_CHANNEL` object. 17 18**Bidi:** Abbreviation of bidirectional, referring to a QUIC bidirectional 19stream. 20 21**CC:** Congestion controller. Estimates network channel capacity and imposes 22limits on transmissions accordingly. 23 24**CFQ:** Control Frame Queue. Considered part of the FIFM, this implements 25the CFQ strategy for frame in flight management. For details, see FIFM 26design document. 27 28**Channel:** See `QUIC_CHANNEL`. 29 30**CID:** Connection ID. 31 32**CMPL:** The maximum number of bytes left to serialize another QUIC packet into 33the same datagram as one or more previous packets. This is just the MDPL minus 34the total size of all previous packets already serialized into to the same 35datagram. 36 37**CMPPL:** The maximum number of payload bytes we can put in the payload of 38another QUIC packet which is to be coalesced with one or more previous QUIC 39packets and placed into the same datagram. Essentially, this is the room we have 40left for another packet payload. 41 42**CSM:** Connection state machine. Refers to some aspects of a QUIC channel. Not 43implemented as an explicit state machine. 44 45**DCID:** Destination Connection ID. Found in most QUIC packet headers. 46 47**DEMUX:** The demuxer routes incoming packets to the correct connection QRX by 48DCID. 49 50**DGRAM:** (UDP) datagram. 51 52**DISPATCH:** Refers to the QUIC-specific dispatch code in `ssl_lib.c`. This 53dispatches calls to libssl public APIs to the APL. 54 55**EL:** Encryption level. See RFC 9000. 56 57**Engine:** See `QUIC_ENGINE`. 58 59**FC:** Flow control. Comprises TXFC and RXFC. 60 61**FIFD:** Frame-in-flight dispatcher. Ties together the CFQ and TXPIM to handle 62frame tracking and retransmission on loss. 63 64**FIFM:** Frame-in-flight manager. Tracks frames in flight until their 65containing packets are deemed delivered or lost, so that frames can be 66retransmitted if necessary. Comprises the CFQ, TXPIM and FIFD. 67 68**GCR:** Generic Control Frame Retransmission. A strategy for regenerating lost 69frames. Stores raw frame in a queue so that it can be retransmitted if lost. See 70FIFM design document for details. 71 72**Key epoch:** Non-negative number designating a generation of QUIC keys used to 73encrypt or decrypt packets, starting at 0. This increases by 1 when a QUIC key 74update occurs. 75 76**Key Phase:** Key phase bit in QUIC packet headers. See RFC 9000. 77 78**Keyslot**: A set of cryptographic state used to encrypt or decrypt QUIC 79packets by a QRX or QTX. Due to the QUIC key update mechanism, multiple keyslots 80may be maintained at a given time. See `quic_record_rx.h` for details. 81 82**KP:** See Key Phase. 83 84**KS:** See Keyslot. 85 86**KU:** Key update. See also TXKU, RXKU. 87 88**LCID:** Local CID. Refers to a CID which will be recognised as identifying a 89connection if found in the DCID field of an incoming packet. See also RCID. 90 91**LCIDM:** Local CID Manager. Tracks LCIDs which have been advertised to a peer. 92See also RCIDM. 93 94**Locally-initiated:** Refers to a QUIC stream which was initiated by the local 95application rather than the remote peer. 96 97**MDPL:** Maximum Datagram Payload Length. The maximum number of UDP payload 98bytes we can put in a UDP packet. This is derived from the applicable PMTU. This 99is also the maximum size of a single QUIC packet if we place only one packet in 100a datagram. The MDPL may vary based on both local source IP and destination IP 101due to different path MTUs. 102 103**MinDPL:** In some cases we must ensure a datagram has a minimum size of a 104certain number of bytes. This does not need to be accomplished with a single 105packet, but we may need to add PADDING frames to the final packet added to a 106datagram in this case. 107 108**MinPL:** The minimum serialized packet length we are using while serializing a 109given packet. May often be 0. Used to meet MinDPL requirements, and thus equal 110to MinDPL minus the length of any packets we have already encoded into the 111datagram. 112 113**MinPPL:** The minimum number of bytes which must be placed into a packet 114payload in order to meet the MinPL minimum size when the packet is encoded. 115 116**MPL:** Maximum Packet Length. The maximum size of a fully encrypted and 117serialized QUIC packet in bytes in some given context. Typically equal to the 118MDPL and never greater than it. 119 120**MPPL:** The maximum number of plaintext bytes we can put in the payload of a 121QUIC packet. This is related to the MDPL by the size of the encoded header and 122the size of any AEAD authentication tag which will be attached to the 123ciphertext. 124 125**MSMT:** Multi-stream multi-thread. Refers to a type of multi-stream QUIC usage 126in which API calls can be made on different threads. 127 128**MSST:** Multi-stream single-thread. Refers to a type of multi-stream QUIC 129usage in which API calls must not be made concurrently. 130 131**NCID:** New Connection ID. Refers to a QUIC `NEW_CONNECTION_ID` frame. 132 133**Numbered CID:** Refers to a Connection ID which has a sequence number assigned 134to it. All CIDs other than Initial ODCIDs and Retry ODCIDs have a sequence 135number assigned. See also Unnumbered CID. 136 137**ODCID:** Original Destination CID. This is the DCID found in the first Initial 138packet sent by a client, and is used to generate the secrets for encrypting 139Initial packets. It is only used temporarily. 140 141**PN:** Packet number. Most QUIC packet types have a packet number (PN); see RFC 1429000. 143 144**Port:** See `QUIC_PORT`. 145 146**PTO:** Probe timeout. See RFC 9000. 147 148**QC:** See `QUIC_CONNECTION`. 149 150**QCSO:** QUIC Connection SSL Object. This is an SSL object created using 151`SSL_new` using a QUIC method. 152 153**QCTX**: QUIC Context. This is a utility object defined within the QUIC APL 154which helps to unwrap an SSL object pointer (a QCSO or QSSO) into the relevant 155structure pointers such as `QUIC_CONNECTION` or `QUIC_XSO`. 156 157**QRL:** QUIC record layer. Refers collectively to the QRX and QTX. 158 159**QRX:** QUIC Record Layer RX. Receives incoming datagrams and decrypts the 160packets contained in them. Manages decrypted packets in a queue pending 161processing by upper layers. 162 163**QS:** See `QUIC_STREAM`. 164 165**QSM:** QUIC Streams Mapper. Manages internal `QUIC_STREAM` objects and maps 166IDs to those objects. Allows iteration of active streams. 167 168**QSO:** QUIC SSL Object. May be a QCSO or a QSSO. 169 170**QSSO:** QUIC Stream SSL Object. This is an SSL object which is subsidiary to a 171given QCSO, obtained using (for example) `SSL_new_stream` or 172`SSL_accept_stream`. 173 174**QTLS**, **QUIC_TLS**: Implements the QUIC handshake layer using TLS 1.3, 175wrapping libssl TLS code to implement the QUIC-specific aspects of QUIC TLS. 176 177**QTX:** QUIC Record Layer TX. Encrypts and sends packets in datagrams. 178 179**QUIC_CHANNEL:** Internal object in the QUIC core implementation corresponding 180to a QUIC connection. Ties together other components and provides connection 181handling and state machine implementation. Belongs to a `QUIC_PORT` representing 182a UDP socket/BIO, which in turn belongs to a `QUIC_ENGINE`. Owns some number of 183`QUIC_STREAM` instances. The `QUIC_CHANNEL` code is fused tightly with the RXDP. 184 185**QUIC_CONNECTION:** QUIC connection. This is the object representing a QUIC 186connection in the APL. It internally corresponds to a `QUIC_CHANNEL` object in 187the QUIC core implementation. 188 189**QUIC_ENGINE:** Internal object in the QUIC core implementation constituting 190the top-level object of a QUIC event and I/O processing domain. Owns zero or 191more `QUIC_PORT` instances, each of which owns zero or more `QUIC_CHANNEL` 192objects representing QUIC connections. 193 194**QUIC_PORT:** Internal object in the QUIC core implementation corresponding to 195a listening port/network BIO. Has zero or more child `QUIC_CHANNEL` objects 196associated with it and belongs to a `QUIC_ENGINE`. 197 198**QUIC_STREAM**: Internal object tracking a QUIC stream. Unlike an XSO this is 199not part of the APL. An XSO wraps a QUIC_STREAM once that stream is exposed as 200an API object. As such, a `QUIC_CONNECTION` is to a `QUIC_CHANNEL` what a 201`QUIC_XSO` is to a `QUIC_STREAM`. 202 203**RCID:** Remote CID. Refers to a CID which has been provided to us by a peer 204and which we can place in the DCID field of an outgoing packet. See also LCID, 205Unnumbered CID and Numbered CID. 206 207**RCIDM:** Remote CID Manager. Tracks RCIDs which have been provided to us by a 208peer. See also LCIDM. 209 210**REGEN:** A strategy for regenerating lost frames. This strategy regenerates 211the frame from canonical data sources without having to store a copy of the 212frame which was transmitted. See FIFM design document for details. 213 214**Remotely-initiated:** Refers to a QUIC stream which was initiated by the 215remote peer, rather than by the local application. 216 217**RIO:** Reactive I/O subsystem. Refers to the generic, non-QUIC specific parts 218of the asynchronous I/O handling code which the OpenSSL QUIC stack is built on. 219 220**RSTREAM:** Receive stream. Internal receive buffer management object used to 221store data which has been RX'd but not yet read by the application. 222 223**RTT:** Round trip time. Time for a datagram to reach a given peer and a reply 224to reach the local machine, assuming the peer responds immediately. 225 226**RXDP:** RX depacketiser. Handles frames in packets which have been decrypted 227by a QRX. 228 229**RXE:** RX entry. Structure containing decrypted received packets awaiting 230processing. Stored in a queue known as the RXL. These structures belong to a 231QRX. 232 233**RXFC:** RX flow control. This determines how much a peer may send to us and 234provides indication of when flow control frames increasing a peer's flow control 235budget should be generated. Exists in both connection-level and stream-level 236instances. 237 238**RXKU:** RX key update. The detected condition whereby a received packet 239has a flipped Key Phase bit, meaning the peer has initiated a key update. 240Causes a solicited TXKU. See also TXKU. 241 242**RXL:** RXE list. See RXE. 243 244**RCMPPL:** The number of bytes left in a packet whose payload we are currently 245forming. This is the CMPPL minus any bytes we have already put into the payload. 246 247**SCID:** Source Connection ID. Found in some QUIC packet headers. 248 249**SRT:** Stateless reset token. 250 251**SRTM:** Stateless reset token manager. Object which tracks SRTs we have 252received. 253 254**SSTREAM:** Send stream. Internal send buffer management object used to store 255data which has been passed to libssl for sending but which has not yet been 256transmitted, or not yet been acknowledged. 257 258**STATM:** Statistics manager. Measures estimated connection RTT. 259 260**TA:** Thread assisted mode. 261 262**TPARAM:** Transport parameter. See RFC 9000. 263 264**TSERVER:** Test server. Internal test server object built around a channel. 265 266**TXE:** TX entry. Structure containing encrypted data pending transmission. 267Owned by the QTX. 268 269**TXFC:** TX flow control. This determines how much can be transmitted to the 270peer. Exists in both connection-level and stream-level instances. 271 272**TXKU:** TX key update. This refers to when a QTX signals a key update for the 273TX direction by flipping the Key Phase bit in an outgoing packet. A TXKU can be 274either spontaneous (locally initiated) or in solicited (in response to receiving 275an RXKU). See also RXKU. 276 277**TXL:** TXE list. See TXE. 278 279**TXP:** TX packetiser. This is responsible for generating yet-unencrypted 280packets and passing them to a QTX for encryption and transmission. It must 281decide how to spend the space available in a datagram. 282 283**TXPIM:** Transmitted Packet Information Manager. Stores information about 284transmitted packets and the frames contained within them. This information 285is needed to facilitate retransmission of frames if the packets they are in 286are lost. Note that the ACKM records only receipt or loss of entire packets, 287whereas TXPIM tracks information about individual frames in those packets. 288 289**TX/RX v. Send/Receive:** The terms *TX* and *RX* are used for *network-level* 290communication, whereas *send* and *receive* are used for application-level 291communication. An application *sends* on a stream (causing data to be appended 292to a *send stream buffer*, and that data is eventually TX'd by the TXP and QTX.) 293 294**Uni:** Abbreviation of unidirectional, referring to a QUIC unidirectional 295stream. 296 297**Unnumbered CID:** Refers to a CID which does not have a sequence number 298associated with it and therefore cannot be referred to by a `NEW_CONNECTION_ID` 299or `RETIRE_CONNECTION_ID` frame's sequence number fields. The only unnumbered 300CIDs are Initial ODCIDs and Retry ODCIDs. These CIDs are exceptionally retired 301automatically during handshake confirmation. See also Numbered CID. 302 303**URXE:** Unprocessed RX entry. Structure containing yet-undecrypted received 304datagrams pending processing. Stored in a queue known as the URXL. 305Ownership of URXEs is shared between DEMUX and QRX. 306 307**URXL:** URXE list. See URXE. 308 309**XSO:** External Stream Object. This is the API object representing a QUIC 310stream in the APL. Internally, it is the `QUIC_XSO` structure, externally it is 311a `SSL *` (and is a QSSO). 312
