Re: Recent trouble with QUIC?

[Cody Grosskopf <codygrosskopf () gmail com>]

I care about the application layer.


ps. nice work on oxidized!

On Sun, Sep 27, 2015 at 2:16 PM, Saku Ytti <saku () ytti fi> wrote:

> On 25 September 2015 at 16:20, Ca By <cb.list6 () gmail com> wrote:
>
> Hey,
>
> > I remained very disappointed in how google has gone about quic.
> >
> > They are dismissive of network operators concerns (quic protocol list and
> > ietf), cause substantial outages, and have lost a lot of good will in the
> > process
> >
> > Here's your post mortem:
> >
> > RFO: Google unilaterally deployed a non-standard protocol to our
> production
> > environment, driving up helpdesk calls x%
> >
> > After action: block udp 80/443 until production ready and standard
> ratified
> > use deployed.
>
> I find this attitude sad. Internet is about freedom. Google is using
> standard IP and standard UDP over Internet, we, the network engineers
> shouldn't care about application layer. Lot of companies run their own
> protocols on top of TCP and UDP and there is absolutely nothing wrong
> with that. Saying this shouldn't happen and if it does, those packets
> should be dropped is same as saying innovation shouldn't happen.
> Getting new IETF standard L4 protocol will take lot of time, and will
> be much easier if we first have experience on using it, rather than
> build standard and then hope it works without having actual data about
> it.
>
> QUIC, MinimaLT and other options for new PKI based L4 protocol are
> very welcome. They offer compelling benefits
> - mobility, IP address is not your identity (say hello to 'mosh' like
> behaviour for all applications)
> - encryption for all applications
> - helps with buffer bloat (BW estimation and packet pacing)
> - helps with performance/congestion (packet loss estimation and FEC
> for redundant data, so dropped packet can be reconstructed be
> receiver)
> - fixes amplification (response is smaller than request)
> - helps with DoS (proof of work) (QUIC does not have this)
> - low latency session establishment (Especially compared to TLS/HTTP)
>
> I'm sure I've omitted many others.
>
>
> --
>   ++ytti