Jun 21, 2006
Feb 24, 2006
Overview of TCP congestion control
TCP implements a window based flow control mechanism. Roughly speaking, a window based protocol means that the so called current window size defines a strict upper bound on the amount of unacknowledged data that can be in transit between a give sender-receiver pair. Originally TCP’s flow control was governed simply by the maximum allowed window size advertised by the receiver and the policy that allowed the sender to send new packets only after receiving the acknowledgement for the previous packet.
After the occurrence of the so called congestion collapse in the Internet in the late 80’s it was realised, however, that special congestion control algorithms would be required to prevent the TCP senders from overrunning the resources of the network. In 1988, Tahoe TCP was released including three congestion control algorithms: slow start, congestion avoidance and fast retransmit. In 1990 Reno TCP, providing one more algorithm called fast recovery, was released.
Besides the receiver’s advertised window, awnd, TCP’s congestion control introduced two new variables for the connection: the congestion window, cwnd, and the slowstart threshold, ssthresh. The window size of the sender, w, was defined to be
w = min(cwnd, awnd),
instead of being equal to awnd. The congestion window can be thought of as being a counterpart to advertised window. Whereas awnd is used to prevent the sender from overrunning the resources of the receiver, the purpose of cwnd is to prevent the sender from sending more data than the network can accommodate in the current load conditions.
The idea is to modify cwnd adaptively to reflect the current load of the network. In practice, this is done through detection of lost packets. A packet loss can basically be detected either via a time-out mechanism or via duplicate ACKs.
If a packet has been lost, the receiver keeps sending acknowledgements but does not modify the sequence number field in the ACK packets. When the sender observes several ACKs acknowledging the same packet, it concludes that a packet has been lost.
Labels: congestion, protocol, tcp
Jan 26, 2006
Exercise 3: Analyze Bandwidth Share of TCP and UDP Traffic
It is equivalently important to understand the ns-2 output trace format and have some knowledge on how to extract relevant information. This exercise is dedicated to familiarize you with ns-2's output format, in particular by trace-all, and techniques to do trace post-processing.
Topology: Use the simple.tcl example discussed in class, but first swap the source/destination of udp1 i.e. make its source be n1 and destination n3.
As a result of running ns on the modified simple.tcl, we obtain an output file "simple.tr". It contains information of all packets enqueued (+), dequeued (-), received (r) and dropped (d).
a. Modify the simple.tcl (name this, say, simple1.tcl) so that
Extract information from the "simple.tr" file and compute the total bytes of TCP (tcp) and UDP (cbr) traffic over link 2-3 for the duration of the simulation. Then, compute total TCP and UDP/CBR traffic in bytes and ratios of TCP and UDP/CBR to the total. Finally, comment on the bandwidth share of TCP vs. UDP/CBR.
b. Modify the simple1.tcl file (name this simple2.tcl) so that
Extract the information from the new simple.tr file and recompute the parameters above. What do you notice?
Note: Fill in the blanks according to your understanding of trace format in the following awk command for computing the total bytes of TCP or UDP traffic
awk '$1=="r" && ??==2 && ??==3 && $5=="??" {a += ??} END {print a}' simple1.tr
simple.tcl script
#create scheduler
set ns [new Simulator]
#choose colors
$ns color 0 blue
$ns color 1 red
$ns color 2 green
#turn tracing on
set f [open simple.tr w]
$ns trace-all $f
set nf [open simple.nam w]
$ns namtrace-all $nf
#create topology
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
$ns duplex-link $n0 $n2 5Mb 2ms DropTail
$ns duplex-link $n1 $n2 5Mb 2ms DropTail
$ns duplex-link $n2 $n3 1.5Mb 10ms DropTail
#limit queue size (otherwise unlimited)
#$ns queue-limit $n2 $n3 5
#adjust nam orientation
$ns duplex-link-op $n0 $n2 orient right-up
$ns duplex-link-op $n1 $n2 orient right-down
$ns duplex-link-op $n2 $n3 orient right
#turn nam visualization for n2-n3 queue
$ns duplex-link-op $n2 $n3 queuePos 0.5
#create udp agent
set udp0 [new Agent/UDP]
#attach agent to node
$ns attach-agent $n0 $udp0
#select packet color for nam
$udp0 set class_ 0
#create a cbr application
set cbr0 [new Application/Traffic/CBR]
#attach application to agent
$cbr0 attach-agent $udp0
#create another udp/cbr agent/application
set udp1 [new Agent/UDP]
$ns attach-agent $n3 $udp1
$udp1 set class_ 1
set cbr1 [new Application/Traffic/CBR]
$cbr1 attach-agent $udp1
#create and attach null agents
set null0 [new Agent/Null]
$ns attach-agent $n3 $null0
set null1 [new Agent/Null]
$ns attach-agent $n1 $null1
$ns connect $udp0 $null0
$ns connect $udp1 $null1
#schedule the start of cbr traffic
$ns at 1.0 "$cbr0 start"
$ns at 1.1 "$cbr1 start"
#create and attach a TCP agent source/sink
set tcp [new Agent/TCP]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns attach-agent $n0 $tcp
$ns attach-agent $n3 $sink
$ns connect $tcp $sink
#attach an ftp application to the TCP agent
set ftp [new Application/FTP]
$ftp attach-agent $tcp
#schedule start of ftp application
$ns at 1.2 "$ftp start"
#schedule end of ftp application
$ns at 5.0 "$ftp stop"
#$ns at 5.0 "$ns detach-agent $n0 $tcp ; $ns detach-agent $n3 $sink"
#print the (default) cbr values
puts [$cbr0 set packetSize_]
puts [$cbr0 set interval_]
$ns at 6.0 "finish"
proc finish {} {
global ns f nf
$ns flush-trace
close $f
close $nf
#puts "running nam..."
#exec nam simple.nam &
exit 0
}
$ns run
** Refer to previous post on Network Simulator, Ns-2 Trace format