Subject: Fwd: New Version Notification for draft-krasic-quic-qcram-00.txt

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Mon, 27 Mar 2017 11:55:58 -0700

FYI, I've submitted my draft.   Apologies in advance if I've made mistakes,
I'm a newbie to the IETF submissions process.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Mar 27, 2017 at 11:52 AM
Subject: New Version Notification for draft-krasic-quic-qcram-00.txt
To: Charles 'Buck' Krasic <[email-masked]>

A new version of I-D, draft-krasic-quic-qcram-00.txt
has been successfully submitted by Charles 'Buck' Krasic and posted to the
IETF repository.

Name:           draft-krasic-quic-qcram
Revision:       00
Title:          Header Compression for HTTP over QUIC
Document date:  2017-03-27
Group:          Individual Submission
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-krasic-quic-
qcram-00.txt
Status:         https://datatracker.ietf.org/doc/draft-krasic-quic-qcram/
Htmlized:       https://tools.ietf.org/html/draft-krasic-quic-qcram-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-krasic-quic-
qcram-00

Abstract:
   The design of the core QUIC transport and the mapping of HTTP
   semantics over it subsume many HTTP/2 features, prominent among them
   stream multiplexing and HTTP header compression.  A key advantage of
   the QUIC transport is that provides stream multiplexing free of HoL
   blocking between streams, while in HTTP/2 multiplexed streams can
   suffer HoL blocking primarily due to HTTP/2's layering above TCP.
   However, assuming HPACK is used for header compression, HTTP over
   QUIC is still vulnerable to HoL blocking, because of how HPACK
   exploits header redundancies between multiplexed HTTP transactions.
   This draft defines QCRAM, a variation of HPACK and mechanisms in the
   QUIC HTTP mapping that allow QUIC implementations the flexibility to
   avoid header-compression induced HoL blocking.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: "Aron ." <[email-masked]>
Date: Mon, 27 Mar 2017 16:15:34 -0400

​Hello Buck,

One unmentioned impact of QCRAM is that to use Rules 1 and 2, header data
must be kept somewhere until packets are generated.  In other words,
copied.  In comparison, when HPACK is used, headers can be compressed as
soon as they are generated and take up much less memory while they wait to
be copied into outgoing packets.

  Aron.

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Mon, 27 Mar 2017 14:13:30 -0700

On Mon, Mar 27, 2017 at 1:15 PM, Aron . <[email-masked]> wrote:

> must be kept somewhere until packets are generated.
>

Agree.

Although I think there might be scenarios like crazy huge header blocks
where progressive encoding could conceivably reduce memory footprint,
because the headers could be handled in a streaming fashion.

> In other words, copied.

Not necessarily.   If QCRAM takes or shares ownership of the original
header data, then an extra copy would not be needed.

> In comparison, when HPACK is used, headers can be compressed as soon as
> they are generated and take up much less memory while they wait to be
> copied into outgoing packets.
>

Perhaps, but its not clear to me whether this would be a significant
overall memory impact.   My gut instinct is that it would be not rise to
the level of a first order memory issue,  I'd imagine caches and
send/receive buffers would be much larger.

I agree that I should mention potential implications on memory footprints.
  Thanks for pointing it out.

---

From: "Aron ." <[email-masked]>
Date: Tue, 28 Mar 2017 08:33:38 -0400

On Mon, Mar 27, 2017 at 5:13 PM, Charles 'Buck' Krasic <[email-masked]>
wrote:

> header data, then an extra copy would not be needed
>

True, but that would likely complicate the API (I am thinking of code that
uses a QUIC library).  In other words, no free lunch.

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Tue, 28 Mar 2017 10:59:22 -0700

On Tue, Mar 28, 2017 at 5:33 AM, Aron . <[email-masked]> wrote:

> On Mon, Mar 27, 2017 at 5:13 PM, Charles 'Buck' Krasic <[email-masked]
> > wrote:
>
> Maybe or maybe not.  Just as one data point,  the interface in chromium
takes ownership of the header data, here is a source code link
<https://codesearch.chromium.org/chromium/src/net/quic/chromium/quic_http_stream.cc?rcl=4e3eedb01d42a459acc405e87e7a0a72ca9c71b8&l=681>
.