Re:PCC: Re-architecting Congestion Control for Consistent Hi...
by jorangreef on Monday September 29, 2014 @04:57AM
(#8382120)
I think in practice it will work well, given that bufferbloat is often the cause of congestion on a home network. TCP itself is usually quadratically impaired when it comes to reacting and backing off in the face of increasing latency caused by buffers (uploading a large file through Dropbox or Google Drive will most likely cause ping times on other machines on the same network to degrade from milliseconds to seconds).
When it comes to bufferbloat, a single TCP flow can dominate all others and be highly unfair because TCP's congestion algorithms are so slow to react (they often only react to packet loss and not latency).
LEDBAT and delay-based congestion algorithms were designed to handle bufferbloat well, and PCC is essentially a superset of these, taking into account loss rate and throughput in addition to just delay.
These are all not quite multi-TCP and there was no real mention of fairness of PCC against a single TCP stream, even of the CUBIC form, not to mention just plain old NewReno.
I can't tell if it's really unfair as I didn't test it myself, but they hint that there is a wide gap between PCC and NewReno or even CUBIC. The algorithm as I understand it also seems to imply that PCC will dominate a NewReno stream with ease, especially when PCC is an established connection and the NewReno is only starting up as the PCC will feel a small bump of losses, probably not do much about it (i.e. not reduce rate by much) and the NewReno generated packet losses will fly under the radar of PCC. At least that's the feeling I get from reading the paper, again, no idea about actual behavior but I'm no longer paid to look at packet traces of congestion control algorithms. (Shame, it was fun while it lasted :-)