Yu Cheng (Jade) ICS 351 Lab Report 5 part 2 November 16, 2008 [Exercise 5A] We connected the ethernet interfaces of PC1, PC2, and the routers. We used command `echo "0" > /proc/sys/net/ipv4/ip_forward` to disable the IP forwarding on both PC1 and PC2. We then used the following commands to configure the interfaces of PC1 and PC2: on PC1: `ifconfig eth0 10.0.1.11/24` on PC1: `ifconfig eth1 10.0.5.11/24` on PC2: `ifconfig eth0 10.0.2.22/24` on PC2: `ifconfig eth1 10.0.5.22/24` After configuring the IP addresses of the PCs, we added the default routes for them as shown on the text book figure. We used command `route -n` to check the existing routing entries. There were no default gateway on both PCs. We used the following commands to add the default routes: on PC1: `route add default gw 10.0.1.3` on PC2: `route add default gw 10.0.2.4` We also configured the routers using the following commands: Router1 yourname# config t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.3.2 yourname(config)# ip route 10.0.4.0 255.255.255.0 10.0.1.3 yourname(config)# interface fa0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.1.1 255.255.255.0 yourname(config-if)# interface fa0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.3.1 255.255.255.0 yourname(config-if)# end Router2 yourname# config t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.3.1 yourname(config)# ip route 10.0.4.0 255.255.255.0 10.0.2.4 yourname(config)# interface fa0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.2.2 255.255.255.0 yourname(config-if)# interface fa0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.3.2 255.255.255.0 yourname(config-if)# end Router3 yourname# config t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.4.4 yourname(config)# ip route 10.0.3.0 255.255.255.0 10.0.1.1 yourname(config)# interface fa0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.1.3 255.255.255.0 yourname(config-if)# interface Serial0/0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.4.3 255.255.255.0 yourname(config-if)# end Router4 yourname# config t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.4.3 yourname(config)# ip route 10.0.3.0 255.255.255.0 10.0.2.2 yourname(config)# interface fa0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.2.4 255.255.255.0 yourname(config-if)# interface Serial0/0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.4.4 255.255.255.0 yourname(config-if)# end We intended to check which end of the cable (Router3 or Router4) was DCE end. We didn't figure out where to look at first, so we used the following commands on both Router3 and Router4. yourname# config t yourname(config)# interface Serial 0/0/1 yourname(config-if)# clock rate 9600 Neither of Router3 and Router4 showed any error message. We then used command `show controllers Serial0/0/1` to check the setting. We saw that Router3 is the DCE end the the configuration was successful. We then issued a ping and a traceroute commands from PC1 to both of the interfaces on PC2, and from PC1 to PC2 as well. The commands were successful. [Exercise 5B] We started the wireshark on PC1 interface 1 to caputure traffic between PC1 and PC2 for this exercise. We then started a telnet session from PC1 to PC2 using command `telnet 10.0.5.22`. Question 3-a For the first part of the exercise, We typed three charactors "e", "d", and "o" at a regular speed. We observed three packets for each charactor. The first one was a telnet data packet from the sender to the receiver. It had a flag type [PSH, ACK]. The second one was also a telent data packet from the receiver to the sender. It also had a flag type [PSH, ACK]. The third packet from the senter to the receiver was a TCP session. It has a flag type [ACK]. We didn't see four packets. We didn't see an ACK for the first packet with a payload. To reduce the number of segments, TCP combined two segments in a delayed acknowledgement. In this case, each end waited for some time to see if there was any data going in the same direction as acknowledgement. If it foud one, the acknowledgement was piggybacked with the data. Question 3-b By observing the three sets of packets in the wireshark, We got three sets of time intervels that the client waited before sending ACKs. -------------------------------------------------------------------------------- Packet 3 for "e": Arrival Time: Nov 13, 2008 17:11:00.869828000 Packet 2 for "e": Arrival Time: Nov 13, 2008 17:11:00.869720000 - _________________________________ 108 micorseconds -------------------------------------------------------------------------------- Packet 3 for "d": Arrival Time: Nov 13, 2008 17:11:01.075398000 Packet 2 for "d": Arrival Time: Nov 13, 2008 17:11:01.075331000 - _________________________________ 167 micorseconds -------------------------------------------------------------------------------- Packet 3 for "o": Arrival Time: Nov 13, 2008 17:11:01.232024000 Packet 2 for "o": Arrival Time: Nov 13, 2008 17:11:01.231946000 - _________________________________ 78 micorseconds -------------------------------------------------------------------------------- TCP waited too see if there was any data going in the same direction. If there was, the ACK can be piggybacked with the data. This was what we observed in the second packets of each communication. Question 3-c We didn't get any [ACK] packets from the server, instead we got the piggybacked echo packets with a flag type [PSH, ACK]. The time intervels are listed as below. -------------------------------------------------------------------------------- Packet 2 for "e": Arrival Time: Nov 13, 2008 17:11:00.869720000 Packet 1 for "e": Arrival Time: Nov 13, 2008 17:11:00.869248000 - _________________________________ 472 micorseconds -------------------------------------------------------------------------------- Packet 2 for "d": Arrival Time: Nov 13, 2008 17:11:01.075331000 Packet 1 for "d": Arrival Time: Nov 13, 2008 17:11:01.075038000 - _________________________________ 293 micorseconds -------------------------------------------------------------------------------- Packet 2 for "o": Arrival Time: Nov 13, 2008 17:11:01.231946000 Packet 1 for "o": Arrival Time: Nov 13, 2008 17:11:01.231522000 - _________________________________ 424 micorseconds -------------------------------------------------------------------------------- Question 3-d Both the first and the second TCP segments carried typed characters as paylaod. They had the same flag type [PSH, ACK]. They carried application data, so they had a flag "push". They both at the same time piggybacked the previous ACK, so also servered as the acknowledgements. Question 3-e -------------------------------------------------------------------------------- Packet 1 "e": Src Port: 35025, Dst Port: telnet (23), Seq: 175, Ack: 238, Len: 1 Packet 2 "e": Src Port: telnet (23), Dst Port: 35025, Seq: 238, Ack: 176, Len: 1 Packet 3 "e": Src Port: 35025, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 0 -------------------------------------------------------------------------------- Packet 1 "d": Src Port: 35025, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 1 Packet 2 "d": Src Port: telnet (23), Dst Port: 35025, Seq: 239, Ack: 177, Len: 1 Packet 3 "d": Src Port: 35025, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 0 -------------------------------------------------------------------------------- Packet 1 "o": Src Port: 35025, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 1 Packet 2 "o": Src Port: telnet (23), Dst Port: 35025, Seq: 240, Ack: 178, Len: 1 Packet 3 "o": Src Port: 35025, Dst Port: telnet (23), Seq: 178, Ack: 241, Len: 0 -------------------------------------------------------------------------------- We observed that the sequence number from PC1, the client increased by one from every first packet to the third packet. It looks like ACK packets didn't consume any sequence number, the same sequence number was used again for the next packet. The relative sequence number and the hexdacimal digits for these repeating sequence numbers were all the same. So, it won't couse confusion because TCP re-use the previous sequence number so that there is no gap in sequence numbers. Question 3-f The window size was advertised as "Window size: 5856 (scaled)" for all of the packets from the client to the server. Question 4-a For the second part of the exercise, we typed in the telnet client program very fast by holding the key. We wre missing [ACK] TCP segments from the client to the server. We observed one telent data packet followed by one echo and repeating in this patern. This is because the transmission was so fast the ACKs were piggybacked onto the next application data segments. For example, in the previous experiment we had the following time interval between the [ACK] and the next application data segment: -------------------------------------------------------------------------------- Packet 1 for "d": Arrival Time: Nov 13, 2008 17:11:01.075038000 Packet 3 for "e": Arrival Time: Nov 13, 2008 17:11:00.869828000 - _________________________________ 205210 microseconds -------------------------------------------------------------------------------- In this experiment, we had the following time interval between the telenet echo pacekt and the next application data packet. It was about 10 times faster. -------------------------------------------------------------------------------- Packet n + 1: Arrival Time: Nov 13, 2008 17:23:12.748355000 Packet n: Arrival Time: Nov 13, 2008 17:23:12.715711000 - _________________________________ 32644 microseconds -------------------------------------------------------------------------------- [Exercise 5C] We repeated the previous exercise and observed the traffic going through a slow link by setting the wireshark monitoring on the cooresponding interface. Question 3-a We observed three packets for each charactor that was typed in the telnet client. They were the same as what we saw in the previous exercise. -------------------------------------------------------------------------------- Packet 1 "e": Src Port: 35025, Dst Port: telnet (23), Seq: 175, Ack: 238, Len: 1 Packet 2 "e": Src Port: telnet (23), Dst Port: 53884, Seq: 238, Ack: 176, Len: 1 Packet 3 "e": Src Port: 53884, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 0 -------------------------------------------------------------------------------- Packet 1 "d": Src Port: 53884, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 1 Packet 2 "d": Src Port: telnet (23), Dst Port: 53884, Seq: 239, Ack: 177, Len: 1 Packet 3 "d": Src Port: 53884, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 0 -------------------------------------------------------------------------------- Packet 1 "o": Src Port: 53884, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 1 Packet 2 "o": Src Port: telnet (23), Dst Port: 53884, Seq: 240, Ack: 178, Len: 1 Packet 3 "o": Src Port: 53884, Dst Port: telnet (23), Seq: 178, Ack: 241, Len: 0 -------------------------------------------------------------------------------- As we typed more quickly, we observed that one segment carried more than one keystroke of data. -------------------------------------------------------------------------------- Packet 1: Src Port: 53884, Dst Port: telnet (23), Seq: 186, Ack: 249, Len: 2 Packet 2: Src Port: telnet (23), Dst Port: 53884, Seq: 249, Ack: 188, Len: 2 Packet 3: Src Port: 53884, Dst Port: telnet (23), Seq: 188, Ack: 251, Len: 0 -------------------------------------------------------------------------------- Question 3-b Yes, we do oberverd delayed acknowledgments, as we typed quickly. Just like the previous exercise, if there was data to sent to the same direction. It waited and piggybacked onto the data segment. Question 3-c We observed multiple characters that were transmitted in the payload of one segment. I've attached the data in question 3-a. This is due to the low rate of the connection. It introduced significant delays between the client and the server. A heuristic in TCP, called Nagle's algorithm forces the sender to wait for an ACK after transmitting a small segment. So multiple segments were boundled and transmitted together. [Exercise 6A] We started wireshark on PC1 interface 1, which monitored on the fast link throught ethernet cables. We started a ttcp connection between PC1 and PC2 throught the fast link. We used commands: on PC2: `ttcp -rs -l1000 -n500 -p4444` on PC1: `ttcp -ts -l1000 -n500 -p4444 -D 10.0.5.22` Question 4-a -------------------------------------------------------------------------------- Packet 2 e.g 1: Arrival Time: Nov 13, 2008 17:42:51.791697000 Packet 1 e.g 1: Arrival Time: Nov 13, 2008 17:42:51.791572000 - _________________________________ 125 micorseconds -------------------------------------------------------------------------------- Packet 2 e.g 2: Arrival Time: Nov 13, 2008 17:42:51.792477000 Packet 1 e.g 2: Arrival Time: Nov 13, 2008 17:42:51.792376000 - _________________________________ 101 micorseconds -------------------------------------------------------------------------------- Packet 2 e.g 3: Arrival Time: Nov 13, 2008 17:42:51.811939000 Packet 1 e.g 3: Arrival Time: Nov 13, 2008 17:42:51.811845000 - _________________________________ 94 micorseconds -------------------------------------------------------------------------------- It looks like about 100 microseconds time interval of the ACKs from the receiver. There were less ACKs from the receiver than the TCP segments sent. I think this can be explained by Nagle's algorithm too. The ACKs were all to the same direction, TCP waited and boundled some ACKs and sent them together. Question 4-b I randomly selected two sets of three consecutive ACKs from the wireshark data. -------------------------------------------------------------------------------- ACK 1: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 128001, Len: 0 ACK 2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 130001, Len: 0 ACK 3: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 132897, Len: 0 -------------------------------------------------------------------------------- Ack: 130001 - Ack: 128001 = 2000 bytes Ack: 132897 - Ack: 130001 = 2896 bytes -------------------------------------------------------------------------------- ACK 1: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 192001, Len: 0 ACK 2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 194001, Len: 0 ACK 3: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 196001, Len: 0 -------------------------------------------------------------------------------- Ack: 194001 - Ack: 192001 = 2000 bytes Ack: 196001 - Ack: 194001 = 2000 bytes -------------------------------------------------------------------------------- One typical ACK acknowledges about 2~3k bytes of data. One TCP segment has 1000 or 1448 bytes data. So, one ACK acknowledges about two TCP segments. Question 4-c The window size advertised by the receiver started from "Win = 5856" in the [ACK] packet of the three way handshake, and increased gradually to "Win=269856" in the last [FIN, ACK] packet from the receiver to terminate the connection. Question 4-d I randomly selected two examples to calculate the time intervals of a TCP segment and it's ACK from the receiver. -------------------------------------------------------------------------------- PC1: Src Port: 36538, Dst Port: krb524 (4444), Seq: 405001, Ack: 1, Len: 1000 Arrival Time: Nov 13, 2008 17:42:51.837470000 PC2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 405001, Len: 0 Arrival Time: Nov 13, 2008 17:42:51.838051000 -------------------------------------------------------------------------------- 17:42:51.838051000 - 17:42:51.837470000 = 581 microseconds -------------------------------------------------------------------------------- PC1: Src Port: 36538, Dst Port: krb524 (4444), Seq: 397001, Ack: 1, Len: 1000 Arrival Time: Nov 13, 2008 17:42:51.836272000 PC2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 387001, Len: 0 Arrival Time: Nov 13, 2008 17:42:51.836486000 -------------------------------------------------------------------------------- 17:42:51.836486000 - 17:42:51.836272000 = 214 microseconds I took serveral hundreds of microseconds from the transmission of the segment until the ACK arrived at the sender. Question 4-e No, it didn't. The maximum amount of datat in one TCP segment was 1448 bytes, rather than the maximum amount of data allowed by the advertised window. This maybe due to the congestion window size control. TCP tried to send as large as it could. Apparently 1448 bytes per segment was the largest that TCP could send. Question 4-f -------------------------------------------------------------------------------- No. Time Source Destination Protocol 327 0.046173 10.0.5.22 10.0.5.11 TCP Info: krb524 > 50900 [FIN, ACK] Seq=1 Ack=500002 Win=269856 Len=0 -------------------------------------------------------------------------------- No. Time Source Destination Protocol 328 0.046283 10.0.5.11 10.0.5.22 TCP Info: 50900 > krb524 [ACK] Seq=500002 Ack=2 Win=5856 Len=0 -------------------------------------------------------------------------------- After PC2 finished sending all the ACKs, it sent a [FIN, ACK] packet to PC1 requesting a termination of the connection. PC1 sent back a [ACK] packet and the connection terminated. [Exercise 6B] We reconfigured the clock rate at Router3, the DCE end of the serial WAN link. yourname# config t yourname(config)# interface Serial0/0/1 yourname (config-if)# clock rate 125000 We repeated the previous exercise and observed the traffic going through a slow link by setting the wireshark monitoring on the cooresponding interface, and establishing ttcp connection on the cooresponding interface. on PC2: `ttcp -rs -l1000 -n500 -p4444` on PC1: `ttcp =ts -l1000 -n500 -p4444 -D 10.0.2.22` Question 4-a We observed a patern in which every one or two TCP segments was followed by one ACK. In the last exercise, however, a bounch of application data TCP segments were sent, and then a bounch of ACKs from the receiver were sent. Question 4-b Yes. In the last exercise we observed that one typical ACK covered about two TCP segment. In this exercise, it seems like one ACK acknowledged the data size of one TCP segment. I randomly picked several consecutive ACKs. -------------------------------------------------------------------------------- ACK 1: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 18793, Len: 0 ACK 2: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 20241, Len: 0 ACK 3: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 21689, Len: 0 -------------------------------------------------------------------------------- Ack: 20241 - Ack: 18793 = 1448 bytes Ack: 21689 - Ack: 20241 = 1448 bytes -------------------------------------------------------------------------------- ACK 1: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 140993, Len: 0 ACK 2: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 142441, Len: 0 ACK 3: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 143889, Len: 0 -------------------------------------------------------------------------------- Ack: 142441 - Ack: 140993 = 1448 bytes Ack: 143889 - Ack: 142441 = 1448 bytes -------------------------------------------------------------------------------- Question 4-c No. The window size advertised by the receiver here looked the same as that in the previous exercise. It started at "Win = 5856" in the [ACK] packet of the three way handshake, and graduatly increased to "Win = 255936" in the [FIN, ACK] packet that was sent to terminate the TCP connection. Question 4-d No. The maximum TCP segment is 1448 bytes as we observed from the saved wireshark data. This might due to the congestion window control. [Exercise 6C] I used the wireshark dat saved in the lab. I generated four graphs and saved them as time-sequence-stevens.png, time-sequence-tcptrace.png, rtt.png, throughput.png. [Exercise 7A] The DCE clock rate was set to 125 kbps in the previous exercise. We started the wireshark traffic on the interface 0 of PC1 to monitor the slow link through serial WAN cable. We started a ttcp connection. on PC2: `ttcp -rs -l1000 -n500 -p4444` on PC1: `ttcp -ts -l1000 -n500 -p4444 -D 10.0.2.22` Question 4 -------------------------------------------------------------------------------- No. Time Source Destination Protocol 5 33.933589 10.0.1.11 10.0.2.22 TCP Info: 50966 > krb524 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=7925644 TSER=0 WS=5 : Transmission Control Protocol, Src Port: 50966 (50966), Dst Port: krb524 (4444), Seq: 0, Len: 0 : Options: (20 bytes) Maximum segment size: 1460 bytes SACK permitted : -------------------------------------------------------------------------------- No. Time Source Destination Protocol 6 33.943974 10.0.2.22 10.0.1.11 TCP Info: krb524 > 50966 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 : Transmission Control Protocol, Src Port: krb524 (4444), Dst Port: 50966 (50966), Seq: 0, Ack: 1, Len: 0 : Options: (20 bytes) Maximum segment size: 1460 bytes SACK permitted : -------------------------------------------------------------------------------- No. Time Source Destination Protocol 7 33.944107 10.0.1.11 10.0.2.22 TCP Info: 50966 > krb524 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=7925656 TSER=7925251 : Transmission Control Protocol, Src Port: 50966 (50966), Dst Port: krb524 (4444), Seq: 1, Ack: 1, Len: 0 : Options: (12 bytes) NOP NOP -------------------------------------------------------------------------------- The sender and receiver did negotiate to permit SACKs or not. I think it said in the las ACK in three way handshake that they didn't permit SACKs. Question 5-a -------------------------------------------------------------------------------- 1st: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448 Arrival Time: Nov 13, 2008 18:59:55.314858000 2nd: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448 Arrival Time: Nov 13, 2008 19:00:03.730858000 3rd: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448 Arrival Time: Nov 13, 2008 19:00:20.562855000 4th: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448 Arrival Time: Nov 13, 2008 19:00:54.226865000 5th: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448 Arrival Time: Nov 13, 2008 19:10:01.556548000 -------------------------------------------------------------------------------- 19:00:03.730858000 - 18:59:55.314858000 = 8.416 sec 19:00:20.562855000 - 19:00:03.730858000 = 16.832 sec 19:00:54.226865000 - 19:00:20.562855000 = 33.664 sec 19:10:01.556548000 - 19:00:54.226865000 = 9 min 7.330 sec -------------------------------------------------------------------------------- The last time interval to considerably longer than the previous one. That's because TCP was waiting for ARP to resolve. The time that ARP requests used didn't count in the retransmission time counting. So, the patern followed the binary exponential backup. Question 5-b The maximum time we observed was a little more than 1 min. After that long time of waitting, TCP gave up and terminated the connection. Question 5-c We observed 5 retransmissions in total. After the 5 retransmission while no ACKs receiving, TCP gave up, and the sender sent out a [FIN, PSH, ACK] packet to terminate the conneciton. Question 6 We observed that the retransmission was different. There was one successful retransmission. After the negociation, No SACKs were allowed. [Exercise 7B] We re-configured the DCE clock time to 64 kbps for this exercise. yourname# config t yourname(config)# interface Serial0/0/1 yourname(config-if)# clock rate 64000 We started the wireshark on the interface 0 to monitor the slow link. We used the following commands to start the TCP conncetion between PC1 and PC2. on PC2: `ttcp -rs -l1000 -n500 -p4444` on PC1: `ttcp -ts -l1000 - n500 -p444 -D 10.0.2.22` We then issued a ping command on PC1 `ping -f 10.0.2.22` to flood ICMP Echo Recall, which would overfolw the buffers of Router3 at the serial WAN link. Question 6-a I save the time-sequence (stevens) graph started as 7b-retransmit-stevens.png. The graph started from a packet from PC1 to PC2. The packets losses happened three times. It looks like the time intervals follow the patern of the binary exponential backup. Question 6-b The advertised window size can be determined in the time-seqence (stevens) graph. It increased gradually at first. Then there was the first pack drop. The window size shrunk into half of its size. Then it tried to increase. After the second packet drop, it shrunk to half of its size, and so on. Question 6-c Most of the retranmission packets were regular retransmission. There were only two fast retransmission packets through out the wireshark file that we saved. They oppeared at the beginning of each retransmssion section.