pccproject / pcc-kernel Goto Github PK

View Code? Open in Web Editor NEW

45.0 12.0 16.0 18 KB

License: Other

Makefile 1.89% C 98.11%

pcc-kernel's Introduction

PCC

Performance-oriented Congestion Control.

This is a Linux kernel module implementing the PCC Allegro and PCC Vivace.

master branch is for PCC Allegro, the first version of PCC, introduced in NSDI15.

vivace branch is for PCC Vivace, the second version of PCC, introduced in NSDI18.

History

PCC heavily relies on the pacing mechanism.
Until recently, this mechanism did not exist in the Linux kernel.
2014 - Implementation of PCC using UDT by Mo Dong - https://github.com/modong/pcc
2016 - Google publishes their BBR congestion algorithm (CA) - an algorithm with similar goals to PCC but slightly different, as a Linux kernel module.
2016 - Google adds pacing mechanism to the Linux kernel in order to support their BBR CA approach.
2017 - Google's BRR team adds more changes - allowing internal timers to implement pacing and multiple bug fixes.
2018 - PCC Vivace released with userspace implementation over UDT - https://github.com/PCCproject/PCC-Uspace

Using PCC

Environment

This module was tested and developed on kernel version 4.15

Compilation

Install git and clone this repository.

cd src
make
sudo insmod tcp_pcc.ko

Usage

Now you can use pcc as a congestion algorithm:

import socket

TCP_CONGESTION = getattr(socket, 'TCP_CONGESTION', 13)

s = socket.socket()
s.setsockopt(socket.IPPROTO_TCP, TCP_CONGESTION, 'pcc')

# Use s

Code

All PCC code resides under src/tcp_pcc.c

pcc-kernel's People

Contributors

Stargazers

Watchers

Forkers

gengchao mengqingkai mhhuang95 tsinghuadong leeweishi wang-xinkai h-jamil mzh741 onehappyforever chenhongquan ashutoshs25 urgodfather cugxchen xudongliao pinkfloyd-eminem zhiming-huang

pcc-kernel's Issues

PCC Vivace don't build for Linux 6.7.0

PCC Vivace don't build for Linux 6.7.0. For < 6.7.0 - all ok. Allegro build ok for 6.7.

Pacing functionally stops working at some point above the link capacity

I'm seeing that pacing using the pcc_set_pacing_rate function works reasonably well below the link capacity.

Here's an example of reasonable pacing (17.5Mbps on a 24Mbps link).

Here's an example of poor pacing (40Mbps on a 24Mbps link). Notice that the actual sending rate goes above the pacing rate at times as well.

This issue still has to be confirmed using the BBR codebase. It appears that this is less of an issue near the link capacity.

without much hope to get any response

extra_rate = pcc->intervals[0].delivered * tsk->mss_cache; this line of code get me confused.

kernel version problem

Monitor intervals aggregate data from times with different sending rates

Because we don't have complete control over the sending rate of the kernel module, we cannot easily line up monitor intervals such that a single monitor interval contains packets sent at exactly the same rate.

To illustrate the problem, consider two adjacent monitor intervals with three sending rates on a 100Mbps link.

MI 1:
t = 0.00 -> t = 0.75, rate = 120Mbps, latency = 200ms (full buffer)
t = 0.75 -> t = 1.00, rate = 80Mbps, latency = 100ms (empty buffer)
average rate: 110Mbps
latency inflation: -100ms

MI 2:
t = 1.00 -> t = 1.75, rate = 80Mbps, latency = 100ms
t = 1.75 -> t = 2.00, rate = 120Mbps, latency = 200ms
average rate: 90Mbps
latency inflation: 100ms

In this case, we would conclude that 110Mbps is a better sending rate because it decreases our latency, while 90Mbps increases our latency. If we had finer granularity in our monitor intervals or they lined up with observed sending rates, we could see that 80Mbps is preferable to 120Mbps and we could change our target rate accordingly.

When PCC Vivace enters the moving phase, the old value is not updated

In function 'pcc_decide()'

if (new_rate != pcc->rate) {
                printk(KERN_INFO "%d decide: on new rate %d %d (%d)\n",
		pcc->id, pcc->rate < new_rate, new_rate,
		pcc->decisions_count);
		pcc->moving = true;
	        pcc_setup_intervals_moving(pcc, list);
	} else {
		printk(KERN_INFO "%d decide: stay %d (%d)\n", pcc->id,
		pcc->rate, pcc->decisions_count);
	        pcc_setup_intervals_probing(pcc, list);
	}
	pcc->rate = new_rate; // update new rate

When the condition: new_rate != pcc->rate is satisified, PCC will enter moving stage and set the next monitor interval's rate in function:
' pcc_setup_intervals_moving(...)'

/* Reset statistics and set the target rate for just one monitor interval */
static void pcc_setup_intervals_moving(struct pcc_data *pcc)
{
	pcc->intervals[0].packets_sent_base = 0;
	pcc->intervals[0].rate = pcc->rate;
	pcc->send_index = 0;
	pcc->recive_index = 0;
	pcc->wait = false;
}

However, at this time, the value of pcc->rate has not been updated, and it is still runs the old rate for the next interval.