Re: Expected Client Response to SERVER_BUSY

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Exponential backoff hopefully has a backstop (unlike the Iphone lockout
incident when you entered the wrong pin too many times).
How about a background QUIC poll ever so often while pursuing other
interests. Even if the connection cannot be used per se, it can provide
useful information. That might to an extend deal with some of the
interference events (3, 5).

On 21 February 2019 at 17.01.17, Ian Swett (
ianswett=[e-mail]) wrote:

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
<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
> <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
>
>