Re: QUIC – Will it Replace TCP/IP?

Wed Apr 29 20:57:35 UTC 2020

> On Apr 29, 2020, at 3:57 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. (c) is application dependent.

I am not actually worried about (b) we used TLS and the transport
headers do not bother me if they are out in the open. And yes we
have TLS 1.3 enabled for clients who can do it at least.
(c) was my point, we don’t need it.. if we needed it we would
have had SCTP in service at NF long ago.

(d) I take issue with, sure if you compare to new-reno and don’t
add in all the advances that have gone on for CC. Rack/TLP/BBR et.al.
We have our own “advanced” CC as a matter of fact, BBR itself has
never been good for us yet.. we are still trying to understand why… basically
it gives us worse Quality of Experience then  our own mix of CC that
is in our rack stack.

> 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.

I suspect at least from talking to Ian that they use Rack and TLP. And
I believe they have a version of BBR in Google Quic...

> Would
> be interesting to know. I guess (e) can be done also with TCP FO and TLS 1.3.

Correct.

> 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.

I don’t think for our use case we need (f) again, SCTP had that at least
10 years ago if we thought it was important.. and of course MPTCP also
opens up the path for TCP to do it too.

> (g) is harder to achieve…

Yes for TCP (g) is harder to achieve, but of course that is not true
for SCTP … but again I need a compelling reason to spend the man power
and the CPU expense .. and so far I don’t see it.. if I needed some
of these features SCTP would have done the trick..

> 
> 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)

And currently I don’t see where I get a big benefit from it.. yes
the extensibility is nice, but if you control both sides you can
do stuff to TCP.. we are close to having TCP over UDP deployed 
and once you do that you can have all sorts of new options or other
things that standard TCP can’t do.. so again.. only the encryption and
heck if I am doing TCP over UDP, I could go one further and put DTLS
in the picture and have all the encryption I wanted.. all that would
be left is the UDP header exposed...

I think the key is that it depends on your business case.. and so
far I don’t see a compelling one …

R

> 
> 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
>> 
>> 
>> 
> 

------
Randall Stewart
rrs at netflix.com