Re: [quicwg/base-drafts] Describe QPACK Feedback mechanisms (#1410)
afrind <notifications@github.com> Fri, 15 June 2018 16:33 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 B8752130E22 for <quic-issues@ietfa.amsl.com>; Fri, 15 Jun 2018 09:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 818jHXKgNcdu for <quic-issues@ietfa.amsl.com>; Fri, 15 Jun 2018 09:33:21 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3D0130F0D for <quic-issues@ietf.org>; Fri, 15 Jun 2018 09:33:21 -0700 (PDT)
Date: Fri, 15 Jun 2018 09:33:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529080400; bh=7gaS/ieZY3vKC7teXv6tL0LAa28QqPXM5Zk2xMDVJH0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iiNkmJQ3Jn4ZJO/YY/hC5zxs/i7Vy7c2Ov6IC1w4AAtUyeua9Pr+ubbRUjktbwKeO jG20Uddjo2y1afeoFwjrMT2AuD6Ei1n7yAGNxPHY75v983gyfV+TkHhMusSd59Xr9d rhKwce7rbcZo+YDL3KOzoD1OM6jqP7HXMFtdhI4Q=
From: afrind <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab98693af164ab6be44e1bf82c13dbde0c9a8fa7d692cf00000001173bac5092a169ce139917f8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1410/review/129227518@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1410@github.com>
References: <quicwg/base-drafts/pull/1410@github.com>
Subject: Re: [quicwg/base-drafts] Describe QPACK Feedback mechanisms (#1410)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b23ea50bf7d4_29be2ab78ded0f5c33041c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: afrind
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/TSnzFBTFIeIxQ4puOWSvkItn8w0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 15 Jun 2018 16:33:25 -0000
afrind commented on this pull request. > ~~~~~~~~~~ -{:#fig-size-sync title="Table Size Synchronize"} +{:#fig-size-sync title="Table State Synchronize"} + +A decoder SHOULD emit a Table State Synchronize after receiving new dynamic +table entries if the most recently inserted entry was not the Largest Reference Since we are going to remove length prefix, 'entries' here is vague. How many entries? I think in the common case the inserts will get processed before the references, but a blocking decoder would not want to send TSS without delaying to check for a referencing header block, so perhaps the SHOULD here is misleading? Maybe it would help to describe the tradeoff - A decoder chooses when to emit TSS instructions. Emitting a TSS after adding each new dynamic table entry will provide the most timely feedback to the encoder, but could be redundant with other decoder feedback. By delaying a TSS, a decoder might be able to coalesce multiple TSS instructions, or replace them entirely with Header Acknowledgements. However, delaying too long may lead to compression inefficiencies if the encoder waits for an entry to be acknowledged before using it. -- 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/pull/1410#pullrequestreview-129227518
- Re: [quicwg/base-drafts] Describe QPACK Feedback … afrind
- Re: [quicwg/base-drafts] Describe QPACK Feedback … Mike Bishop
- Re: [quicwg/base-drafts] Describe QPACK Feedback … Mike Bishop
- Re: [quicwg/base-drafts] Describe QPACK Feedback … afrind
- Re: [quicwg/base-drafts] Describe QPACK Feedback … Martin Thomson
- Re: [quicwg/base-drafts] Describe QPACK Feedback … Mike Bishop
- Re: [quicwg/base-drafts] Describe QPACK Feedback … Mike Bishop
- [quicwg/base-drafts] Describe QPACK Feedback mech… Mike Bishop
- Re: [quicwg/base-drafts] Describe QPACK Feedback … Mike Bishop
- Re: [quicwg/base-drafts] Describe QPACK Feedback … Mike Bishop
- Re: [quicwg/base-drafts] Describe QPACK Feedback … afrind