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" <list@satchell.net> 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.