Re: [quicwg/base-drafts] Client connection IDs are broken (#2844)

Christian Huitema <notifications@github.com> Tue, 25 June 2019 19:48 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF36F12011F for <quic-issues@ietfa.amsl.com>; Tue, 25 Jun 2019 12:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCKqpXG1y1DB for <quic-issues@ietfa.amsl.com>; Tue, 25 Jun 2019 12:48:38 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31CD120188 for <quic-issues@ietf.org>; Tue, 25 Jun 2019 12:48:38 -0700 (PDT)
Date: Tue, 25 Jun 2019 12:48:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1561492118; bh=OoyfTVhuXEBtNfLOpDeYDKcJveHzgoOefKhu7DHAMSQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dUWiK1Sp7InVHTtO13j1QTolksXlW+cmQeIywmPglRMjdn6q5X/M3EiIVnD4SOxbe G+srLJoQtSGe9uhmXpbrCfSoVWLp78i95XVmE6sRKubtWhbD/pkj8KOwJgfvxX2prK EfWKSwH+KR+fvDPOdM8OAfW0J/X2X64ubvvmEZ1k=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3ACZDEJGNU766ZBPV3D6WRLEVBNHHBW5BWIY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2844/505595723@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2844@github.com>
References: <quicwg/base-drafts/issues/2844@github.com>
Subject: Re: [quicwg/base-drafts] Client connection IDs are broken (#2844)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d127a95f05c5_5e863fbd2e6cd95c790af"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/ORIMOwmyM-76ldlVtFZ6vhQ9vHo>
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, 25 Jun 2019 19:48:41 -0000

On 6/25/2019 12:31 PM, David Schinazi wrote:

> QUIC supports client connection IDs (CIDs) in order to allow a client
> to multiplex multiple QUIC connections on the same local IP and port.
> However, the current spec doesn't allow that to work, as pointed out
> by @kazuho <https://github.com/kazuho> on #2834
> <https://github.com/quicwg/base-drafts/issues/2834> : if a server
> decides to use zero-length CIDs, then the client cannot establish
> multiple connections to that server from the same local port. For this
> to work, the client would need to know out-of-band that the server
> will not use zero-length CIDs, and that's not viable.
>
> Therefore we have two protocol features that are at odds with one another:
> (1) server can share port and use zero-length CIDs (which prohibits
> migration)
> (2) client can share port and use non-zero-length CIDs
>
> We can't have both (1) and (2) because the client wanting to do (2)
> doesn't know if the server will do (1) or not. If that happens, long
> headers will be demultiplexed properly because they contain the
> client's CID, but short headers from client to server do not and
> therefore cannot be demultiplexed.
>
> @huitema <https://github.com/huitema> and I have a use-case for (2)
> which is a QUIC proxy that only uses one port for outbound connections
> and relies on client CIDs for demultiplexing. I don't see a use for (1).
>

Sure, but that use case comes with a deployment requirement. QUIC nodes
using the proxy service MUST use a CID of equal or larger length than
required by the proxy. This is a requirement on incoming packets, and
the CID on incoming packets is chosen by the intended recipient of these
packets, in our case the nodes behind the proxy. It is not a requirement
of outgoing packets -- the proxy will just send the packets formatted by
the client to the address and port that the clients specifies. It will
work even if Azure servers are using zero length CID. Theses servers
won't work behind a proxy, but they will reachable through the proxy.

-- Christian Huitema



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2844#issuecomment-505595723