IETF Logo Mail Archive

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

Kazuho Oku <notifications@github.com> Wed, 11 December 2019 04:36 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 29A7F120219 for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 20:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.979
X-Spam-Level:
X-Spam-Status: No, score=-7.979 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] 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 jEE7DMlHSz7l for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 20:36:33 -0800 (PST)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873E3120115 for <quic-issues@ietf.org>; Tue, 10 Dec 2019 20:36:33 -0800 (PST)
Received: from github-lowworker-f62aa54.va3-iad.github.net (github-lowworker-f62aa54.va3-iad.github.net [10.48.17.68]) by smtp.github.com (Postfix) with ESMTP id A47B3520A3F for <quic-issues@ietf.org>; Tue, 10 Dec 2019 20:36:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576038992; bh=dWQVyfbYwABpQxmEu1cAoDZn4p+Rp0PYq7OAuxrMUds=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=K2RVxCKnMa6JWSpLh5PUBis/VEgnYoejz68kggmcBvSaYf1tn+qA8LXyPnfzfUrs4 oWPsjXhKdKLHT0uGreqIhP6t2fs0WfoX/nkzygoa57HaOQx0f8A/Y7ye4+agqCGoRO q036waB2V5eEoiR8y1U0uTDx7FOc3whxS0tG99mo=
Date: Tue, 10 Dec 2019 20:36:32 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZBAMKLOL7TNK5HD7F37WSNBEVBNHHB72WFIM@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/564375959@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_5df072509517a_6a703fb8178cd96c20851"; 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/PpFHN7yncs0s4mWjIJkjsAODFp8>
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 04:36:35 -0000

I also think that we do not need more than 2^16 space for Transport Parameters.

In addition to what we know from how TCP options are being used (as @janaiyengar points out), I would also point out that every TP consumes space in the handshake packets that the endpoints exchange. To paraphrase, there is an incentive to keep the number of TPs being used small. I do not think we'd ever see endpoints sending thousands of TPs.

Assuming that is the case, there is no practical reason to switch to varints. As I have pointed out in #3020, some of us have been reusing a encoder / decoder designed for TLS, switching to a varint-based design would require those to write a new codec specifically for QUIC. That's just a burden.

I think we should concentrate on fixing real issues rather than requiring everybody to make an unneeded change. 

-- 
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-564375959

v2.23.0 | Report a Bug | By Email