PCC: Performance-oriented Congestion Control | Hacker News Reader

PCC: Performance-oriented Congestion Control

modong.github.io

62 pointsbelleville9 comments

This seems like a pretty cool idea. They essentially bolt on a new congestion control strategy onto TCP. It only requires server side changes and doesn't need any changes to either the receivers or the routers or the packet headers. Instead of taking predefined actions when events like packet loss occurs it uses the events as a feedback mechanism into its control algorithm which attempts to optimize a plugable utility function. Very cool. I would like to try this out my laptop but it looks like it isn't quite ready for that yet! (the prototype is a user space implementation) (you can run their experiments if you have a fedora 15 box. There are some issues on ubuntu)

That's how most/all the congestion control works. It's essentially a send side only algorithm. On linux congestion control algorithm is actually a per socket option, as I recall. The receivers input/signal is limited to loss, latency, and windowing. "Other" congestion control algorithms also make changes based on loss/latency/windowing events, not necessarily per packet though. The "predefined" wording also struck me as a bit odd; is an undefined response preferable?

I read the readme, but not the implementation yet. It's possible I'm missing some magic. Would have been nice to include even a cursory description of the algorithm/mechanism instead of a bunch of pretty pictures.

Check the paper for all the magic: http://arxiv.org/abs/1409.7092

Sec 2.1 describes the key ideas, with longer description after.

PCC gets consistent high performance because it observes what performance outcome actually results from a particular sending rate -- rather than assuming that certain events like a packet loss should be hardwired to certain actions.

> you can run their experiments if you have a fedora 15 box

Huh, that is somewhat peculiar choice of platform, considering that F15 has been EOL for 2.5 years

We used fedora 15 because that is what provided in the test platform we can access: emulab.net You can also use it on newer fedora versions for sure. However, I would not recommend running it on ubuntu machines since we notice a severe (and weird) performance issue caused by ubuntu's send() call for udp

interesting. I'd like to see performance comparisons to TCP/NC and/or CTCP.

Good question.

TCP/NC = network coding I assume. This is not really a competitor to PCC: the two techniques are solving different problems and could work together. PCC controls the sending rate, while erasure coding (in general - I'm not familiar with the details of TCP/NC) avoids extra round trips to recover from losses. Erasure coding would be quite relevant to very short flows, for which every RTT matters, which is extremely interesting and valuable but not the focus of this paper. Also note TCP/NC needs a new end-to-end protocol.

CTCP is probably compound TCP. We haven't done a performance comparison but it appears to fall within the large set of TCP variants that use what we called "hardwired" control. If you try it out, let us know!

What are those proposals? The paper discusses quite a few different alternatives and does performance comparisons. Are there any specific advantages to TCP/NC and CTCP vs:

1. RCP 2. XCP 3. TCP CUBIC 4. FAST TCP 5. Remy

Not being in this area it is hard to know if TCP/NC and CTCP are important protocols which should have been included in the evaluation or if they even solve the same problem.

With a quick search, ICTCP and DCTCP are mentioned in the paper [1], but I haven't finished actually reading it yet.

[1] http://arxiv.org/abs/1409.7092

Reply on news.ycombinator.com