Proposal: drop QPACK encoder stream framing

Dmitri Tikhonov <> Thu, 07 June 2018 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1445F130F27 for <>; Thu, 7 Jun 2018 08:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 uIwMcIgNJMBX for <>; Thu, 7 Jun 2018 08:11:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDB44130F2D for <>; Thu, 7 Jun 2018 08:11:26 -0700 (PDT)
Received: by with SMTP id j80-v6so6751708qke.9 for <>; Thu, 07 Jun 2018 08:11:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=zoKs830pbycydXPJH63EB4wns5a+kusp1u/B8n4pKPY=; b=i7KBwO3a2ZbuwsUaqmDmA6vEo5yq6xsStUh9kM/FlcEAAPdlo1iU+0jLTuA5Wgno1c 6wAeI6OmRJPu/2BYMXA2H7c8TFb/JqY12WKUDsfW4A5vkgKggyk2AewcmFddl4Cm5iHb A8U3IGERDflGF24qu0JIMMJqhqGsz40I1BPxo0A5//cStapJOKI0qsji6wXpNjBTeLD1 72wGp6AAqGYGKUSZflYR03uqudPOz1ZpmXWGsh74pySxlCx4nYKCJlfwIGwkuPiecdJP Zc5619xlfFsIKOZiBWcti98HFG/S3FCjbywOtco3OSxLXXCH8qexWvKJvLhPEIDQCIf8 S8pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=zoKs830pbycydXPJH63EB4wns5a+kusp1u/B8n4pKPY=; b=Kln3qy8uTAAW3d+bx4BntVZUWOUq1kd0fyEGh5F8exc4fOEbMACj5SbfFR3WzXy+RL nFuYRfISQEezV198JLEuPvPX1N2+kJsFsAKzP6ntD3d39vh+VxOxf5OWBhcoL/QQxNjC 42Nwb6EYz+MYKIGBOyjYkmGOOA82+mNF2rN/HC37+dWciX1IAmyg5MGgFGY/WCNjhG/O 2l67eDHr48L+Sd+bqjMx6tmdzgeDBgnbRJQk3o6D5WN4Shw8qkQjt/P4ykXLI2zQb9Sq apW3ZprqHk+bLnh7DZQqy/9q00/UANkltSxWk8xJOlDSmDsr8NeKEkMZsFZiv/48Pxrv DyVw==
X-Gm-Message-State: APt69E1mht8BMCYS7jRcUVwoHsHnBS7mHdVC/6pv2N3BEz3c6BOEEfLg d47iJ7dhgyOTBYYnFO3d2wNdNWUx
X-Google-Smtp-Source: ADUXVKIdbN+M5Nj7txQSbawGFnBO8DMutdPDj4yMRF+1Ah5UVkJS/al7n91e1kih6jI9n+4gxq0tNQ==
X-Received: by 2002:a37:1246:: with SMTP id c67-v6mr1891109qkh.411.1528384285649; Thu, 07 Jun 2018 08:11:25 -0700 (PDT)
Received: from ubuntu-dmitri ( []) by with ESMTPSA id j28-v6sm22638760qtk.56.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 08:11:24 -0700 (PDT)
Date: Thu, 07 Jun 2018 11:11:13 -0400
From: Dmitri Tikhonov <>
Subject: Proposal: drop QPACK encoder stream framing
Message-ID: <20180607151112.GA28823@ubuntu-dmitri>
Mail-Followup-To: IETF QUIC WG <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
X-Mailman-Version: 2.1.26
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, 07 Jun 2018 15:11:31 -0000


The encoder block specified in Section 3.3 of draft-ietf-quic-qpack-00
is unnecessary.  For reasons of efficiency, I propose that the framing
be removed: let the encoder instructions be written and interpreted as
a stream instead.


I brought this up during the first day (June 6) of the Kista Interim.
Alan explained that there are two reasons for framing the instructions
in this way on the encoder stream:

    1. Historically, some (or most) HPACK decoders have struggled with
       input that breaks in the middle of an instruction, as they do
       not maintain state.

    2. The blocks can be used as a clue to send Table State Synchronize
       instructions on the decoder stream (Section 3.4.1).

The downside to having length-prefixed blocks is that it makes it
difficult to optimize encoding by writing to the outgoing packets
directly.  One has to buffer the block, write the block length first,
and then copy the block.

Additionally, there is a potential for a deadlock (issue #1420).  Recall
that QPACK owes its current form to the fact that the WG decided to
prevent deadlocks at the compression protocol level, and not via advisory
notes to the implementers.

Reasons Behind the Block

First, let's look at the historical HPACK chokers.

The HPACK decoder only processes HEADER blocks.  There is only one stream
and thus only one HEADER block can be processed at a time.

The QPACK decoder has to process two inputs: a) the encoder stream
and b) HEADER blocks.  There is only one encoder stream.  This stream
modifies the decoder state: the dynamic table.  The HEADER blocks do not
modify the state.

The HEADER blocks already come with a prefix length (HQ framing), and so
QPACK implementations can choose to wait until the whole HEADER block is
available.  It is processing of the encoder stream that is under

With regards to the Table Synch signaling, the draft states that

 "                                                         A decoder MAY
 " coalesce multiple synchronization updates into a single update.

This effectively means that the encoder already should not expect to get
a one-to-one mapping between its Encoder Blocks and Table Synchs.

Working with the Encoder Stream

The dynamic table instruction stream can be thought of as its own state.
Already, the QPACK decoder must be able to pause reading from streams when
a blocked HEADERS block arrives.  Similar techniques can be used to resume
reading from the encoder stream.  It should not be difficult to resume
decoding a single instruction!  While breaking with the HPACK precedent
(the hold-my-hand-I-need-buffer-size chokers), it keeps in line with the
Seattle hum that the new compression mechanism is free from its HPACK


Prefixing arbitrary sets of encoder instructions with a length denies
zero-copy optimization opportunities.  At the cost of some slight
complexity increase at the decoder, this framing mechanism can be
dropped.  The proposed change is limited to just this -- technically
superfluous -- piece.

  - Dmitri.

P.S.  An added bonus is some saved framing bytes on the encoder stream.
      I believe the "compression performance above everything else" is
      also the Working Group's consensus (Melbourne).