Re: Proposal: drop QPACK encoder stream framing

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Dmitri,

On Thu, Jun 7, 2018 at 2:02 PM Dmitri Tikhonov <[e-mail]>
wrote:

> 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.
>

Thanks for this. It's helpful.

Spencer

  - Dmitri.
>