is FEC enabled by default?

[Brian Prodoehl]

I'm testing the quic_server and quic_client, and I'm not seeing any advantage over bog standard HTTP in the face of random packet loss between 0.1% and 5%.  Even at 0.1% loss, QUIC seems just as affected as HTTP over TCP.

Looking at QUIC sessions in Chrome Canary, I'm also never seeing the FEC flag set, and the FEC group seems to always be 0, so either I'm missing the purpose of those fields, or FEC is disabled.

[Jim Roskind]

FEC is not currently enabled in the QUIC prototype experiments in Chromium.

TBD is the heuristic for when to use it. 

Possibilities include:

a) Near the packets at the end of a stream (to reduce delay of providing a completed FINished stream).

b) Near the end of a packet train, where we are going into a idle mode (to better deal with tail loss, and avoid RTO).

c) Around the 2nd packet sent by a client, which apparently has a notably higher packet lass than the 1st or 3rd packet sent (based on client side experimentation... and conjectured to be caused by a router being "busy" setting up the route when the 2nd packet arrives "too quickly" after the 1st packet).

d) Around the start of a new stream, to reduce HOL blocking induced by the loss of a compressed header (in the current QUIC header compression scheme).

On Fri, Oct 25, 2013 at 9:02 AM, Brian Prodoehl <bpro...@gmail.com> wrote:

I'm testing the quic_server and quic_client, and I'm not seeing any advantage over bog standard HTTP in the face of random packet loss between 0.1% and 5%.  Even at 0.1% loss, QUIC seems just as affected as HTTP over TCP.

Looking at QUIC sessions in Chrome Canary, I'm also never seeing the FEC flag set, and the FEC group seems to always be 0, so either I'm missing the purpose of those fields, or FEC is disabled.

--
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/groups/opt_out.

[Arash Molavi]

Any updates on this? Looking at QUIC sessions in chrome, FEC seems to be disabled. Is Google still looking into this or they decided not to use this feature?

[Ryan Hamilton]

We are actively investigating it, but don't have anything to report yet.

Cheers,

Ryan

On Wed, Jul 15, 2015 at 1:43 PM, Arash Molavi <arash....@gmail.com> wrote:

Any updates on this? Looking at QUIC sessions in chrome, FEC seems to be disabled. Is Google still looking into this or they decided not to use this feature?

--

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.

[Àlex Ulloa]

Hello,

I have been trying to test QUIC using FEC in the transmissions,

First i enabled the flag 

net/quic/quic_flags.cc

-bool FLAGS_enable_quic_fec = false;

+bool FLAGS_enable_quic_fec = true;

And I read that I have to tell to the client to use FEC, I tried to add headers like --headers="fec_flag:1" but dont respond to it. I understand that the fec flag are in the private flags of QUIC and are encrypted but how can i activate it? Can you help me?

Regards,

Alex

[Ian Swett]

The initial version of FEC has been removed from QUIC in the last few months because it didn't show sufficient performance benefits(doc), so I believe that flag is obsolete and should be removed.

[Jana Iyengar]

The flag is no longer present in Chromium code; you should get the latest copy of the code.

[Jim Roskind]

The greatest value of the existing FEC feature was expected to be reaped when applied to stream creation, by adding redundancy only to the client request (which is rarely constrained by congestion avoidance). I don't believe the doc you cited tested for that advantage.

Quoting from the doc about the first experiment:

"Due to the FEC flag never being enabled in Chrome, this experiment had no effect on data sent from the client to the server, only from the server to the client."

Quoting from the doc about the second experiment:

"The QUIC team enabled an experiment later in Chrome Dev, and this one had the client as well as the server sending FEC. "

The download direction (server sending) is generally limited by congestion control, and it is more questionable as to whether speculative addition of FEC redundancy is valuable, or detrimental to the system. The experiments seem to confirm this as a problem (server sending FEC in general, during a large stream, is a bad thing). 

FEC is generally fruitless for large downloads, where bandwidth efficiency is critical, and NACK based retransmission latency is masked.  The two cases are where the large download is a buffered stream (such as YouTube), or the large download can't be processed until it *all* arrives (such as a traditional chrome file download).  In those situations, NACK based retransmission is optimal (no extra bandwidth cost, no latency added).

I look forward to hearing results of other experiments, and other variations in FEC, but suspect that the value of FEC may have been overlooked in the documented experiments (unless I've misread the doc you cited).  If I did misread anything, I look forward to being corrected.

Thanks in advance,

Jim

p.s., The place where it is more plausible for server sent FEC to be valuable is around stream-completion time.  It should be more than competitive with a TLP, especially when used *only* for stream completion, and not abused during larger stream (and mid-stream) transmission.  I'm fearful the the documented experiments may have abused FEC during such large server-sent streams.

[Jim N]

wow quite an unexpected bump there... but an interesting thread to read nonetheless.

The usecase where FEC really presents value is probably where the equality and latency of full-duplex on a link approaches zero.  

cheap FEC on a fast link does sort of seem like it would increase the rate limiting events by however much fec overhead it introduces. 

according to the wikipedia article https://en.wikipedia.org/wiki/Linear_network_coding "Linear network coding may be used to improve a network's throughput, efficiency and scalability, as well as resilience to attacks and eavesdropping."    

back in the y2k timeframe (R)LNC was a cpu intense experiment that was compared to bittorrent and i think microsoft tried to put in some patents on the avalanche file distribution protocol.   in the present tense, we have qualcomm chipsets with gpu's on the consumer midpoint. it's a different landscape.  

Is the QUIC agenda for source and sink encoding options a closed book at this point?