RE: handling a QUIC accept backlog

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 21 February 2018 20:15 UTC

From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CY4PR21MB01336E0007959CF0DF01D330B6CE0@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <CAOYVs2p=wdOMLxdMatoY4f=P3ZMCNOBHeg4-ep+dNJ8TRM7zEA@mail.gmail.com> <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> <CY4PR21MB01336E0007959CF0DF01D330B6CE0@CY4PR21MB0133.namprd21.prod.outlook.com>
MIME-Version: 1.0
Date: Wed, 21 Feb 2018 15:15:51 -0500
Message-ID: <CAN1APdeJjOqR08Y9p-qPa6h59sLf8F5Jr=9nimhBg4yCFairOw@mail.gmail.com>
Subject: RE: handling a QUIC accept backlog
To: Marten Seemann <martenseemann@gmail.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Praveen Balasubramanian <pravb@microsoft.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114760b20190d70565be98b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hIhkmUORaNIR9387uv3Ux-6kZ28>
Precedence: list

There is also the argument for HTTP 500 Server Busy - could be protocol
specific.
But load balancer might also want to know when routing encrypted data.
LB signals could also happen through the CID sub protocol -
helping load balancers might otherwise also help DoS attackers?
It could also be an ECN signal + drop.

Unless we really want to help load balancers, I agree it is more an
applicability thing.

On 21 February 2018 at 20.45.42, Praveen Balasubramanian (
pravb@microsoft.com) wrote:

This is somewhat related to DoS attack mitigation and could go into
“Security and Privacy Considerations” section of either the transport or
the applicability draft with some recommendation on the attack vectors and
mitigations.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja Kühlewind
Sent: Wednesday, February 21, 2018 10:13 AM
To: Marten Seemann <martenseemann@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Subject: Re: handling a QUIC accept backlog

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 <martenseemann@gmail.com>:
>
> 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?
>

handling a QUIC accept backlog Marten Seemann
Re: handling a QUIC accept backlog Mirja Kühlewind
RE: handling a QUIC accept backlog Praveen Balasubramanian
RE: handling a QUIC accept backlog Mikkel Fahnøe Jørgensen
Re: handling a QUIC accept backlog Martin Thomson