I think that you're forgetting that packet loss on a TCP stream incurs a retransmit.
So, when there is 33% loss, you end up sending rexmits with an overhead of 50% (33% of the first 33% lost would also be lost, etc. so the series of sum of (p^i) where p ==1/3 and i goes from 1->infinity converges at 50%)

In any case, you end up with an overhead of packets/bytes on the wire with rexmits as well.

With XOR based FEC, it takes one FEC packet at MTU size to recreate any one lost packet in the range of packets covered by the FEC. This means that, so long as your flow is long enough, FEC becomes potentially superior at recovering data, as the FEC can cover a longer range packets, making multiple-packet-recoveries possible. This really depends on the length of the flow, however, and it is certainly true that FEC by itself is never sufficient.

Comparing the two:
FEC: is good since it has a probability of removing an RTT before the application can interpret the data. It is not as great when one focuses on bandwidth efficiency in a non-loss case. It can potentially do better in terms of bandwidth efficiency than rexmit at higher loss rates since the FEC packet can deal with any one packet being lost within the range.

Rexmit: is good since it uses no additional bandwidth in the no-loss case. It is potentially a fair bit worse when there is loss (the internet seems to average ~1.5% packet loss) in terms of latency for the application, and it isn't great in terms of bandwidth efficiency when loss is occuring.

Both FEC and rexmit seem like reasonable loss recovery mechanisms, each excels at different parts of the curve.

Part of the focus is on mobile devices, which often achieve fairly poor throughput, with large jitter and moderate to large RTTs. .. so, yes there is attention to low bandwidth scenarios.
Surprisingly, QUIC can be more efficient given how it packs stuff together, but there this wasn't a primary goal.
Think about second-order effects:
Given current numbers, if FEC is implemented, it is likely that it would reduce the number of bytes actually fed to the network, since you end up sending fewer retransmitted packets than you send FEC packets since the FEC packets allow for any one packet in the range of packets it covers to be reconstructed!

Nah; it is valuable for many people to be doing this benchmarking even with the current state of code. .. it just requires careful explanation of what the benchmark entails!

Concluding that buggy-unfinished-QUIC is slower than TCP is absolutely valid, for instance.
That isn't the same as QUIC being slower than TCP (at least, not yet!)

TCP doesn't suck.

TCP is, however, a bottleneck, and not optimal for all uses.

Part of the issue there is the API-- TCP has all kinds of cool, well-thought-out machinery which simply isn't exposed to the application in a useful way.

As an example, when SPDY or HTTP2 is layered on TCP, when there is a single packet lost near the beginning of the TCP connection, it will block delivery of all other successfully received packets, even when that lost packet would affect only one resource and would not affect the framing of the application-layer protocol.

bprodoehl is absolutely correct-- the code is unfinished, and while the scenario is certainly one which is worried about, it isn't the focus of attention at the moment. The focus at the moment is getting the protocol working reliably and in all corner cases... Some of the bugs here can cause interesting performance degredations, even when the data gets transferred successfully.

I hope to see the benchmarking continue!

AC, don't worry.
TCP is simply a reliable, in-order stream transport.
HTTP on TCP is what was described, and, yes, not the best idea in today's web (though keep in mind that most browsers open up 6 connections per hostname), but that is also why HTTP2 is working on being standardized today.

The benchmark looked well constructed, and as such is a fair test for what it is testing: unfinished-userspace-QUIC vs kernel-TCP

It will be awesome to follow along with future runs of the benchmark (and further analysis) as the QUIC code improves.
It is awesome to see people playing with it, and working to keep everyone honest!

Right now QUIC is unfinished, so I hesitate to draw conclusions about it. :)

What I mean by unfinished is that the code does not yet implement the design; the big question right now is how the results will look after correctness has been achieved and a few rounds of correctness/optimization iterations have finished.

That is a complicated question :)

Hopefully this mostly answers it:

The goal is to not be worse than TCP in any way. Whether or not we'll achieve that is something we won't know 'till we've achieve correctness and had time to optimize, and then time to analyze where and why it performs badly, then iterate a few times!

I'd be curious to see that/those study-- can you tell which one/ones it is (so I can go read 'em and fix stuff?)
I thought I was aware of most of the SPDY/HTTP2 studies, but that is becoming more and more difficult these days!

To be clear, the solution isn't even done being implemented yet-- the project is working towards achieving correctness still, and hasn't gotten there yet. After that part is done, the work on optimization begins.

As it turns out, unsurprisingly, implementing a transport protocol which works reliably over the internet in all conditions isn't trivial!

There are definitely people and opinions on both sides of the fence on this.

Unfortunately, though performance might improve with access to the hardware, wide and consistent deployment of anything in the kernel/OS (how many WinXP boxes are there still??) takes orders of magnitude more time than putting something into the application.

So.. we have a problem: We want to try out a new protocol and learn and iterate (because, trust me, it isn't right the first time out!), however can't afford to wait long periods of time between iterations/availability.

Hopefully the project will drive us all towards solutions to these problems that are generic, usable for any new protocol, and which actually work!

What seems likely is that when you generate a large burst of back-to-back packets, you are much more likely to overflow a buffer, causing packet loss.
Pacing makes it less likely that you overflow the router buffers, and so reduces the chance of packet loss.

TCP does actually do pacing, though it is what is called "ack-clocked". For every ACK one receives, one can send more packets out. Since the ACKs traverse the network and get spread out in time as they go through bottlenecks, you end up with pacing.... but ONLY when bytes are continually flowing. TCP doesn't end up doing well in terms of pacing out packets when the bytes start flowing and stop and restart, as often happens with web browsing.

It is similar in some ways, and dissimilar in other ways.
One of the outcomes of the QUIC stuff that is considered a good outcome is that the lessons learned are incorporated into other protocols like TCP, or SCTP.

QUIC absolutely takes security into account, including SYN floods, magnification attacks, etc.

The benchmarking itself is awesome-- it is good to have people playing with it.

Concluding things right now, when the implementation is working towards correctness instead of optimality, however, is potentially misleading.