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

ekr <> Sat, 11 January 2020 00:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EB4C120120 for <>; Fri, 10 Jan 2020 16:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DSQngAjYKjpH for <>; Fri, 10 Jan 2020 16:19:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D434120047 for <>; Fri, 10 Jan 2020 16:19:24 -0800 (PST)
Date: Fri, 10 Jan 2020 16:19:23 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578701963; bh=vub0hq16YfhTRUrtlAURkMpDhswNAqkESuqm1ig6aMs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UQL+PeNLIGKY+fYcpMhulH3zNpDwiYWpgeWEV3E0YmZf/CVGWxvfz9ZsLooJghoHs ZwilTeHyndoUAO6NAWSqZY1tw7B0UYQDg8/7h+bBXtLJvtbEdJEyYUbaomWOEYt/Co pGpK2zyGr5KQpGtZKuLS3DZBSQ2nXNvj+ZfAULao=
From: ekr <>
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_5e19148b53f43_6ebd3fd25cacd96033786"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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: Sat, 11 Jan 2020 00:19:26 -0000

On Fri, Jan 10, 2020 at 3:13 PM David Schinazi <>

> 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.
I agree with David. If you have extensions which are non-orthogonal, having
the wire encoding be separate isn't going to help that much.

I propose we just don't have this requirement and the first time it comes
up, we figure it out then.


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