[quicwg/base-drafts] Incorrect values for Required Insert Count (#3305)

Martin Thomson <notifications@github.com> Tue, 17 December 2019 09: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 []) by ietfa.amsl.com (Postfix) with ESMTP id E303B120994 for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 01:36:22 -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 kOgyT_PaO2p7 for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 01:36:21 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.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 E63C61200DB for <quic-issues@ietf.org>; Tue, 17 Dec 2019 01:36:20 -0800 (PST)
Received: from github-lowworker-ca5950c.va3-iad.github.net (github-lowworker-ca5950c.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 9A03DC61F90 for <quic-issues@ietf.org>; Tue, 17 Dec 2019 01:36:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576575379; bh=JKCkskiUxUcnXKTM+XuEX106cuyxpcL1HFL5SGxc2dQ=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=glPw3WvqJBPQyBjvv9BQVth/eO88Nj14ZifBhS/HgXf0qywszL1Lq0mrd8lKeGcj8 +YRUG5YBfYnjl6K+D9zbRw0okdWcMxVUraeTpC3ikv4q6qGsfUt+41UOjsM9035AZj u5zTNiPsgxJWJHM7yTrT+cz77nxRFOuCi1nuy61s=
Date: Tue, 17 Dec 2019 01:36:19 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4OOEZJBI5RTJHIVBV4AXKBHEVBNHHCAH5LIA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3305@github.com>
Subject: [quicwg/base-drafts] Incorrect values for Required Insert Count (#3305)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df8a1938b2ef_77793fed684cd96c5141e2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/8iAWraAxiOiaOoeunFmp-aQKoHg>
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: Tue, 17 Dec 2019 09:36:23 -0000

If an encoder produces a Required Insert Count that is invalid, what can a decoder do?

The encoder could provide a value that is too high.  In the case where the value is high, but the number of entries is already acknowledged, this is probably harmless.  However, the decoder might block unnecessarily, if the values were not already present and the encoder references none of those entries or only references lower-indexed entries than it declared.  This is a performance problem up until the point where the encoder hasn't provided the "required" entries and finds no reason to do so, at which point the performance bug could be come a deadlock.

The encoder could provide a value that is too low.  The decoder might then reasonably reject an encoding, but some will not.  If the value is only too low and the entry is present in the dynamic table, some encoders will happily pull the value from the table and use it.  Those decoders will only generate an error if the entry isn't there yet.

I think that it would be better for the protocol if a decoder were able to generate an error if the maximum index referred to in a header block did not exactly match the Required Insert Count.

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