setting Initial Window Size of TCP in linux

Hello,

How can I set the initial window size in TCP? (i.e how many segments to
to during start up (slow start)?)

all I see under /proc/sys/net/ipv4 that are concerned with tcp are shown
below and none of them seem to be concerned with the initial window
size...I suspected the tcp_wmem or tcp_rmem but it seems that these
refer to maximum, minimum, and default sender and receiver window sizes,
not the initial window...

tcp_abort_on_overflow tcp_low_latency tcp_rmem
tcp_adv_win_scale tcp_max_orphans tcp_sack
tcp_app_win tcp_max_syn_backlog tcp_stdurg
tcp_dsack tcp_max_tw_buckets tcp_synack_retries
tcp_ecn tcp_mem tcp_syn_retries
tcp_fack tcp_orphan_retries tcp_timestamps
tcp_fin_timeout tcp_reordering tcp_tw_recycle
tcp_frto tcp_retrans_collapse tcp_tw_reuse
tcp_keepalive_intvl tcp_retries1 tcp_window_scaling
tcp_keepalive_probes tcp_retries2 tcp_wmem
tcp_keepalive_time tcp_rfc1337


Thanks in advance,
Oumer

On Fri, 24 Feb 2006 15:02:55 +0100, Oumer Teyeb <(E-Mail Removed)> wrote:

>all I see under /proc/sys/net/ipv4 that are concerned with tcp are shown
>below and none of them seem to be concerned with the initial window
>size...I suspected the tcp_wmem or tcp_rmem but it seems that these
>refer to maximum, minimum, and default sender and receiver window sizes,
>not the initial window...

RTFM -> linux-kernel/Documentation/

grep -r is your friend.

Grant.
--
.... The computer scientist, who had listened to all of this said,
"Yes, but where do you think the chaos came from?"

["Followup-To:" header set to comp.os.linux.networking.]
On Fri, 24 Feb 2006 15:02:55 +0100, Oumer Teyeb
<(E-Mail Removed)> wrote:
> Hello,
>
> How can I set the initial window size in TCP? (i.e how many segments to
> to during start up (slow start)?)
>
You can set window size in the route command. I have one old ISA
NE-2000 clone network card which needs this.


--
It is the wise bird who builds his nest in a tree.

In comp.protocols.tcp-ip Oumer Teyeb <(E-Mail Removed)> wrote:
> How can I set the initial window size in TCP? (i.e how many segments to
> to during start up (slow start)?)

That would be the initial _congestion_ window size, and I'm not sure
that linux has a way to alter that, it more or less follows the 4380
bytes or 2 (maybe three) segments logic from one of the RFC's.

Are you looking to increase or decrease? And which version and distro
are you running?

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rick Jones wrote:
> In comp.protocols.tcp-ip Oumer Teyeb <(E-Mail Removed)> wrote:
>
>>How can I set the initial window size in TCP? (i.e how many segments to
>>to during start up (slow start)?)
>
>
> That would be the initial _congestion_ window size, and I'm not sure
> that linux has a way to alter that, it more or less follows the 4380
> bytes or 2 (maybe three) segments logic from one of the RFC's.
>
> Are you looking to increase or decrease? And which version and distro
> are you running?
>
> rick jones
I am using debian distribution with 2.4 kernel...and I want both to
increase or decrease it...

Oumer Teyeb wrote:
> Rick Jones wrote:
>> In comp.protocols.tcp-ip Oumer Teyeb <(E-Mail Removed)> wrote:
>>
>>> How can I set the initial window size in TCP? (i.e how many segments
>>> to to during start up (slow start)?)
>>
>>
>> That would be the initial _congestion_ window size, and I'm not sure
>> that linux has a way to alter that, it more or less follows the 4380
>> bytes or 2 (maybe three) segments logic from one of the RFC's.
>>
>> Are you looking to increase or decrease? And which version and distro
>> are you running?
>>
>> rick jones
> I am using debian distribution with 2.4 kernel...and I want both to
> increase or decrease it...

Just a minute - the receiving end determines its TCP window size (in
both directions).

Robert

>> I am using debian distribution with 2.4 kernel...and I want both to
>> increase or decrease it...

I suspect you need to crack-open an editor and the compiler.

> Just a minute - the receiving end determines its TCP window size (in
> both directions).

There are, in broad handwaving terms, three things that limit how much
data is "in flight" at one time on a TCP connection.

The first is what I like to call the "classic" TCP window - it is the
"receive" window advertised by the receiver, and is seen in the TCP
header. Indeed, it is maintained by the receiver.

The second is the congestion window. It is the _sender's_ best guess
as to how much data can be in flight at one time without overloading
some component between the sender and the receiver. It is purely a
figment of the sender's imagination (as it were) and does not
appear on the wire in the TCP header.

The third I call the "SO_SNDBUF" window. TCP must retain a reference
to the data it has sent until it receives an ACK from the remote.
Generally, the place where TCP keeps this data is the socket send
buffer, and that is controlled in part by setsockopt() calls setting
SO_SNDBUF - typically bounded by some sort of system configuration
limits. If TCP has no place to keep the reference to the data, it
cannot send it, so it can send no more data at one time than it can
track.

So, the maximum quantity of data outstanding at any one time will be
the minimum of those three things.

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

> The first is what I like to call the "classic" TCP window - it is the
> "receive" window advertised by the receiver, and is seen in the TCP
> header. Indeed, it is maintained by the receiver.
>
> The second is the congestion window. It is the _sender's_ best guess
> as to how much data can be in flight at one time without overloading
> some component between the sender and the receiver. It is purely a
> figment of the sender's imagination (as it were) and does not
> appear on the wire in the TCP header.

This is the one I am concerned about...because at the beginning of a
slow start, in original tcp specification the cwnd was set to 1
packet....but other RFCs updated that to go upto 4.....so I wanted to
know if it can be easily set up in linux (or is this one of the easiest
thing to set up in windows but not in linux? amazing....)


> The third I call the "SO_SNDBUF" window. TCP must retain a reference
> to the data it has sent until it receives an ACK from the remote.
> Generally, the place where TCP keeps this data is the socket send
> buffer, and that is controlled in part by setsockopt() calls setting
> SO_SNDBUF - typically bounded by some sort of system configuration
> limits. If TCP has no place to keep the reference to the data, it
> cannot send it, so it can send no more data at one time than it can
> track.
>

On Thu, 02 Mar 2006 15:41:19 +0100, Oumer Teyeb <(E-Mail Removed)> wrote:

>know if it can be easily set up in linux (or is this one of the easiest
>thing to set up in windows but not in linux? amazing....)

Windows use the BSD stack.


--
Living in a land down under / Where women glow and men plunder / Can't you
hear, can't you hear the thunder? / You better run, you better take cover!
--Men At Work

Hello Guys,

I have some questions regarding TCP SACK implementation in Linux
could you please cc the reply to me? thanks!


I am doing these experiments to find out the impact of reordering. So I
have different TCP versions (newReno, SACK, FACk, DSACK, FRTO,....) as
implemented in Linux. and I am trying their combination to see how they
behave. What struck me was that when I dont use timestamps, introducing
SACK increases the download time but decreases the total number of
retransmissions.
When timestamps is used, SACK leads to an increase in both the download
time and the retransmissions.

So I looked further into the results, and what I found was that when
SACK is used, the retransmissions seem to happen earlier .
at http://www.kom.auc.dk/~oumer/first_t...sion_times.pdf
you can find the pic of cdf of the time when the first TCP
retransmission occured for the four combinations of SACK and timestamps
after hundrends of downloads of a 100K file for the different conditions
under network reordering...

This explains the reason why the download time increases with SACK,
because the earlier we go into fast recovery the longer the time we
spend on congestion avoidance, and the longer the download time....

....but I couldnt figure out why the retransmissions occur earlier for
SACK than no SACK TCP. As far as I know, for both SACK and non SACK
cases, we need three (or more according to the setting) duplicate ACKs
to enter the fast retransmission /recovery state.... which would have
resulted in the same behaviour to the first occurance of a
retransmission..... or is there some undocumented enhancment in Linux
TCP when using SACK that makes it enter fast retransmit earlier... the
ony explanation I could imagine is something like this

non SACK case
=============
1 2 3 4 5 6 7 8 9 10..... were sent and 2 was reorderd....and assume we
are using delayed ACKs...and we get a triple duplicate ACK after pkt#8
is received. (i.e 3&4--first duplicate ACK, 5&6..second duplicate ACK
and 7&8...third duplicate ACK.....)...

so if SACK behaved like this...

3&4 SACKEd.... 2 packets out of order received
5&6 SACKEd....4 packets out of order received.... start fast
retransmission....as reorderd is greater than 3.... (this is true when
it comes to marking packets as lost during fast recovery, but is it true
als for the first retransmission?)

... any ideas why this is happening???


Thanks in advance,
Oumer