QUIC v2

In order to get the most possibly focus on the core QUIC protocol and be ableto ship it on time, several features that were originally planned to be partof the core protocol have been postponed and are now planned to instead getdone in a subsequent QUIC version. QUIC version 2 or beyond.

The author of this document does however have a rather faulty crystal ball sowe can not tell for sure exactly what features will or will not appear inversion 2. We can however mention some of the features and things thatexplicitly have been removed from the v1 work to be “worked on later” and thatthen possibly might appear in a version 2.

Forward Error Correction

Forward error correction (FEC) is a method of obtaining error control in datatransmission in which the transmitter sends redundant data and the receiverrecognizes only the portion of the data that contains no apparent errors.

Google experimented with this in their original QUIC work but it wassubsequently removed again since the experiments did not turn out well. Thisfeature is subject for discussion for QUIC v2 but probably takes for someoneto prove that it actually can be a useful addition without too much penalty.

Multipath

Multipath means that the transport can by itself use multiple network paths tomaximize resource usage and increase redundancy.

The SCTP proponents of the world like to mention that SCTP already featuresmultipath and so does modern TCP.

Unreliable data

It has been discussed to offer “unreliable” streams as an option, that wouldthen allow QUIC to also replace UDP-style applications.

Non-HTTP adaptions

DNS over QUIC was one of the early mentioned non-HTTP protocols that justmight get some attention once QUIC v1 and HTTP/3 ship. But with a newtransport like this having been brought on to the world I cannot imagine thatit will stop there.