Re: Recent trouble with QUIC?

[Sean Hunter <jamesb2147 () gmail com>]

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.