We're still nailing elements of "correctness," where that means "matching TCP's performance." Bottom line: We hope to soon be past this phase, as we are now starting to add additional optimizations which should help us to shine.
I think there was (for example) a bug where (contrary to TCP) when more than one packet was lost during an epoch (a single round trip time), then the congestion window could be reduced more than once (i.e., multiplied by a reduction factor more than once). I think that might explain one of your results. (We should have upstreamed that change... but probably have not yet landed it back into Chromium where you were testing).
We also had (perhaps still have) a clamp on the "maximum congestion window" (re: CWND), and that may have prevented the bandwidth from rising endlessly in your 0-packet-loss experiment. We put in the clamp as were were working to straighten out our RTO response (which had a bug), but it should be removed shortly (even though it would not have impacted most common user scenarios... but did show in your test).
We appreciate the report.... and hope you'll post again in a few weeks as we hopefully progress.
Thanks,
Jim