Re: [quicwg/base-drafts] Add application parameters to QUIC handshake and use it for H3 SETTINGS (#3086)

Nick Harper <notifications@github.com> Fri, 11 October 2019 20:42 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 25CBF12010D for <quic-issues@ietfa.amsl.com>; Fri, 11 Oct 2019 13:42:23 -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 XRl56YUITXbQ for <quic-issues@ietfa.amsl.com>; Fri, 11 Oct 2019 13:42:21 -0700 (PDT)
Received: from out-14.smtp.github.com (out-14.smtp.github.com [192.30.254.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DDB1200DF for <quic-issues@ietf.org>; Fri, 11 Oct 2019 13:42:21 -0700 (PDT)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id AC7B5120B33 for <quic-issues@ietf.org>; Fri, 11 Oct 2019 13:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1570826540; bh=newfHpB0vZBCrBWSxi4+xhp/Oe7BN6vbQTzRMW52oKE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2IYQl5dMUFE9JHQP7Yhe61jad/hfv7M3FKgJFFSWLYdz4wvEG+/zuaa1bBKLOWIkc 13TKit++Bil2R7Jgu8CMUpvgHKjdAXzF90GpSnnEQZWD8jgthRz8GyE0CQTQw/oDW5 U0X+Up7xCbEEZbpZEfTGhn7xQ5Vuq6jpgrphM0RM=
Date: Fri, 11 Oct 2019 13:42:20 -0700
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6OJJFFNDTMCYCYTZV3VYU3ZEVBNHHB4IOF7M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3086/541216958@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3086@github.com>
References: <quicwg/base-drafts/issues/3086@github.com>
Subject: Re: [quicwg/base-drafts] Add application parameters to QUIC handshake and use it for H3 SETTINGS (#3086)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5da0e92c682e6_7c6b3fbbc06cd96c602d3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
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/WZi04W7xvXALOAsvUBMQPfAajuU>
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, 11 Oct 2019 20:42:23 -0000

I disagree that moving this from H3 to the transport makes the transport more complicated than it simplifies H3.

The additional complexity to the transport is setting on the client a map of ALPN identifiers to application layer blobs of data (opaque to the transport), on the server setting a blob of data based on the ALPN, and getting the params sent by the peer.

Making this change to H3 means we remove the complexity of migrating from the default SETTINGS for a connection to the SETTINGS received some time later. It also reduces the complexity of binding SETTINGS to the NST for 0-RTT: on the server the SETTINGS is now in TP which already needs to be remembered, and the client now doesn't need to wait for SETTINGS to arrive after a NST to store them. It also removes the edge case where a client might do 0-RTT resumption without any remembered SETTINGS. This also removes the need for an H3 client to decide whether to send a request under default SETTINGS or wait for SETTINGS to arrive from the server.

I also disagree that this change introduces new meaningful complexity to generating the server's transport parameters message. The server needs to read the client's ALPN list and choose one that the server is configured for (this isn't new), and now it needs to when choosing the ALPN also choose the appropriate application parameters to go with that ALPN. For H3, the server will need those SETTINGS shortly after in the handshake when sending a NST so it can bind the SETTINGS to the NST. Likely the SETTINGS are constant, so it can be configured before accepting the connection with what the SETTINGS are and do a lookup to get those SETTINGS when sending ALPN.

-- 
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/3086#issuecomment-541216958