Re: unique tuples
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 04 May 2018 10:26 UTC
Return-Path: <mikkelfj@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 9B1651241F8 for <quic@ietfa.amsl.com>; Fri, 4 May 2018 03:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 eM0-HY2m0S2K for <quic@ietfa.amsl.com>; Fri, 4 May 2018 03:26:14 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 2EB5E120726 for <quic@ietf.org>; Fri, 4 May 2018 03:26:14 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id r9-v6so25054898iod.6 for <quic@ietf.org>; Fri, 04 May 2018 03:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wiX3+34ecZScuEPzaYersV3qp/nEx/kc6dQ4jpnCnBY=; b=b8XbYg0nSo1tD1VWcxNpYufh7eTci/4UqRIIzbRC3/Le+Km57rf7PobTsK4R2z1YH9 jS8mFkGCG2k9xHG7ugTJKz5xPbLs0VHODIXx7837U7hPqqPzjDef1ZdiVNftx2OPqvBe gBnHd5EDfkGjDyPanLMu0bFTmmh8+brwN3NMo88IRp7djcqrKh6902ELZr26RqBke1f2 7P+UsKRtDfu4p6Ie5PmUez5thxpclyy5bDosF6fz5Y7J3eZquOWoGMcXFq+Ut5UqKiZ8 ZU7b21Z+Kb0Adck+RrUundKaSty/KfhtIsWn4pNbhsNkgTiBsKFpesanV7wHYl+G664c zeQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wiX3+34ecZScuEPzaYersV3qp/nEx/kc6dQ4jpnCnBY=; b=Ii0OHjVUYL4pMo3dRjqsRueRY1qkvR6GhqeVEIodcZ1ei5xM8vVvABt6KxTxVOxhSy YnkFFPslSRMr0xuHb2qPe6SPrazpNis9EXieJg+rBKJzE354znMgr6OyrJlTMizCOEB+ cwMIjVMBEL+coJ1v7cKcsEnvBl279/Nmf0CbVMnIWBo3sXmW3VME2aL94mZ3SuFa4C0T c//0L5wcm8UzS8qm/mU63vbAScPDXnoAFeZ7UvOogsJ5eM7HdUpU2w3/tOKkTIcfdmME IwpQZV+ncqwOZMsyE7G56PjqKvxzvz4FfG7lakepCNYNhn/GyF/QaJpQVf/xtckagkFp nw8Q==
X-Gm-Message-State: ALQs6tCh5CuGJybomvOMuGrB9oiVpMmTdXKGdHM5YaR5NU3hLk4umAsR EYA+29WArOvOksRcjFNp/wb7rIeUQs4FpA88ESE=
X-Google-Smtp-Source: AB8JxZr9HqLEVXD0PwAC5fd4SVXFCUmCAebOYMbRHlH54xkocdsBNkvTAZK+E/GVtzNstQb0NtZSGumsmoBen/otpyI=
X-Received: by 2002:a6b:5010:: with SMTP id e16-v6mr28132625iob.274.1525429573568; Fri, 04 May 2018 03:26:13 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 4 May 2018 03:26:12 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CABkgnnWG_qSOLak23_zyxff6QSV2rGWSLTf+Bw94JVF0v-L1zg@mail.gmail.com>
References: <CAN1APdfbFrHvc2Q8qGDbZBR44ouL0v+Loadtnay-jjqVvSmoZg@mail.gmail.com> <CABkgnnWG_qSOLak23_zyxff6QSV2rGWSLTf+Bw94JVF0v-L1zg@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 04 May 2018 03:26:12 -0700
Message-ID: <CAN1APddL7UNWqF8JrEz+HeFMqJOU2xQ2zO7_GJE1V9i=j_XyHQ@mail.gmail.com>
Subject: Re: unique tuples
To: Martin Thomson <martin.thomson@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dcd030056b5ebfd6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RRRgHVV_lWohH9xyKWJexjCPNaQ>
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: Fri, 04 May 2018 10:26:16 -0000
Thanks, this is helpful. On 4 May 2018 at 09.01.13, Martin Thomson (martin.thomson@gmail.com) wrote: Yes, with the change to connection IDs, it should be possible to have multiple connections running concurrently on the same address tuple. This is true at any stage of the connection, including the handshake. Of course, you have to use a connection ID if this is what you want to do. On Fri, May 4, 2018 at 3:27 PM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> wrote: > There has been a lot of back and forth on unique tuples in QUIC, and I am not quite sure where it all landed. > It is my understanding that at some meeting it was decided to require unique tuples in V1, if only in certain contexts like handshake for the sake of simplicity. At the same time, having introduced dual CID’s the need for unique tuples is greatly reduced along with random initial CID’s that are reflected in version negotiation and stateless retry. > Reading through the spec, I can’t find any obvious places where unique tuples are still required unless a peer volunteer to have a 0-length CID. > This does matter a lot, because there is a world of difference between managing a single socket and many concurrent sockets in how you talk to the OS. QUIC makes it possible to move all the 10K multiplexing problem into QUIC and out of the OS interface, except for this one detail. Even if it is only for, say, handshake, it still places a constraint that must be handled. > It of course also matters wrt. ephemeral port exhaustion although the argument here is that if you limit it to the duration of handshakes you should be good. But especially in server p2p with many concurrent connections between same hosts, this adds complexity. > So bottom line, do we still have constraints in this area, and are they really worth keeping? And if so, could this be made more obvious in the spec? And if not, could it be made explicit that unique tuples are only required if the CID is 0 - it already almost says so for connection identification, but this does not exclude certain packet types from having such a constraint. > Kind Regards, > Mikkel Fahnøe Jørgensen
- unique tuples Mikkel Fahnøe Jørgensen
- Re: unique tuples Martin Thomson
- Re: unique tuples Mikkel Fahnøe Jørgensen