CSE 573S Protocols for Computer Networks (Spring 2005 Final Project)

Transcription

1 CSE 573S Protocols for Computer Networks (Spring 2005 Final Project) To Investigate the degree of congestion control synchronization of window-based connections bottlenecked at the same link Kumar, Vikram So-In Chakchai May 10 th, 2005 (1)

2 Abstract : Our project basically investigates the degree of congestion control synchronization of window-based connections bottlenecked at the same link and for this we conducted experiment s in ns2 and in cec labs which is located in Washington University in St. louis. The questions which we expected to answer where What is the fraction of connections that do not notice congestion before it is resolved by the other connections? & to identify the conditions for the buffer to always remain full. Some of the considered parameters where number of connections, buffer size, delay of their paths and the bottleneck link capacity. 1. Introduction 1.1 Queuing Drop Model Figure 1.1: Drop Tail Queue [1] First model is Drop Tail Queue. In this model, FIFO queuing mechanism is implemented in order to drop packets when the queue overflows. This technique is simple use and less complexity which widely uses in the Internet; however, it would introduces global synchronization when packets are dropped from several connections. Figure 1.2: Random Drop Queue [1] Second model is Random Drop Queue. When a packet arrives and the queue is full, randomly choose a packet from the queue to drop. Figure 1.3: Random Early Drop Queue [1] (2)

3 Third model is Random Early Drop Queue. If the queue length exceeds a drop level, then the router drops each arriving packet with a fixed drop probability. The big advantage for this technique is that it can reduce the global synchronization. 1.2 TCP Synchronization TCP sends as many packets as possible until it detects a loss in packet at which point it reduces the sending rate. Like many congestion control protocols, TCP uses packet loss as an indication of congestion. (Figure 1.4) Ideally, if losses are synchronized, TCP flows sharing bottleneck receive loss indications at around the same time decrease rates at around the same time periods due to which the link bandwidth is significantly underutilized. (Figure 1.5) As a result, if rate synchronization can be prevented, then bandwidth will be used more efficiently. (Figure 1.6) Figure 1.4: TCP behavior [2] Figure 1.5: Synchronization of TCP behavior (3)

4 Figure 1.6: De-synchronization of TCP behavior 2. Explanation of the implementation and experimental setup 2.1 Design Choice We use four congestion control algorithms for TCP connections and they are Slow start, Congestion Avoidance, Fast retransmit & Fast recovery for fast recovery & retransmit we use New Reno algorithm and Drop tail queue model for the buffer in the router. 2.2 How does the algorithm work? The four congestion control algorithms work in the following way Slow start: The slow start and congestion avoidance algorithms MUST be used by a TCP sender to control the amount of outstanding data being injected into the network.to implement these algorithms, two variables are added to the TCP per-connection state. The congestion window (cwnd) is a sender-side limit on the amount of data the sender can transmit into the network before receiving an acknowledgment (ACK), while the receiver's advertised window (rwnd) is a receiver-side limit on the amount of outstanding data. The minimum of cwnd and rwnd governs data transmission. Another state variable, the slow start threshold (ssthresh), is used to determine whether the slow start or congestion avoidance algorithm is used to control data transmission. The initial congestion window size is MUST be less than or equal to 2*SMSS bytes and MUST NOT be more than 2 segments. The initial value of ssthresh MAY be arbitrarily high (for example, some implementations use the size of the advertised window), but it may be reduced in response to congestion. The slow start algorithm is used when cwnd < ssthresh. During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that acknowledges new data. Slow start ends when cwnd exceeds ssthresh (or, optionally, when it reaches it, as noted above) or when congestion is observed. (4)

5 Fast Retransmit: A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives. The purpose of this ACK is to inform the sender that a segment was received out-of-order and which sequence number is expected. From the sender's perspective, duplicate ACKs can be caused by a number of network problems. First, they can be caused by dropped segments. In this case, all segments after the dropped segment will trigger duplicate ACKs. Second, duplicate ACKs can be caused by the re-ordering of data segments by the network (not a rare event along some network paths [Pax97]). Finally, duplicate ACKs can be caused by replication of ACK or data segments by the network. In addition, a TCP receiver SHOULD send an immediate ACK when the incoming segment fills in all or part of a gap in the sequence space. The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire. After the fast retransmit algorithm sends what appears to be the missing segment, the "fast recovery" algorithm governs the transmission of new data until a non-duplicate ACK arrives. New Reno Fast Recovery: In New-Rent, partial ACKs do not take TCP out of Fast Recovery. Instead, partial ACKs received during Fast Recovery are treated as an indication that the packet immediately following the acknowledged packet in the sequence space has been lost, and should be retransmitted. Thus, when multiple packets are lost from a single window of data, New- Rent can recover without a retransmission timeout, retransmitting one lost packet per round-trip time until all of the lost packets from that window have been retransmitted. New-Rent remains in Fast Recovery until all of the data outstanding when Fast Recovery was initiated has been acknowledged. The fast retransmit and fast recovery algorithms are usually implemented together as follows. 1. When the third duplicate ACK is received, set ssthresh to no more than the value given in equation Retransmit the lost segment and set cwnd to ssthresh plus *SMSS.This artificially "inflates" the congestion window by the number of segments (three) that have left the network and which the receiver has buffered. 3. For each additional duplicate ACK received, increment cwnd by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network. (5)

6 4. Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window. 5. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This is termed "deflating" the window. Congestion Avoidance: The congestion avoidance algorithm is used when cwnd > ssthresh. During congestion avoidance, cwnd is incremented by 1 full-sized segment per round-trip time (RTT). Congestion avoidance continues until congestion is detected. One formula commonly used to update cwnd during congestion avoidance is given in equation 2: cwnd += SMSS*SMSS/cwnd (2) This adjustment is executed on every incoming non-duplicate ACK. Equation (2) provides an acceptable approximation to the underlying principle of increasing cwnd by 1 full-sized segment per RTT. Drop tail Queue Buffer : Firstinfirstout, drop tail when full was the original queue management scheme used in Internet routers. With this scheme packets are enqueued at the tail of a queue as they arrive and dequeued from the head of queue when there is capacity on the link. Problems arise when queues overflow due to bursty of packets. At this moment more packets can not be admitted and they have to be dropped where they are entering, this means, at the tail of the queue. That's the reason why all queuing discipline based on the FIFO queue are known as DropTail queues. (6)

7 3. Description of the used of hosts and network path for ns2 simulation Figure 3.1: Network Design and Path setup for ns2 simulation In ns2 simulation, we did an experiment by varying four standard parameters, namely, the number of connections, delays of their paths, bottleneck link capacity and buffer size in order to investigate the impact of these parameters had on the degree of TCP synchronization & on the Router buffer behavior. Basically, FTP connections using TCP are sent continuously for 200 sec from each node passed through simulated router and then it forwards each packet to the receiver through bottleneck link. 536 bytes TCP packet is sent each in order to comply the minimum standard packet for Internet (plus extra 40 bytes for IP and TCP headers). set ns [new Simulator] set nf [open out.nam w] $ns namtrace-all $nf set tf [open out.tr w] set windowvstime [open win w] set param [open parameters w] $ns trace-all $tf #Define a 'finish' procedure proc finish { { global ns nf tf $ns flush-trace close $nf close $tf exec nam out.nam & exit 0 #Create bottleneck and dest nodes set n2 [$ns node] set n3 [$ns node] (7)

8 #Create links between these nodes $ns duplex-link $n2 $n3 1Mb 20ms DropTail set NumbSrc 4 set Duration 200 #Source nodes for {set j 1 {$j<=$numbsrc { incr j { set S($j) [$ns node] # Create a random generator for starting the ftp and for bottleneck link delays set rng [new RNG] $rng seed 2 # parameters for random variables for begenning of ftp connections set RVstart [new RandomVariable/Uniform] $RVstart set min_ 0 $RVstart set max_ 7 $RVstart use-rng $rng #We define random starting times for each connection for {set i 1 {$i<=$numbsrc { incr i { #set startt($i) [expr [$RVstart value]] set startt($i) 0 set dly($i) 1 puts $param "startt($i) $startt($i) sec" #Links between source and bottleneck for {set j 1 {$j<=$numbsrc { incr j { $ns duplex-link $S($j) $n2 10Mb $dly($j)ms DropTail $ns queue-limit $S($j) $n2 20 #Set Queue Size of link (n2-n3) to 100 $ns queue-limit $n2 $n3 64 #TCP Sources for {set j 1 {$j<=$numbsrc { incr j { set tcp_src($j) [new Agent/TCP/Reno] $tcp_src($j) set window_ 8000 #TCP Destinations for {set j 1 {$j<=$numbsrc { incr j { set tcp_snk($j) [new Agent/TCPSink] #Connections for {set j 1 {$j<=$numbsrc { incr j { $ns attach-agent $S($j) $tcp_src($j) $ns attach-agent $n3 $tcp_snk($j) $ns connect $tcp_src($j) $tcp_snk($j) #FTP sources for {set j 1 {$j<=$numbsrc { incr j { set ftp($j) [$tcp_src($j) attach-source FTP] #Parametrisation of TCP sources (8)

9 for {set j 1 {$j<=$numbsrc { incr j { $tcp_src($j) set packetsize_ 536 #Schedule events for the FTP agents: for {set i 1 {$i<=$numbsrc { incr i { $ns at $startt($i) "$ftp($i) start" $ns at $Duration "$ftp($i) stop" proc plotwindow {tcpsource file k { global ns NumbSrc set time 0.01 set now [$ns now] set cwnd [$tcpsource set cwnd_] if {$k == 1 { puts -nonewline $file "$now \t $cwnd \t" else { if {$k < $NumbSrc { puts -nonewline $file "$cwnd \t" if { $k == $NumbSrc { puts -nonewline $file "$cwnd \n" $ns at [expr $now+$time] "plotwindow $tcpsource $file $k" # The procedure will now be called for all tcp sources for {set j 1 {$j<=$numbsrc { incr j { $ns at 0.1 "plotwindow $tcp_src($j) $windowvstime $j" set qfile [$ns monitor-queue $n2 $n3 [open queue.tr w] 0.01] [$ns link $n2 $n3] queue-sample-timeout; $ns at [expr $Duration] "finish" $ns run Table 3.1: Simulated Drop tail TCL script for ns2 simulator [3] Note: The bold line indicates the modification we made for all the concerned parameters Considering the parameters, that we anticipated to be most effect on the degree of TCP synchronization, we ran four experiments in order to analyze their impact. First scenario, we fixed the number of connections and varied the buffer size from 256 KB, 512 KB to 1024 KB, and found out the relationship between the CWND for each connection with the relative buffer size. (Figure 3.1) In this case, each input delay path was set to 1 ms and input link capacity was 10 Mbps. Also, output link capacity is limited at 1 Mbps with 20 ms delay. After that, we increased the number of connection from 4, 8, 16 to 32 nodes. (Figure 3.2, 3.3, 3.4, and 3.5) (9)

10 Figure 3.2: CWND and Buffer graph consisting of 4 nodes with 256, 512, and 1024 buffer size (10)

11 Figure 3.3: CWND and Buffer graph consisting of 8 nodes with 256, 512, and 1024 buffer size. (11)

12 Figure 3.3: CWND and Buffer of 16 nodes with 256, 512, and 1024 buffer (12)

13 Figure 3.4: CWND and Buffer of 32 nodes with 256, 512, and 1024 buffer OBSERVATIONS: According to the above graphs, we can see that by increasing the number of connections or nodes; the connections still remain synchronized which is a result of all connections looking at congestion at the same time. As the buffer size is increased keeping the number of connections constant, the connections still remain synchronized. With increase in buffer size we don t see the queuing delay of the connections vary and also all connections look at the congestion at the same time. In order to verify that having varied initial delay (de-synchronization) does not impact the TCP behavior compared with having the same initial delay for each connection. Another experiment was setup by randomly varying the starting times which uniformly distributed between 0 and 7 sec. (Figure 3.5.1) It showed that when we ran the experiment for some period of time, TCP would behave like the way the same start up did (Figure 3.2) (13)

14 However, all later experiment setup would be based of the synchronization for start up delay. Figure 3.5: CWND and Buffer of 8 nodes with 256, 512, and 1024 buffer (initial desynchronization) Apart from the first scenario, in order to confirm that increasing the number of connections does not affect the degree of TCP synchronization. Another experiment was also set up by fixed buffer, 64 KB, and varied the number of connections from 4, 8, 16, and 32 nodes. (Figure 3.6) (14)

15 Figure 3.6: CWND and Buffer of 64 with 4, 8, 16, and 32 nodes Third scenario, we did experiment to find out the impact of link delay to TCP synchronization and Router buffer. (Figure 3.7) Input link delay is varied from 0.01, 0.1, 1, to 10 ms with fixing the number of connections to 8 nodes. Output link capacity is still limited at 1 Mbps with 20 ms delay. (15)

16 Figure 3.7: CWND and Buffer of 8 nodes with 0.01, 0.1, 1, and 1ms input link delay OBSERVATIONS: According to the above graphs, we can see that by varying the input link delay ; the connections still remain synchronized which is a result of all connections looking at congestion at the same time. This remains true as we increase the number of connections for the same scenario. (16)

17 Fourth scenario, in order to find the relationship of the effect between output link capacity and the degree of TCP synchronization, another experiment was also setup. (Figure 3.8) Output link capacity was varied from 0.01, 0.1, 1, to 10 Mbps with also fixed the number of connections to 8 nodes and 10 Mbps for each input link capacity and 1 ms link delay. Figure 3.8: CWND and Buffer of 8 nodes with 0.01, 0.1, 1, and 1Mbps output link capacity (17)

18 OBSERVATIONS: According to the above graphs,,we can see that by varying the output link capacity ; the connections still remain synchronized which is a result of all connections looking at congestion at the same time. This remains true as we increase the number of connections for the same scenario. 4. Description of the used of hosts and network path for software based router simulation In this simulation, Router based on Drop Tail Queue simulation was implemented with UDP simulated TCP behavior. In order to support MTU along the path, 548 bytes packet size was chosen to be 1 SMSS including 48 bytes header (sequence and acknowledge number and timestamp in both sending and acknowledge packet) from the client side. A text file, "INSTALL.B", was used to transfer among two hosts with file size 15,777,611 bytes. Figure 4.9: Network Design and Path setup for simulated Router simulation Because of the time and space constrains, we did experiment only to see the effect of buffer size and the number of connections with TCP synchronization and Router buffer behavior. We ran experiment on CEC lab (Washington University in St.Louis) with maximum 15 computers, one simulated router and one receiver. First scenario, we fixed the number of connection and varied the buffer size from 256 KB and 512 KB and find out the relationship between the CWND for each connection with the relative buffer size. (Figure 4.10, 4.11, and 4.12) Due to the real network, we could not control input delay; however, physical input link capacity was 100 Mbps, which all dedicated link connected to Cisco 6506 Switch; however, it was not the private network so it was possible to have a lot of cross traffic. Also, output link capacity was also 100 Mbps Ethernet shared with unknown delay. After that, we increased the number of (18)

19 connection from 4, 8, to 16 nodes. (x axis represents delivery time in second and y axis represents CWND size and Buffer size) Figure 4.10: CWND and Buffer of 4 nodes with 256 KB and 512 KB buffer Figure 4.11: CWND and Buffer of 8 nodes with 256 KB and 512 KB buffer (19)

20 Figure 4.12: CWND and Buffer of 16 nodes with 256 KB and 512 KB buffer OBSERVATIONS: According to the above graphs, the connections are completely desynchronized as we increase the number of connections and also when we increase the buffer size but even though the connections are completely desynchronized the buffer doesn t remain full all the time. There have also been losses when the buffer is not full. In fig 4.11 with 256 buffer size the effect of connections being completely desynchronized can be observed where one of the connections congestion window increases rapiadly and finishes the file transfer way ahead of time. 5. The experimental Observations 5.1 Ns2 simulation: The conclusion we can draw from the graphs which were generated from Ns2 simulation, is that by increasing number of connections, buffer size and varying output link capacity or input link delay; de-synchronization of tcp connections couldn t be achieved. The synchronization effect causes the oscillation in the buffer and hence doesn t keep the buffer always full. (20)

21 5.2 Simulated router simulation: When we ran the experiment in CEC network with cross traffic, we found that the result showed both the same and different TCP characteristics. First, connection s CWND size keeps increasing hence other connections loose a lot more packets when connections are in congestion avoidance mode. It may be because of de- synchronization effect. Second, percentage of buffer being full increases with number of connections. When buffer size is to be varied parameter, on decrease, many connections see the congestion and probability of the buffer being full is still high and on increase, fewer connections notice the congestion hence the buffer tends to be full. One interesting result we observed is not only the number of connections looking at congestion matter but also the CWND size of each connection which looks at the congestion matter when the connections are desynchronized. One more interesting result to be observed is that even with desynchronization of connections the buffer wasn t always full but this could be attributed to the nature of the router implementation. In this experiment we implemented the router in software and in software implementation the router faces problems of scheduling etc. 6. Conclusion The current belief is that because of tcp connections being completely synchronized the buffer is not always full or the link is not always full thus leading to under utilization of the resources. From our ns2 simulation we confirmed that the above statement is true for synchronized tcp connections. But, from our 2 nd experiment we learnt that de synchronization of tcp connections is not sufficient in keeping the buffer full or completely utilizing the resources( Reasons being- CWND size of each connection which looks at the congestion matter when the connections are de-synchronized ). We have also seen that the parameters like number of connections & buffer size effect for desynchronized connection but not for synchronized connections. The effects being more utilization of the buffer or the output link. 7.Future Work One of our observation has been the oscillation in the buffer graph (ns2 simulation) which results in underutilization of the resources. To solve this problem our hypotheses is, when connections are synchronized, if they can remember the first point of congestion then during the congestion avoidance mode before they hit the previous point of congestion they can query the router before they increase the congestion window size. By dong this we might be able to utilize the resources completely. (21)

22 8. Reference [1] Dan Rubenstein, Active Queue Mgmt Fairness Inference, Online available: [2] Bob Kinicki, Random Early Detection Gateways for Congestion Avoidance, Online available: [3] Eitan Altman and Tania Jimenez, NS Simulator for beginners, Univ. de Los Andes, Merida, Sophia-Antipolis, France, December [4] Srinivasan Seshan, More TCP & Congestion Control, Online available: www-2.cs.cmu.edu/~srini/ /S05/lectures/18-tcpdetails.ppt. [5] RFC 793, "Transmission Control Protocol". [6] RFC 2581, "TCP Congestion Control". [7] Kevin Fall and Sally Floyd, "Simulation-based Comparisons of Tahoe, Reno, and SACK TCP". (22)