Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)

Kazuho Oku <notifications@github.com> Wed, 11 December 2019 21:55 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 086D112004C for <quic-issues@ietfa.amsl.com>; Wed, 11 Dec 2019 13:55:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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: 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 BCE9R_jYuSzV for <quic-issues@ietfa.amsl.com>; Wed, 11 Dec 2019 13:55:00 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C950B120025 for <quic-issues@ietf.org>; Wed, 11 Dec 2019 13:55:00 -0800 (PST)
Date: Wed, 11 Dec 2019 13:55:00 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576101300; bh=0SNLU67D9b+NQZtKND4mM7gTbVUnNnM8R+32Zin4SmI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NIEIMXAPQBxkFODXLT8pY3u4+/9KmnycUMbJbbCDpUqwMWyIMwYmtUOWP/DnPBKkE Sq0VV0PTlt1F9u2awvwenm3KhjenbKib3OpBpSrFoL4qhXAQdlipIoT6Dk6Pvg4wkM 8igAT3luh7AIPSyMsIl6f/6L7CP0diqJn8duiR0o=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3A6EHVXYVMLDEFHWF372MDJEVBNHHB72WFIM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3294/564750434@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3294@github.com>
References: <quicwg/base-drafts/issues/3294@github.com>
Subject: Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df165b4f30c_2ed3fca0e6cd9601212c5"; 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/NnAvCdTAo4WyokF4yCTiSaBFIys>
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: Wed, 11 Dec 2019 21:55:03 -0000

@MikeBishop 
> Fundamentally, this seems to be a case of design reflecting a coding pattern. If your pattern is that the QUIC layer generates a binary structure, hands the opaque blob to TLS and says "this is the payload of extension foo," then it makes total sense to varint everything, because it's part of QUIC.
> 
> If your coding pattern is that the transport parameters are a known structure and TLS is handed a key-value store that it knows how to serialize, then it makes total sense to TLSPL everything, because it's part of TLS.

I think that this is a good summary of the trade-off that we have here.

FWIW, the latter approach (using a helper provided by TLS) can use something other than a key-value store.

As an example, picotls does not provide an API for encoding / decoding extensions, but provides a closure-based API<sup>1</sup> for encoding decoding TLS blocks instead, which is used by quicly. The code that encodes TP is at [quicly.c line 1389-1435](https://github.com/h2o/quicly/blob/0b0ba909eb502ae9db300f75819e3d207ba503c8/lib/quicly.c#L1389-L1435), the code that decodes TPs is at [line 1459-1546](https://github.com/h2o/quicly/blob/0b0ba909eb502ae9db300f75819e3d207ba503c8/lib/quicly.c#L1459-L1546). Because the encoding / decoding process are defined as callbacks of the TLS stack, they directly read from / append to the buffer built by the TLS stack.

As stated in [my previous comment](https://github.com/quicwg/base-drafts/issues/3294#issuecomment-564442061), encoding / decoding TPs is a complicated task that happens as part of the TLS handshake message processing, it would be helpful to allow these kinds of code reuse.

If we are to switch to varints for both TP ID and length, there would be much much less chance of such code reuse, because the structures of the TLV encoding would depend on the varint encoding of QUIC. In case of quicly, we would be copy-pasting the helper functions provided by picotls, changing the code that handles uint16 to varints.

That's certainly possible, but the additional complexity is far more than the cost of using uint16 instead of varints here.

1: With the caveat that something that looks like a closure (or a block of code) is actually a macro in case of C though :-)

-- 
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/3294#issuecomment-564750434