Re: QUIC – Will it Replace TCP/IP?

[Michael Tuexen]

> 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. (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. I guess (e) can be done also with TCP FO and TLS 1.3.
The difference might be the length of the initial flight. (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...

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.

For me it looks like the benefits are:
* Increased level of encryption
* Extensibility (especially if you control both sides)

This might map differently to business cases.

Best regards
Michael
> 
> This is something I have debated with some of my colleagues for a while now.
> 
> Thinking in terms of NF we have:
> 
> 1) 1 audio connection
> <and>
> 2) 1 video connection (sometimes 3, but if we have 3 we take each
>   request and divide it amongst the 3 connections.. we have to
>   wait for all of them to complete).
> 
> So I don’t need QUIC for HOL blocking
> 
> We have TLS 1.3, so that means I have the quick start thing. And we
> also have a TCP over UDP stack that means I can run, if I want to, 
> my own TCP stack on each client… which means I can enable the
> TCP-fastopen… so I can get the 0-RTT start of quick (which means
> I can shave 100ms off of play delay… which in terms of a 1 hour
> movie is not that big of deal)..
> 
> I had this same angst when I got to NF since SCTP offered all of
> the features QUIC does now (and some more by the way) years ago.. but
> I could not justify:
> 
> 1) The development cost
> <and>
> 2) The CPU cost (QUIC is more costly then TCP just like SCTP is more costly)
> 
> So I am unsure of the benefit here. There is nothing new or novel in QUIC
> that other transports have not done or are already doing. And unless there
> is some huge benefit so I get a gain in QoE or CPU performance I can not 
> get from TCP I wonder why I need it?
> 
> I would love to know of some feature in QUIC that makes it a 
> undisputed gain that cannot be done in TCP and that would sell it
> to me .. but I just don’t know what that is..
> 
> 
> Suggestions on this marvelous feature, that I may
> not know about... would be most welcome…
> 
> R
> 
> 
> 
>> On Apr 29, 2020, at 8:03 AM, Scheffenegger, Richard <Richard.Scheffenegger at netapp.com> wrote:
>> 
>> FYI only.
>> 
>> 
>> Richard Scheffenegger
>> 
>> 
>> -----Original Message-----
>> From: Eggert, Lars <lars at netapp.com> 
>> Sent: Mittwoch, 29. April 2020 13:01
>> Subject: Re: QUIC – Will it Replace TCP/IP?
>> 
>> Hi,
>> 
>> Microsoft just announced that they are open-sourcing their QUIC stack (under an MIT license).
>> 
>> MSQUIC is suitable for application and kernel-use (it will ship as part of the Windows kernel), so it might be usable in other kernel contexts (FreeBSD/ONTAP, Linux) as well. The amount of work needed is likely (much) less than porting another QUIC stack that is only meant for user-space use. Also, based on my testing, MSQUIC is amongst the faster and most interoperable stacks.
>> 
>> In short, if we wanted to do something with QUIC, MSQUIC would probably a good starting point.
>> 
>> Lars
>> 
>> 
>> On 2020-4-29, at 2:38, Nick Banks <nibanks=40microsoft.com at dmarc.ietf.org> wrote:
>>> 
>>> Hey Folks,
>>> 
>>> We just open sourced the Microsoft QUIC implementation, MsQuic:
>>> https://github.com/microsoft/msquic. Feel free to read a little bit 
>>> about it in this post: 
>>> https://techcommunity.microsoft.com/t5/networking-blog/msquic-is-open-
>>> source/ba-p/1345441
>>> 
>>> Thanks,
>>> - Nick
>> 
> 
> ------
> Randall Stewart
> rrs at netflix.com
> 
> 
>