Re: QUIC – Will it Replace TCP/IP?

[Matt Joras]

Full disclosure: I work on a QUIC implementation for my $DAYJOB (not msquic).

On Wed, Apr 29, 2020 at 12:58 PM Michael Tuexen <tuexen at freebsd.org> wrote:
>
> > On 29. Apr 2020, at 14:13, Randall Stewart <rrs at netflix.com> wrote:
> >
> > That is interesting and something we may in the future
> > interest us.. but I am not sure what exactly is
> > the gain we get from QUIC?
> From https://github.com/microsoft/msquic
>
> (a) Handshake authenticated with TLS 1.3
> (b) All packets are encrypted
> (c) Parallel streams of application data.
> (d) Improved (compared to TCP) congestion control and loss recovery.
> (e) Exchange application data in the first round trip (0-RTT).
> (f) Survives a change in the clients IP address or port.
> (g) Easily extendable for new features (such as unreliable delivery).
>
> (a) and (b) are also true for the payload if you use TLS 1.3/TCP, but not
> for the transport information.
Indeed, this is something that is a benefit for QUIC implementers but
also "problematic" for network operators. By keeping most of the
transport encrypted, "middle boxes" on the path can make very few
assumptions about how QUIC works, which prevents the gradual
ossification of protocol features we have seen with TCP, as many
features are not usable on the general Internet.

>
> (c) is application dependent. If only a small
> number of streams are needed, you can use multiple TCP connections. (d) is
> interesting. The CC in MSQUIC is Cubic, which is also available for TCP. I'm not
> sure about the relation of RACK loss recovery and QUIC loss recovery. Would
> be interesting to know.
If you are interested, I highly recommend you read the current
recovery draft, it is accessible:
https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html
In general the IETF charter for QUIC is to _not_ innovate in the
recovery and congestion control space, but rather integrate the
current best practices for TCP (from published RFCs). The same
algorithms that apply to TCP generally end up being easier to
implement in QUIC, as you do not need to deal with things like
sequence number ambiguity for retransmissions (QUIC packet numbers are
monotonically increasing). For congestion control, the draft describes
a variant of Reno, not Cubic, though most major deployments will
probably end up using their own implementation of Cubic or BBR or
something else.

> I guess (e) can be done also with TCP FO and TLS 1.3.
> The difference might be the length of the initial flight.
Technically yes, though TCP FO has the general problem of middle
boxes, often home routers, blocking SYNs with payloads.

> (f) is not possible
> with base TCP, but MPTCP has been deployed for that use case, as far as I know.
> (g) is harder to achieve...
MPTCP is much more ambitious and complex than the connection migration
described in the QUIC drafts. MPTCP nominally provides a way to have
Active/Active paths, rather than simply migrating to a new path. MPTCP
has also not seen wide adoption outside of Apple's usecase, AFAIK. An
implementation has only recently become available on Linux, and never
passed a prototype state for FreeBSD.

> Please note that the transport features are available via SCTP, but not used
> that much. Partial unreliability is available in WebRTC data channels, but I
> don't know if it is used that much.

SCTP, being a new L4, has the problems of actually being usable on the
Internet. The whole reason QUIC is built on top of UDP is that
operators allow a whitelist of protocol types, including UDP.

> For me it looks like the benefits are:
> * Increased level of encryption
> * Extensibility (especially if you control both sides)
I would agree with this but also add to it.

>From personal experience, the loss recovery described in the QUIC
drafts outperforms stock TCP in Linux even when the congestion control
algorithms are the same. This is measurable in both strictly transport
terms (retransmissions, TLPs, etc) but also in real application
metrics (e.g. video MTBR, request latency, etc.). This could be
achieved with TCP with tighter control of OS's TCP stack, or by doing
something like TCP over UDP, but I would actually argue the
development cost of changing an OS TCP stack is higher for most places
than utilizing or creating their own QUIC implementation. You an
already see this, in practice. There are over a dozen QUIC
implementations at various stages of maturity (see a list here:
https://github.com/quicwg/base-drafts/wiki/Implementations). There are
probably more people hacking on QUIC right now than major OS TCP
implementations, and QUIC isn't even an RFC yet. QUIC is highly
accessible as a protocol. There are only 4 drafts to read, compared to
decades of TCP RFCs and drafts and "de facto" standards.

Beyond this QUIC being typically implemented in userspace has
advantages and disadvantages. At the cost of CPU, which is a cost that
can gradually be brought down, applications can benefit from a tighter
integration with the transport than you can achieve with syscalls and
BSD sockets. This, when combined with the inherent extensibility
relative to TCP, makes it a very appealing protocol if you have
concerns beyond throughput per CPU cycle.

I don't think TCP is going anywhere any time soon, but it's almost
certain that within the next decade total QUIC traffic on the internet
will be similar to the volume of TCP.

Matt