QUIC
Last updated
Last updated
QUIC was developed and deployed by Google in 2013, but was presented as a standard in 2021 by RFC9000.
QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks.
QUIC handshake combines the negotiation of cryptographic (TLS) and transport parameters.
It is structured to allow the exchange of application data as soon as possible.
Application protocols exchange information over a QUIC connection via streams which are ordered sequences of bytes. Two types of streams can be created:
Bidirectional streams, which allow both endpoints to send data.
Unidirectional streams, which allow a single endpoint to send data.
Avoids head-of-line blocking across multiple streams.
When a packet loss occurs, only streams with data in that packet are blocked waiting for a retransmission to be received, while other streams can continue making progress.
Two levels of data flow control in QUIC:
Stream flow control, which prevents a single stream from consuming the entire receive buffer for a connection by limiting the amount of data that can be sent on each stream.
Connection flow control prevents senders from exceeding a receiver's buffer capacity for the connection by limiting the total bytes of stream data sent on all streams.
Use separate sequence numbers for data and packet delivery.
Decouple reliability completely from ordered delivery.
Packet numbers are monotonically increasing (and hence unique).
Distinct from frame offsets within the stream.
Use the time between the transmission of a packet and its ACK (identifiable using a unique packet number) for RTT estimate.
Regardless of original transmission or retransmission.
Packet loss was detected through a lack of ACK packets.
However, the congestion control is independent of RTT.
One of the most used algorithms is CUBIC.
Congestion control does not depend on the delays of the wireless medium.
Congestion control is applied upon detection of packet loss.
Again, packet loss may not be a sign of congestion.