Recent trouble with QUIC?

Mon Sep 28 01:38:04 UTC 2015

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.