Re: [quicwg/base-drafts] Default settings in HTTP (#2038)

Mike Bishop <notifications@github.com> Mon, 26 November 2018 19:33 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 937C2130E03 for <quic-issues@ietfa.amsl.com>; Mon, 26 Nov 2018 11:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 32BiscqINKKZ for <quic-issues@ietfa.amsl.com>; Mon, 26 Nov 2018 11:33:34 -0800 (PST)
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 63599130DE0 for <quic-issues@ietf.org>; Mon, 26 Nov 2018 11:33:34 -0800 (PST)
Date: Mon, 26 Nov 2018 11:33:33 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543260813; bh=hMXfoy79xhUq/eafFqc9DCADaNyCDsyNBOHXAjg+hus=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QEMiTrCHFL/IhbRy8CnHTfkRARZvn4bDW7tZ9QWwcnOce1F9I1mNSx4M3EpSOWjMh DhYd4+8QpWI6UbQIXRKsDQLXpWUf8qJh/70UmM5SAhhocdT4dsCTiuZJD+si7P+iGz bTyGp7vIHID1gGTFIF2k89Nez89ZOdy4xillhiOc=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abf64f746f92958ed6c73e143df94bcf690cd2ee7492cf0000000118140c8d92a169ce16d8e664@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2038/c441767889@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2038@github.com>
References: <quicwg/base-drafts/pull/2038@github.com>
Subject: Re: [quicwg/base-drafts] Default settings in HTTP (#2038)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bfc4a8d5ed73_72b63fb0770d45b441959c"; 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/5pv1vs0yq6kk8MZNFS_u4DLbjPI>
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: Mon, 26 Nov 2018 19:33:36 -0000

@LPardue, I think the key point here is in the text added to the extensions section:  "SETTINGS does not provide a mechanism to identify when the choice takes effect."

There are really three types of extensions:
- **Advisory, purely-optional frames / streams:**  Send speculatively; if the peer doesn't understand, they'll ignore them.  Once you see SETTINGS, if it's not supported, you can stop sending to save bytes.
- **Non-optional semantic-changing frames / streams:**  Send only once you've seen SETTINGS, but okay to use as soon as you see SETTINGS -- you know the peer will handle them on receipt.  Need to be willing to handle "surprise" arrival of these frames / streams before SETTINGS, unless they're frames on control streams.
- **Breaking changes to interpretation of existing frames/streams:**  Here's the sticky one.  There's no coordination point to know when the change to existing elements takes effect, so the peer could interpret what you send under the old or new scheme unless the extension itself provides a way to identify this.

I think this really only harms the last category, and the easiest solution seems to be jumping into the previous category for most extensions I can envision.  For example, redefining DATA to be a reference to a unidirectional stream instead of carrying payload would fall in the third bucket and be hard.  But if you instead defined a new EXTERNAL_DATA frame, you've moved into the second bucket.

-- 
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/2038#issuecomment-441767889