Re: [quicwg/base-drafts] Describe a new version negotiation mechanism which allows for (#1755)

Ryan Hamilton <> Mon, 17 September 2018 19:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3F3212D7EA for <>; Mon, 17 Sep 2018 12:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.009
X-Spam-Status: No, score=-3.009 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hz5hBmEt8hlo for <>; Mon, 17 Sep 2018 12:24:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63322129619 for <>; Mon, 17 Sep 2018 12:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=xp2UEruck07HHOZ06mKMwjpDvZg=; b=eRNR6Dm8/Hi3+lgU x8MkvRxNfISfQMOsN9VpDIAp+hnI3p7Nz4668jkVTHY/VQEJNLx1Pdd6gw1KhP72 7b+IlMdjmYpx5HkzkYb+asKR5UZRY+++nFgDcg/pAFQuYygwDLUwmoq6+NjjJUH0 w16NVc92nOBZPbRhXJdm8flbukU=
Received: by with SMTP id filter0391p1iad2-7505-5B9FFF5F-1 2018-09-17 19:24:15.085618072 +0000 UTC m=+939478.046594874
Received: from (unknown []) by (SG) with ESMTP id Bp9yjRnPTPiFCWsDxn2GOg for <>; Mon, 17 Sep 2018 19:24:14.977 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id E76DFC1DC9 for <>; Mon, 17 Sep 2018 12:24:14 -0700 (PDT)
Date: Mon, 17 Sep 2018 19:24:15 +0000
From: Ryan Hamilton <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/1755/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Describe a new version negotiation mechanism which allows for (#1755)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b9fff5ee4f77_6fbd3fcbbd2d45c46361b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: RyanAtGoogle
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1Ud1Jwa4fB8+wcwwz1QwRsWSq0Jkqn37e8Sf fQCuGm4l1H3OU4A9xt/1Z92mkUoqMH+zuBp2FKLYbsmt0TgSkVRriB2jK7MbI6Vhu10YEInohHpdKu 2a4TMkuRWqeOy5fN5vC9M4yMKb0vk3jqioeTkIlcrA+8HtokRkUknpE76GPfy6JEezlJ4S80/0lCM1 s=
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Sep 2018 19:24:19 -0000

I think an issue for this would be a good idea.

I'm not sure that I understand what constraints on the two versions are required in order to allow this approach to work. Consider the case where only two versions are supported, A and B. The client sends an INITIAL packet containing the ClientHello (or the like) encoded with A, but indicates that it also supports B. The server and client both prefer B, so the server decide to upgrade to B. Are we guaranteed that everything needed for B will be in the A ClientHello? Could the TLS handshake mapping change between A and B is some way that would cause problems here? What about 0-RTT data? What if between A and B we changed the stream mapping / numbering? The client would have created (and sent) streams allocated with the logic of A but which would be incorrect for B? It seems really hard to guarantee that there are no such changes between A and B.

I think there are simpler solutions to the problem this PR intends to solve:
1) Advertise supported versions. For the HTTP/QUIC use case, Alt-Svc already gives us a mechanism to advertise QUIC versions so we're not in a position where the client doesn't know the server's versions.
2) Use two connections. Start a connection with versions A and send 0-RTT streams. When the client learns that the server supports a preferred version, it should start a new connection using version B, but not send new requests on this connection until/unless the handshake completes. Once that happens, the client should send new requests on B and close A once it become idle. This avoids waiting an RTT to learn about the new version and avoids the complexity of trying to upgrade an existing connection from one version to another.

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