[184136] in North American Network Operators' Group
Re: Recent trouble with QUIC?
daemon@ATHENA.MIT.EDU (Lyle Giese)
Sun Sep 27 21:38:12 2015
X-Original-To: nanog@nanog.org
Date: Sun, 27 Sep 2015 20:38:04 -0500
From: Lyle Giese <lyle@lcrcomputer.net>
To: nanog@nanog.org
In-Reply-To: <CAAeewD9-f+xgufpsV5myi2hyCTF-WOca8MCGe1O=a96SFGPySg@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
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.
