nanog mailing list archives
Re: Recent trouble with QUIC?
From: Matthew Kaufman <matthew () matthew at>
Date: Sun, 27 Sep 2015 20:15:17 -0700
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 () lcrcomputer net> wrote: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.
Current thread:
- Re: Recent trouble with QUIC?, (continued)
- Re: Recent trouble with QUIC? Cody Grosskopf (Sep 25)
- Recent trouble with QUIC? Ca By (Sep 25)
- Re: Recent trouble with QUIC? chris (Sep 25)
- Re: Recent trouble with QUIC? Stephen Satchell (Sep 25)
- Re: Recent trouble with QUIC? Sean Hunter (Sep 25)
- Re: Recent trouble with QUIC? Matthew Kaufman (Sep 25)
- Re: Recent trouble with QUIC? Mike Hale (Sep 26)
- Re: Recent trouble with QUIC? James Bensley (Sep 26)
- Recent trouble with QUIC? Ca By (Sep 25)
- Re: Recent trouble with QUIC? Cody Grosskopf (Sep 25)
- Re: Recent trouble with QUIC? Saku Ytti (Sep 27)
- Re: Recent trouble with QUIC? Lyle Giese (Sep 27)
- Re: Recent trouble with QUIC? Matthew Kaufman (Sep 27)
- Re: Recent trouble with QUIC? Saku Ytti (Sep 27)
- Re: Recent trouble with QUIC? Cody Grosskopf (Sep 28)
- Re: Recent trouble with QUIC? Alan Buxey (Sep 27)