IETF Logo Mail Archive

Re: handling a QUIC accept backlog

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Wed, 21 February 2018 18:13 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 232AF12D890 for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 10:13:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 2nIFoq4pDX_g for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 10:13:13 -0800 (PST)
Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DC812D887 for <quic@ietf.org>; Wed, 21 Feb 2018 10:13:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3zmlw75Cm5zMmrF; Wed, 21 Feb 2018 19:13:11 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch
Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ1yQXrj5KVK; Wed, 21 Feb 2018 19:13:10 +0100 (CET)
X-MtScore: NO score=0
Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 21 Feb 2018 19:13:10 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: handling a QUIC accept backlog
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <CAOYVs2p=wdOMLxdMatoY4f=P3ZMCNOBHeg4-ep+dNJ8TRM7zEA@mail.gmail.com>
Date: Wed, 21 Feb 2018 19:13:10 +0100
Cc: QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch>
References: <CAOYVs2p=wdOMLxdMatoY4f=P3ZMCNOBHeg4-ep+dNJ8TRM7zEA@mail.gmail.com>
To: Marten Seemann <martenseemann@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/bCIpAePMdssFgTZFhj5CDlMvKAM>
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 18:13:15 -0000

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

v2.23.0 | Report a Bug | By Email