Re: [quicwg/base-drafts] Make HTTP frames a TLV format. This has several advantages: (#2235)

Kazuho Oku <notifications@github.com> Sun, 23 December 2018 02:44 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 1D4E0130E6A for <quic-issues@ietfa.amsl.com>; Sat, 22 Dec 2018 18:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 E0N1mVpfvGSn for <quic-issues@ietfa.amsl.com>; Sat, 22 Dec 2018 18:44:22 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A713130E1D for <quic-issues@ietf.org>; Sat, 22 Dec 2018 18:44:22 -0800 (PST)
Date: Sat, 22 Dec 2018 18:44:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545533061; bh=TaZYdgj4k6qbDA6JlLBVt4rrsI/FQIewdcP4/EI+zq8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AZ4j8v8nliMGMNzaYJ6W1os33CfZhXY6nV5gS99hxO5yhDrl/0PNTxbIOTPh3ENGI FaktUUk0qhwpByMoA38cSRVF50ucbkxFQXljH7M1HOTpYyVfT8enUaBQhWg1jkeBoi KOC2Y8VTEaF77Xf1LShxNjWGR53ytEIStiGf1YDQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab3cca87091067f46e7367259f608714ef823f8d0e92cf000000011836b88592a169ce17707fcb@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2235/c449610469@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2235@github.com>
References: <quicwg/base-drafts/pull/2235@github.com>
Subject: Re: [quicwg/base-drafts] Make HTTP frames a TLV format. This has several advantages: (#2235)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c1ef685680f7_2df53ff1122d45b823854e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/HqhkGKC18siSqQMFz6R0lbtQdzU>
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: Sun, 23 Dec 2018 02:44:24 -0000

I'm fine with moving frame type in front of the length.

OTOH, I am not sure if I prefer using varints for frame types.

IIRC, using varints for frame types of the transport, with the requirement that the minimal-sized encoding MUST be used, was based on the fact that it reserves more code points to future extensions, at the same time not making existing implementations complex. The reason the change did not make existing implementations complex was because new frame types cannot be used without negotiation.

The situation is different in H3.

H3 allows frames to be used without negotiation. In fact, we allow endpoints to grease the codepoints.

That means that every implementation would be required to support frame types using varints, even though in practice only the single-octet versions would be used.

To me that sounds like an unnecessary complexity.

I am also skeptical if we would ever run out of H3 frame types even if they are kept 8 bits, considering how few we have used in H2.

-- 
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/2235#issuecomment-449610469