[Thanks everyone for using TCP-Linux. This is a summary of discussion between Arya and I on Compound TCP Error In TCP-Linux Patch for NS2]
For general trouble-shooting, there are scripts shared at the TCP-Linux website as references on how to get simulated TCP congestion control behavior close to real implementation. See Section 2 "Basic behavior" in http://netlab.caltech.edu/projects/ns2tcplinux/ns2linux/. It will be easier for a user to compare these scripts with a new scenario script to see if there are any missing parameters. There is also discrepancy between the compound code (which discontinued in Linux mainstream before 2.6.20) and the Linux skb-based timestamp interface since 2.6.22. Since 2.6.22, the TCP_CONG_RTT_STAMP is used to indicate a module needs the most accurate timestamp (skb-based timestamp). But compound didn't set this on. So, compound didn't use the skb timestamp and could not accurate result. Thanks for Arya to finding the bug due to this discrepency. I've pushed a new patch which changes the compound module code in the patch to add TCP_CONG_RTT_STAMP option to the field. It also changes the tcp-linux code to make it compatible with both 2.6.22 and 2.6.16 in the skb-based RTT measurement. More details about timestamps in Linux (which also in TCP-Linux of NS-2) which is good to know if you are writing/evaluating a Linux congestion control module : There are at least two different kind of time stamps: RFC1323 timestamp and SKB-based timestamp. The RFC1323 timestamp is on-packet timestamp, which is not intended to be used to measure very accurate RTT (though you can use it to measure RTT in the accuracy of jiffy). It is intended to be used to avoid PAWS. RFC1323 timestamp is on/off independent of congestion control module. The control variable in NS-2 Agent/TCP/Linux is timestamps_. The SKB-based timestamp records TCP_CONG_RTT_STAMP is the timestamp on skb (packets in retransmission queue in the sender side). It is up to microsecond accuracy which means very accurate. The SKB-based timestamp is on/off according to TCP_CONG_RTT_STAMP flag in each module. (TThere is a control variable in NS-2 Agent/TCP/Linux bugfix_ts_ that enables the SKB-based implementation. But users of TCP-Linux do not need to control it directly -- TCP-Linux turns it on/off based on the TCP_CONG_RTT_STAMP flag). Thanks everyone for the feedback! -David > -------- Original Message -------- > Subject: [ns] Compound TCP Error In Linux Patch for NS2? > Date: Thu, 29 Nov 2007 19:47:15 -0500 > From: Arya Afrashteh <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: <ns-users@ISI.EDU> > > > I have downloaded the linux patch for ns2 from the following site: > http://www.cs.caltech.edu/~weixl/technical/ns2linux/index.html > > The patch is meant to include the implementations for various new congestion > control/avoidance algorithms that have been published to solve the problem > reno has with high bandwidth-delay networks. > > I have noticed that when I run the compound TCP algorithm, it acts exactly > like reno. I then modified the c file to put a simple printf() statement > printing out the value of dwnd (this variable is used to make compound TCP > more aggressive in high bandwidth-delay products), and I have noticed it is > ALWAYS 0. Am I using compound TCP wrong or was I suppose to change > something, is the protocol flawed or was there an incorrect implementation > in ns2? > > ----------------------------------------------- > Arya Afrashteh > Virginia Tech - CpE Grad Student > [EMAIL PROTECTED] > ----------------------------------------------- > >
