Re: Recent trouble with QUIC?

[Matthew Kaufman <matthew () matthew at>]

Maybe Google should return the money you paid for access to their search engine and associated free applications during 
the time it was down.

Matthew Kaufman

(Sent from my iPhone)

> On Sep 27, 2015, at 6:38 PM, Lyle Giese <lyle () lcrcomputer net> wrote:
>
>
>
> > On 09/27/15 16:16, Saku Ytti 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.
>
> There are advantages to QUIC or Google would not be trying to work on it and implement it.
>
> The problem is that it has been added to a popular application(Chrome) which many/most end users know little to 
> nothing about QUIC and what the implications are when a version in Chrome is defective and harmful to the Internet.
>
> Part of freedom is to minimize the harm and I think that is where the parties replying to this thread diverge.  A 
> broken change that causes harm should have/could have been tested better before releasing it to the public on the 
> Internet.
>
> Or if a bad release is let loose on the Internet, how does Google minimize the harm?
>
> Lyle Giese
> LCR Computer Services, Inc.