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

Marten Seemann <notifications@github.com> Fri, 10 January 2020 12:26 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 32E3F12006E for <quic-issues@ietfa.amsl.com>; Fri, 10 Jan 2020 04:26:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 11NQ7B6o71dX for <quic-issues@ietfa.amsl.com>; Fri, 10 Jan 2020 04:26:39 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4CF12006F for <quic-issues@ietf.org>; Fri, 10 Jan 2020 04:26:39 -0800 (PST)
Date: Fri, 10 Jan 2020 04:26:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578659198; bh=Lmyor3FTZMaW/bsmNl5fa24m4pN2ErThX1V2HNid7xA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Rif40P/ZzRPsz2kocEeViPCyPGOtYSTwzLzXeb4FqxS6yNQgyO0c0ZJ9stb4pZ/Vv yw00ABwr/VkL5UJD8yQTug3XDisXPuyAuC9U6O5APY+qnADIkBTanrLLcTfqEqLI03 BcILlOFH4Uh+C9MY2HO5iusi5EvGXu/G+NEoNXAc=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZZYBJ2ZNWVTROTBEN4EWP75EVBNHHCBKU5VI@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@github.com>
Subject: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e186d7e45e18_2c053f80b54cd9641244f3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/Bh9N2SDwbUbiF11gGoiY2PumrLY>
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 12:26:42 -0000

@LPardue just raised an interesting point on the mailing list, which is currently not covered in the documents:

> In draft-deconinck-quic-multipath-03 [1] it states that because there are new path-related IDs, some frames need to be modified and then lists them: NEW_CONNECTION_ID, RETIRE_CONNECTION_ID and ACK. IIUC this would keep the type value but modify the frame contents. My model of thinking has been to assume that frame definitions are immutable, and that extensions that require tweaks to frames would define new ones.
> [...]
> So my observation is not about the proposals themselves but about the composability of extensions. Say for example someone wanted to combine mpquic with 1wd, would they modify the ACK frame or define a new one?

I find the composability argument convincing, and was wondering if it makes sense to add something along those lines to the transport document:
> Extensions MUST NOT modify existing frame types.

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