

PCC: Performance-oriented Congestion Control - belleville
http://modong.github.io/pcc-page

======
timtadh
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)

~~~
donavanm
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.

~~~
brighten
Check the paper for all the magic:
[http://arxiv.org/abs/1409.7092](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.

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

~~~
brighten
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!

