Return-Path: 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 ; 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 ; 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 ; Wed, 21 Feb 2018 08:40:07 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id t126so1312459vkb.11 for ; 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 Date: Wed, 21 Feb 2018 16:39:55 +0000 Message-ID: Subject: handling a QUIC accept backlog To: QUIC WG Content-Type: multipart/alternative; boundary="001a1143fc2660e9e60565bb944d" Archived-At: X-BeenThere: quic@ietf.org 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 16:40:20 -0000 --001a1143fc2660e9e60565bb944d Content-Type: text/plain; charset="UTF-8" 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? --001a1143fc2660e9e60565bb944d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

When using a socket API for a QUIC server, it c= an happen that there are more incoming connections than the server can acce= pts at that moment. I imagine that a server will implement some sort of que= ue 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 hand= le this situation:

  • Drop all Initial packets.
  • Send a CONNECTION_CLOSE as a response to an I= nitial.
  • Reply with Retries to Initial packets, but dr= op 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 themselv= es without any guidance?

--001a1143fc2660e9e60565bb944d--