Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

Martin Thomson <notifications@github.com> Fri, 02 August 2019 02:34 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 BE5A8120089 for <quic-issues@ietfa.amsl.com>; Thu, 1 Aug 2019 19:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_IMAGE_ONLY_24=1.618, 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 2fQYW_b3QNoy for <quic-issues@ietfa.amsl.com>; Thu, 1 Aug 2019 19:34:22 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687F512001A for <quic-issues@ietf.org>; Thu, 1 Aug 2019 19:34:22 -0700 (PDT)
Date: Thu, 01 Aug 2019 19:34:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1564713261; bh=LGtd4KPlmwSSpmgdN8nYj/95+lyoeDxAdYpPmD1E5uY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bfFqGbgRKmuRSb5jNnV1rdbfz319XFc40oHE9ce9FYgeGqSuT7XGfr9OQOjFyA8pa 067Y7MMsFolkeQjKbt7gqyz7sEzg86pEdGc80ynvAZ5aUaV9Z7bnLzIcNlxIlGtGEn wKkDe2Z+XMsZdF59TIhlxFgmeekwAzGQwjFx2Pwk=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYMWDWYDU6LDBT7DYV3KDJ23EVBNHHBYVUFKY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2945/517524656@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2945@github.com>
References: <quicwg/base-drafts/issues/2945@github.com>
Subject: Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d43a12d607d2_30b63fc18eacd96c349767"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/jVrCtFj9dpsTs4OeAXWeU5CdImw>
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, 02 Aug 2019 02:34:24 -0000

The asymmetry continues to bother me.  I don't want these in the clear either.

It seems like moving to transport parameters really only has the effect of forcing head-of-line blocking.  I'm not that enthusiastic about that.

> this means that any application that wants to use QUIC for its transport has to provide some mechanism to convey session tickets 

That's right.  The interaction needs to be there anyway.  The question is more to what extent we try to hide that interaction.  

The ticket elevation was mostly just a request for consideration than it was any serious suggestion.  Though it does neatly address the problem of which protocols get to use 0-RTT - because only those that bother to design a mechanism get to use it.  That's a neat property.

-- 
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/2945#issuecomment-517524656