Subject: RE: Splitting QPACK

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Feb 2017 22:16:49 +0000

An -02 version of the QPACK draft based on the split model and the discussion from this thread can be found at  https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack-02.

From: Patrick McManus [mailto:[email-masked]]
Sent: Tuesday, January 31, 2017 10:29 PM
To: Charles 'Buck' Krasic <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Mike Bishop <[email-masked]>; IETF QUIC WG <[email-masked]>; Kazuho Oku <[email-masked]>; Ryan Hamilton <[email-masked]>
Subject: Re: Splitting QPACK

or to put it another related way - the value of hpack has always been in avoiding cwnd stalls. quic breaks down the old abstractions and an encoder can certainly better take into account cwnd, the amount of data it thinks it will be sending, and how it wants to combine frames in packets. that's pretty powerful in balancing the tradeoffs here.
off hand it seems clients doing the o(100) thing would be highly incented early on, but later might not need to accommodate such bursts and would use different strategies.. similarly servers might only use compression rarely.
beyond to compress or not, different choices might be made in how tightly each packet is stuffed again based on cwnd.

On Wed, Feb 1, 2017 at 1:23 AM, Charles 'Buck' Krasic <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jan 31, 2017 at 3:28 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
On 1 February 2017 at 10:06, Charles 'Buck' Krasic <[email-masked]<mailto:[email-masked]>> wrote:
> Ok I get it now.  For the header that causes a table insert, it would be
> ill-advised to use a hpack literal on the headers stream.   There's no point
> guarding HoL blocking among things that that will end up in the same packet
> anyway.

The hazard is where you have multiple concurrent uses in short order.
If packetization causes the insert and the reference to appear in
different packets, you have a HOLB exposure.

As Mike observes, the odds of having a reference that causes an insert
split between two packets is low.  Well, depending on how you
construct packets.  You can minimize this by generating interleaved
STREAM frames, but that has a bunch of overhead associated with it.

It all depends on how much you want to spend to avoid stalling in the
case of packet loss.  I can imagine using different strategies based
on observed packet loss, but then I can also imagine flying cars and
we all know how common those are.

Yea.  I can imagine that the trade-offs may play out differently for requests vs responses.

Considering the O(100) requests example Patrick mentioned.

There could be a very good chance that after compression many packets contain headers from several distinct requests.   The subset of requests packed into a common packet now share fate, so no point giving up compression efficiency by coding them independently of each other.   *if* it were the case that all the requests fit into a single packet, then clearly any HoL avoidance would be strictly losing tactic.

In the response direction it is quite different.  Suppose the request were for images, such that the bodies were all one or more packets large.    If the bodies were consistently written along with the corresponding response headers, the chance of two response headers sharing fate (by virtue of serializing into the same packet) may be effectively zero.     In that case, having the response headers encoded independent of each other could be quite valuable (still modulo compression efficiency).

We clearly need some measurements...

--
Charles 'Buck' Krasic | Software Engineer | [email-masked]<mailto:[email-masked]> | +1 (408) 412-1141