Recent trouble with QUIC?

Sun Sep 27 21:16:22 UTC 2015

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.

-- 
  ++ytti