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] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTime8wfTLfdNMAx_HYr6XO0DiO12r5FVdGBjVNwT@mail.gmail.com>
Date:	Thu, 27 May 2010 09:14:09 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	David Miller <davem@...emloft.net>, andi@...stfloor.org,
	shemminger@...tta.com, netdev@...r.kernel.org, ycheng@...gle.com
Subject: Re: [PATCH] tcp: Socket option to set congestion window

> And this is the most important aspect in this email: core network components
> rely on end hosts to behave in a fair manner. Disable Slow Start/Congestion
> Avoidance and the network will instantly collapse (mmh, net-next? ;-)
>
> The mechanism as proposed in the patch is not fair. There are a lot of
> publications available that analyse the impact CWND in great detail as well as
> several RFC that talk about the CWND.

The mechanism proposed in the patch is merely an API change; misuse,
abuse, or unfairness are inferences of how it might be used.  Proper
safeguards should be applied to prevent misuse, but I don't see that
it should be any more insidious than 350 other mechanisms in the
system that could be used to screw things up.

Yes, there has been a lot of talk about CWND, but the standard has not
changed since 2002.  In the meantime, browsers have increased the
number of parallel connections they open to a destination, and servers
hide behind multiple domains-- the end result of this is that browsers
use aggregate initial congestion windows much larger than the
standard, which sidesteps slowstart and is a source of unfairness.
This is contrary to RFC 3390:

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

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.

It would be better, by almost any perspective, to rein in the number
of connections servers are allowing clients to open.  However this
isn't going to happen if this means increase latency for end users,
there's is no competitive rationale for servers to do that.  That's
where a primary motivation of this patch becomes evident.  Instead of
a server allowing 6 connections from a client, for instance, it could
allow just one connection but with a initial congestion window equal
to the aggregate of the 6 connections.  This reduces connections and
does not change the size of initial data burst going into the
Internet.  The Internet is happy because there a fewer connections
(better for fairness) and fewer packets (fewer 3WHS); the server and
client are happy because there are fewer connections to deal without
and no increased latency.

Tom
--
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