[RFC] TCP Illinois preliminary version

[RFC] TCP Illinois preliminary version

[Stephen Hemminger]

Preliminary version if TCP Illinois for 2.6.22.
It needs more testing and refinement but it captures the
basic concepts.

---
 net/ipv4/Kconfig        |   13 +++
 net/ipv4/Makefile       |    1 +
 net/ipv4/tcp_illinois.c |  238 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 252 insertions(+), 0 deletions(-)
 create mode 100644 net/ipv4/tcp_illinois.c

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index dc61e66..e62aee0 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -588,6 +588,19 @@ config TCP_CONG_YEAH
 	For further details look here:
 	  http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
 
+config TCP_CONG_ILLINOIS
+	tristate "TCP Illinois"
+	depends on EXPERIMENTAL
+	default n
+	---help---
+	TCP-Illinois is a sender-side modificatio of TCP Reno for
+	high speed long delay links. It uses round-trip-time to
+	adjust the alpha and beta parameters to achieve a higher average
+	throughput and maintain fairness.
+
+	For further details see:
+	  http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+
 choice
 	prompt "Default TCP congestion control"
 	default DEFAULT_CUBIC
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index eeb94d5..4ff6c15 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
 obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
 obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
 obj-$(CONFIG_TCP_CONG_YEAH) += tcp_yeah.o
+obj-$(CONFIG_TCP_CONG_ILLINOIS) += tcp_illinois.o
 obj-$(CONFIG_NETLABEL) += cipso_ipv4.o
 
 obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
diff --git a/net/ipv4/tcp_illinois.c b/net/ipv4/tcp_illinois.c
new file mode 100644
index 0000000..3536089
--- /dev/null
+++ b/net/ipv4/tcp_illinois.c
@@ -0,0 +1,238 @@
+/*
+ * TCP Illinois congestion control.
+ * Home page:
+ *	http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+ *
+ * The algorithm is described in:
+ * "TCP-Illinois: A Loss and Delay-Based Congestion Control Algorithm
+ *  for High-Speed Networks"
+ *  http://www.ews.uiuc.edu/~shaoliu/papersandslides/tcpillinois_10pages.pdf
+ *
+ * This implementation uses same constants as the ns-2 simulation.
+ */
+
+#include <linux/module.h>
+#include <net/tcp.h>
+#include <linux/skbuff.h>
+#include <linux/inet_diag.h>
+
+#define ALPHA_SHIFT	7
+#define ALPHA_SCALE	(1u<<ALPHA_SHIFT)
+#define ALPHA_MIN	(ALPHA_SCALE/10)
+#define ALPHA_MAX	(10*ALPHA_SCALE)
+#define ALPHA_BASE	ALPHA_SCALE		/* 1.0 */
+
+#define BETA_SHIFT	6
+#define BETA_SCALE	(1u<<BETA_SHIFT)
+#define BETA_MIN	(BETA_SCALE/8)
+#define BETA_MAX	(BETA_SCALE/2)
+#define BETA_BASE	BETA_MAX		/* 0.5 */
+
+static int win_thresh __read_mostly = 10;
+module_param(win_thresh, int, 0644);
+MODULE_PARM_DESC(win_thresh, "Window threshold for starting adaptive sizing");
+
+/* TCP Illinois Parameters */
+struct tcp_illinois {
+	u32	min_rtt;
+	u32	max_rtt;
+	u32	avg_rtt;
+};
+
+static void tcp_illinois_init(struct sock *sk)
+{
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	ca->min_rtt = 0x7fffffff;
+}
+
+/*
+ * Keep track of min, max and average RTT
+ *
+ * In the paper, it implies that they want average of RTT over
+ * last window of packets. Doing that exactly would require too much
+ * memory (W samples). So we use a sliding average.
+ */
+static void tcp_illinois_rtt_calc(struct sock *sk, u32 rtt)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	/* Compute sliding average over last N packets */
+	ca->avg_rtt = (ca->avg_rtt * (tp->snd_cwnd-1) + rtt) / tp->snd_cwnd;
+
+	if (rtt < ca->min_rtt)
+		ca->min_rtt = rtt;
+
+	if (rtt > ca->max_rtt)
+		ca->max_rtt = rtt;
+}
+
+/*
+ * Compute value of alpha used for additive increase.
+ * If small window then use 1.0, equivalent to Reno.
+ *
+ * For larger windows, adjust based on average delay.
+ * A. If average delay is at mininum (we are uncongested),
+ *    then use large alpha (10.0) to increase faster.
+ * B. If average delay is at maximum (getting congested)
+ *    then use small alpha (1.0)
+ *
+ * Given dm is max delay, and da is average delay
+ * and we assume d1 as zero.
+ *
+ *      dm * αmin * αmax
+ * κ1 = ---------------------
+ *       αmax − αmin
+ *                        
+ *       dm * αmin
+ * κ2 = ------------
+ *	 αmax − αmin
+ *
+ *       κ1
+ * α = --------
+ *     κ2 + da
+ *
+ * The result is a convex window growth curve.
+ * 
+ * Scaling notes:  value (scaled) [bits]
+ * 	ALPHA_MAX = 10.0 (1280) [11]
+ *	ALPHA_MIN = ~0.1 (12)  [4]
+ * 	delay max = 2 * 10^6 [21]
+ */
+static inline u32 alpha(const struct sock *sk)
+{
+	const struct tcp_sock *tp = tcp_sk(sk);
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm, k2;
+	u64 k1;
+
+	if (tp->snd_cwnd < win_thresh)
+		return ALPHA_BASE;	/* same as Reno (1.0) */
+
+	dm = ca->max_rtt - ca->min_rtt;
+	k1 = (u64) dm * (u64)(ALPHA_MAX * ALPHA_MIN);
+	k2 = dm * ALPHA_MIN;
+	k2 += (ca->avg_rtt - ca->min_rtt) * (ALPHA_MAX - ALPHA_MIN);
+
+	do_div(k1, k2);
+
+	return k1;
+}
+
+/*
+ * Increase window in response to successful acknowledgment.
+ */
+static void tcp_illinois_cong_avoid(struct sock *sk, u32 ack, u32 rtt,
+				    u32 in_flight, int flag)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* RFC2861 only increase cwnd if fully utilized */
+	if (!tcp_is_cwnd_limited(sk, in_flight))
+		return;
+
+	/* In slow start */
+	if (tp->snd_cwnd <= tp->snd_ssthresh)
+		tcp_slow_start(tp);
+
+	else {
+		/* additive increase  cwnd += alpha / cwnd */
+		if ((tp->snd_cwnd_cnt * alpha(sk)) >> ALPHA_SHIFT >= tp->snd_cwnd) {
+			if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+				tp->snd_cwnd++;
+			tp->snd_cwnd_cnt = 0;
+		} else
+			tp->snd_cwnd_cnt++;
+	}
+}
+
+/*
+ * Beta used for multiplicative decrease.
+ * For small window sizes returns same value as Reno (0.5)
+ * 
+ * If delay is small (10% of max) then beta = 1/8
+ * If delay is up to 80% of max then beta = 1/2
+ * In between is a linear function
+ */
+static inline u32 beta(const struct sock *sk)
+{
+	const struct tcp_sock *tp = tcp_sk(sk);
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm, d2, d3, da;
+
+	if (tp->snd_cwnd < win_thresh)
+		return BETA_BASE;
+
+	/* max delay (ie most congested) */
+	dm = ca->max_rtt - ca->min_rtt;
+	/* average delay */
+	da = ca->avg_rtt - ca->min_rtt;
+
+	d2 = dm / 10;
+	if (da < d2)
+		return BETA_MIN;
+	d3 = (8 * dm) / 10;
+	if (da > d3)
+		return BETA_MAX;
+
+	return ((BETA_MIN * d3 - BETA_MAX * d2) + BETA_MAX - BETA_MIN) /
+		max(d3 - d2, 1U);
+
+}
+
+static u32 tcp_illinois_ssthresh(struct sock *sk)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* Multiplicative decrease */
+	return max((tp->snd_cwnd * beta(sk)) >> BETA_SHIFT, 2U);
+}
+
+/* Extract info for Tcp socket info provided via netlink. 
+ * We aren't really doing Vegas, but we can provide RTT info
+ */
+static void tcp_illinois_get_info(struct sock *sk, u32 ext,
+			       struct sk_buff *skb)
+{
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	if (ext & (1 << (INET_DIAG_VEGASINFO - 1))) {
+		struct tcpvegas_info info = {
+			.tcpv_enabled = 1,
+			.tcpv_rtt = ca->avg_rtt,
+			.tcpv_minrtt = ca->min_rtt,
+		};
+
+		nla_put(skb, INET_DIAG_VEGASINFO, sizeof(info), &info);
+	}
+}
+
+static struct tcp_congestion_ops tcp_illinois = {
+	.init		= tcp_illinois_init,
+	.ssthresh	= tcp_illinois_ssthresh,
+	.min_cwnd	= tcp_reno_min_cwnd,
+	.cong_avoid	= tcp_illinois_cong_avoid,
+	.rtt_sample	= tcp_illinois_rtt_calc,
+	.get_info	= tcp_illinois_get_info,
+
+	.owner		= THIS_MODULE,
+	.name		= "illinois",
+};
+
+static int __init tcp_illinois_register(void)
+{
+	return tcp_register_congestion_control(&tcp_illinois);
+}
+
+static void __exit tcp_illinois_unregister(void)
+{
+	tcp_unregister_congestion_control(&tcp_illinois);
+}
+
+module_init(tcp_illinois_register);
+module_exit(tcp_illinois_unregister);
+
+MODULE_AUTHOR("Stephen Hemminger, Shao Liu");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Illinois TCP");
-- 
1.5.0.5

Re: [RFC] TCP Illinois preliminary version

[David Miller]

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon, 2 Apr 2007 20:15:25 -0700

> Preliminary version if TCP Illinois for 2.6.22.
> It needs more testing and refinement but it captures the
> basic concepts.

No objections from me and I don't see any obvious problems.

Would you like me to stuff this into net-2.6.22 now so that
it can get some more exposure and people banging on it or
would you like me to wait a bit?

Thanks.

Re: [RFC] TCP Illinois preliminary version

[Stephen Hemminger]

On Mon, 02 Apr 2007 20:39:37 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Mon, 2 Apr 2007 20:15:25 -0700
> 
> > Preliminary version if TCP Illinois for 2.6.22.
> > It needs more testing and refinement but it captures the
> > basic concepts.
> 
> No objections from me and I don't see any obvious problems.
> 
> Would you like me to stuff this into net-2.6.22 now so that
> it can get some more exposure and people banging on it or
> would you like me to wait a bit?
> 
> Thanks.

I would like one of the originators to check the math. 

In case you are worried, I received assurance from Shao Liu that they decided
not to pursue patent and doing a Linux version was okay.

RE: [RFC] TCP Illinois preliminary version

[Julian Shao Liu]

Hi, Stephen, David 

Yes, you can go ahead to implement it in Linux. We are glad to see that
TCP-Illinois gets more exposure by this way.


Best regards!
 
Yours sincerely,
Shao Liu (Julian)
 
University of Illinois at Urbana Champaign
Coordinated Science Laboratory and Department of Electrical and Computer
Engineering
www.ews.uiuc.edu/~shaoliu

-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@linux-foundation.org] 
Sent: Monday, April 02, 2007 10:45 PM
To: David Miller
Cc: shaoliu@uiuc.edu; chaitanya_tk@tamu.edu; jgarrison@tamu.edu;
srikant@ifp.uiuc.edu; tbasar@control.csl.uiuc.edu; jheffner@psc.edu;
netdev@vger.kernel.org
Subject: Re: [RFC] TCP Illinois preliminary version

On Mon, 02 Apr 2007 20:39:37 -0700 (PDT) David Miller <davem@davemloft.net>
wrote:

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Mon, 2 Apr 2007 20:15:25 -0700
> 
> > Preliminary version if TCP Illinois for 2.6.22.
> > It needs more testing and refinement but it captures the basic 
> > concepts.
> 
> No objections from me and I don't see any obvious problems.
> 
> Would you like me to stuff this into net-2.6.22 now so that it can get 
> some more exposure and people banging on it or would you like me to 
> wait a bit?
> 
> Thanks.

I would like one of the originators to check the math. 

In case you are worried, I received assurance from Shao Liu that they
decided not to pursue patent and doing a Linux version was okay.

RE: [RFC] TCP Illinois preliminary version

[Julian Shao Liu]

HI Stephen,

Do you wish me to check the modified code of the implementation in your
first email yesterday? I have noticed the modification and have not had a
chance to check that. I can check it tonight. 

BTW, are all the changes in that first email?

Best regards!
 
Yours sincerely,
Shao Liu (Julian)
 
University of Illinois at Urbana Champaign
Coordinated Science Laboratory and Department of Electrical and Computer
Engineering
www.ews.uiuc.edu/~shaoliu

-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@linux-foundation.org] 
Sent: Monday, April 02, 2007 10:45 PM
To: David Miller
Cc: shaoliu@uiuc.edu; chaitanya_tk@tamu.edu; jgarrison@tamu.edu;
srikant@ifp.uiuc.edu; tbasar@control.csl.uiuc.edu; jheffner@psc.edu;
netdev@vger.kernel.org
Subject: Re: [RFC] TCP Illinois preliminary version

On Mon, 02 Apr 2007 20:39:37 -0700 (PDT) David Miller <davem@davemloft.net>
wrote:

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Mon, 2 Apr 2007 20:15:25 -0700
> 
> > Preliminary version if TCP Illinois for 2.6.22.
> > It needs more testing and refinement but it captures the basic 
> > concepts.
> 
> No objections from me and I don't see any obvious problems.
> 
> Would you like me to stuff this into net-2.6.22 now so that it can get 
> some more exposure and people banging on it or would you like me to 
> wait a bit?
> 
> Thanks.

I would like one of the originators to check the math. 

In case you are worried, I received assurance from Shao Liu that they
decided not to pursue patent and doing a Linux version was okay.

[PATCH] TCP Illinois congestion control

[Stephen Hemminger]

This is a new implementation of TCP Illinois invented by Shao Liu
at University of Illinois. It is a another variant of Reno which adapts
the alpha and beta parameters based on RTT. The basic idea is to increase
window less rapidly as delay approaches the maximum. See the papers
and talks to get a more complete description.

Please consider for 2.6.22.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
---
 net/ipv4/Kconfig        |   13 +++
 net/ipv4/Makefile       |    1 +
 net/ipv4/tcp_illinois.c |  212 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 226 insertions(+), 0 deletions(-)
 create mode 100644 net/ipv4/tcp_illinois.c

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index dc61e66..e62aee0 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -588,6 +588,19 @@ config TCP_CONG_YEAH
 	For further details look here:
 	  http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
 
+config TCP_CONG_ILLINOIS
+	tristate "TCP Illinois"
+	depends on EXPERIMENTAL
+	default n
+	---help---
+	TCP-Illinois is a sender-side modificatio of TCP Reno for
+	high speed long delay links. It uses round-trip-time to
+	adjust the alpha and beta parameters to achieve a higher average
+	throughput and maintain fairness.
+
+	For further details see:
+	  http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+
 choice
 	prompt "Default TCP congestion control"
 	default DEFAULT_CUBIC
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index eeb94d5..4ff6c15 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
 obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
 obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
 obj-$(CONFIG_TCP_CONG_YEAH) += tcp_yeah.o
+obj-$(CONFIG_TCP_CONG_ILLINOIS) += tcp_illinois.o
 obj-$(CONFIG_NETLABEL) += cipso_ipv4.o
 
 obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
diff --git a/net/ipv4/tcp_illinois.c b/net/ipv4/tcp_illinois.c
new file mode 100644
index 0000000..f7c0b76
--- /dev/null
+++ b/net/ipv4/tcp_illinois.c
@@ -0,0 +1,212 @@
+/*
+ * TCP Illinois congestion control.
+ * Home page:
+ *	http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+ *
+ * The algorithm is described in:
+ * "TCP-Illinois: A Loss and Delay-Based Congestion Control Algorithm
+ *  for High-Speed Networks"
+ *  http://www.ews.uiuc.edu/~shaoliu/papersandslides/tcpillinois_10pages.pdf
+ *
+ * Implemented from description in paper and ns-2 simulation.
+ * Copyright (C) 2007 Stephen Hemminger <shemminger@linux-foundation.org>
+ */
+
+#include <linux/module.h>
+#include <net/tcp.h>
+#include <linux/skbuff.h>
+#include <linux/inet_diag.h>
+
+#define ALPHA_SHIFT	7
+#define ALPHA_SCALE	(1u<<ALPHA_SHIFT)
+#define ALPHA_MIN	(ALPHA_SCALE/10)
+#define ALPHA_MAX	(10*ALPHA_SCALE)
+#define ALPHA_BASE	ALPHA_SCALE		/* 1.0 */
+
+#define BETA_SHIFT	6
+#define BETA_SCALE	(1u<<BETA_SHIFT)
+#define BETA_MIN	(BETA_SCALE/8)
+#define BETA_MAX	(BETA_SCALE/2)
+#define BETA_BASE	BETA_MAX		/* 0.5 */
+
+static int win_thresh __read_mostly = 15;
+module_param(win_thresh, int, 0644);
+MODULE_PARM_DESC(win_thresh, "Window threshold for starting adaptive sizing");
+
+/* TCP Illinois Parameters */
+struct tcp_illinois {
+	u32	min_rtt;
+	u32	max_rtt;
+	u32	avg_rtt;
+};
+
+static void tcp_illinois_init(struct sock *sk)
+{
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	ca->min_rtt = 0x7fffffff;
+}
+
+/*
+ * Keep track of min, max and average RTT
+ *
+ * In the paper, it implies that they want average of RTT over
+ * last window of packets. Doing that exactly would require too much
+ * memory (W samples). So we use a sliding average.
+ */
+static void tcp_illinois_rtt_calc(struct sock *sk, u32 rtt)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	/* Compute sliding average over last N packets */
+	ca->avg_rtt = (ca->avg_rtt * (tp->snd_cwnd-1) + rtt) / tp->snd_cwnd;
+
+	if (rtt < ca->min_rtt)
+		ca->min_rtt = rtt;
+
+	if (rtt > ca->max_rtt)
+		ca->max_rtt = rtt;
+}
+
+/*
+ * Compute value of alpha used for additive increase.
+ * If small window then use 1.0, equivalent to Reno.
+ *
+ * For larger windows, adjust based on average delay.
+ * A. If average delay is at minimum (we are uncongested),
+ *    then use large alpha (10.0) to increase faster.
+ * B. If average delay is at maximum (getting congested)
+ *    then use small alpha (1.0)
+ *
+ * The result is a convex window growth curve.
+ */
+static inline u32 alpha(const struct sock *sk)
+{
+	const struct tcp_sock *tp = tcp_sk(sk);
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm, da;
+
+	if (tp->snd_cwnd < win_thresh)
+		return ALPHA_BASE;	/* same as Reno (1.0) */
+
+	dm = ca->max_rtt - ca->min_rtt;	/* max queuing delay */
+	da = ca->avg_rtt - ca->min_rtt; /* avg queuing delay */
+
+	return (dm * ALPHA_MAX) /
+		(dm - (da  * (ALPHA_MAX - ALPHA_MIN)) / ALPHA_MIN);
+}
+
+/*
+ * Increase window in response to successful acknowledgment.
+ */
+static void tcp_illinois_cong_avoid(struct sock *sk, u32 ack, u32 rtt,
+				    u32 in_flight, int flag)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* RFC2861 only increase cwnd if fully utilized */
+	if (!tcp_is_cwnd_limited(sk, in_flight))
+		return;
+
+	/* In slow start */
+	if (tp->snd_cwnd <= tp->snd_ssthresh)
+		tcp_slow_start(tp);
+
+	else {
+		/* additive increase  cwnd += alpha / cwnd */
+		if ((tp->snd_cwnd_cnt * alpha(sk)) >> ALPHA_SHIFT >= tp->snd_cwnd) {
+			if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+				tp->snd_cwnd++;
+			tp->snd_cwnd_cnt = 0;
+		} else
+			tp->snd_cwnd_cnt++;
+	}
+}
+
+/*
+ * Beta used for multiplicative decrease.
+ * For small window sizes returns same value as Reno (0.5)
+ * 
+ * If delay is small (10% of max) then beta = 1/8
+ * If delay is up to 80% of max then beta = 1/2
+ * In between is a linear function
+ */
+static inline u32 beta(const struct sock *sk)
+{
+	const struct tcp_sock *tp = tcp_sk(sk);
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm, d2, d3, da;
+
+	if (tp->snd_cwnd < win_thresh)
+		return BETA_BASE;
+
+	dm = ca->max_rtt - ca->min_rtt;
+	da = ca->avg_rtt - ca->min_rtt;
+
+	d2 = dm / 10;
+	if (da <= d2)
+		return BETA_MIN;
+	d3 = (8 * dm) / 10;
+	if (da >= d3 || d3 <= d2)
+		return BETA_MAX;
+
+	return (BETA_MIN * d3 - BETA_MAX * d2 + (BETA_MAX - BETA_MIN) * da)
+		/ (d3 - d2);
+}
+
+static u32 tcp_illinois_ssthresh(struct sock *sk)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* Multiplicative decrease */
+	return max((tp->snd_cwnd * beta(sk)) >> BETA_SHIFT, 2U);
+}
+
+/* Extract info for TCP socket info provided via netlink. 
+ * We aren't really doing Vegas, but we can provide RTT info
+ */
+static void tcp_illinois_get_info(struct sock *sk, u32 ext,
+			       struct sk_buff *skb)
+{
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	if (ext & (1 << (INET_DIAG_VEGASINFO - 1))) {
+		struct tcpvegas_info info = {
+			.tcpv_enabled = 1,
+			.tcpv_rtt = ca->avg_rtt,
+			.tcpv_minrtt = ca->min_rtt,
+		};
+
+		nla_put(skb, INET_DIAG_VEGASINFO, sizeof(info), &info);
+	}
+}
+
+static struct tcp_congestion_ops tcp_illinois = {
+	.init		= tcp_illinois_init,
+	.ssthresh	= tcp_illinois_ssthresh,
+	.min_cwnd	= tcp_reno_min_cwnd,
+	.cong_avoid	= tcp_illinois_cong_avoid,
+	.rtt_sample	= tcp_illinois_rtt_calc,
+	.get_info	= tcp_illinois_get_info,
+
+	.owner		= THIS_MODULE,
+	.name		= "illinois",
+};
+
+static int __init tcp_illinois_register(void)
+{
+	return tcp_register_congestion_control(&tcp_illinois);
+}
+
+static void __exit tcp_illinois_unregister(void)
+{
+	tcp_unregister_congestion_control(&tcp_illinois);
+}
+
+module_init(tcp_illinois_register);
+module_exit(tcp_illinois_unregister);
+
+MODULE_AUTHOR("Stephen Hemminger, Shao Liu");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Illinois TCP");
-- 
1.5.0.5

RE: [PATCH] TCP Illinois congestion control

[Julian Shao Liu]

Hi Stephen,

Thanks for the implementation. I have checked the codes, and I have the
following comments:

1, The math is basically correct in computing alpha and beta from da.

2, In the computation of da, you implicitly set d1=0. Setting d1=0 is a
conservative approach, although it also works well (it may lead to a longer
convergence time than a positive d1). The reason is that, even if far from
congestion, there are some burstiness in RTT measurements, and we get
da>d_min. This way, we have an alpha<alpha_max even if congestion is far
away. We choose d1 to be close to 0 in our simulations for conservativeness,
but we believe even if d1 is non-trivial positive, like 0.05*dm, it should
work, and it might work better.

3, There is one more feature in TCP-Illinois: to avoid setting alpha to be
alpha_max if actually the congestion level is high and the small queueing
delay is due to noise. We have explained that in our updated version of the
paper, available at 
http://www.ews.uiuc.edu/~shaoliu/papersandslides/liubassri06perf.pdf
We have also implemented this feature in our ns-2 code. The basic idea of
this feature is that, once da exceeds d1 and alpha<alpha_max, we know that
congestion level is not very low. Once this happen, the congestion level
should not drop unless some user has experienced a packet loss and backed
off its window size. If that is the case, da should drop to below d1 for a
long time. If, however, da drops to below d1 suddenly, but increases back to
above d1 soon, we predict that congestion is not alleviated, and the small
da measurement comes from noise. Under this case, we should not set
alpha=alpha_max, but should set it to be its previous legitimate value.

We believe that this feature is important if there is noise in delay
measurement and if d1 is set to be nonzero. Even if d1 is set to be zero, we
think this feature should be included if the noise is delay measurement is
significant. Under this case, we can modify the feature a little bit: alpha
is initially computed to be around alpha_max when congestion is far. As da
increases, alpha decreases. But alpha cannot be increased as soon as da
drops. Alpha can only be increased if the decrease trend of da last for a
certain period.

4, In your implementation, you set alpha_max=10 and alpha_min=0.1. Although
this parameter setting is chosen by our paper, we suggest you try some
different values, especially for alpha_min. An alpha_min from 0.2 to 0.5
might be a better choice, as this will make the convergence time faster.

Please feel free to tell me if you have any related questions.

Thanks!

Best regards!
 
Yours sincerely,
Shao Liu (Julian)
 
University of Illinois at Urbana Champaign
Coordinated Science Laboratory and Department of Electrical and Computer
Engineering
www.ews.uiuc.edu/~shaoliu

-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@linux-foundation.org] 
Sent: Tuesday, April 03, 2007 11:17 AM
To: David Miller
Cc: shaoliu@uiuc.edu; chaitanya_tk@tamu.edu; jgarrison@tamu.edu;
srikant@ifp.uiuc.edu; tbasar@control.csl.uiuc.edu; jheffner@psc.edu;
netdev@vger.kernel.org
Subject: [PATCH] TCP Illinois congestion control

This is a new implementation of TCP Illinois invented by Shao Liu at
University of Illinois. It is a another variant of Reno which adapts the
alpha and beta parameters based on RTT. The basic idea is to increase window
less rapidly as delay approaches the maximum. See the papers and talks to
get a more complete description.

Please consider for 2.6.22.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
---
 net/ipv4/Kconfig        |   13 +++
 net/ipv4/Makefile       |    1 +
 net/ipv4/tcp_illinois.c |  212
+++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 226 insertions(+), 0 deletions(-)  create mode 100644
net/ipv4/tcp_illinois.c

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig index dc61e66..e62aee0
100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -588,6 +588,19 @@ config TCP_CONG_YEAH
 	For further details look here:
 	  http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
 
+config TCP_CONG_ILLINOIS
+	tristate "TCP Illinois"
+	depends on EXPERIMENTAL
+	default n
+	---help---
+	TCP-Illinois is a sender-side modificatio of TCP Reno for
+	high speed long delay links. It uses round-trip-time to
+	adjust the alpha and beta parameters to achieve a higher average
+	throughput and maintain fairness.
+
+	For further details see:
+	  http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+
 choice
 	prompt "Default TCP congestion control"
 	default DEFAULT_CUBIC
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile index eeb94d5..4ff6c15
100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
 obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
 obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
 obj-$(CONFIG_TCP_CONG_YEAH) += tcp_yeah.o
+obj-$(CONFIG_TCP_CONG_ILLINOIS) += tcp_illinois.o
 obj-$(CONFIG_NETLABEL) += cipso_ipv4.o
 
 obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ diff
--git a/net/ipv4/tcp_illinois.c b/net/ipv4/tcp_illinois.c new file mode
100644 index 0000000..f7c0b76
--- /dev/null
+++ b/net/ipv4/tcp_illinois.c
@@ -0,0 +1,212 @@
+/*
+ * TCP Illinois congestion control.
+ * Home page:
+ *	http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+ *
+ * The algorithm is described in:
+ * "TCP-Illinois: A Loss and Delay-Based Congestion Control Algorithm
+ *  for High-Speed Networks"
+ *  
+http://www.ews.uiuc.edu/~shaoliu/papersandslides/tcpillinois_10pages.pd
+f
+ *
+ * Implemented from description in paper and ns-2 simulation.
+ * Copyright (C) 2007 Stephen Hemminger 
+<shemminger@linux-foundation.org>  */
+
+#include <linux/module.h>
+#include <net/tcp.h>
+#include <linux/skbuff.h>
+#include <linux/inet_diag.h>
+
+#define ALPHA_SHIFT	7
+#define ALPHA_SCALE	(1u<<ALPHA_SHIFT)
+#define ALPHA_MIN	(ALPHA_SCALE/10)
+#define ALPHA_MAX	(10*ALPHA_SCALE)
+#define ALPHA_BASE	ALPHA_SCALE		/* 1.0 */
+
+#define BETA_SHIFT	6
+#define BETA_SCALE	(1u<<BETA_SHIFT)
+#define BETA_MIN	(BETA_SCALE/8)
+#define BETA_MAX	(BETA_SCALE/2)
+#define BETA_BASE	BETA_MAX		/* 0.5 */
+
+static int win_thresh __read_mostly = 15; module_param(win_thresh, int, 
+0644); MODULE_PARM_DESC(win_thresh, "Window threshold for starting 
+adaptive sizing");
+
+/* TCP Illinois Parameters */
+struct tcp_illinois {
+	u32	min_rtt;
+	u32	max_rtt;
+	u32	avg_rtt;
+};
+
+static void tcp_illinois_init(struct sock *sk) {
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	ca->min_rtt = 0x7fffffff;
+}
+
+/*
+ * Keep track of min, max and average RTT
+ *
+ * In the paper, it implies that they want average of RTT over
+ * last window of packets. Doing that exactly would require too much
+ * memory (W samples). So we use a sliding average.
+ */
+static void tcp_illinois_rtt_calc(struct sock *sk, u32 rtt) {
+	struct tcp_sock *tp = tcp_sk(sk);
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	/* Compute sliding average over last N packets */
+	ca->avg_rtt = (ca->avg_rtt * (tp->snd_cwnd-1) + rtt) / tp->snd_cwnd;
+
+	if (rtt < ca->min_rtt)
+		ca->min_rtt = rtt;
+
+	if (rtt > ca->max_rtt)
+		ca->max_rtt = rtt;
+}
+
+/*
+ * Compute value of alpha used for additive increase.
+ * If small window then use 1.0, equivalent to Reno.
+ *
+ * For larger windows, adjust based on average delay.
+ * A. If average delay is at minimum (we are uncongested),
+ *    then use large alpha (10.0) to increase faster.
+ * B. If average delay is at maximum (getting congested)
+ *    then use small alpha (1.0)
+ *
+ * The result is a convex window growth curve.
+ */
+static inline u32 alpha(const struct sock *sk) {
+	const struct tcp_sock *tp = tcp_sk(sk);
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm, da;
+
+	if (tp->snd_cwnd < win_thresh)
+		return ALPHA_BASE;	/* same as Reno (1.0) */
+
+	dm = ca->max_rtt - ca->min_rtt;	/* max queuing delay */
+	da = ca->avg_rtt - ca->min_rtt; /* avg queuing delay */
+
+	return (dm * ALPHA_MAX) /
+		(dm - (da  * (ALPHA_MAX - ALPHA_MIN)) / ALPHA_MIN); }
+
+/*
+ * Increase window in response to successful acknowledgment.
+ */
+static void tcp_illinois_cong_avoid(struct sock *sk, u32 ack, u32 rtt,
+				    u32 in_flight, int flag)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* RFC2861 only increase cwnd if fully utilized */
+	if (!tcp_is_cwnd_limited(sk, in_flight))
+		return;
+
+	/* In slow start */
+	if (tp->snd_cwnd <= tp->snd_ssthresh)
+		tcp_slow_start(tp);
+
+	else {
+		/* additive increase  cwnd += alpha / cwnd */
+		if ((tp->snd_cwnd_cnt * alpha(sk)) >> ALPHA_SHIFT >=
tp->snd_cwnd) {
+			if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+				tp->snd_cwnd++;
+			tp->snd_cwnd_cnt = 0;
+		} else
+			tp->snd_cwnd_cnt++;
+	}
+}
+
+/*
+ * Beta used for multiplicative decrease.
+ * For small window sizes returns same value as Reno (0.5)
+ *
+ * If delay is small (10% of max) then beta = 1/8
+ * If delay is up to 80% of max then beta = 1/2
+ * In between is a linear function
+ */
+static inline u32 beta(const struct sock *sk) {
+	const struct tcp_sock *tp = tcp_sk(sk);
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm, d2, d3, da;
+
+	if (tp->snd_cwnd < win_thresh)
+		return BETA_BASE;
+
+	dm = ca->max_rtt - ca->min_rtt;
+	da = ca->avg_rtt - ca->min_rtt;
+
+	d2 = dm / 10;
+	if (da <= d2)
+		return BETA_MIN;
+	d3 = (8 * dm) / 10;
+	if (da >= d3 || d3 <= d2)
+		return BETA_MAX;
+
+	return (BETA_MIN * d3 - BETA_MAX * d2 + (BETA_MAX - BETA_MIN) * da)
+		/ (d3 - d2);
+}
+
+static u32 tcp_illinois_ssthresh(struct sock *sk) {
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* Multiplicative decrease */
+	return max((tp->snd_cwnd * beta(sk)) >> BETA_SHIFT, 2U); }
+
+/* Extract info for TCP socket info provided via netlink. 
+ * We aren't really doing Vegas, but we can provide RTT info  */ static 
+void tcp_illinois_get_info(struct sock *sk, u32 ext,
+			       struct sk_buff *skb)
+{
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	if (ext & (1 << (INET_DIAG_VEGASINFO - 1))) {
+		struct tcpvegas_info info = {
+			.tcpv_enabled = 1,
+			.tcpv_rtt = ca->avg_rtt,
+			.tcpv_minrtt = ca->min_rtt,
+		};
+
+		nla_put(skb, INET_DIAG_VEGASINFO, sizeof(info), &info);
+	}
+}
+
+static struct tcp_congestion_ops tcp_illinois = {
+	.init		= tcp_illinois_init,
+	.ssthresh	= tcp_illinois_ssthresh,
+	.min_cwnd	= tcp_reno_min_cwnd,
+	.cong_avoid	= tcp_illinois_cong_avoid,
+	.rtt_sample	= tcp_illinois_rtt_calc,
+	.get_info	= tcp_illinois_get_info,
+
+	.owner		= THIS_MODULE,
+	.name		= "illinois",
+};
+
+static int __init tcp_illinois_register(void) {
+	return tcp_register_congestion_control(&tcp_illinois);
+}
+
+static void __exit tcp_illinois_unregister(void) {
+	tcp_unregister_congestion_control(&tcp_illinois);
+}
+
+module_init(tcp_illinois_register);
+module_exit(tcp_illinois_unregister);
+
+MODULE_AUTHOR("Stephen Hemminger, Shao Liu"); MODULE_LICENSE("GPL"); 
+MODULE_DESCRIPTION("Illinois TCP");
--
1.5.0.5

[PATCH] TCP Illinois congestion control (rev3)

[Stephen Hemminger]

This is an implementation of TCP Illinois invented by Shao Liu
at University of Illinois. It is a another variant of Reno which adapts
the alpha and beta parameters based on RTT. The basic idea is to increase
window less rapidly as delay approaches the maximum. See the papers
and talks to get a more complete description.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
---
 net/ipv4/Kconfig        |   13 ++
 net/ipv4/Makefile       |    1 +
 net/ipv4/tcp_illinois.c |  284 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 298 insertions(+), 0 deletions(-)
 create mode 100644 net/ipv4/tcp_illinois.c

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index dc61e66..e62aee0 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -588,6 +588,19 @@ config TCP_CONG_YEAH
 	For further details look here:
 	  http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
 
+config TCP_CONG_ILLINOIS
+	tristate "TCP Illinois"
+	depends on EXPERIMENTAL
+	default n
+	---help---
+	TCP-Illinois is a sender-side modificatio of TCP Reno for
+	high speed long delay links. It uses round-trip-time to
+	adjust the alpha and beta parameters to achieve a higher average
+	throughput and maintain fairness.
+
+	For further details see:
+	  http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+
 choice
 	prompt "Default TCP congestion control"
 	default DEFAULT_CUBIC
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index eeb94d5..4ff6c15 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
 obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
 obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
 obj-$(CONFIG_TCP_CONG_YEAH) += tcp_yeah.o
+obj-$(CONFIG_TCP_CONG_ILLINOIS) += tcp_illinois.o
 obj-$(CONFIG_NETLABEL) += cipso_ipv4.o
 
 obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
diff --git a/net/ipv4/tcp_illinois.c b/net/ipv4/tcp_illinois.c
new file mode 100644
index 0000000..1990ff2
--- /dev/null
+++ b/net/ipv4/tcp_illinois.c
@@ -0,0 +1,284 @@
+/*
+ * TCP Illinois congestion control.
+ * Home page:
+ *	http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+ *
+ * The algorithm is described in:
+ * "TCP-Illinois: A Loss and Delay-Based Congestion Control Algorithm
+ *  for High-Speed Networks"
+ * http://www.ews.uiuc.edu/~shaoliu/papersandslides/liubassri06perf.pdf
+ *
+ * Implemented from description in paper and ns-2 simulation.
+ * Copyright (C) 2007 Stephen Hemminger <shemminger@linux-foundation.org>
+ */
+
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/inet_diag.h>
+#include <asm/div64.h>
+#include <net/tcp.h>
+
+#define ALPHA_SHIFT	7
+#define ALPHA_SCALE	(1u<<ALPHA_SHIFT)
+#define ALPHA_MIN	((3*ALPHA_SCALE)/10)	/* ~0.3 */
+#define ALPHA_MAX	(10*ALPHA_SCALE)	/* 10.0 */
+#define ALPHA_BASE	ALPHA_SCALE		/* 1.0 */
+
+#define BETA_SHIFT	6
+#define BETA_SCALE	(1u<<BETA_SHIFT)
+#define BETA_MIN	(BETA_SCALE/8)		/* 0.8 */
+#define BETA_MAX	(BETA_SCALE/2)
+#define BETA_BASE	BETA_MAX		/* 0.5 */
+
+#define THETA		5
+
+static int win_thresh __read_mostly = 15;
+module_param(win_thresh, int, 0644);
+MODULE_PARM_DESC(win_thresh, "Window threshold for starting adaptive sizing");
+
+#define MAX_RTT		0x7fffffff
+
+/* TCP Illinois Parameters */
+struct tcp_illinois {
+	u32	last_alpha;
+	u32	min_rtt;
+	u32	max_rtt;
+	u32	rtt_low;
+	u32	rtt_cnt;
+	u64	sum_rtt;
+};
+
+static void tcp_illinois_init(struct sock *sk)
+{
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	ca->last_alpha = ALPHA_BASE;
+	ca->min_rtt = 0x7fffffff;
+}
+
+/*
+ * Keep track of min, max and average RTT
+ */
+static void tcp_illinois_rtt_calc(struct sock *sk, u32 rtt)
+{
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	if (rtt < ca->min_rtt)
+		ca->min_rtt = rtt;
+	if (rtt > ca->max_rtt)
+		ca->max_rtt = rtt;
+
+	if (++ca->rtt_cnt == 1)
+		ca->sum_rtt = rtt;
+	else
+		ca->sum_rtt += rtt;
+}
+
+/* max queuing delay */
+static inline u32 max_delay(const struct tcp_illinois *ca)
+{
+	return ca->max_rtt - ca->min_rtt;
+}
+
+/* average queueing delay */
+static u32 avg_delay(struct tcp_illinois *ca)
+{
+	u64 avg_rtt = ca->sum_rtt;
+
+	do_div(avg_rtt, ca->rtt_cnt);
+
+	ca->sum_rtt = 0;
+	ca->rtt_cnt = 0;
+
+	return avg_rtt - ca->min_rtt;
+}
+
+/*
+ * Compute value of alpha used for additive increase.
+ * If small window then use 1.0, equivalent to Reno.
+ *
+ * For larger windows, adjust based on average delay.
+ * A. If average delay is at minimum (we are uncongested),
+ *    then use large alpha (10.0) to increase faster.
+ * B. If average delay is at maximum (getting congested)
+ *    then use small alpha (1.0)
+ *
+ * The result is a convex window growth curve.
+ */
+static u32 alpha(const struct sock *sk)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm = max_delay(ca);
+	u32 da = avg_delay(ca);
+	u32 d1, a;
+
+	if (tp->snd_cwnd < win_thresh)
+		return ALPHA_BASE;	/* same as Reno (1.0) */
+	
+	d1 = dm / 100;
+	if (da <= d1) {
+		/* Don't let noise force agressive response */
+		if (ca->rtt_low < THETA) {
+			++ca->rtt_low;
+			return ca->last_alpha;
+		} else
+			return ALPHA_MAX;
+	}
+
+	ca->rtt_low = 0;
+
+	/*
+	 * Based on:
+	 *
+	 *      (dm - d1) amin amax
+	 * k1 = -------------------
+	 *         amax - amin
+	 *
+	 *       (dm - d1) amin
+	 * k2 = ----------------  - d1
+	 *        amax - amin
+	 *
+	 *             k1
+	 * alpha = ----------
+	 *          k2 + da
+	 */
+
+	dm -= d1;
+	da -= d1;
+
+	a = (dm * ALPHA_MAX) / (dm - (da  * (ALPHA_MAX - ALPHA_MIN)) / ALPHA_MIN);
+	ca->last_alpha = a;
+	return a;
+}
+
+/*
+ * Increase window in response to successful acknowledgment.
+ */
+static void tcp_illinois_cong_avoid(struct sock *sk, u32 ack, u32 rtt,
+				    u32 in_flight, int flag)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* RFC2861 only increase cwnd if fully utilized */
+	if (!tcp_is_cwnd_limited(sk, in_flight))
+		return;
+
+	/* In slow start */
+	if (tp->snd_cwnd <= tp->snd_ssthresh)
+		tcp_slow_start(tp);
+
+	else {
+		/* additive increase  cwnd += alpha / cwnd */
+		if ((tp->snd_cwnd_cnt * alpha(sk)) >> ALPHA_SHIFT >= tp->snd_cwnd) {
+			if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+				tp->snd_cwnd++;
+			tp->snd_cwnd_cnt = 0;
+		} else
+			tp->snd_cwnd_cnt++;
+	}
+}
+
+/*
+ * Beta used for multiplicative decrease.
+ * For small window sizes returns same value as Reno (0.5)
+ *
+ * If delay is small (10% of max) then beta = 1/8
+ * If delay is up to 80% of max then beta = 1/2
+ * In between is a linear function
+ */
+static inline u32 beta(struct sock *sk)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+	struct tcp_illinois *ca = inet_csk_ca(sk);
+	u32 dm = max_delay(ca);
+	u32 da = avg_delay(ca);
+	u32 d2, d3;
+
+	if (tp->snd_cwnd < win_thresh)
+		return BETA_BASE;
+
+	d2 = dm / 10;
+	if (da <= d2)
+		return BETA_MIN;
+	d3 = (8 * dm) / 10;
+	if (da >= d3 || d3 <= d2)
+		return BETA_MAX;
+
+	/*
+	 * Based on:
+	 *
+	 *       bmin d3 - bmax d2
+	 * k3 = -------------------
+	 *         d3 - d2
+	 *
+	 *       bmax - bmin
+	 * k4 = -------------
+	 *         d3 - d2
+	 *
+	 * b = k3 + k4 da
+	 */
+	return (BETA_MIN * d3 - BETA_MAX * d2 + (BETA_MAX - BETA_MIN) * da)
+		/ (d3 - d2);
+}
+
+static u32 tcp_illinois_ssthresh(struct sock *sk)
+{
+	struct tcp_sock *tp = tcp_sk(sk);
+
+	/* Multiplicative decrease */
+	return max((tp->snd_cwnd * beta(sk)) >> BETA_SHIFT, 2U);
+}
+
+/* Extract info for TCP socket info provided via netlink.
+ * We aren't really doing Vegas, but we can provide RTT info
+ */
+static void tcp_illinois_get_info(struct sock *sk, u32 ext,
+			       struct sk_buff *skb)
+{
+	const struct tcp_illinois *ca = inet_csk_ca(sk);
+
+	if (ext & (1 << (INET_DIAG_VEGASINFO - 1))) {
+		struct tcpvegas_info info = {
+			.tcpv_enabled = 1,
+			.tcpv_rttcnt = ca->rtt_cnt,
+			.tcpv_minrtt = ca->min_rtt,
+		};
+		u64 avg_rtt = ca->sum_rtt;
+		do_div(avg_rtt, ca->rtt_cnt);
+		info.tcpv_rtt = avg_rtt;
+
+		nla_put(skb, INET_DIAG_VEGASINFO, sizeof(info), &info);
+	}
+}
+
+static struct tcp_congestion_ops tcp_illinois = {
+	.init		= tcp_illinois_init,
+	.ssthresh	= tcp_illinois_ssthresh,
+	.min_cwnd	= tcp_reno_min_cwnd,
+	.cong_avoid	= tcp_illinois_cong_avoid,
+	.rtt_sample	= tcp_illinois_rtt_calc,
+	.get_info	= tcp_illinois_get_info,
+
+	.owner		= THIS_MODULE,
+	.name		= "illinois",
+};
+
+static int __init tcp_illinois_register(void)
+{
+	BUILD_BUG_ON(sizeof(struct tcp_illinois) > ICSK_CA_PRIV_SIZE);
+	return tcp_register_congestion_control(&tcp_illinois);
+}
+
+static void __exit tcp_illinois_unregister(void)
+{
+	tcp_unregister_congestion_control(&tcp_illinois);
+}
+
+module_init(tcp_illinois_register);
+module_exit(tcp_illinois_unregister);
+
+MODULE_AUTHOR("Stephen Hemminger, Shao Liu");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("TCP Illinois");
+MODULE_VERSION("0.3");
-- 
1.5.0.6

TCP congestion control for fast, short-distance networks ?

[davef1624]

Hello,

We are currently using both 1 Gb & 10 Gb links, that interconnect 
several servers that are very *local* to each other.
Typical RTT times range from 0.2 ms - 0.3 ms.

We are currently using TCP reno - is there a more suitable congestion 
control algorithm for our application,
especially using the 10 Gb links ?
(Most of the High-Speed TCP algorithms seem suitable for large RTT, 
long-distance networks).

Thanks
David

________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free 
from AOL at AOL.com.

Re: TCP congestion control for fast, short-distance networks ?

[Baruch Even]

* davef1624@aol.com <davef1624@aol.com> [070404 18:29]:
> Hello,
> 
> We are currently using both 1 Gb & 10 Gb links, that interconnect several servers that are very *local* to 
> each other.
> Typical RTT times range from 0.2 ms - 0.3 ms.
> 
> We are currently using TCP reno - is there a more suitable congestion control algorithm for our 
> application,
> especially using the 10 Gb links ?
> (Most of the High-Speed TCP algorithms seem suitable for large RTT, long-distance networks).

I'm not aware of any tests for high speed links with very low RTTs, but
I suspect that the new algorithms will not change much, if the
connections you have are indeed local than the Ethernet pause mechanism
is more effective for the flow control you need.

Baruch

Re: TCP congestion control for fast, short-distance networks ?

[davef1624]

Thanks - so you are suggesting we enable 802.3 flow-control / 
pause-frames?
(it's currently disabled)

-----Original Message-----
From: baruch@ev-en.org
To: davef1624@aol.com
Cc: shemminger@linux-foundation.org; netdev@vger.kernel.org
Sent: Wed, 4 Apr 2007 8:39 AM
Subject: Re: TCP congestion control for fast, short-distance networks ?

  * davef1624@aol.com <davef1624@aol.com> [070404 18:29]:
> Hello,
>
> We are currently using both 1 Gb & 10 Gb links, that interconnect 
several
servers that are very *local* to
> each other.
> Typical RTT times range from 0.2 ms - 0.3 ms.
>
> We are currently using TCP reno - is there a more suitable congestion 
control
algorithm for our
> application,
> especially using the 10 Gb links ?
> (Most of the High-Speed TCP algorithms seem suitable for large RTT,
long-distance networks).

I'm not aware of any tests for high speed links with very low RTTs, but
I suspect that the new algorithms will not change much, if the
connections you have are indeed local than the Ethernet pause mechanism
is more effective for the flow control you need.

Baruch
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free 
from AOL at AOL.com.

Re: TCP congestion control for fast, short-distance networks ?

[Baruch Even]

* davef1624@aol.com <davef1624@aol.com> [070404 19:03]:
> Thanks - so you are suggesting we enable 802.3 flow-control / pause-frames?
> (it's currently disabled)

I do, but do test it before you bet on it. I've never tested such a
scenario but from my experience the lower the rtt the lesser are the
problems that the high speed algorithms are trying to solve.

Baruch

> 
> -----Original Message-----
> From: baruch@ev-en.org
> To: davef1624@aol.com
> Cc: shemminger@linux-foundation.org; netdev@vger.kernel.org
> Sent: Wed, 4 Apr 2007 8:39 AM
> Subject: Re: TCP congestion control for fast, short-distance networks ?
> 
>  * davef1624@aol.com <davef1624@aol.com> [070404 18:29]:
> >Hello,
> >
> >We are currently using both 1 Gb & 10 Gb links, that interconnect 
> several
> servers that are very *local* to
> >each other.
> >Typical RTT times range from 0.2 ms - 0.3 ms.
> >
> >We are currently using TCP reno - is there a more suitable congestion 
> control
> algorithm for our
> >application,
> >especially using the 10 Gb links ?
> >(Most of the High-Speed TCP algorithms seem suitable for large RTT,
> long-distance networks).
> 
> I'm not aware of any tests for high speed links with very low RTTs, but
> I suspect that the new algorithms will not change much, if the
> connections you have are indeed local than the Ethernet pause mechanism
> is more effective for the flow control you need.
> 
> Baruch

Re: TCP congestion control for fast, short-distance networks ?

[Stephen Hemminger]

On Wed, 4 Apr 2007 19:11:21 +0300
Baruch Even <baruch@ev-en.org> wrote:

> * davef1624@aol.com <davef1624@aol.com> [070404 19:03]:
> > Thanks - so you are suggesting we enable 802.3 flow-control / pause-frames?
> > (it's currently disabled)
> 
> I do, but do test it before you bet on it. I've never tested such a
> scenario but from my experience the lower the rtt the lesser are the
> problems that the high speed algorithms are trying to solve.
> 
> Baruch
> 
> > 
> > -----Original Message-----
> > From: baruch@ev-en.org
> > To: davef1624@aol.com
> > Cc: shemminger@linux-foundation.org; netdev@vger.kernel.org
> > Sent: Wed, 4 Apr 2007 8:39 AM
> > Subject: Re: TCP congestion control for fast, short-distance networks ?
> > 
> >  * davef1624@aol.com <davef1624@aol.com> [070404 18:29]:
> > >Hello,
> > >
> > >We are currently using both 1 Gb & 10 Gb links, that interconnect 
> > several
> > servers that are very *local* to
> > >each other.
> > >Typical RTT times range from 0.2 ms - 0.3 ms.
> > >
> > >We are currently using TCP reno - is there a more suitable congestion 
> > control
> > algorithm for our
> > >application,
> > >especially using the 10 Gb links ?
> > >(Most of the High-Speed TCP algorithms seem suitable for large RTT,
> > long-distance networks).
> > 
> > I'm not aware of any tests for high speed links with very low RTTs, but
> > I suspect that the new algorithms will not change much, if the
> > connections you have are indeed local than the Ethernet pause mechanism
> > is more effective for the flow control you need.
> > 
> > Baruch

Pause helps (if the hardware works). But on very high speed links with low
RTT, your main source of throttling is lack of bus bandwidth on receiver.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: TCP congestion control for fast, short-distance networks ?

[David Miller]

From: Baruch Even <baruch@ev-en.org>
Date: Wed, 4 Apr 2007 19:11:21 +0300

> * davef1624@aol.com <davef1624@aol.com> [070404 19:03]:
> > Thanks - so you are suggesting we enable 802.3 flow-control / pause-frames?
> > (it's currently disabled)
> 
> I do, but do test it before you bet on it. I've never tested such a
> scenario but from my experience the lower the rtt the lesser are the
> problems that the high speed algorithms are trying to solve.

Congestion control, at the TCP level, is from one perspective
completely senseless on local high-speed networks.  The reason is that
once any kind of congestion at that level is detected, the condition
is gone by the time you could even possibly respond to it.

So with that in mind, reno is as good as anything and yes do use
pause frames.

Re: TCP congestion control for fast, short-distance networks ?

[davef1624]

thanks for your help - I'll investigate turning on 802.3 level flow 
control


-----Original Message-----
From: davem@davemloft.net
To: baruch@ev-en.org
Cc: davef1624@aol.com; shemminger@linux-foundation.org; 
netdev@vger.kernel.org
Sent: Wed, 4 Apr 2007 12:55 PM
Subject: Re: TCP congestion control for fast, short-distance networks ?

  From: Baruch Even <baruch@ev-en.org>
Date: Wed, 4 Apr 2007 19:11:21 +0300

> * davef1624@aol.com <davef1624@aol.com> [070404 19:03]:
> > Thanks - so you are suggesting we enable 802.3 flow-control / 
pause-frames?
> > (it's currently disabled)
>
> I do, but do test it before you bet on it. I've never tested such a
> scenario but from my experience the lower the rtt the lesser are the
> problems that the high speed algorithms are trying to solve.

Congestion control, at the TCP level, is from one perspective
completely senseless on local high-speed networks.  The reason is that
once any kind of congestion at that level is detected, the condition
is gone by the time you could even possibly respond to it.

So with that in mind, reno is as good as anything and yes do use
pause frames.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free 
from AOL at AOL.com.

Re: [PATCH] TCP Illinois congestion control (rev3)

[David Miller]

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 4 Apr 2007 08:07:43 -0700

> This is an implementation of TCP Illinois invented by Shao Liu
> at University of Illinois. It is a another variant of Reno which adapts
> the alpha and beta parameters based on RTT. The basic idea is to increase
> window less rapidly as delay approaches the maximum. See the papers
> and talks to get a more complete description.
> 
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>

I've applied this to net-2.6.22, let me know if there are any
follow-on bug fixes I need to add as well.

Thanks!

Re: [PATCH] TCP Illinois congestion control (rev3)

[Stephen Hemminger]

On Fri, 20 Apr 2007 17:08:13 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Wed, 4 Apr 2007 08:07:43 -0700
> 
> > This is an implementation of TCP Illinois invented by Shao Liu
> > at University of Illinois. It is a another variant of Reno which adapts
> > the alpha and beta parameters based on RTT. The basic idea is to increase
> > window less rapidly as delay approaches the maximum. See the papers
> > and talks to get a more complete description.
> > 
> > Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> 
> I've applied this to net-2.6.22, let me know if there are any
> follow-on bug fixes I need to add as well.
> 
> Thanks!

I have a new version ready.