Re: [quicwg/base-drafts] Do we need two ways to represent Base Index? (#2002)

Kazuho Oku <notifications@github.com> Wed, 14 November 2018 12:21 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 2735B1292F1 for <quic-issues@ietfa.amsl.com>; Wed, 14 Nov 2018 04:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.469
X-Spam-Level:
X-Spam-Status: No, score=-8.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDttBuR2nT76 for <quic-issues@ietfa.amsl.com>; Wed, 14 Nov 2018 04:21:09 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5745126F72 for <quic-issues@ietf.org>; Wed, 14 Nov 2018 04:21:08 -0800 (PST)
Date: Wed, 14 Nov 2018 04:21:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542198067; bh=cHQ02k7v7SlZ6mlkeZlkLFoTEtUzJ4QCPECNejzknI0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=05zYG8ofdUwpalmhCneinpymyyW0oicqYuWnTgElzGxzvH0TuodvdeIgdlFMJXcb0 t3Lm1DE/JK1BrrGYiMwTaNaxNgq8u8Qr3f6b+ZY8dl/RcryR/2DmTXXsW5MYos7zvw Kh11WTrOOxuNv5tKoUNrOYb6WCWU+x6J0VAgiMNg=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abcb1bbce3ae6d28b22a56eb38469f93ac7fa38e9992cf000000011803d53392a169ce16afb802@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2002/438643525@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2002@github.com>
References: <quicwg/base-drafts/issues/2002@github.com>
Subject: Re: [quicwg/base-drafts] Do we need two ways to represent Base Index? (#2002)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bec13334ab75_6bd33fe7c08d45b812878"; 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/VXyZty_qadKEibhoU7rUc2rLc7s>
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, 14 Nov 2018 12:21:11 -0000

@martinthomson 
> Hmm, diagrams suggest that we already have the latter form. My code might not be interoperable, but it subtracts the extra 1 already.

The ones with the diagram; i.e. Post Base Index that appears in the request and push streams is OK.

However, the Delta Base Index calculated in [section 5.4.1](https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#rfc.section.5.4.1) is missing the "subtract the extra 1." That is what I am complaining.

> Oh, have I mentioned recently that I hate post-base indexing? Could we perhaps reconsider its addition and have any single-pass encoder lose any opportunity to use insertions it makes after committing to a largest reference? Maybe I should open another issue.

I think it might be sensible to open a new issue for the purpose.

Even though I have an implementation that emits post-base indexing (for the time being), I agree that it  is an unnecessary complexity at least in the current form. Because in the current form, even if you emit the headers in single pass, you still need to adjust the Header Data Prefix afterwards so that Largest Reference will include the correct value. To put it another way, it is impossible to write a "streaming encoder."

Therefore, my preference goes to either removing post-base indexing, or to removing "Largest Reference" to allow true one-pass encoding (i.e. streaming encoding). In the latter case, every decoder can / will check if an unresolvable reference is included in each of the header field rather than relying on "Largest Reference."

-- 
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/2002#issuecomment-438643525