IETF Logo Mail Archive

Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

Kazuho Oku <notifications@github.com> Thu, 25 October 2018 21: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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF61277BB for <quic-issues@ietfa.amsl.com>; Thu, 25 Oct 2018 14:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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] 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 jiXYpaaYBAyd for <quic-issues@ietfa.amsl.com>; Thu, 25 Oct 2018 14:52:58 -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 16AAC124BE5 for <quic-issues@ietf.org>; Thu, 25 Oct 2018 14:52:58 -0700 (PDT)
Date: Thu, 25 Oct 2018 14:52:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540504376; bh=4FQrqKpno4sN8g8qbZgPhaw0EOi7Y689dN27V+ZS9lc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LdKALEF/nB1gq43CFT4wFGCHofzhVhcv+Fqtk4jFv0h2agaGn99DkraNpmNNUqRla S3G6l8barJ0nmYwFa6zXJb+Ej8b+RUPlqHdIipAm57lFJEEwn2IJp6AVzMF6ibcRBA R6wX92ULeZN8Po86R3NQH44gAatwJTwt6PQIfp94=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab4256927278dbe662a40343a3a4c4206c8166450992cf0000000117e9fd3892a169ce1640b1a8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1901/c433218454@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1901@github.com>
References: <quicwg/base-drafts/pull/1901@github.com>
Subject: Re: [quicwg/base-drafts] Compatible version upgrade (#1901)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bd23b38c8dfc_2ec23fefbccd45c420546e2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/ZmLts3Ah0SlP2a2GBE-ubAam5No>
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: Thu, 25 Oct 2018 21:53:00 -0000

@martinthomson 
> Thanks @kazuho for finding another hole. That validated the design that @ekr had for this, which separated the first attempted version from the supported versions list. It turns out that the preference order in the supported versions was necessary to prevent that. The client needs to tell the server how it would select between common versions so that the choice between incompatible versions can be validated.

I think we agree, though I might say that we do not need a list that lists every versions in the preference order. Just having a way to separate the supported versions into two groups in fine.

IMO, a workable design with minimal change would be use the packet version as a sentinel to divide the supported versions into two groups: a list that contains the versions that the client was not able to choose (due to VN) and a list that contains the other supported versions.

Consider the case where client supports five versions: v1, v1.1, v1.2, v2, v3. Upgrade is possible between different minor versions but not between major versions.

The client, first attempts to connect using v3. The first packet will be a v3 packet. V1.x server responds with a VN that contains v1, v1.2, v1.3.

Then, the client sends an Initial packet in v1, that contains a supported list of (v3, v2, v1, v1.1, v1.2). The server can determine which versions that the client assumed was impossible to use (i.e. v3, v2), because they are placed before v1 which is the packet version.

The benefit of using this "grouping" approach instead of the "total preference order" approach is that it allows the use of the _lowest_ version as the packet format when there are more than one compatible versions. That is generally preferable, because a server can perform a compatible version upgrade only if it can parse the packet format, and using the lowest version provides the maximum chance.

@martinthomson Do my comments sound sensible?

-- 
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/pull/1901#issuecomment-433218454

v2.23.0 | Report a Bug | By Email