RE: Expected Client Response to SERVER_BUSY

[Nick Banks <[e-mail]>]

It would be nice to have a way for the server to say “QUIC is temporarily unavailable right now, please go use TCP instead.” Additionally, I don’t want to have to modify anything on the TCP side (Alt-Svc). The next connection after you fallback to TCP may try QUIC again, but you might just get the same behavior.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

________________________________
From: Ian Swett <[e-mail]>
Sent: Wednesday, February 20, 2019 6:41:40 AM
To: Brian Trammell (IETF)
Cc: Nick Banks; IETF QUIC WG; Mirja Kühlewind
Subject: Re: Expected Client Response to SERVER_BUSY

If a client follows 3xx redirects by default, then it seems sensible it'd fall back to TCP automatically, but I'm not sure an immediate QUIC connection close is equivalent to a redirect.  I can also imagine clients that don't follow redirects by default falling back to TCP, so I think I just chose a poor example.


On Wed, Feb 20, 2019 at 8:52 AM Brian Trammell (IETF) <[e-mail]<mailto:[e-mail]>> wrote:
hi Ian,

Sent from my iPhone

On 20 Feb 2019, at 14:34, Ian Swett <ianswett=[e-mail]<mailto:ianswett=[e-mail]>> wrote:

For HTTP/3, my intent was to close the connection immediately with a connection close as you suggest, then the client would fall back to TCP, and then ensure the next Alt-Svc advertisement via TCP cleared any existing Alt-Svc entry so QUIC wasn't tried again in the immediate future.

I hadn't thought of assigning semantics to a specific error code, but I'm reluctant to do so.  In our case, I think a more likely error code would indicate the infrastructure doesn't support QUIC, rather than DDoS, but the desired behavior of falling back to TCP and not attempting QUIC for a while is the same.

The assumption I made above is that the client immediately falls back to TCP.  That of course depends upon the type of client it is.  I'd expect a browser to fall back, but I wouldn't expect curl or wget to.

This is a bit of an aside, but I’m curious here: why not? I’ve always thought of the semantics of TCP fallback as equivalent to a 3xx redirect (either temporary or permanent, depending on the client heuristics wrt the underlying reason for the redirect). curl won’t do this automagically unless you tell it to, but iirc wget will...

Am I wrong in thinking that most clients will see this as YA form of redirect?

Cheers,

Brian

There is a decent amount of text on fallback in the Applicability draft: https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability..md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fops-drafts%2Fblob%2Fmaster%2Fdraft-ietf-quic-applicability.md&data=02%7C01%7Cnibanks%40microsoft.com%7Cda54737de15f4f6a414d08d697419140%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636862705204591925&sdata=F7YkRR5oHUTuGTPGHdji929999WlXfSK7nIBeFohyLo%3D&reserved=0>



On Tue, Feb 19, 2019 at 5:11 PM Nick Banks <nibanks=[e-mail]<mailto:[e-mail]..org>> wrote:
Hello Folks,

I’ve been looking at interim DDoS mitigation strategies for QUIC until we can have a more complete and QUIC aware DDoS and LB solution. One thing I came up with is just trying to force the client to fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and cooperation between the offload device and the backend server. Until that is complete, a simple solution could be a device in path just responding to new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SERVER_BUSY error. The logic to implement a simple device to do that should be quite trivial.

To that end, I was trying to figure out what the expected client response to any immediate (in the first RTT) connection close packets/frames would be and it seems we don’t have anything in the spec. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fallback to TCP immediately? Should we say anything in the spec?

Thanks,
- Nick