modong / pcc

performance oriented congestion control

#PCC: Re-architecting Congestion Control for High Performance

###Read before use: The utility function in use in the current code base is a latency senstive one we are actively experimenting. To switch back to the default utility function, you just need one line of code change in cc.h. Uncomment cc.h:302 and comment out cc.h:303. And do a make clean;make (Proof of flexibility :))

How to use PCC

Installation Guide

Setup: For sender:

1. go to ./sender

2. make clean

3. make

4. export LD_LIBRARY_PATH=/path/to/install/sender/src

For receiver:

1. go to ./receiver

2. make clean

3. make

4. export LD_LIBRARY_PATH=/path/to/install/receiver/src

Replicate Demo with Emulab

Comming soon

Evaluate PCC in Your Network

1. Memory to Memory Data transfer speed test(without using disk):

1.1 On receiver, go to recever/app run ./appserver

1.2 On sender goto sender/app run ./appclient receiver's address 9000 2>monitor_log

2. File transfer software:

1.1 On receiver, run ./recvfile

1.2 on Sender, run ./sendfile dst_address 9000 file_to_send 2>monitor_log

Known Issues

1. We recommend do test on FEDORA 15.0 STD system and a server with at least two cores, on which the performance is best. We have tested it on Unbuntu 12.04LTS and 14.04LTS, it normally works fine but there is an issue of UDP’s sendto() system call (sometimes sendto just slows down awfully) that may break the packet pacing PCC relies on.

2. Also, if you are running using a low-end CPU without constant time counter in hardware or running in a virtualized environment, especially KVM based VMs, please run it under static core binding using likwid-pin provided by google, otherwise, the timer will be messed up and the pacing will break.

3. You may notice that pacing is the main performance issue we have. You can turn on non_busy_waiting pacing in udt.h, it gives you inaccurate pacing but avoid PCC eating one core per flow. A better solution we are looking at is SENIC. I would like to use SENIC to replace the pacing module of PCC.

pcc's Issues

Reverse setup does not work

According to your setup, if I want to test a file transfer, I should run ./recvfile from receiver and ./sendfile from sender. In this setup ./recvfile listens for connections and ./sendfile connects to it and starts sending the data.
Now the reverse setup [i.e ./sendfile listens for connections and sends data to every ./recvfile that connects to it] doesn't seem to work. This implementation is also present in the app folder of receiver and sender. I also changed the code of ./appserver and ./appclient so that ./appserver listens for connections and sends the data and ./appclient just connects to the ./appserver and receives the data and it doesn't work too. Can you provide some insight into why this is the case?

Loss-Based Utility Function

Could you please clarify where the loss based utility function is? I couldn't find it alongside the delay based utility function.
Thanks,
Venkat

running error

I am trying to run PCC on my computer (ubuntu), and I got this error:
error while loading shared libraries: libudt.so: connat open shared object file: No such file or directory.
Would you mind helping me solve it, please?

run error

Hi author
I'm interested in your research, when I ran the pcc-master , it had a problem.
./appserver: error while loading shared libraries: libudt.so: cannot open shared object file: No such file
but when i ran PCC-Uspace-master (not deep-learning branch) , it can work. So why is that.Thanks.

bringing to mainline

Stumbled over though a little dated ... Why have there been no attempts to bring this into mainline kernels?

Clarify licensing

In the top-level directory there's a LICENSE file that suggests the code is GPLv3, but then the "receiver" and "sender" subdirectories have their own LICENSE.txt files with a copy of the 3-clause BSD license. The inherited UDT code all reiterates the 3-clause licensing, but the newly added code is ambiguous whether you intend for it to be GPLv3 or BSD. (I'd encourage you to use BSD for consistency with UDT, but that's ultimately your decision.)

Could you please add copyright and licensing notices to the remaining files? E.g., sender/app/cc.h, sender/app/incast_client.cpp, and so on.

Operation interruption？

hello ,I am very interested in this project, but when I run into some problems, how to solve this problem?
~/pcc-master/sender/app$ ./appclient 127.0.0.1 9000 2>monitor_log
SendRate(Mb/s) RTT(ms) CWnd PktSndPeriod(us) RecvACK RecvNAK
2332.55 1.226 202678 172964 90 0
3283.09 0.984 484584 405760 140 0
3276.79 2.297 765929 631614 195 0
3237.49 1.081 1043896 860359 247 0
3238.69 1.302 1321977 1098856 297 0
3267.88 1.095 1602557 1331324 364 0
3226.62 0.897 1879598 1572917 418 0
3225.93 1.922 2156577 1813238 459 0
3242.16 1.574 2434947 2040442 502 0
3249.61 1.387 2713958 2270349 546 0
3235.4 1.756 2991767 2505809 594 0
Segment error (core dumped)

better rtt measurement

As recently discovered by a user, the current RTT measurement is delayed by almost one RTT and coupled with underlying packet handling mechanism.

The coupling of data ACK and RTT measurement can break the accuracy of RTT measurement very nastily (no measurement will come back for a long period of time because of delayed accumulative ACK) in extremely deep buffer(200 times of BDP) + small bandwidth environment (e.g. hotel wifi).

This is a software implementation deficit and should be fixed.

performance problem

Hi, I have finished a performance on my centos7 equipment about pcc, and I found that pcc don't care about the network link capacity or other envirement always to send packet in a high speed, so this operation lead to sender udp buffer outbreak and program breakout, and it not a nice congestion control solution.

Looking forward to your optimization.