Re: QUIC – Will it Replace TCP/IP?

[Randall Stewart]

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?

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