IETF Logo Mail Archive

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

Ryan Hamilton <notifications@github.com> Fri, 26 October 2018 18:22 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 C6E12130E8B for <quic-issues@ietfa.amsl.com>; Fri, 26 Oct 2018 11:22:46 -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 jvItKox2-Zdj for <quic-issues@ietfa.amsl.com>; Fri, 26 Oct 2018 11:22:44 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9BF130E76 for <quic-issues@ietf.org>; Fri, 26 Oct 2018 11:22:44 -0700 (PDT)
Date: Fri, 26 Oct 2018 11:22:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540578163; bh=9SovC0JQa5HLFMNwI2X/0ZQJU+VmCDyp5P4aS8TIL1Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HEd55/uqdrZzYsY8T+iTf84G4CvSMf4tEwSmN2lolIRVWw1I4WrVPKylyV+7dwI5u UGVYdBF+6WTt2eL3lJiUFFp7E5ChZc65I0vMTDEePCPjIP5CUHrS/DOHryyMwUm1EC XoYU5yRyYXVf4K+QOc9sGjhY9guO+GcOuKwh7anw=
From: Ryan Hamilton <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abaac7874d28781f1d13be3b4901cd2a081de5ba1792cf0000000117eb1d7392a169ce1640b1a8@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/c433500016@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_5bd35b73d677a_65563f9b9b6d45b87404e0"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/sfvtIsn3tY5xEYyLbKRb-T9thJU>
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: Fri, 26 Oct 2018 18:22:53 -0000

I'm not a fan of this "compatible version upgrade". It seems to introduce complexity and does not appear necessary. In order of this behavior to be a win over the existing version negotiation mechanism, we need both the client and the server to support both the old and new version. If the client is an HTTP client it should use Alt-Svc to pick the correct best version in which case no version negotiation will happen at all. As such, I have a hard time seeing where we expect this to be used. If we're not doing HTTP, the client can simply cache the last version that server supported and use the best version from that list for the next connection, again typically avoiding version negotiation altogether.

In other words, there's a bunch of complexity here that I really don't see realistic benefits from.) Not to mention, this seems like a rather major piece of new behavior so close to the finish line.)

-- 
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-433500016

v2.23.0 | Report a Bug | By Email