Hi,
I am Hira. 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.
