Re: Questions about QPACK

Bence Béky <bnc@chromium.org> Thu, 21 November 2019 14:57 UTC

Return-Path: <bnc@google.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 B0AFC120878 for <quic@ietfa.amsl.com>; Thu, 21 Nov 2019 06:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.252
X-Spam-Level:
X-Spam-Status: No, score=-9.252 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 22WCtWk9zh0u for <quic@ietfa.amsl.com>; Thu, 21 Nov 2019 06:57:37 -0800 (PST)
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 A69AB120843 for <quic@ietf.org>; Thu, 21 Nov 2019 06:57:37 -0800 (PST)
Received: by mail-vk1-xa2f.google.com with SMTP id p78so800141vkp.8 for <quic@ietf.org>; Thu, 21 Nov 2019 06:57:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C7VoYYUgZ8J8aK84Yyl1lrq95gKKt+3DA6MnPAnmOKc=; b=oFcBd6DuNlnRH6H23OtYM3Wsvvdd/O4KQnlP/wAYrW8EiHkUcnOehyylaZQOzHuzoW B7oINdUVDnGE+TDFDbKUYqKJ//Aj6nnWO9EsVSTQ9VgckNUEOHaOGrRhaL9Yu4+TlchT vXkDws0qXAgGTwjFucqfs2Z6PRSpUwnZeK7dg=
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:cc; bh=C7VoYYUgZ8J8aK84Yyl1lrq95gKKt+3DA6MnPAnmOKc=; b=tqgNbKg5tGCywne7ujs3ol5+s9ZDJx0/Dp6WhlgaSktzq3MZTAD1xDacRPNAoG5Mp9 AaZhO4QM5reyvajKvqE0kYE1SQ83bYVdiVVdazvTP7n13lHmAsvwmC3ltoFBPGEOsJGG sA84Pm9qrF0cwZwTGpPlSj/8CcIptVbOVwzh5JNCB6vw8J5vevS6PaTruD1DRz3tct8K FcQUOjkxvsloWpPvCXZ7WsNogBVeb8eJdOXJ8fLOZ8ZBpdAZIiz1ub+i86iq4WDmb6TE 1+lHs76pfUs9DhkVXocg4K3i4pIhuLscWDBOFvfcnalOLU0mZvww835NnT2mziUpw4Ph Yl1g==
X-Gm-Message-State: APjAAAWOz7AyAapLcP2vH5nuqqx9Oze0hIwA0igQnler1JT5eCqvar7U gRv6WDymhDlI972tiPy1WBLVyMjV+dR327HlYGfilQ==
X-Google-Smtp-Source: APXvYqygxbV8ExSrLB2xfjmUI7/WdWyao9nkHof9haVh/MBgxGp9fYxUu9nkl5bOrm5OkDHVwb6CmHBdQZJapGnB8bk=
X-Received: by 2002:a1f:5106:: with SMTP id f6mr5832286vkb.88.1574348255882; Thu, 21 Nov 2019 06:57:35 -0800 (PST)
MIME-Version: 1.0
References: <CAG9+TpYtZniZ63xc3Wpb7NNpkVyj1G9_p-rtCjspdCr+oz8edg@mail.gmail.com>
In-Reply-To: <CAG9+TpYtZniZ63xc3Wpb7NNpkVyj1G9_p-rtCjspdCr+oz8edg@mail.gmail.com>
From: Bence Béky <bnc@chromium.org>
Date: Thu, 21 Nov 2019 09:57:24 -0500
Message-ID: <CACMu3tq6q+UDyyUqQHC_VK0gxGSnBj_=1DsnmRMHPChgawL0tw@mail.gmail.com>
Subject: Re: Questions about QPACK
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: quic@ietf.org, 78690842@qq.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ubx7IMbwIESy0YgxNGNlGwEauzU>
X-Mailman-Approved-At: Thu, 21 Nov 2019 07:25:44 -0800
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 21 Nov 2019 14:57:39 -0000

Hi,

Great questions.

>
> Q1:why we send N bit to peer? it seems we don't need to send the bit, if sender don't want to put in dynamic table.
>

QPACK is hop-to-hop, that is, client to intermediary, intermediary to
intermediary, intermediary to server, all separately (and the other
way around).  Intermediary can be locally installed
firewall/antivirus, proxy, reverse proxy, load balancer etc.
Intermediaries are allowed to recompress headers using different
algorithms using QPACK, or they might relay to an HTTP/2 connection
using HPACK, etc.  The N bit is to inform intermediaries whether the
original sender of the headers deems that the header MUST always be
encoded using literals.

>
> Q2:when we encode new name, new value, we should insert name,value pair into dynamic table, should we insert name only into dynamic table?
>

Header block representations do not mutate the dynamic table: they do
not insert or duplicate or evict entries or change dynamic table
capacity.  Mutating of the dynamic table only happens on the dedicated
encoder stream.  This is because the order of delivery between header
blocks on different requests streams is not guaranteed, so if
insertions were allowed in header blocks, the order in which these
insertions could arrive would be undefined.

Bence