RE: Expected Client Response to SERVER_BUSY

[Nick Banks <[e-mail]>]

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