Re: question about QPACK decode framing

Dmitri Tikhonov <> Thu, 01 November 2018 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25BBC1286E3 for <>; Thu, 1 Nov 2018 08:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p9pGywNmsO0N for <>; Thu, 1 Nov 2018 08:43:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7960124BAA for <>; Thu, 1 Nov 2018 08:43:19 -0700 (PDT)
Received: by with SMTP id v1-v6so17338903qtq.5 for <>; Thu, 01 Nov 2018 08:43:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ShCItPV5gqySci4xljpZU8UbcDmOoyhhAndJFadIxY4=; b=aM5YjCQBqotCKAk6By8ax6sRRX9yYvZZCem+UkuR7arnyUOGQEEllz3g7AashvEoZv HUWhaoI3TPHPfFD1bZjUHy8goFWjZXNS9sxJ9akIn6Is0mfYQ4LFvRZ8cGKYyCWSzDEb VVozKhLPZZSf9+aVg9nQ8O0CDlDn2LmbdQ83rWqqzUXhDnG2yonGn22sAs1ZuO+kAh8L BRRlKUwhub3JN3/3X1n/W1Jn0B9zoKjxXle8JlnR9mous9OFOziEIq33OdJMi576kS5B 72+OOqc88QWiqqK/pq1EZRXqAMSXpCkZB6y4C0CXickSSEZ9SKZhYhpUg616/2swOQg1 xKEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=ShCItPV5gqySci4xljpZU8UbcDmOoyhhAndJFadIxY4=; b=JMTL99I5sEXz2fA1+mbwMX8zGon8PJYgnCRNklvveZgqhAaln46KIK5YOhPSdOlKQ6 ZoO+09/uCdYr21b+TpOMDswoS85q3zax0ZLW1UeJZNCYKqqtm9lUgMJeu/Z/b5+Qiniq 5shWqa5j2hnl7s7YXCUNKgvmsJqnH7JrRMypTCxqXUpPgBZEH9ZlheZ61XL7LRyrTNpw vox3kxP+541/7R3EiffwxR3w+TdhZ5tGodG1RWfoTFLunsI43fArqktuXKty8aR+Aw7+ rfHGmkOd33OwYtt1nywbFhtQ796Bi76LhPl4r1XgE448KhXVBERvuRtv8mUhk5KIcR0j JQtA==
X-Gm-Message-State: AGRZ1gJoWTHZ/r6WzMC55jAfpzBYY+yHlxa5SMuhLcXvV/K6PvBXt1NW CBJEtNnKdt/iduO86MGuBDDgIQ==
X-Google-Smtp-Source: AJdET5fJ2xtmC0P4NiLkER1RoVoFStMW87Dco2aspYo3OTHeOIiKdaddwGuT1jerJr77AMPHjJbGgA==
X-Received: by 2002:aed:2b43:: with SMTP id p61-v6mr6787737qtd.94.1541086998947; Thu, 01 Nov 2018 08:43:18 -0700 (PDT)
Received: from ubuntu-dmitri ( []) by with ESMTPSA id q70sm6827190qkq.10.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 08:43:18 -0700 (PDT)
Date: Thu, 1 Nov 2018 11:43:14 -0400
From: Dmitri Tikhonov <>
To: Brian Swander <>
Cc: Matthew Cox <>, "" <>
Subject: Re: question about QPACK decode framing
Message-ID: <20181101154312.GA18531@ubuntu-dmitri>
Mail-Followup-To: Brian Swander <>, Matthew Cox <>, "" <>
References: <> <20181031211518.GA9622@ubuntu-dmitri> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Nov 2018 15:43:22 -0000

On Thu, Nov 01, 2018 at 03:27:09PM +0000, Brian Swander wrote:
> From our read of the current drafts:
> It seems that in the drafts that the HEADERS frame is only for the
> compressed headers being sent on a real stream.  The encoder and decoder
> streams for QPACK are just the raw encodings as described in the QPACK
> spec without extra framing.  If so, then on the decoding on the decoder
> stream, there is no way to know (a priori) that we have a complete
> set of headers, since there is no overall header length available.

QPACK uses two unidirectional control streams: one called the
encoder stream and the other, the decoder stream.  Each side
opens both, so there are four streams altogether.

The encoder stream carries instructions that modify the dynamic
table.  The header sets are placed into header blocks which are
carried in HQ HEADERS frame on the bidirectional request/response
streams.  The encoder stream does *not* carry header sets.

With regards to framing: the encoder stream does not have framing.
For discussion for the rationale for the lack of encoder stream
framing, see this thread:

  - Dmitri.