unique tuples
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 04 May 2018 05:27 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 1541D1273E2 for <quic@ietfa.amsl.com>; Thu, 3 May 2018 22:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Dcov7wfqsmUg for <quic@ietfa.amsl.com>; Thu, 3 May 2018 22:27:06 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 37910127342 for <quic@ietf.org>; Thu, 3 May 2018 22:27:06 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id e78-v6so24355195iod.0 for <quic@ietf.org>; Thu, 03 May 2018 22:27:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=E5/9W3brD74JSFGXe0VOm1Vb3TrigvYn5jhEzlk43x4=; b=S9aHL9gVkijVlWbEr6DBbaFipJjElAl4FZnv1QVMWo8Bk1EF8jyWD9de4J8yki+ZYX tL4Dlkj4tb5QYXZ07FwNzSJ8kqwwJgA5pr9Knc1MxtRoJFeav6fGfnkfwoNyLczUS6H5 EQ4qVypSsMgEmD7iA+ScwuOcxkUwiwIlfCbqsrOE56bpHGrW/e1lOh+0Quy/uCy2CTj6 PMDcujC71UT5FUfTTareu9ywztoNKPg2QvmaUdi+gDWo9L9Pby1Vsk8cWXiYExtC30AU KALtYA6bZIj+PrVPD7ETd/Ukw/TxYtmyYZG6+e6pdkoMcHSTvGyM/r9hJKQmSuL7Fs6p R6VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=E5/9W3brD74JSFGXe0VOm1Vb3TrigvYn5jhEzlk43x4=; b=Rz0T3aoOa/l4Sm66j94TIWtBoEHt8WaEc3ZVSch037rAIGD8lU8NC6x9rXbU4fZhTP ZfdoqDrNigOQzz0T6v2pTqZIzkdfmE6RrypuFwTQEVq/sCXULp1jgP2gvYpJWMHVqAlA BYRhqERWXT3vLaudyDyCNf2JzajB5VcKEdVok2YLrA85suhMZtvRQ2EmZrroaYM0zPtq mOScrErBRqLW0l0acmo6V8mvkrtR0seURCoHvnlr3/iGfwiDZYZtcwOGOPX31pPC0Pop E8fKqlZX6KXzcynkU8nYV1+U8dHMJ4CJp4FDZceGXPgzpOvtBt4u+DEzV/3lXCgJOa/L vhUg==
X-Gm-Message-State: ALQs6tCVsEBfYC+CdgSVMpF3GZxOfYUxrpShru+BnMy+oktZyHB6xVCc anQ62qD8WwjqCl4lD0kSD3b00MZwu8KRyTRJUGlGfQ==
X-Google-Smtp-Source: AB8JxZrQJOXImvK/yCII0LWJuJgCamce0NFfiSnaM9KDUaLIi+3ICfGJT+HdFqVfTSl03vj19Pb72JAKhvPQR9IdU1U=
X-Received: by 2002:a6b:b60a:: with SMTP id g10-v6mr27130479iof.209.1525411625277; Thu, 03 May 2018 22:27:05 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 4 May 2018 01:27:04 -0400
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 04 May 2018 01:27:04 -0400
Message-ID: <CAN1APdfbFrHvc2Q8qGDbZBR44ouL0v+Loadtnay-jjqVvSmoZg@mail.gmail.com>
Subject: unique tuples
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000f9de2056b5a92c6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mjKGfF6DnluAKqeyhBBpH9MgHBU>
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 05:27:08 -0000
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