netdev - Re: [PATCH] tcp: Socket option to set congestion window

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 27 May 2010 21:19:44 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Tom Herbert <therbert@...gle.com>
Cc:	David Miller <davem@...emloft.net>, andi@...stfloor.org,
	shemminger@...tta.com, netdev@...r.kernel.org, ycheng@...gle.com,
	lars.eggert@...ia.com
Subject: Re: [PATCH] tcp: Socket option to set congestion window

* Tom Herbert | 2010-05-27 09:14:09 [-0700]:

>"When web browsers open simultaneous TCP connections to the same
>destination, they are working against TCP's congestion control
>mechanisms"

Right, the problem can applied for other protocols as well. Often p2p
protocols behave unfair. This problem is known, but there is currently no
IETF effort to address the problem. The problem is not that simple and it is
difficult to draft a universal statement.

>I have yet to find any paper on CWND that analyzed the effect of this
>phenomena on the Internet which is quite unfortunate.  In our own full
>scale experiments
>(http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf), we
>anlayzed the effects of using larger initial congestion windows on the
>Internet which might be the closest thing to such an analysis.  I know
>in LEDBAT WG of IETF they are trying to come up with new
>recommendations for number of connections a browser can open, this is
>good but I hope it's not after the fact.

I know your paper and if I remember correctly I was a little bit sceptical
about the efforts to analyze the fairness behavior in deep. It takes one day
to validate the fairness issues: take NS3 (with NSC so you can take the Linux
network stack with your patch), setup a dumpbell topology and analyse the
behavior. I will read the paper one more time.

I had no problem with you patch if you apply this patch on top of it:  ;-)


diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 0ca9832..73f9d46 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2371,7 +2371,7 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
 		break;
 
 	case TCP_CWND:
-		if (sysctl_tcp_user_cwnd_max <= 0)
+		if (sysctl_tcp_user_cwnd_max <= 0 || !capable(CAP_NET_ADMIN))
 			err = -EPERM;
 		else if (val > 0 && sk->sk_state == TCP_ESTABLISHED &&
 		    icsk->icsk_ca_state == TCP_CA_Open) {


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