QUIC FEC v1

[Ian Swett]

Short Summary

• The QUIC team ran multiple experiments with QUIC's XOR FEC.
• None of them improved metrics, and most performed worse.
• QUIC's first version of FEC is being removed.
• The QUIC team is talking to teams internally and externally who have had past success with FEC before designing a new version of FEC.

https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit?usp=sharing

[Wesley Davison]

Hi, Yan, 

In the document, more specifically in the "Summary" section, when you say "Youtube QoE metrics", you mean YouTube Join Latency" and "YouTube Rebuffer Rate" ? Or you are meaning other way of measuring QoE ?

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Ian Swett]

Those are exactly what I mean, yes.

[Jim Roskind]

The current FEC design in QUIC was expected to provide the greatest benefit in covering packets involved with stream creation (and possibly with the final packets in a stream).  

The biggest impact of the FEC design should be apparent when covering the first few data packets sent by Chrome following the CHLO, such as are present in a 0-RTT request.  The big advantage *should* be that the first data packet (the second physical packet) has relatively high loss probability, compared with physical packets 1 or 3 or 4 etc.  I presented these loss-results publicly in the slides at IETF 88 when I gave the first IETF talk on QUIC back in 2013. Take a look at slide 22, and you'll see the remarkable result that the 2nd packet was notably more likely to be lost. That second physical packet (containing the GET) is a packet that could dearly enjoy FEC protection!  (...and of course, this first data-request packet is typically on the critical path for the top-level resource).

In addition, the bandwidth is commonly underutilized in the client->server direction during a 0-RTT request, as it usually consists of little more than a single request (and if several requests are sent, then compression often reduces them in size enough to fit into a single physical packet).  Since the upload bandwidth is not fully utilized during connection initialization (and the initial request), there should be no adverse impact from adding redundant data contained in the FEC packet... and there should only be a latency win.

The original QUIC Design and Rationale Document actually covered the YouTube cases that you're considering, and stated:

"For larger streams, where serialization latency is deemed to be the dominant factor (by the application that constructs and send the stream), the use of FEC redundancy may be reduced or eliminated for most packets of the stream."

So I'd say +1 for not using FEC for things like YouTube content, which is dominated by serialization latency, as per the planned design, but it is less clear that you should discard the whole FEC feature.

The experiments quoted in your document suggest that you typically wait 1/4th RTT before sending an FEC packet.  When you are in a 0-RTT scenario, I wouldn't expect a high-quality RTT signal (yet!).  At best, you might have an "old RTT" signal, which could easily include some bloated buffer latencies (unless perhaps it is a min-RTT??).  

Have you considered experimenting with sending the FEC packet sooner, such as after something more related to the pacing rate?  Examples include:

1. Send an FEC packet from Chrome as soon as you go idle for a one or two interpacket pacing intervals?
2. Send an FEC packet from Chrome only during 0-RTT (where greatest benefit is expected!), and send it immediately after the first packet containing the first stream request is complete?
   

YMMV,

Jim (no longer on the QUIC implementation team)

p.s., I also recorded histograms in Chrome for "real data loss" that is part of "live QUIC connections," but never had a chance to summarize/analyze it before I left the team.  You might have a look at that data to better quantify the potential of any FEC strategy, as that data is being gathered within the congestion-control and pacing limits, during live QUIC connections.  That data is also designed to have implications for other classes of FEC than XOR (single error-correcting erasure codes), such as fountain codes etc. (providing multiple error-correction support). If you posted some sanitized versions of that data, perhaps others outside of Google could chime in with suggestions.