Re: handling a QUIC accept backlog

[Martin Thomson <[e-mail]>]

Marten's question is a design one, I think.  But as an operational
practice, some additional documentation elsewhere could help.

I don't think that I had any expectation, but it seems like a good
idea to have some way that a server can signal "not now".  That
increases DoS risk (to the other discussion this week), but I think
that in terms of our agreed principle on trying to stop that sort of
attack, we shouldn't worry too much about that right now.

Dropping Initial packets works.  It's probably something to do in the
extreme case.
CONNECTION_CLOSE is probably better (better yet if we had an "I'm
overloaded" code, PR wanted).
Retry doesn't really work unless you think an extra round trip will
cool things down enough.
If you get to the point of receiving Handshake, then CONNECTION_CLOSE
is all you really have, but you probably want to avoid doing that
(because you already sunk a ton of effort into the first round of
Handshake messages).

Note that a server with too many connections can (and probably should)
use HTTP Alternative Services to shed load, but that won't necessarily
help in the short term.

On Thu, Feb 22, 2018 at 5:13 AM, Mirja Kühlewind
<[e-mail]> wrote:
> Hi Martin,
>
> I think that could fit well in the applicability doc. If people agree, please go ahead and file an issue or a PR.
>
> As a general note, both the applicability and the manageability statements are outdated, as things are so much in move still and therefore we didn’t put effort in to sync up with every revision. As soon as things (especially around the wire image and handshake) have settle a bit more, we will do an update.
>
> Mirja
>
>
>
>> Am 21.02.2018 um 17:39 schrieb Marten Seemann <[e-mail]>:
>>
>> When using a socket API for a QUIC server, it can happen that there are more incoming connections than the server can accepts at that moment. I imagine that a server will implement some sort of queue containing connections that have the handshake completed. Do we need any guidance on what should happen when that queue is full?
>>
>> There are multiple ways how a server could handle this situation:
>>
>>       • Drop all Initial packets.
>>       • Send a CONNECTION_CLOSE as a response to an Initial.
>>       • Reply with Retries to Initial packets, but drop Handshake packets.
>>       • Something more sophisticated?
>> Should we write anything about this in the spec, or is this something that implementations have to figure out for themselves without any guidance?
>>
>