Help For Quick Start TCP Implementation in ns 2.31 / ns 2.34

Kindly if someone has any experience with Quick Start implementation of TCP in ns2.31 or ns 2.34 , reply. I am detailed the problems that i faced.

Thank you in advance.

Problem:

I have compiled and tested the Quick Start (QS) TCP implementation in ns 2.31 and 2.34. I have compared throughput results with SACK. If comparison of instantaneous throughput is drawn yes it comes closely to SACK. but regards congestion window behaviour and if i calculate average throughput in QS implemented TCP sources the variations are not much different from normal TCP implementations.

A brief on the simulation scenario:

3 nodes. 1 sender node, 1 act as Base station node and 1 node acts as a mobile node.

links are configured to: ns duplex_link $W1 $W2 1Mb 15ms DropTail

ns duplex_link $W2 $W3 550Kb 15ms DropTail – the last mile

3 TCP/Reno sources starting at 0 secs.

What I have observed by debugging is:

1. In TCP.cc file there is a function ‘process quickstart’. In it there is an ‘If’ statement that compares ttl_diff at sender with ttl_diff of receiver according to the QS algorithm. Well these two values never equal. I have configured the nodes with statement in tcl as $ns node-config-QS ON, and put QS/Agent set qs_enabled_ false and put TCP set qs_enabled _ true (i have double checked these values from the test files present in ns2.31/tcl/test/ test-suite-quickstart.tcl) …

2. I defined a source file where I changed values for TCP QS parameters such as $tcp1 set window_ 10000 $tcp1 set rate_request_ 20 … and after every 0.5 seconds different window and rate_requests were generated.. However the TCP and QS modules weren’t able to take these values. The QS only invoked for the first request. But it never got approved since ttl_diff at sender and receiver never equaled.

3. Also, I changed the link of the last mile as in alternated it to act as a link first having 550Kb and than 1Mb. and changed the TCP QS parameters of window and rate request. But nothing seemed to happen.

4. Also for your reference, I set the following parameters for QS mode. I am including all the parameters for QS/Agent as well as TCP/Agent that I enabled for QS:

# parameters for QS
set opt(qs) 0
set opt(qs_alloc_rate) 0.75
set opt(qs_threshold) 0.75
set opt(qs_state_delay) 0.35
set opt(qs_request_mode) 2
set opt(qs_algorithm) 3
set opt(qs_rate_request) 40
set opt(qs_rtt) 50
set opt(util_records) 3
set opt(util_weight) 2
set opt(qs_rate_function) 1
set opt(tcp_qs_recovery) true
set opt(qs_set_ssthresh) 4 // this is from the default.tcl file …..

Queue set util_weight_ $opt(util_weight)
Queue set util_records_ $opt(util_records)

Agent/QSAgent set alloc_rate_ $opt(qs_alloc_rate)
Agent/QSAgent set qs_enabled_ $opt(qs) // I have even checked this by putting it 1
Agent/QSAgent set state_delay_ $opt(qs_state_delay)
Agent/QSAgent set rate_function_ $opt(qs_rate_function)
Agent/QSAgent set algorithm_ $opt(qs_algorithm)
Agent/QSAgent set threshold_ $opt(qs_threshold)

Agent/TCPSink set qs_enabled_ true
Agent/TCP/Newreno set qs_enabled_ true
Agent/TCP/Reno set qs_enabled_ true

if {$opt(qs)} {
Agent/TCP set tcp_qs_recovery_ $opt(tcp_qs_recovery)
Agent/TCP/Reno set tcp_qs_recovery_ $opt(tcp_qs_recovery)
}

Agent/TCP/Reno set qs_request_mode_ $opt(qs_request_mode)
Agent/TCP/Reno set qs_thresh_ $opt(qs_set_ssthresh)
Agent/TCP/Reno set rate_request_ $opt(qs_rate_request)
Agent/TCP/Reno set qs_rtt_ $opt(qs_rtt)

Agent/TCP/Newreno set qs_request_mode_ $opt(qs_request_mode)
Agent/TCP/Newreno set qs_thresh_ $opt(qs_set_ssthresh)
Agent/TCP/Newreno set rate_request_ $opt(qs_rate_request)
Agent/TCP/Newreno set qs_rtt_ $opt(qs_rtt)

5. I debugged the tcp.cc, reno.cc, qs_hdr.cc, QSagent.cc. Below is the sequence of the functions called.

Here is the set of printf statements:

Called from TCP.cc for sender ttl_diff: -127
QS Response is being made in TCPSink ttl: -129
QS request is called from Reno sender
Process QS in TCP.cc is called

flag: 2 ttl: -129 ttl_diff: -127 rate: 2

The last line shows : flag= QS response, ttl = receiver side ttl_diff, diff = sender side ttl, which is displayed from process quickstart function in tcp.cc

The reason I feel that the QS is not being approved is the ttl_diff at sender and receiver are not same.
Perhaps because the nodes are not decrementing the qs->ttl? I have configured the nodes by the way it has been done in test.tcl for quickstart that I found in ns2.31/tcl/test/test-all-quickstart.tcl … I have also checked my code by setting $my_node set qs_agent_ [new agent/QSAgent], to check if now the node works as QS agent or QS/Agent.cc is called.. but to no avail.

6. A final word, I fixed/hard coded the value for ttl_diff at sender and receiver inside the tcp.cc code, the QS got approved and the cwnd in the start rose to 47, 28, 20 for the three reno sources.

Kindly if someone is working on/ or has worked with Quick start TCP in ns2, please reply.

Regards.

Hira Samir.