Re: Proposal: drop QPACK encoder stream framing

[Dmitri Tikhonov <[e-mail]>]

Hi Spencer,

On Thu, Jun 07, 2018 at 11:55:23AM -0500, Spencer Dawkins at IETF wrote:
> This is me as an individual, asking a question, and NOT making an informed
> observation or suggestion ... but I was curious.

[snip]

> I note that TSVWG  currently has two FECFRAME docs in WGLC now:
> 
> (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/
> 
> (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/
> 
> The intent for these documents is to add support for sliding window FEC
> codes to the RFC 6363 FEC Framework, which was limited to block FEC codes.

I have to admit, I have never seen RFC 6363 or the FECFRAME drafts until
today.  With that said, I believe I understand on high level what they
are about after reading the abstracts.

> I don't know whether there is any relationship between your proposal
> (moving from framing to a stream for compression) and the work currently in
> TSVWG. I have some guesses, but not well-informed guesses, so thought I
> should ask.

There is no relationship to the QPACK framing in question.  The QPACK
framing mechanism used to write encoder instructions to the encoder
QUIC stream is there solely as an aid to the decoder -- evidently
with the aim of making the QPACK decoder easier to implement (or to
port existing HPACK decoders).

Google experimented with FEC in gQUIC but the bandwidth overhead
proved to outweigh any advantages offered by ability to reconstruct
lost packets and the effort was abandoned, IMMSMC, in 2015.

Using FEC in IETF QUIC is something that is interesting to think about.
For example, one could envision adding FEC to a critical stream, such
as the QPACK encoder stream above, to cope with packet loss.  The
challenges posed by such approach would be non-trivial and likely
require changes to the transport layer.

  - Dmitri.