Re: Expected Client Response to SERVER_BUSY

[Ian Swett <[e-mail]>]

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]>
wrote:

> hi Ian,
>
> Sent from my iPhone
>
> On 20 Feb 2019, at 14:34, Ian Swett <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://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability.md>
>
>
>
> On Tue, Feb 19, 2019 at 5:11 PM Nick Banks <nibanks=
> [e-mail] <[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
>>
>