Re: Expected Client Response to SERVER_BUSY

[Ian Swett <[e-mail]>]

When the handshake fails for any reason, Chrome stops attempting to use
QUIC for 5 minutes to that hostname, and if the Alt-Svc is still present 5
minutes later(ie: it hasn't been cleared), then the next request to that
hostname after 5 minutes will try QUIC again.  If that QUIC handshake
fails, Chrome exponentially backs off and waits 10 minutes before trying
again.

An old, but fairly accurate doc describes this:
https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2LFxPM/edit

I think breaking it down by reason makes sense, as you suggest.  If the
handshake fails due to a connection close, not trying that hostname for 5
minutes seems like a reasonable approach.  If you receive no packets in
response, then it might make more sense to assume that UDP 443 is blocked
completely and not try QUIC at all for 5 minutes(unless you have other
active/recent QUIC connections).

This is an area of heuristics, so we should be careful not to over-specify
what a client should do, but I'd be happy to see a bit more detail on the
blackhole and connection close cases at least.  I'm also curious what
people think we should do in response to 3 or 5?

On Thu, Feb 21, 2019 at 10:43 AM Nick Banks <nibanks=
[e-mail]> wrote:

> I read that section, generally, as you should support fallback to TCP. No
> real specifics.
>
> I'm asking if we should add more. As Ian had already alluded to the client
> might take the Alt-Svc into account when falling back. How is it supposed
> to decide what to do if that says QUIC is available, but right now they
> just get a SERVER_BUSY error from QUIC?
>
> It might be worth calling out a few possible scenarios that might be
> encountered and recommend a course of action. I can think of several
> scenarios that a client might encounter that might be interested to
> describe:
>
> 1. Client gets no response ever.
> 2. Client only gets a response after a long time.
>
Defining 'a long time' is hard. I'd avoid trying to specify behavior for
this case separately.

3. Client gets some kind of protocol error in response (bad middlebox?).
> 4. Client gets a valid connection close in response.
> 5. Client handshake eventually fails (perhaps tampered with).
>
> Thanks,
> - Nick
>
> -----Original Message-----
> From: QUIC <[e-mail]> On Behalf Of Mirja Kühlewind
> Sent: Thursday, February 21, 2019 7:33 AM
> To: Töma Gavrichenkov <[e-mail]>
> Cc: Praveen Balasubramanian <[e-mail]>; IETF QUIC WG <
> [e-mail]>; Roberto Peon <[e-mail]>
> Subject: Re: Expected Client Response to SERVER_BUSY
>
> As pointer out earlier in this thread there is text in
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&amp;data=02%7C01%7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d69811e099%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&amp;sdata=KO36Bt6jX5Xe%2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&amp;reserved=0
> (section 2).
>
> Do you think anything else is needed?
>
>
>
> > Am 20.02.2019 um 23:56 schrieb Töma Gavrichenkov <[e-mail]>:
> >
> > > This mechanism provides a very low CPU cost fast fallback to TCP
> > > under DoS attacks until all infrastructure can support QUIC natively
> >
> > There are [a] few use cases when switching from TCP to QUIC v1 (in its
> current state) is not feasible because of huge operational costs. So it
> would be a more long term solution than that, probably till v2 or even
> further.
> >
> > > anything we do to allow non-malicious ones to respond appropriately
> > > requires pre-sharing, or for the connection to succeed
> >
> > The question here is basically how to ensure the latter given a X00 Gbps
> attack scale if you're neither Facebook nor Google.
> >
> > > In some circumstances, falling back to TCP may be something that the
> > > application shouldn't do
> >
> > Well, maybe, but then IMO the consequences of not being able to benefit
> from switching to TCP if you're doing certain things with QUIC should be
> outlined in the spec. Again, this is an application-level thing *now*, but
> formerly the transport used to take full care of it, and the change in that
> sort of breaks the habit of the users.
> >
> > --
> > Töma
>
>