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

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Thu, 3 Aug 2017 11:30:53 -0700

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

Highlights of 01->02:

   - more concise:  lines of text down ~ 30%.
   - simplifications:
   - flexibility to trade-off between compression ratio and HoL blocking
      resilience.
      - handling stream reset, dropped QPACK style split between updates
      and encoded headers.
      - new eviction scheme, avoids eviction races and icky resets.
      - mostly eliminated coordinated packetization (just a note in
      performance section now).

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

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

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

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 it 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 if 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