IETF Logo Mail Archive

Re: [quicwg/base-drafts] Robert Wilton's QPACK Comment 4 (#4803)

Lucas Pardue <notifications@github.com> Thu, 21 January 2021 22:08 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 4F7FC3A09BE for <quic-issues@ietfa.amsl.com>; Thu, 21 Jan 2021 14:08:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.804
X-Spam-Level:
X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huM0t6yZQ7rM for <quic-issues@ietfa.amsl.com>; Thu, 21 Jan 2021 14:08:25 -0800 (PST)
Received: from smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114143A09C0 for <quic-issues@ietf.org>; Thu, 21 Jan 2021 14:08:25 -0800 (PST)
Received: from github.com (hubbernetes-node-94792f7.va3-iad.github.net [10.48.19.40]) by smtp.github.com (Postfix) with ESMTPA id 53875340EAF for <quic-issues@ietf.org>; Thu, 21 Jan 2021 14:08:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1611266904; bh=6wfzmuf9uCd7E8uIYtBPHVwWdGABj5Dfc62cZeZvrVQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wMGPGjuYc2BuX9SxUZRfBCCPR8f3p7BoEbOZ2erza0p/U0KvMlNVFAstvy3NrFR9g yYPSYpybtLQGMbXZmRANEgE0wVWd9CIfy/fclGqvY7CgjaLRwQrvChTCNnZKt+51YD mY+81zybvIN7INhtrt/CRXNR2AvsHjTiL/TRHV5M=
Date: Thu, 21 Jan 2021 14:08:24 -0800
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4V45IMY6ZHF7OPHBF6CXOFREVBNHHC6KAERQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4803/764972417@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4803@github.com>
References: <quicwg/base-drafts/issues/4803@github.com>
Subject: Re: [quicwg/base-drafts] Robert Wilton's QPACK Comment 4 (#4803)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_6009fb584fd6a_4c1a04112314"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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/4LAeVdgvR7UjSdlkuWQrpEQ9kwk>
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: Thu, 21 Jan 2021 22:08:26 -0000

Its a fair observation. There's been some ideas floating around. But as Martin says, there's tradeoff. The scheme, via the dynamic table, is flexible enough to support evolving HTTP trends without standards coordination effort. The static table has been optimised for a client first flight request,  and I dare say that many of those characteristics won't vary so much for the primary HTTP use case of browsing. Evolving or alternate tables might help, but the latency cost to negotiate them makes the net result similar to dynamic compression. I'm happy that our extension or evolving mechanisms are sufficient for the current understood needs.

-- 
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/4803#issuecomment-764972417

v2.23.0 | Report a Bug | By Email