Increase tcp initial window

[Loganaden Velvindron]

From: draft-ietf-tcpm-initcwnd-08.txt

http://www.ietf.org/id/draft-ietf-tcpm-initcwnd-08.txt

This document proposes to raise the upper bound on TCP's initial
window (IW) to 10 segments (maximum 14600B). It is patterned after
and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
area. Due to lingering concerns about possible side effects to other
flows sharing the same network bottleneck, some of the
recommendations are conditional on additional monitoring and
evaluation.

The primary argument in favor of raising IW follows from the evolving
scale of the Internet. Ten segments are likely to fit into queue
space available at any broadband access link, even when there are a
reasonable number of concurrent connections.

My attempt on netbsd box:

--- /root/src/sys/netinet/tcp_var.h 2013-03-22 21:44:12.000000000 +0000
+++ /usr/src/sys/netinet/tcp_var.h 2013-03-22 21:57:39.000000000 +0000
@@ -613,7 +613,7 @@ struct syn_cache_head {
* Compute the initial window for slow start.
*/
#define TCP_INITIAL_WINDOW(iw, segsz) \
- (((iw) == 0) ? (min(4 * (segsz), max(2 * (segsz), 4380))) : \
+ (((iw) == 0) ? (min(10 * (segsz), max(2 * (segsz), 14600))) : \
((segsz) * (iw)))

/*

Feedback/comments welcomed.
//logan
C-x-C-c

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matt Thomas]

Post by Loganaden Velvindron
From: draft-ietf-tcpm-initcwnd-08.txt
http://www.ietf.org/id/draft-ietf-tcpm-initcwnd-08.txt
This document proposes to raise the upper bound on TCP's initial
window (IW) to 10 segments (maximum 14600B). It is patterned after
and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
area. Due to lingering concerns about possible side effects to other
flows sharing the same network bottleneck, some of the
recommendations are conditional on additional monitoring and
evaluation.
The primary argument in favor of raising IW follows from the evolving
scale of the Internet. Ten segments are likely to fit into queue
space available at any broadband access link, even when there are a
reasonable number of concurrent connections.
--- /root/src/sys/netinet/tcp_var.h 2013-03-22 21:44:12.000000000 +0000
+++ /usr/src/sys/netinet/tcp_var.h 2013-03-22 21:57:39.000000000 +0000
@@ -613,7 +613,7 @@ struct syn_cache_head {
* Compute the initial window for slow start.
*/
#define TCP_INITIAL_WINDOW(iw, segsz) \
- (((iw) == 0) ? (min(4 * (segsz), max(2 * (segsz), 4380))) : \
+ (((iw) == 0) ? (min(10 * (segsz), max(2 * (segsz), 14600))) : \
((segsz) * (iw)))

Why not make the 4 or 10 a tuneable via sysctl?
net.inet.tcp.initseg ?

(((iw) == 0) ? (min(tcp_initset * (segsz), max(2 * (segsz), tcp_initseg*1460)))


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Matt Thomas

Post by Loganaden Velvindron
From: draft-ietf-tcpm-initcwnd-08.txt
http://www.ietf.org/id/draft-ietf-tcpm-initcwnd-08.txt
This document proposes to raise the upper bound on TCP's initial
window (IW) to 10 segments (maximum 14600B). It is patterned after
and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
area. Due to lingering concerns about possible side effects to other
flows sharing the same network bottleneck, some of the
recommendations are conditional on additional monitoring and
evaluation.
The primary argument in favor of raising IW follows from the evolving
scale of the Internet. Ten segments are likely to fit into queue
space available at any broadband access link, even when there are a
reasonable number of concurrent connections.
--- /root/src/sys/netinet/tcp_var.h 2013-03-22 21:44:12.000000000 +0000
+++ /usr/src/sys/netinet/tcp_var.h 2013-03-22 21:57:39.000000000 +0000
@@ -613,7 +613,7 @@ struct syn_cache_head {
* Compute the initial window for slow start.
*/
#define TCP_INITIAL_WINDOW(iw, segsz) \
- (((iw) == 0) ? (min(4 * (segsz), max(2 * (segsz), 4380))) : \
+ (((iw) == 0) ? (min(10 * (segsz), max(2 * (segsz), 14600))) : \
((segsz) * (iw)))

Why not make the 4 or 10 a tuneable via sysctl?
net.inet.tcp.initseg ?
(((iw) == 0) ? (min(tcp_initset * (segsz), max(2 * (segsz), tcp_initseg*1460)))

4380 == 3 * 1460 ...

So if you want to be compatible, you need to provide initseg=ninit,nmss
with 4,3:

(((iw) == 0) ? (min(ninit * (segsz), max(2 * (segsz), nmss*1460)))

christos



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

From: draft-ietf-tcpm-initcwnd-08.txt

http://www.ietf.org/id/draft-ietf-tcpm-initcwnd-08.txt

This document proposes to raise the upper bound on TCP's initial
window (IW) to 10 segments (maximum 14600B). It is patterned after
and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
area. Due to lingering concerns about possible side effects to other
flows sharing the same network bottleneck, some of the
recommendations are conditional on additional monitoring and
evaluation.

My memory is that this draft was quite controversial and has not
achieved Proposed Standard status.

In general, the notion of allowing user tunability [1] of congestion
control to do things which are not generally regarded as safe is a bit
scary.

But I could be off about the IETF status of IW10.

[1] Yes, I get it that users can rebuild their kernels to do arbitrary
things. Partly this is about not helping people without adequate
technical skill to violate internet norms, and partly it's about setting
expectations.

[Loganaden Velvindron]

Post by Loganaden Velvindron
From: draft-ietf-tcpm-initcwnd-08.txt
http://www.ietf.org/id/draft-ietf-tcpm-initcwnd-08.txt
This document proposes to raise the upper bound on TCP's initial
window (IW) to 10 segments (maximum 14600B). It is patterned after
and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
area. Due to lingering concerns about possible side effects to other
flows sharing the same network bottleneck, some of the
recommendations are conditional on additional monitoring and
evaluation.
My memory is that this draft was quite controversial and has not
achieved Proposed Standard status.
In general, the notion of allowing user tunability [1] of congestion
control to do things which are not generally regarded as safe is a bit
scary.
But I could be off about the IETF status of IW10.

It seems to be getting a lot of revisions. Other BSDs have also
implemented it.

Post by Loganaden Velvindron
[1] Yes, I get it that users can rebuild their kernels to do arbitrary
things. Partly this is about not helping people without adequate
technical skill to violate internet norms, and partly it's about setting
expectations.

Maybe we should try to do the some empirical measurements to see if it has
too many side effects.

What about putting this as a sysctl and document it properly as christos and
matt suggested ?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Hawkinson]

Post by Loganaden Velvindron
It seems to be getting a lot of revisions. Other BSDs have also
implemented it.

Loganaden, Greg's criticism is of making the parameter entirely tunable.
In a fashion that would allow an ignorant user to set an initial
window of not just 10, but also 20, 40, 50, 100.

Are you saying that other BSDs permit that?

Post by Loganaden Velvindron

Post by Greg Troxel
[1] Yes, I get it that users can rebuild their kernels to do arbitrary
things. Partly this is about not helping people without adequate
technical skill to violate internet norms, and partly it's about setting
expectations.

Maybe we should try to do the some empirical measurements to see if it has
too many side effects.

The problem is what happens when large numbers of people in the
Internet do this. This is why the research community has been very
careful to propose changes to this parameter quite slowly.

Post by Loganaden Velvindron
What about putting this as a sysctl and document it properly as christos and
matt suggested ?

That misses Greg's point -- that allowing users this flexibility is
not generally regarded as safe, and is indeed quite scary.

We could allow tunability within some restricted range, as a
compromise, but even that, I think is unwise. Those with the requisite
skill to understand this parameter in the context of its effect on the
broader Internet also have the requisite skill to rebuild their kernels
(or patch them live!).

--***@mit.edu
John Hawkinson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Loganaden Velvindron
What about putting this as a sysctl and document it properly as christos and
matt suggested ?

Let's do it.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Christos Zoulas

Post by Loganaden Velvindron
What about putting this as a sysctl and document it properly as christos and
matt suggested ?

Let's do it.

I think this parameter is in the domain of network research. Network
researchers can make their own code changes; it's not like this is hard.
If there's an IETF consensus to implement it, we can do so immediately.
I think it's not good Internet citizenship to hand users an option
before then.

[Christos Zoulas]

On Mar 30, 7:49pm, ***@ir.bbn.com (Greg Troxel) wrote:
-- Subject: Re: Increase tcp initial window

| I think this parameter is in the domain of network research. Network
| researchers can make their own code changes; it's not like this is hard.
| If there's an IETF consensus to implement it, we can do so immediately.
| I think it's not good Internet citizenship to hand users an option
| before then.

I think that ship has already sailed a long time ago:

http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
http://monolight.cc/2010/12/increasing-tcp-initial-congestion-window/
http://support.microsoft.com/kb/2472264
http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html

In addition, the browsers opening multiple connection streams by
default end up doing more harm than bumping bumping initcwnd to a max
of 10 or 16.

As you probably already most other OS's (except the BSD's and AIX) provide
a tunable that is clamped to 10 or 16.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Loganaden Velvindron

Post by Loganaden Velvindron
From: draft-ietf-tcpm-initcwnd-08.txt
http://www.ietf.org/id/draft-ietf-tcpm-initcwnd-08.txt
This document proposes to raise the upper bound on TCP's initial
window (IW) to 10 segments (maximum 14600B). It is patterned after
and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
area. Due to lingering concerns about possible side effects to other
flows sharing the same network bottleneck, some of the
recommendations are conditional on additional monitoring and
evaluation.
My memory is that this draft was quite controversial and has not
achieved Proposed Standard status.
In general, the notion of allowing user tunability [1] of congestion
control to do things which are not generally regarded as safe is a bit
scary.
But I could be off about the IETF status of IW10.

It seems to be getting a lot of revisions. Other BSDs have also
implemented it.

Revisions are not a sign of consensus; they are a sign that the author
is revising.

(The IETF web site seems to be broken right now; that's perhaps about
IPv6.)

Post by Loganaden Velvindron
Maybe we should try to do the some empirical measurements to see if it has
too many side effects.

Sure, but that's network research and would be welcome published or
publicized to the tcpm working group. NetBSD is a fine software base to
use, but it's not really a NetBSD issue. Empirical measurements are
had; the real question is "what if everyone did this". It's clear that
one host running a more aggressive transmit algorithm is better for that
host and has no global effect. But that's not the right question.

[Erik Fair]

No, let's not.

John Hawkinson is correct. Imagine this in the presence of routers which implement RED - it would not (and should not) win. Absent RED, tragedy of the commons ensues (and, possibly, "congestion collapse" - google that and Nagle's RFC on gateways with infinite storage for enlightening historical perspective).

Erik E. Fair <***@netbsd.org>
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alistair Crooks]

Post by Erik Fair
No, let's not.
John Hawkinson is correct. Imagine this in the presence of routers
which implement RED - it would not (and should not) win. Absent
RED, tragedy of the commons ensues (and, possibly, "congestion
collapse" - google that and Nagle's RFC on gateways with infinite
storage for enlightening historical perspective).

Why would that preclude making the initial congestion window a sysctl
tunable?

There are numerous white papers (including the original Google one
which started off the IETF effort) which show that having a larger
initial window is a win, and optimising for the lowest common
denominator is a sure way to mediocrity or worse. Making it tunable
means that this doesn't have to happen.

Regards,
Alistair

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Alistair Crooks

Post by Erik Fair
Imagine this in the presence of routers which implement RED - it
would not (and should not) win. Absent RED, tragedy of the commons
ensues (and, possibly, "congestion collapse" - google that and
Nagle's RFC on gateways with infinite storage for enlightening
historical perspective).

Why would that preclude making the initial congestion window a sysctl
tunable?

It doesn't, per se. What it does argue against is making it tunable by
end-user admins over a nontrivial range.

Post by Alistair Crooks
There are numerous white papers (including the original Google one
which started off the IETF effort) which show that having a larger
initial window is a win,

I'd have to read the paper to tell, but I suspect it either is "theory
indicates this ought to be a win" (with underspecified or unrealistic
assumptions) or "this is a win when dropped as an isolated instance
into [then-]today's Internet".

I think Erik is right. A large initial window on an end-user host, in
the presence of routers doing RED, just pushes it into congestion
instantly as packets get REDded (hopefully congestion backoff, because
if not it then leads to congestion collapse); absent RED, well, as Erik
put it, tragedy of the commons ensues, with endpoints effectively
fighting over who gets to monopolize choke-point bandwidth. "You're
going to send ten packets? _I_'ll send _twenty_!". Like most
tragedies of the commons, until mechanisms to defend the commons
against the greedy are put in place, this ends up rewarding the greedy
and penalizing the well-behaved good neighbours. (In this case, the
defense mechanism is something that, like RED, preferentially penalizes
those sending packet floods.)

The only cases where it will win, as far as I can see, are (a) the case
where either there is sufficient capacity that there is no contention
and (b) the case where everyone else is well-behaved, backing off in
the presence of initial packet storms from hosts starting off with
unreasonably large windows for the paths in question. It's essentially
the opposite of slow start, and loses for the reasons slow start wins.

Of course, rewarding the greedy and penalizing the well-behaved good
neighbours _is_ the direction the net is going these days, so perhaps
this would be appropriate.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Loganaden Velvindron]

Post by John Hawkinson

Post by Loganaden Velvindron
It seems to be getting a lot of revisions. Other BSDs have also
implemented it.

Loganaden, Greg's criticism is of making the parameter entirely tunable.
In a fashion that would allow an ignorant user to set an initial
window of not just 10, but also 20, 40, 50, 100.
Are you saying that other BSDs permit that?

None of them allows use to set it to an arbitary value.

OpenBSD implements the draft and sets it as a default:
http://www.freshbsd.org/commit/openbsd/fbe66f35aec02197673ca6889e55bc629e198fdd

FreeBSD implements it as a sysctl:
http://www.freshbsd.org/commit/freebsd/r242266/diff.txt

dflybsd:
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/bf522a910724004644c81f18dd228361fdb88b74

Linux has implemented it since 3.0.

What I propose is that we add it as a sysctl, similar to how OpenBSD does.
rfc_3390 = 1 (default behaviour)
rfc_3390 = 2 (draft-ietf-tcpm-initcwnd)

OR create a new sysctl
initcwnd10 = 0 (default behaviour)
initcwdnd1 = 1 (draft-ietf-tcpm-initcwnd)

We also amend the man pages to explain to end-users the risks involved
by pointing them to:
http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00

Post by John Hawkinson

Post by Loganaden Velvindron

Post by Greg Troxel
[1] Yes, I get it that users can rebuild their kernels to do arbitrary
things. Partly this is about not helping people without adequate
technical skill to violate internet norms, and partly it's about setting
expectations.

Maybe we should try to do the some empirical measurements to see if it has
too many side effects.

The problem is what happens when large numbers of people in the
Internet do this. This is why the research community has been very
careful to propose changes to this parameter quite slowly.

Post by Loganaden Velvindron
What about putting this as a sysctl and document it properly as christos and
matt suggested ?

That misses Greg's point -- that allowing users this flexibility is
not generally regarded as safe, and is indeed quite scary.
We could allow tunability within some restricted range, as a
compromise, but even that, I think is unwise. Those with the requisite
skill to understand this parameter in the context of its effect on the
broader Internet also have the requisite skill to rebuild their kernels
(or patch them live!).
John Hawkinson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Hawkinson]

Post by Loganaden Velvindron
What I propose is that we add it as a sysctl, similar to how OpenBSD does.

In principal this is fine, and I am much less concerned about it.
(though still a little concerned.) What IETF working group is dealing
with this stuff (tcpm?), and is anyone on this mailing list following it
closely? I'm not on the tcpm mailing list.

Post by Loganaden Velvindron
rfc_3390 = 1 (default behaviour)
rfc_3390 = 2 (draft-ietf-tcpm-initcwnd)
OR create a new sysctl
initcwnd10 = 0 (default behaviour)
initcwdnd1 = 1 (draft-ietf-tcpm-initcwnd)

It's not super-important, but I think we want an option with slightly
differnt properties. We want an option whose default value should
now be the initial window of 4, but whose default value can change
in the future when the IETF recommendation changes.

Therefore, I think we want a tri-state. The default being
to use window of 4 today, but to shift to using the window of 10
if the standards community changes to that. Then a value to
indicate always use 4, even if NetBSD's default changes in a future release
(so users can hard-code it to 4 now and into the future). And
a default value to indicate always use 10, even if NetBSD's default
changes in the future.

I guess probably I'd suggest

net.inet.tcp.initcwnd:
0 Choose initial window based on current IETF recommendations
(now 4)
4 Force window to RFC3390 (Proposed Standard 2002) recommendation
10 Force window to draft-ietf-tcpm-initcwnd-08 (Experimental 2013)

All other values disallowed at this time. (But you could imagine
a afuture where the IETF recommended a value like 8 or 12, at which
point we could change the options).

On the other hand, it doesn't look like other implementors have chosen
an architecture like that.

--jhawk

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Loganaden Velvindron

Post by John Hawkinson

Post by Loganaden Velvindron
It seems to be getting a lot of revisions. Other BSDs have also
implemented it.

Loganaden, Greg's criticism is of making the parameter entirely tunable.
In a fashion that would allow an ignorant user to set an initial
window of not just 10, but also 20, 40, 50, 100.
Are you saying that other BSDs permit that?

None of them allows use to set it to an arbitary value.

As I mentioned before, this ship has sailed:

1.29 (thorpej 11-Dec-97): { "init_win", CTLTYPE_INT }, \

We already allow setting the initial window to anything, but some people
cannot be bothered to read the source instead of arguing.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de