Re: handling a QUIC accept backlog

Martin Thomson <> Wed, 21 February 2018 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91080120724 for <>; Wed, 21 Feb 2018 15:50:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cqi98lqUUZ6H for <>; Wed, 21 Feb 2018 15:50:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 901C91200E5 for <>; Wed, 21 Feb 2018 15:50:44 -0800 (PST)
Received: by with SMTP id k7so2387018otj.0 for <>; Wed, 21 Feb 2018 15:50:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=96dN6jIeYnt/mYmSEhqukualw/Mal7qBJXFKjmM+pO0=; b=rmJRFiDEr+YCovphZzBHs9ti+4rKYWgMA6wqSl4rj90aXHaO8J9WmZ4smyiua3wPQB WaFSSWoqRBvoTtAcOKw0E9bz1RvmuFc5fqsiL+PgJ7IHNXduUWmBA1F3u2/GdAFiDtFO O7OPchuemhsJOSilBJ1B3cXkMpiswNdZ8C5x3vOZn+qi9JxB/F4RMC8ndalg18mSgEGf /M+Pw6L8SRDLrxhONUzeDc19cZa0mziJe3zX7YJSyb0K7ZYkr29YKwKFqS/+Ccmtg1LF fyZFHuHMIkxX8W+b6ZWCXBtNpZKG2oh80TlJm9IRPGLlucEulYniKI5R5Jq4XnHnm4Dz M3mQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=96dN6jIeYnt/mYmSEhqukualw/Mal7qBJXFKjmM+pO0=; b=kwg6G50Delb4neYiUdPcoRZXC7rOnP+3JhTdIRyfRnewoIy5dCyZN6eFSmh81RctIo CSKcUm/wNYf3PoYgus4fjzokDT6Raxic4IayfNTSO9jW9HTcfTevaACdM+B0eDSa/DdT fGK6C069+xuAq5WocWuZTqLfmQSh29ADQoPTCs5fqT8XkkVGd0a6cgJrk4uFccBLsaQ/ fNvWyQ0k7fLAoNKDIj/NnwZ2XbWyAJooh3BIZlb65Z8/6eLXtqUAHeSuuK8OGYCHJJqW cXOQedJVFLhsNc0cFi6mafpMxW0CUjJ3FMND26GhiiW/FyBXyrY2SOya8XfyVWG+EWTy tASA==
X-Gm-Message-State: APf1xPA36bWvk3qC6J0nSpMsRrqkVUkCFeb8qJ7Y6VRSHvYkkLLWdHaz E8KTn8+gIhmBDCAOwXm00ycpna3wm3lQSpV8rgI=
X-Google-Smtp-Source: AH8x227n04LDUxknBrWgREDW611jofpu0FnV8R23RZNw66NYr05YD8gZW50oImH31Q6CDTdgYCLEJtsIUqjwXvwDgWg=
X-Received: by with SMTP id 68mr3563421ota.392.1519257043795; Wed, 21 Feb 2018 15:50:43 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 21 Feb 2018 15:50:43 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Thu, 22 Feb 2018 10:50:43 +1100
Message-ID: <>
Subject: Re: handling a QUIC accept backlog
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>
Cc: Marten Seemann <>, QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Feb 2018 23:50:46 -0000

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
<> 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 <>om>:
>> 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?