Re: [quicwg/base-drafts] Robert Wilton's QPACK Comment 3 (#4802)

Robert Wilton <notifications@github.com> Wed, 27 January 2021 10:04 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 583493A0D01 for <quic-issues@ietfa.amsl.com>; Wed, 27 Jan 2021 02:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.804
X-Spam-Level:
X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 2V-fImMc5IAd for <quic-issues@ietfa.amsl.com>; Wed, 27 Jan 2021 02:04:52 -0800 (PST)
Received: from out-27.smtp.github.com (out-27.smtp.github.com [192.30.252.210]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F763A0CB1 for <quic-issues@ietf.org>; Wed, 27 Jan 2021 02:04:51 -0800 (PST)
Received: from github.com (hubbernetes-node-818a524.ash1-iad.github.net [10.56.113.62]) by smtp.github.com (Postfix) with ESMTPA id 41AF39025F0 for <quic-issues@ietf.org>; Wed, 27 Jan 2021 02:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1611741891; bh=2B6DIh1IMi4rSQ2ex+VhJX9Iznbf9KQ/PMTzl38jb2w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ubgmbf3EpUmottgImrAgu9r33brBv5UXx9T14PiUkfkwI65KIK4u9T/TcT7MQyjic BX9ia5JXFqvZ0CQln8xqJ9+mgt6MxDlBGyTbPFoTtkO3Aqyer4gj2Oah4RO+kdXW4j xtjglcwq/svrhwq66yQxaXtuBnka8rLKOh0glLW0=
Date: Wed, 27 Jan 2021 02:04:51 -0800
From: Robert Wilton <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3BCBA2HKBVZWX6CTF6DUN4HEVBNHHC6KACPU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4802/768175712@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4802@github.com>
References: <quicwg/base-drafts/issues/4802@github.com>
Subject: Re: [quicwg/base-drafts] Robert Wilton's QPACK Comment 3 (#4802)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_60113ac33ebd3_551a041347f4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: rgwilton
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/ouSsloxsHTwmw9Sf3OfaiNF1iME>
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, 27 Jan 2021 10:04:59 -0000

I don't think that using arbitrarily sized integer libraries is the answer here due to the performance overheads of such libraries.

My concerns are two fold:

(1) It is unclear what arbitrary limit receivers should apply.  E.g., is 255 bytes enough for a string?  Is a 64 bit signed integer enough for an integer?

(2) Senders probably won't really know that the reason the stream has failed is because they are hitting some arbitrary limit in the receiver, and even if they did then I'm not sure there is anything that they can do about it.

Hence, another suggestion is to specifying minimum expected bounds for these values?  Or if these bounds are effectively provided by the HTTP spec, perhaps the appropriate section in that spec. could be referenced.



-- 
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/4802#issuecomment-768175712