Recent trouble with QUIC?

Mon Sep 28 03:15:17 UTC 2015

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 at lcrcomputer.net> wrote:
> 
> 
> 
>> On 09/27/15 16:16, Saku Ytti wrote:
>> On 25 September 2015 at 16:20, Ca By <cb.list6 at 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.