Re: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)

Mike Bishop <notifications@github.com> Fri, 10 January 2020 16:13 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 EB04F120130 for <quic-issues@ietfa.amsl.com>; Fri, 10 Jan 2020 08:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 b19h0jSXsIRO for <quic-issues@ietfa.amsl.com>; Fri, 10 Jan 2020 08:13:06 -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 4733C1200DF for <quic-issues@ietf.org>; Fri, 10 Jan 2020 08:13:06 -0800 (PST)
Date: Fri, 10 Jan 2020 08:13:05 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578672785; bh=nF70bMEYEnLdq9KKcWrU3MqZwUpwcuvjnxiYxEYLE00=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vyWiu0Da+suH3OpKsygJiWPVJ1IW4DGAs05O3qT9+sIUhxUlxBIMvak1Fdp0Oa7VC OEPyKW8wWKg/7BYnThEBROHuRdB4uSJm/HC99szk491GNJQ2fFfr36bsIjjJuKvllp 4/Hl2pFSWxjUnpRYzXnoFNmLqvcJtP4edTwGThqU=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3G3WMX5PORG7NJR7N4EXKRDEVBNHHCBKU5VI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3332/573099706@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3332@github.com>
References: <quicwg/base-drafts/issues/3332@github.com>
Subject: Re: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e18a2915d609_70bf3fbb14ecd95c28826f"; 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/Ubmpano4d-mhNESKg1LSniBYcFU>
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, 10 Jan 2020 16:13:08 -0000

The recipient must be able to identify and parse the frames it receives, obviously.  HTTP/3 already recommends redefining, rather than modifying, frames.  This is because frames can be sent before receiving SETTINGS, and coordinating the point in the connection at which things change is... challenging.

QUIC doesn't have this problem directly, because the negotiation takes place before any frames are sent.  (0-RTT implies support for everything that was supported last time.)  So for single extensions that modify frame definitions, this is fine.

The insight here is that multiple extensions which all redefine the same frame will stomp on each other.  This is potentially true with redefinitions as well.  If extension 1 deprecates A and replaces it with X, but extension 2 deprecates A and replaces it with Y, you're either repeating the information (and effects) of the base frame by sending both X and Y, or you're only supplying information to one of the two extensions each time you would have sent A.

It's probably better that extensions define *separate* frames whenever possible and leave the base ones totally alone, even if that means using some kind of reference to the base frame to correlate them.  I don't know that we can go so far as mandating that, though.  Perhaps simply a caution that extensions which modify the core protocol have the potential to interact poorly with other extensions modifying the same component unless that interaction is defined.

-- 
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/3332#issuecomment-573099706