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

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Mon, 17 Jul 2017 15:39:54 -0700

Hi all.  I have uploaded a new revision of the QCRAM draft.

The main changes:

   - assuming we'll move back to one stream per HTTP message exchange, and
   adopted Mike's idea to split updates off onto the connection control
   stream.
   - introduced de-duplication to handle a table explosion case.
   - more clearly defined HPACK fallback options, and I think they handle
   some corner cases much more neatly now.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Jul 17, 2017 at 3:27 PM
Subject: New Version Notification for draft-krasic-quic-qcram-01.txt
To: Charles 'Buck' Krasic <[email-masked]>

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

Name:           draft-krasic-quic-qcram
Revision:       01
Title:          Header Compression for HTTP over QUIC
Document date:  2017-07-17
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-krasic-quic-
qcram-01.txt
Status:         https://datatracker.ietf.org/doc/draft-krasic-quic-qcram/
Htmlized:       https://tools.ietf.org/html/draft-krasic-quic-qcram-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-krasic-quic-
qcram-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-krasic-quic-qcram-01

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