<story><title>QUIC – Will It Replace TCP/IP?</title><url>https://www.brighttalk.com/webcast/663/382768</url></story><parent_chain><item><author>_vbdg</author><text>Nah, I think it won&amp;#x27;t.&lt;p&gt;1. Not everything needs encryption, so QUIC&amp;#x27;s built-in TLS doesn&amp;#x27;t always make sense.&lt;p&gt;2. Not everything that needs encryption needs TLS specifically.  TLS is not a one-size-fits-all solution.&lt;p&gt;These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement.&lt;p&gt;By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]?  Different environments benefit from different algorithms so I don&amp;#x27;t see why.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;draft-ietf-quic-recovery-12#section-4&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;draft-ietf-quic-recovery-12#sect...&lt;/a&gt;</text></item></parent_chain><comment><author>vasilvv</author><text>&amp;gt; By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don&amp;#x27;t see why.&lt;p&gt;It&amp;#x27;s a &amp;quot;reasonable default&amp;quot;, in the sense that it normally works quite well, and is easy to implement.  The dangerous thing about congestion control is that it&amp;#x27;s really easy to get it wrong and not notice (as noticing requires performance testing and monitoring).&lt;p&gt;Google QUIC uses BBR on the server side.  I wrote the initial version of said BBR implementation, and it took a lot of effort to get it to a production-ready state, so I would not generally recommend writing BBR from scratch.  CUBIC is much simpler than BBR, but is also prone to subtle bugs like [0].&lt;p&gt;&amp;gt; 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution.&lt;p&gt;I&amp;#x27;m actually curious what use cases you have in mind.  TLS definitely does not cover 100% of all possible cases, but I&amp;#x27;ve seen a surprising number of cases where people rolled their own thing when using (D)TLS would have just worked.&lt;p&gt;[0] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;bitsup.blogspot.com&amp;#x2F;2015&amp;#x2F;09&amp;#x2F;thanks-google-tcp-team-for-open-source.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;bitsup.blogspot.com&amp;#x2F;2015&amp;#x2F;09&amp;#x2F;thanks-google-tcp-team-fo...&lt;/a&gt;</text></comment>
<story><title>QUIC – Will It Replace TCP/IP?</title><url>https://www.brighttalk.com/webcast/663/382768</url></story><parent_chain><item><author>_vbdg</author><text>Nah, I think it won&amp;#x27;t.&lt;p&gt;1. Not everything needs encryption, so QUIC&amp;#x27;s built-in TLS doesn&amp;#x27;t always make sense.&lt;p&gt;2. Not everything that needs encryption needs TLS specifically.  TLS is not a one-size-fits-all solution.&lt;p&gt;These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement.&lt;p&gt;By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]?  Different environments benefit from different algorithms so I don&amp;#x27;t see why.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;draft-ietf-quic-recovery-12#section-4&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;draft-ietf-quic-recovery-12#sect...&lt;/a&gt;</text></item></parent_chain><comment><author>ajrw</author><text>The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.</text></comment>