These are all interesting viewpoints. Personally, I was only surprised that Google didn't:
A) identify the issue during early rollout (starting Sept 9) when Google has specifically talked up to the community their tooling for monitoring QUIC changes B) catch what seems like a pretty basic bug during Chrome code reviews C) identify the problem more quickly once they realized that *something* was wrong (I guess another tooling issue) D) roll back more quickly (though perhaps identification was really the delaying factor here) I do find the anecdote about support amusing, though. Google has always resisted providing support of any kind; I think it's a culture that comes from their extremely strong engineering history where needing support is viewed as a failure of the engineering and product teams. Recovery times could probably be improved if they had a help desk, but I'm not sure customer satisfaction would be improved in any significantly value adding way. The lesson I walked away with is that if you don't want QUIC on your network, don't allow it. At my institution, I think we view this the same way we'd view a problem with any website; we're only responsible for making sure your packets are flowing out to the internet and back. Finally, thanks to all who responded. It's been an informative experience. On Sep 25, 2015 7:45 PM, "Stephen Satchell" <[email protected]> wrote: > On 09/25/2015 04:20 PM, Ca By wrote: > >> 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. >> > > Let me be gentle about this. Why were you allowing 80/udp and 443/udp in > the first place into your production environment? > > In my network, I run a mostly-closed firewall, only allowing those ports > that are needed to be forwarded between the inside and outside networks. > > I don't have -- or need -- a DMZ here at this time, so I don't have to > worry about that side of the routing triangle. If I did, I would also run > mostly closed between inside/outside and the DMZ. > > I'm liberal about opening ports on request, but the ports have to be > requested before I'll allow them in, out, or forwarded. >
