Re: QPACK proposal: wrap absolute index values

Martin Thomson <martin.thomson@gmail.com> Mon, 06 August 2018 06:52 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D411292AD for <quic@ietfa.amsl.com>; Sun, 5 Aug 2018 23:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hqQnsL77C8JG for <quic@ietfa.amsl.com>; Sun, 5 Aug 2018 23:52:45 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB020128CE4 for <quic@ietf.org>; Sun, 5 Aug 2018 23:52:45 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id s198-v6so20269936oih.11 for <quic@ietf.org>; Sun, 05 Aug 2018 23:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9BcELXssg94K8jaEqlP7wYkdIrK9FbVv/d0G7Nx/SjQ=; b=pl4XHB9tKGow+nALvp8HN+t1eekxVJWFwLljmdZ244p5HNO3it5+5GfFN+AGY4Em7U zrw443ZPBNJGG73IjufJwHWcDsAxmoiLEvVU8ixUZ1e0FpUmXfBoSNQc7AnNMRGev33l 3STFJpKxpFvDf4FpyksJYVrqQ2mQF5GN2pnQGdTQCqs6XiO7wHIPGAK4P/RsMo0ATNob nliS9iqYimYnI/t4CZl7VOMxMfVXV52eUa/KaeAei0jD3xFeWRTb9PiaLvaGPAB53Cry txOWDXI/ReNFlyGfbHRIT5Kmv3PSwN972aXrt7FfgRiYEmeM3sY5K92i6psEvUZm33vh 2Ziw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9BcELXssg94K8jaEqlP7wYkdIrK9FbVv/d0G7Nx/SjQ=; b=DLQNwP/ITB632ZY5GFybHF8BUmt07vD8ab5i2XHfxaSsthpKWnv1DYUgx5kPtOUpKU hXWfr7Io2EJW5GUOBeqsUUmemaFKTzxlJdgLh9DmE0hZkOgjTbfEydwm1fUKyuwBYlpj fvjS+Txz5B3vPnB4y8vkQ03F1YkWsKlTxjiOrCzO1zqD3cjbzewNQSPEW283jOtjUIA7 4AmNRb/kM8tVwVj7+W7xVgCFjnufWVPitlrE2pTELFODU+cAaKJPFnfhkyH+MmSQKa7G 7N+3GnPqKaH6s55kmRPMwtGf+a1xDBVBzVjBCTiS8Gk6aDsOefzE86qowwr0Uh6czyKO dkyw==
X-Gm-Message-State: AOUpUlEirzUmaxVFiqbIX18EiEwDFRlByAnGoDrihg8VegophlGFLuMN O7BLYdtFCn5vvFNXrC1QNBrLB5xS7ZaqOfGplpiLnsot
X-Google-Smtp-Source: AAOMgpcU3U5MTPvw/TXU9tzLJ/ZnBONdcemaoVMUSkie5Mz5jUW6RICroWgiHl2ZcRDk/DI1f2mcH5WhHxgXkwJtTE8=
X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr12266136oib.254.1533538364663; Sun, 05 Aug 2018 23:52:44 -0700 (PDT)
MIME-Version: 1.0
References: <20180805154649.GA14245@ubuntu-dmitri> <CABkgnnV2Ugu6O_6Q8grjhQiqavUe6P8FVP_BNRuNqtzVXTbOgw@mail.gmail.com> <20180806043610.GC25402@ubuntu-dmitri> <20180806044626.GD25402@ubuntu-dmitri>
In-Reply-To: <20180806044626.GD25402@ubuntu-dmitri>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 6 Aug 2018 16:52:34 +1000
Message-ID: <CABkgnnWA8ZzrKzjZ-hQ1Qk3yOtgtcmwNuFwkJEP3DnqqqnCkBA@mail.gmail.com>
Subject: Re: QPACK proposal: wrap absolute index values
To: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/XYF9b0D0LUGVoRLXoI4famAywLA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 06:52:47 -0000

On Mon, Aug 6, 2018 at 2:46 PM Dmitri Tikhonov
<dtikhonov@litespeedtech.com> wrote:
>       bool
>       isHeaderBlocked (unsigned LargestRef)

Thanks for sharing code.  Note that I'm not just interested in whether
I'm blocked, but for how many table updates I should block for, but I
can use this function (repeatedly if necessary) to make that
determination, I guess.

It took me ages to understand this code.  Are you expecting all the
arithmetic for CurMax to be modulo MaxEntries*2 ?  Because if that is
the case, then this makes sense.  Without that stipulation, I really
struggled.

We should examine the assertion here then.  That is, you make two
claims: one true, and one maybe-true:

1. You can't receive a header block with a largest reference that is
more than MaxEntries old from the current state.  This holds trivially
because that would mean that the entire header table was evicted.  We
don't allow entries to be referenced after eviction and there is no
way to reach this state without evicting the largest reference.

2. You can't receive a header block with a largest reference that is
more than MaxEntries new.  This doesn't hold because we don't cap the
amount that a header block can be blocked by.  Now, it's arguably a
reasonable restriction, because it takes multiple round trips to reach
a state where that header block can be used, but we don't currently
prevent someone from doing something like that.

Now, it's reasonable to assume that you can't have more than
MaxEntries worth of updates in flight, which means that in one round
trip, this will never happen.  But we don't say that you can't
reference dynamic table entries that are far in the future.  For this
to work, we would have to prohibit that.  Maybe we should, because
referencing entries that can't be sent is a footgun, just as
referencing entries that have not yet been sent is a footgun (it can
deadlock flow control if you do that).