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 <[email protected]> wrote: > > > >> On 09/27/15 16:16, Saku Ytti wrote: >> On 25 September 2015 at 16:20, Ca By <[email protected]> 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.
