[184155] in North American Network Operators' Group
Re: Recent trouble with QUIC?
daemon@ATHENA.MIT.EDU (Cody Grosskopf)
Mon Sep 28 12:47:56 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <CAAeewD9-f+xgufpsV5myi2hyCTF-WOca8MCGe1O=a96SFGPySg@mail.gmail.com>
Date: Mon, 28 Sep 2015 09:45:54 -0700
From: Cody Grosskopf <codygrosskopf@gmail.com>
To: Saku Ytti <saku@ytti.fi>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
>
