IETF Logo Mail Archive

[quicwg/base-drafts] Version negotiation gaps (#89)

Mike Bishop <notifications@github.com> Sat, 17 December 2016 21:24 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 C6823129654 for <quic-issues@ietfa.amsl.com>; Sat, 17 Dec 2016 13:24:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 ulhHGj8s4HmB for <quic-issues@ietfa.amsl.com>; Sat, 17 Dec 2016 13:24:40 -0800 (PST)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FEB12711D for <quic-issues@ietf.org>; Sat, 17 Dec 2016 13:24:39 -0800 (PST)
Date: Sat, 17 Dec 2016 13:24:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1482009878; bh=Zj0+v53M13zn9AuSWd/Dti4XhEb/jchnau9C1OpZZeA=; h=From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=hAoER+nL7nMB1xqpJMclo9+SOdJ6/q7bQXvPF0Ej6jBjhBRgOv2rtEpqX/etLz6Cm NTbhyGDXaC44YZDLiVS6uRgVm10HZ80bk0eYgnjxB8a+Di3WLiIsCT4N2a75J2TIZ2 ZKfaW7b9fRDxFOlCfTH3B4dVF7MFGDACBhyArItk=
From: Mike Bishop <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/89@github.com>
Subject: [quicwg/base-drafts] Version negotiation gaps (#89)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5855ad16ce67e_26513fb0d914313c8460b1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/bH5b6LVtEreBf93hQyy1vALVCvg>
Cc: Subscribed <subscribed@noreply.github.com>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quicwg/base-drafts <reply+0166e4abcbc2486fb03d4e53f662cb1219b3acd67f5e752c92cf00000001146d6f1692a169ce0bb27100@reply.github.com>
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: Sat, 17 Dec 2016 21:24:42 -0000

#87 covers improving the current use of ALPN and the Alt-Svc v= parameter for HTTP.  However, I think this is something that QUIC needs to solve generically, so forking off a separate issue for that.

Here are the paths I see that we need to support:

- **Client to server, first time:** This is inherently a 1-RTT handshake *if* the client guesses the version correctly; 2 RTTs if it's wrong.  This incents clients to attempt the most widely-deployed version of QUIC rather than their highest version.  Consequently, there needs to be a way for a conservative client to discover that a server supports a more advanced version.
- **Client to server, subsequent:** The cached information should contain information about the server's supported versions so the client can come back with the same version as last time. The scenarios where one side has changed need consideration, though:
    - **Client upgraded:** Would require client to cache server's full set of supported versions and compare against the client's supported set at connect time, not just caching the selected version.
    - **Server upgraded:** The current mechanism offers no way for a client to discover that the server would have accepted a version it didn't initially offer, whether because the server didn't previously support it or the client is being conservative.

Ideally, I'd like to see these solved for QUIC independent of Alt-Svc -- there will be other users besides HTTP.

I think this could be solved by requiring the server to always send its Version Negotiation list in the crypto handshake, not just if a Version Negotiation packet was actually sent.  Clients can discover when the server supports a newer version than they attempted, and either know what to offer next time or actively open a new connection with the new version in parallel.

-- 
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/89

v2.38.3 | Report a Bug | By Email | System Status