IETF Logo Mail Archive

handling a QUIC accept backlog

Marten Seemann <martenseemann@gmail.com> Wed, 21 February 2018 16:40 UTC

Return-Path: <martenseemann@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866B912D872 for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 08:40:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBti5qq-Od4O for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 08:40:17 -0800 (PST)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FD412E894 for <quic@ietf.org>; Wed, 21 Feb 2018 08:40:07 -0800 (PST)
Received: by mail-vk0-x22a.google.com with SMTP id t126so1312459vkb.11 for <quic@ietf.org>; Wed, 21 Feb 2018 08:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=q7InYHrBt00CU1Vcj9gLy6r+Axby6i/lO6d9gMOyEvk=; b=DVt/aQF8m7MP+wtUeZPqAiNRytXXbN2H/kt/SqpMB44nPYNsVhUpSl5dLe0H96Aa7k 2if0xH70E6wO3/UPkwIHz1PLL23z0DoijC3QoHJ0xWP6ybADSHEMqkt92DNfTsypvuM1 Htm5SRkK4GuO9/AR/DdeLJ0ilDgMTCeLgS6bBeUwwnRcIVPPW21TVrmcbQkToJKXFuW0 v6VzyxxE7hkTwW4cFoOULOMRiEFem8IocFAeIlrMuWSW5uNqRxieDCOKdqFiFl6A+XG8 zmK5EKgnSV6Vm+5NNhF9xqTKpHTqTFq/brczLCPYXA7XhAPvrExe9gBQRIVGQwIrKTIQ 28zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=q7InYHrBt00CU1Vcj9gLy6r+Axby6i/lO6d9gMOyEvk=; b=W8EZ1/fKYwcG2BxtIE7CBBA62QlDCh1a5lIY0yiR4DnLfgZIsV1SAJbbThQxQrind6 D1Wxtdvx5yWAFWsL6ZWsOGPVWTDMTGWPB9QSM14/Y/fIAEHwdbwzyQvX2QySW74UKilP 2p4TeSef0qVvla9mUj8cJ6QnPfPUFp0VbQtlnRB03z/TcL7DbBmo7eWtqxOeeFNHDGr3 bgWrYgrg8fgKPuOftOq3cEIVmi1cWXN/i4Fq/fJ+7y3hWPtWLIygajpMsptxDQ8EsA3t CyCYUOCG1IP6YGbtKjPzWjwxKphp8jATdw85abSpGWK5xhWYR2FOmnhirYoEWqDQgmZE ZL6w==
X-Gm-Message-State: APf1xPCajUW9Lekz+XMZQkSs01QrlqSW3zZLThWy8Hpe6YYPiMkv1ucg CC+K3w449iuIRfoS2KWypg7kOwI9XJy9rI7gj6ZuAg==
X-Google-Smtp-Source: AH8x225PV7HG1o8fGk5dO9hkGNypCrwDxFLktkAaaz/TdXzLEi/mSsM1NHpvPS8t2Pp0kICvEysPYevdocBEtsD+e7I=
X-Received: by 10.31.161.70 with SMTP id k67mr2795917vke.82.1519231206220; Wed, 21 Feb 2018 08:40:06 -0800 (PST)
MIME-Version: 1.0
From: Marten Seemann <martenseemann@gmail.com>
Date: Wed, 21 Feb 2018 16:39:55 +0000
Message-ID: <CAOYVs2p=wdOMLxdMatoY4f=P3ZMCNOBHeg4-ep+dNJ8TRM7zEA@mail.gmail.com>
Subject: handling a QUIC accept backlog
To: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143fc2660e9e60565bb944d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IpG1AjDdMUWGZsVdLJGTiBetiwo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2018 16:40:20 -0000

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?

v2.23.0 | Report a Bug | By Email