6 ms·

They only compared with multi-TCP, and while this is a method that can be used to utilize high BDP with AIMD-TCP it is not a common use case. In most cases you

by baruch 12y ago

They only compared with multi-TCP, and while this is a method that can be used to utilize high BDP with AIMD-TCP it is not a common use case. In most cases you just have a browser with independent streams or a bittorrent client with quite a few somewhat short-lived connections to a wide range of locations and also just a plain single transfer from a remote server to upgrade your Debian system. 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 :-)

jorangreef 12y ago
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.

by baruch 12y ago

jorangreef 12y ago

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.