search

quic-go / quic-go

A QUIC implementation in pure Go
https://quic-go.net
MIT License
9.97k stars 1.3k forks source link

TCP fairness #1385

Closed razvancojocaru closed 5 years ago

razvancojocaru commented 6 years ago

Is quic-go/TCP fairness an issue? As far as I know, QUIC used to be pretty unfair compared to TCP, but with quic-go it seems the other way round and that it is actually way too nice, going almost up to 20%-80% in favor of TCP.

Specific example: I'm using a raw quic connection (similar to the echo example) that is sharing a 100Mbps link with a tcp connection (iperf). QUIC - 20Mbps TCP - 75Mbps By itself, quic-go gets about 93Mbps on the same testbed. I can provide more details about the testbed/measurements if necessary.

Any help to shed some light on the issue would be appreciated.

marten-seemann commented 6 years ago

That’s a really interesting measurement, and I’m definitely interested in exploring this further.

The congestion controller we’re using in quic-go is the same one as in Chrome (we literally translated their implementation into Go). Other than that though, the two implementations are fundamentally different. An interesting comparison therefore would be 1. how Chrome’s QUIC implementation competes with TCP flows and 2. how quic-go competes with Chrome. Do you have any numbers on that?

I’d like to learn more about your testbed environment, especially about the network conditions you’re using. What’s the packet loss rate and what’s the RTT? My own benchmarking suggests that quic-go comes throughout reasonably close (around 80%) or so under most loss conditions and for RTTs > 5 ms, but is somewhat suboptimal for very short RTTs.

razvancojocaru commented 6 years ago

Just a bit of background context, I'm doing a series of experiments to compare QUIC to TCP on a transport level. I'm running a 3 machine Server-Router-Client setup, each one with 2 NICs (1 for management and 1 for traffic) and Ubuntu 16. All test traffic goes through the router. I'm using tc/netem on the router in order to simulate network conditions.

So, I did some measurements with the chromium toy client/server(version 38) and it still seems QUIC is performing poorly, so maybe it's a problem on my end, on the testbed setup.

TCP vs chromium: TCP 24, chromium 4.7 TCP vs quic-go: TCP 27.4, quic-go 0.8 chromium vs quic-go: chromium 17, quic-go 12

Chromium and quic-go behavior is pretty interesting, since convergence is extremely slow. For about 50s, quic-go slowly loses bandwidth until it gets about to 5.7Mbps, afterwards it stabilizes at about 11-12 in 2-3 seconds. For chromium I only have average.

For the fairness experiments I set up a 20ms RTT between S-C, with a 30Mbps rate limit.

Any suggestions on how to look into this?

marten-seemann commented 5 years ago

This should probably have gotten a lot better with the recent fixes to our pacing algorithm (#1855 and #1857). Feel free to open a new issue if the problem still exists.