Subject: So how critical is header compression?

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 22 Jan 2018 22:32:50 -0600

If I understood correctly (and this is my most accessible remote meeting
ever, so I have hopes), there was a tension in today's meeting between not
wanting to make a premature choice on header compression,  and not wanting
to have header compression make meeting the current milestone dates in
QUICv1 harder than that needs to be.

Was that about right?

Spencer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jan 2018 16:43:44 +1100

Buck tells me that header compression is critical: they can't deploy
QUIC without it and that 30% (what we get now) is still completely
unacceptable.

This is probably a moot point given the decision today.  I think that
we have a plan.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 23 Jan 2018 01:30:59 -0500

> This is probably a moot point given the decision today.  I think that

The Working Group decided only two of the three questions that were
to be posed, as the last slide never quite made it onto the main
screen.  The questions were:

    1. Allow or disallow blocking?
    2. Configurable (or negotiable) blocking or not blocking?
    3. Delayed reading from transport OK?

In regards to 1 and 2 the Working Group responded with "allow" and
"yes: make this into a knob."

The answer to the last question, however, has important implications.
I think we should revisit this issue: that is, the Working Group should
decide explicitly whether not reading from stream is appropriate.  Now
is the time to think about corner cases.

  - Dmitri.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Jan 2018 09:06:06 +0100

On 2018-01-23 07:30, Dmitri Tikhonov wrote:
> ...

FWIW (and just to clarify): anything discussed at a meeting (be it IETF 
or interim) will need to be confirmed on the mailing list...

Best regards, Julian

---

From: Mike Bishop <[email-masked]>
Date: Tue, 23 Jan 2018 11:14:50 +0000

I thought the last one was pretty clearly answered as well:  The transport doesn't trust that the application will read.  If HTTP fails to read in certain cases, that's exactly what flow control is for.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Dmitri Tikhonov
Sent: Tuesday, January 23, 2018 5:31 PM
To: Martin Thomson <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: So how critical is header compression?

> This is probably a moot point given the decision today.  I think that 

The Working Group decided only two of the three questions that were to be posed, as the last slide never quite made it onto the main screen.  The questions were:

The answer to the last question, however, has important implications.
I think we should revisit this issue: that is, the Working Group should decide explicitly whether not reading from stream is appropriate.  Now is the time to think about corner cases.

  - Dmitri.

---

From: Ian Swett <[email-masked]>
Date: Tue, 23 Jan 2018 16:46:41 -0500

I would agree with Mike's understanding.

On Tue, Jan 23, 2018 at 6:14 AM, Mike Bishop <[email-masked]> wrote:

> I thought the last one was pretty clearly answered as well:  The transport
> doesn't trust that the application will read.  If HTTP fails to read in
> certain cases, that's exactly what flow control is for.
>
> The Working Group decided only two of the three questions that were to be
> posed, as the last slide never quite made it onto the main screen.  The
> questions were:
>
> decide explicitly whether not reading from stream is appropriate.  Now is
> the time to think about corner cases.
>
>   - Dmitri.
>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Jan 2018 16:59:19 -0600

Hi, Martin,

On Jan 22, 2018 23:43, "Martin Thomson" <[email-masked]> wrote:

That doesn't answer the question I asked, but it does answer what my next
question would have been ;-)

Thanks for reading my mind!

Spencer

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 24 Jan 2018 09:23:09 -0500

On Tue, Jan 23, 2018 at 11:14:50AM +0000, Mike Bishop wrote:
> I thought the last one was pretty clearly answered as well:

I do not believe this question was explicitly stated in this form nor
considered by itself.  The notes do not capture any discussion regarding
this issue.

> The transport doesn't trust that the application will read.  If HTTP
> fails to read in certain cases, that's exactly what flow control is for.

I am talking about the effect, not the cause.  The implication of this
in combination with moving table updates to a single control stream is
that the current header compression proposal, QCRAM-04, is just a
variant of HPACK/GQUIC with the same set of problems.

I will expand on this in a reply to the recent QCRAM email thread.

  - Dmitri.