Re: Proposal: drop QPACK encoder stream framing

[Roberto Peon <[e-mail]>]

To be fair, Google's FEC implementation was.... naïve at best.
I wouldn't say that it proved FEC unuseful, but rather that it proved that FEC over temporally-proximate packets wasn't that useful.
-=R

On 6/7/18, 12:03 PM, "QUIC on behalf of Dmitri Tikhonov" <[e-mail] on behalf of [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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Dfecframe-2Dext_&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kc5MaxpPcqAxoBem1RsFu2d5jUxRsvSOFAU1tUoujBk&s=J_0CNYflHhBvUwAf9oBP40OHkGDkZ8rNBswKhx7fyOA&e=
    > 
    > (2) https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Drlc-2Dfec-2Dscheme_&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kc5MaxpPcqAxoBem1RsFu2d5jUxRsvSOFAU1tUoujBk&s=1dWjaPRse5ArHTUgAQvsEMJEZtU15tsDEV5w6X_DGoM&e=
    > 
    > 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.