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
- Questions about QPACK Jiuhai Zhang
- Re: Questions about QPACK Bence Béky
- Re: Questions about QPACK Dmitri Tikhonov
- Re: Questions about QPACK Dmitri Tikhonov
- Re: Questions about QPACK Dmitri Tikhonov