[quicwg/base-drafts] Insert Count Increment instruction description has race condition (#3082)

Bence Béky <notifications@github.com> Tue, 08 October 2019 13:38 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 D563E12004E for <quic-issues@ietfa.amsl.com>; Tue, 8 Oct 2019 06:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Status: No, score=-7.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SRJHME5EqBFl for <quic-issues@ietfa.amsl.com>; Tue, 8 Oct 2019 06:38:41 -0700 (PDT)
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 E7586120018 for <quic-issues@ietf.org>; Tue, 8 Oct 2019 06:38:40 -0700 (PDT)
Date: Tue, 08 Oct 2019 06:38:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1570541920; bh=8del2v1k69eBtYiFLPA0v2QMrnLVA4I6RlrWhi6TF0M=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=bcKseuQ4j65yTw20pi/FQGfd25aVbnQ5X6qu8EMAjU7zhzNYJ3tz4qUkr+i692WNG bEivfMBbH+836NO49XhzooRgdDl3I+Kd5Go80+Qd462psn6iZ2WhxqSjeB9ChkRHEX t9PakuR8OZ4iwZT1ZxbCHnn2HFSpIwL8a/UZph8M=
From: Bence Béky <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4KYZ2GS2W5NZD75R53VHI7BEVBNHHB4CZRUQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3082@github.com>
Subject: [quicwg/base-drafts] Insert Count Increment instruction description has race condition (#3082)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d9c91601d002_7b9f3ff95c0cd95c143067"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: bencebeky
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/5VFjHLY_gK7oDFZIgXeAWsVgXU4>
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, 08 Oct 2019 13:38:43 -0000

Assume a decoder receives the following data:

A: the first dynamic table insertion,
B: the second dynamic table insertion,
C: the third dynamic table insertion,
X: a header block with required insert count of one.

A, B, and C are guaranteed to be received in this order, because they are all on
the encoder stream.  X arrives on a request stream, so its order relative to the
insertions is not guaranteed.

Consider the orders A, B, X, C, and A, X, B, C.  Suppose the decoder sends a
Header Acknowledgement of the header block as soon as it is received (all
necessary entries are available by that time).  This Header Acknowledgement
instruction increases the encoder's Known Received Count by one.  Suppose that
after receiving C, the decoder decides to send an Insert Count Increment

According to
"The value of the Increment is the total number of dynamic table insertions and
duplications processed by the decoder since the last time it sent a Header
Acknowledgement instruction that increased the Known Received Count (see Section
2.1.4) or an Insert Count Increment instruction."

In the first case, one insertion (C) was processed since the last Header
Acknowledgment instruction that increased the Known Received Count was sent.  In
the second case, two insertions (B and C).

I'm ready to address this issue with a PR but waiting for review of issue 2942 which would conflict.

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