|
|
|
|
|
|
| Author |
Message |
Oumer Teyeb
*nix forums beginner
Joined: 24 Feb 2006
Posts: 11
|
 Posted: Tue Jul 18, 2006 10:07 pm Post subject:
Re: Strange TCP SACK behaviour in Linux
|
|
|
Hi all,
I have put some traces you can look into if you have the time.....
www.kom.auc.dk/~oumer/sackstuff.tar.gz
I have run the different cases 10 times each,
NT_NSACK[1-10].dat---no timestamp, no SACK
NT_SACK[1-10].dat----no timestamp, SACK
T_NSACK[1-10].dat---timestamp, no SACK
T_SACK[1-10].dat----timestamp. SACK
the files without extension are just two column file that summarize the
ten different cases, the first column in the # retransmission, and
second column is the download time, the values I gathered from tcptrace
the two eps files are just the plot summarizing the above average
download time and average retransmission # for each case...
one more thing in the trace files, you will find 3 tcp connections, the
first one is not modified by my emulator that causes the reordering
(actually, that is the connection through which I reset the destination
catch that stores some metrics from previous runs using some commands
via ssh), the second one is the ftp control channel and the third one is
the ftp data channel....the emulator affects the last two channels
and causes reordering once in a while.....
please dont hesistate to ask me if anything is not clear...
Thanks a lot for taking the time
Regards,
Oumer
Oumer Teyeb wrote:
| Quote: | 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 www.kom.auc.dk/~oumer/first_transmission_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
|
|
|
| Back to top |
|
 |
Oumer Teyeb
*nix forums beginner
Joined: 24 Feb 2006
Posts: 11
|
| Posted: Tue Jul 18, 2006 4:30 pm Post subject:
Strange TCP SACK behaviour in Linux
|
|
|
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 www.kom.auc.dk/~oumer/first_transmission_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 |
|
| Back to top |
|
|
Oumer Teyeb
*nix forums beginner
Joined: 24 Feb 2006
Posts: 11
|
| Posted: Tue Jul 18, 2006 4:29 pm Post subject:
Strange TCP SACK behaviour in Linux
|
|
|
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 www.kom.auc.dk/~oumer/first_transmission_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 |
|
| Back to top |
|
|
Grant
*nix forums Guru
Joined: 07 Mar 2005
Posts: 739
|
| Posted: Thu Mar 02, 2006 7:25 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
On Thu, 02 Mar 2006 15:41:19 +0100, Oumer Teyeb <oumer@kom.aau.dk> wrote:
| Quote: | 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 |
|
| Back to top |
|
|
Oumer Teyeb
*nix forums beginner
Joined: 24 Feb 2006
Posts: 11
|
| Posted: Thu Mar 02, 2006 2:41 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
| Quote: | 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....)
| Quote: | 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.
|
|
|
| Back to top |
|
|
Rick Jones
*nix forums Guru
Joined: 24 Feb 2005
Posts: 492
|
| Posted: Mon Feb 27, 2006 7:32 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
| Quote: | 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.
| Quote: | 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... |
|
| Back to top |
|
|
Robert Harris
*nix forums Guru Wannabe
Joined: 03 Mar 2005
Posts: 118
|
| Posted: Mon Feb 27, 2006 4:24 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
Oumer Teyeb wrote:
| Quote: | Rick Jones wrote:
In comp.protocols.tcp-ip Oumer Teyeb <oumer@kom.aau.dk> 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 |
|
| Back to top |
|
|
Oumer Teyeb
*nix forums beginner
Joined: 24 Feb 2006
Posts: 11
|
| Posted: Mon Feb 27, 2006 2:47 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
Rick Jones wrote:
| Quote: | In comp.protocols.tcp-ip Oumer Teyeb <oumer@kom.aau.dk> 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... |
|
| Back to top |
|
|
Rick Jones
*nix forums Guru
Joined: 24 Feb 2005
Posts: 492
|
| Posted: Fri Feb 24, 2006 7:28 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
In comp.protocols.tcp-ip Oumer Teyeb <oumer@kom.aau.dk> wrote:
| Quote: | 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... |
|
| Back to top |
|
|
Bill Marcum
*nix forums Guru
Joined: 28 Mar 2005
Posts: 1264
|
| Posted: Fri Feb 24, 2006 6:17 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
["Followup-To:" header set to comp.os.linux.networking.]
On Fri, 24 Feb 2006 15:02:55 +0100, Oumer Teyeb
<oumer@kom.aau.dk> wrote:
| Quote: | 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. |
|
| Back to top |
|
|
Grant
*nix forums Guru
Joined: 07 Mar 2005
Posts: 739
|
| Posted: Fri Feb 24, 2006 4:00 pm Post subject:
Re: setting Initial Window Size of TCP in linux
|
|
|
On Fri, 24 Feb 2006 15:02:55 +0100, Oumer Teyeb <oumer@kom.aau.dk> wrote:
| Quote: | 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?" |
|
| Back to top |
|
|
Oumer Teyeb
*nix forums beginner
Joined: 24 Feb 2006
Posts: 11
|
| Posted: Fri Feb 24, 2006 2:02 pm Post subject:
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 |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 12:08 pm | All times are GMT
|
|
Loans | Adverse Credit Remortgage | Cheap Loan | McDonalds | Loan
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
networking
