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

David Schinazi <> Fri, 10 January 2020 23:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4942312008C for <>; Fri, 10 Jan 2020 15:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_28=1.404, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Wwl1zTJAktl for <>; Fri, 10 Jan 2020 15:13:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CAFF2120047 for <>; Fri, 10 Jan 2020 15:13:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8CBBB2C33CD for <>; Fri, 10 Jan 2020 15:13:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578698017; bh=ajlnbufOo6kvHNLmF7v0r6iHKxtlz22q3r3cmpDdXl0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Z07mMTHqJo8r81ZXNubEkU3iRgnVckOeXSFHQEJzNC8XpvNNT8supdY/4G5sNSvX7 qqhB73jm7S6iopBBr0jsYiUzXbVkv2k4ap4LiFs1RKhch8q8yTK0olpfjHqR+1MlHs MBrGza3Q1Zi/AtmBc4C/4cR0JILNUuWr2RpUS/KI=
Date: Fri, 10 Jan 2020 15:13:37 -0800
From: David Schinazi <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3332/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1905217de13_11613ffc2a2cd95c433275"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jan 2020 23:13:41 -0000

I really don't think we should ban extensions from modifying core frames. I think this restricts our extensibility without providing any benefits that I can see.

The original example is a good one: if extension A wants to modify ACK frames to add field ACK_FIELD_A at the end of the ACK frame and extension B does the same with the ACK_FIELD_B field, then we have a problem when both extensions are in use: we don't know how to parse ACK frames (is ACK_FIELD_B before or after ACK_FIELD_A?).

However, saying that extensions should have their own separate frame types does not solve this problem. If extension A defines custom frame type ACK_A which contains a regular ACK plus ACK_FIELD_A, and B does the same with ACK_B, we end up having to send double the ACK data to get ACK_FIELD_A and ACK_FIELD_B across, and in my opinion that's a deal-breaker.

Therefore we'll need to define how to compose extensions A and B, no matter what. Banning changes to existing core frames didn't solve this problem.

If and when we do end up having this problem, we can deal with it then.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: