TCP control block interdependence

[Oumer Teyeb <oumer@kom.aau.dk>]

Hi,

I am not sure if it is the right place to post this but people at
comp.protocols.tcp-ip, comp.os.linux.networking suggested it.
Could you please cc the reply to oumer@kom.auc.dk?

as a part of my studies I have to investigate some link layer protocol 
impacts on TCP performance...so I have some emulator working on linux, 
and I was investigating the impact of delay spikes....

I results I am getting are a little bit wierd and I think it is mainly 
due to TCP control block interdependence implementation in linux....

EXPERIMENT ILLUSTRATING THE PROBLEM
=======================================

I downloaded a 100K file using FTP over a 384kbps connection...and I 
introduce a delay of 10 sec, 2 seconds after the download starts..

case 1)
I did four downloads immediatley after each other

case 2)
I did four downloads but this time, I wait ten mintues before the next 
download

results)
Case 1) I have a lot of retransmissions in the first one (because of the 
10sec gap)..but the rest dont seem to suffer from retransmission at all, 
even during the 10sec gap...the rtt values confirm it ..i,e. in the 
first case, the rtt curve shows the RTT values are mostly below 1 
sec..while in the next three downloads, the RTTs are sometimes more than 
10sec....showing that the RTO value used for the three cases is 
something different than the first one
curves can be found at :tsg=time sequence graph
http://kom.auc.dk/~oumer/case1_1_tsg.ps
http://kom.auc.dk/~oumer/case1_1_rtt.ps
http://kom.auc.dk/~oumer/case1_2_tsg.ps
http://kom.auc.dk/~oumer/case1_2_rtt.ps
http://kom.auc.dk/~oumer/case1_3_tsg.ps
http://kom.auc.dk/~oumer/case1_3_rtt.ps
http://kom.auc.dk/~oumer/case1_4_tsg.ps
http://kom.auc.dk/~oumer/case1_4_rtt.ps

Case 2) There is almost no different between the four downloads
http://kom.auc.dk/~oumer/case2_1_tsg.ps
http://kom.auc.dk/~oumer/case2_1_rtt.ps
http://kom.auc.dk/~oumer/case2_2_tsg.ps
http://kom.auc.dk/~oumer/case2_2_rtt.ps
http://kom.auc.dk/~oumer/case2_3_tsg.ps
http://kom.auc.dk/~oumer/case2_3_rtt.ps
http://kom.auc.dk/~oumer/case2_4_tsg.ps
http://kom.auc.dk/~oumer/case2_4_rtt.ps

From these I conclude that there is some TCP congestion control and 
retransmission parameter caching, that is also time dependant....
and I want to disable it completley...

So in short do you know how to disable this control block interdepence? 
I am doing experiments related to some link layer issues, and any 
dependancy between two consecutive connections to the same host is 
seriously biasing my results..and to get statistical measures, I have to 
do the runs hundrends of times, under different conditions, so I cant 
afford to wait several minutes between consecutive runs (to make sure 
control block interdependence is not at work)...so maybe there is a way 
to trick linux tcp not to apply interdependence?

In the Linux congestion control paper by Pasi Sarlhoti, "Congestion 
Control in Linux TCP" it is mentioned that "the Linux destination cache 
provides functionality similar to the RFC 2140 that proposes Control 
Block Interdependence between the TCP connections." but there was no 
additional details...

in 
http://www.cs.helsinki.fi/research/iwtcp/kernel-patch/README-2.4.18-frto-20020419.txt
I found some text where there is a patch that will make it possible to 
control the interdependence setting..but I am using some servers at our 
university, and I dont think the admins will be willing to install 
patches that are not stable....
how stable is this patch? and have anyone been using it?
Is there another simple way like setting some default values in some 
headers and recompiling the kernel, maybe the admins will be willing to 
do that for me in some servers (I am not that familiar the linux kernel, 
and I have to admit I had never recompiled/"messed" with it...)

by the way I am using debian linux distribution and "uname -a" gives me
Linux 2.4.25-std #1 SMP Mon Mar 22 10:25:51 CET 2004 i686 unknown

Thanks in advance,
Oumer Teyeb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/