|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org In-Reply-To: <560899FC.6010405@lcrcomputer.net> From: Matthew Kaufman <matthew@matthew.at> Date: Sun, 27 Sep 2015 20:15:17 -0700 To: Lyle Giese <lyle@lcrcomputer.net> Cc: "nanog@nanog.org" <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org Maybe Google should return the money you paid for access to their search eng= ine 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: >=20 >=20 >=20 >> On 09/27/15 16:16, Saku Ytti wrote: >> On 25 September 2015 at 16:20, Ca By <cb.list6@gmail.com> wrote: >>=20 >> Hey, >>=20 >>> I remained very disappointed in how google has gone about quic. >>>=20 >>> They are dismissive of network operators concerns (quic protocol list an= d >>> ietf), cause substantial outages, and have lost a lot of good will in th= e >>> process >>>=20 >>> Here's your post mortem: >>>=20 >>> RFO: Google unilaterally deployed a non-standard protocol to our product= ion >>> environment, driving up helpdesk calls x% >>>=20 >>> After action: block udp 80/443 until production ready and standard ratif= ied >>> use deployed. >>=20 >> 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. >>=20 >> 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) >>=20 >> I'm sure I've omitted many others. >=20 > There are advantages to QUIC or Google would not be trying to work on it a= nd implement it. >=20 > The problem is that it has been added to a popular application(Chrome) whi= ch many/most end users know little to nothing about QUIC and what the implic= ations are when a version in Chrome is defective and harmful to the Internet= . >=20 > Part of freedom is to minimize the harm and I think that is where the part= ies replying to this thread diverge. A broken change that causes harm shoul= d have/could have been tested better before releasing it to the public on th= e Internet. >=20 > Or if a bad release is let loose on the Internet, how does Google minimize= the harm? >=20 > Lyle Giese > LCR Computer Services, Inc.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |