[quicwg/base-drafts] More Connection ID Space (#2736)

martinduke <notifications@github.com> Tue, 21 May 2019 15:53 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7979612016C for <quic-issues@ietfa.amsl.com>; Tue, 21 May 2019 08:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VSWEs7l5Fftc for <quic-issues@ietfa.amsl.com>; Tue, 21 May 2019 08:53:08 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3E712012D for <quic-issues@ietf.org>; Tue, 21 May 2019 08:53:08 -0700 (PDT)
Date: Tue, 21 May 2019 08:53:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558453987; bh=bPoR0Y7Qk4XsMrnmSIjWmWKKAknNsTNyIyEe9HSBZRY=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=XbliHlvltqIvh5Sjso8l0eMt8WveZLibAixnZzAvz311WnMzSTXq9HcsndLXr1T66 MqN4+FVC2T/1yY5XrKI/jh2E571+WfVscYomQ0nJwNureGwuDowWdsDnoQT5yR2CMq JzGq7dRJ6oKIvhYZaZTROd1fZw68xaEaaS/T31vo=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK72AZP2A5HYFZI4VPV26FIWHEVBNHHBVIAR2Q@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2736@github.com>
Subject: [quicwg/base-drafts] More Connection ID Space (#2736)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ce41ee3582c5_6f923fdc118cd96c52494"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ewvf5J51s_UexARSn0N9q_zVfqM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2019 15:53:10 -0000

Although it is quite late in the day for this objection, I find that we already bumping up against the limits of the 18 byte connection ID.

Inevitably, this touches on some issues we're exploring in the quic-load-balancers draft, which isn't adopted, and many of you are no doubt happily ignoring.

There are basically three uses of the 144 bits of CID entropy in QUIC-LB:

1) Server ID encoding -- as there are only so many servers one might have, 16 bits is usually enough for this.
2) "Private" server entropy -- the load balancer doesn't care what the bits are, but they're protected by crypto. The server created and encrypted the CID, so it can use this for its local purposes, but no one else can. The amount of this depends, but if you're using a 256-bit block cipher it's something like 240 bits -- plenty
3)  "Public" entropy -- not encrypted, these bits are readable by anyone who is familiar with the encoding scheme. With a 16 B encryption block, we have only 16 bits to play with here.

QUIC-LB is already taking 2 of these last bits for config rotation, which allows server pools to incrementally deploy new CID keys or encoding schemes. So we're down to 14 bits.

The public entropy is useful for a growing pile of trusted hardware devices that are presumably not going to perform CID decryption. On f5 boxes, we have a hardware disaggregator for the many dataplane processors and threads that are operating. Today, we'd use perhaps 8 of the bits, but in future architectures even 14 might not quite be enough.

And now, having chatting with Manasi Deval from Intel after her Prague talk about hardware offload, I'm fairly sure we're going to need 4 to cheaply encode the connection ID length, at least for servers that want to use this service.

If we ever wanted a solution that allowed multiple tiers of load balancing, which is not currently in scope for QUIC-LB, we don't have nearly enough space.

While I think that existing use cases can just barely make do with what we have, it is a bad sign if something in the invariants is *already* constraining use cases.

Offline in London, we've circulated a number of possible approaches to this, but the first-order discussion is a willingness to reopen the invariants. If so, there are a couple of solutions that won't break existing load balancer deployments.

I'm happy to write a PR if this is the consensus.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: