IP LAB Question 1 The IP Address of my computer is 192.168.2.2 as
advertisement
IP LAB Question 1 The IP Address of my computer is 192.168.2.2 as indicated by the packet below: No. Time Source 1 0 192.168.2.2 Destination 66.94.234.13 Protocol Info ICMP Echo (ping) request Frame 1 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Lite-OnC_d0:f2:17 (00:a0:cc:d0:f2:17), Dst: Belkin_e2:0d:c1 (00:17:3f:e2:0d:c1) Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 66.94.234.13 (66.94.234.13) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 () Checksum: 0x760f [correct] Identifier: 0x0200 Sequence number: 44801 (0xaf01) Data (28 bytes) Question 2 Upper player protocol field contains value 1, which is the value assigned for ICMP. No. Time Source 1 0 192.168.2.2 Destination 66.94.234.13 Protocol Info ICMP Echo (ping) request Frame 1 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Lite-OnC_d0:f2:17 (00:a0:cc:d0:f2:17), Dst: Belkin_e2:0d:c1 (00:17:3f:e2:0d:c1) Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 66.94.234.13 (66.94.234.13) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 56 Identification: 0x6f66 (28518) Flags: 0x00 Fragment offset: 0 Time to live: 1 Protocol: ICMP (0x01) Header checksum: 0x5b49 [correct] Source: 192.168.2.2 (192.168.2.2) Destination: 66.94.234.13 (66.94.234.13) Internet Control Message Protocol For example, the value for TCP is 6, and for UDP its 17. Question 3 No. Time Source 1 0 192.168.2.2 Destination 66.94.234.13 Protocol Info ICMP Echo (ping) request Frame 1 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Lite-OnC_d0:f2:17 (00:a0:cc:d0:f2:17), Dst: Belkin_e2:0d:c1 (00:17:3f:e2:0d:c1) Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 66.94.234.13 (66.94.234.13) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 56 Identification: 0x6f66 (28518) Flags: 0x00 Fragment offset: 0 Time to live: 1 Protocol: ICMP (0x01) Header checksum: 0x5b49 [correct] Source: 192.168.2.2 (192.168.2.2) Destination: 66.94.234.13 (66.94.234.13) Internet Control Message Protocol The length of the IP header is 20 bytes as indicated in the “Header length” field. The size of the IP datagram payload is 36 bytes. Since the total length of the IP datagram is 56 bytes, and the header is 20 bytes, then the payload carried in the IP datagram must be 36 bytes. Question 4 Depending on the packet size set in PingPlotter, fragmentation may or may not occur. When the packet size was set to 56, no fragmentation occurred. When the packet size was set to 2000, then fragmentation started to occur. Wireshark notifies when fragmentation has occurred by coloring a packet in read, and displaying appropriate status information. This can also be observed by looking at the More Fragments flag in the IP header. No. Time Source Destination 1 0 192.168.2.2 66.94.234.13 (proto=ICMP 0x01, off=0) [Reassembled in #2] Protocol Info IP Fragmented IP protocol Frame 1 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: Lite-OnC_d0:f2:17 (00:a0:cc:d0:f2:17), Dst: Belkin_e2:0d:c1 (00:17:3f:e2:0d:c1) Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 66.94.234.13 (66.94.234.13) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 1500 Identification: 0xd655 (54869) Flags: 0x02 (More Fragments) 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..1. = More fragments: Set Fragment offset: 0 Time to live: 1 Protocol: ICMP (0x01) Header checksum: 0xceb5 [correct] Source: 192.168.2.2 (192.168.2.2) Destination: 66.94.234.13 (66.94.234.13) Reassembled IP in frame: 2 Data (1480 bytes) The fragment above comes from the first ICMP echo request. The payload is too big, so the datagram is fragmented. Question 5 The TTL value always changes. This behavior is appropriate, because the packet must traverse the next router on the path to the destination. The identification field also changes from packet to packet. This is necessary, because it is possible that some router will fragment the packet, so the identification field will be used to determine if a fragment belongs to a certain packet or not. The checksum also changes, because other fields in the packet change. Question 6 The fields that stay constant is source address, destination address, protocol field (ICMP), and some other less used options. These fields must stay constant, because the goal of the packet is to reach a particular destination at the ICMP layer, and then be sent back encapsulated with ICMP to the source. The field that must change is the TTL value. The identification number may need to be changed for every packet in case some router on the path decides to fragment the packet. Question 7 The identification number seems to be increasing by 1. Question 8 No. Time Source Destination 2 15:01:14 192.168.2.1 192.168.2.2 exceeded (Time to live exceeded in transit) Protocol Info ICMP Time-to-live Frame 2 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Belkin_e2:0d:c1 (00:17:3f:e2:0d:c1), Dst: Lite-OnC_d0:f2:17 (00:a0:cc:d0:f2:17) Internet Protocol, Src: 192.168.2.1 (192.168.2.1), Dst: 192.168.2.2 (192.168.2.2) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 56 Identification: 0xaf81 (44929) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0x45f0 [correct] Source: 192.168.2.1 (192.168.2.1) Destination: 192.168.2.2 (192.168.2.2) Internet Control Message Protocol Type: 11 (Time-to-live exceeded) Code: 0 (Time to live exceeded in transit) Checksum: 0xc5ee [correct] Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 66.94.234.13 (66.94.234.13) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 56 Identification: 0x6f66 (28518) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 1 Protocol: ICMP (0x01) Header checksum: 0x5b49 [correct] Source: 192.168.2.2 (192.168.2.2) Destination: 66.94.234.13 (66.94.234.13) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 () Checksum: 0x760f [incorrect, should be 0x46fe] Identifier: 0x0200 Sequence number: 44801 (0xaf01) The return reply to the first echo request is some content of the original packet encapsulated in ICMP. It can be seen that when the router observed a TTL of 1, it issued the ICMP reply above. The reply is also to the first echo request which had an identification number of 28518. Question 9 The TTL value never changes for each echo reply, because in order to receive the echo reply the router must’ve decreased a TTL of 1 to 0. So, all echo reply packets come with a TTL of 1. The identification number does change, because the original echo request packets had different identification numbers. Question 10 The first echo request packet has been fragmented into two packets. This is indicated by Wireshark by highlighting fragments in red, and the last one using the usual color scheme. Question 11 No. Time Source Destination 1 16:11:08 192.168.2.2 66.94.234.13 protocol (proto=ICMP 0x01, off=0) [Reassembled in #2] Protocol Info IP Fragmented IP Frame 1 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: Lite-OnC_d0:f2:17 (00:a0:cc:d0:f2:17), Dst: Belkin_e2:0d:c1 (00:17:3f:e2:0d:c1) Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 66.94.234.13 (66.94.234.13) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 1500 Identification: 0xd655 (54869) Flags: 0x02 (More Fragments) 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..1. = More fragments: Set Fragment offset: 0 Time to live: 1 Protocol: ICMP (0x01) Header checksum: 0xceb5 [correct] Source: 192.168.2.2 (192.168.2.2) Destination: 66.94.234.13 (66.94.234.13) Reassembled IP in frame: 2 Data (1480 bytes) The More fragments field is set to 1, therefore the packet above is a fragment of a larger packet. This is the first segment because the Fragment offset field is set to 0. If the Fragment offset field was set to larger number, then that would imply that the fragment contains data further in the message. The entire datagram is 1500 bytes, 1480 bytes for data, and 20 bytes for IP header. Question 12 No. Time Source 2 16:11:08 192.168.2.2 Destination 66.94.234.13 Protocol Info ICMP Echo (ping) request Frame 2 (534 bytes on wire, 534 bytes captured) Ethernet II, Src: Lite-OnC_d0:f2:17 (00:a0:cc:d0:f2:17), Dst: Belkin_e2:0d:c1 (00:17:3f:e2:0d:c1) Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 66.94.234.13 (66.94.234.13) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 520 Identification: 0xd655 (54869) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 1480 Time to live: 1 Protocol: ICMP (0x01) Header checksum: 0xf1d0 [correct] Source: 192.168.2.2 (192.168.2.2) Destination: 66.94.234.13 (66.94.234.13) [IP Fragments (1980 bytes): #1(1480), #2(500)] [Frame: 1, payload: 0-1479 (1480 bytes)] [Frame: 2, payload: 1480-1979 (500 bytes)] Internet Control Message Protocol Since the Fragment offset is set to 1480, then this particular datagram is a fragment. There are no more fragment, this one is the last one, because the More fragments field is set to 0. When More fragments field is set to 0, then that particular datagram is the last one of the fragments. Question 13 The More fragments, and Fragment offset, fields changed from the first datagram to the second one. Question 14 Three fragments were created from the original datagram. Question 15 Between the first one and the second, the Fragment offset field changed, because the first fragment contains the beginning of the data, while the second one contains data further into the message. The last fragment had More fragments field off, because it was the last fragment of the entire message. This goes without saying, the checksum usually always changes. TCP LAB I used the trace provided for download called tcp-ethereal-trace-1. Question 1 No. Time 4 0.026477 a reassembled PDU] Source 192.168.1.102 Destination 128.119.245.12 Protocol Info TCP [TCP segment of Frame 4 (619 bytes on wire, 619 bytes captured) Ethernet II, Src: Actionte_8a:70:1a (00:20:e0:8a:70:1a), Dst: LinksysG_da:af:73 (00:06:25:da:af:73) Internet Protocol, Src: 192.168.1.102 (192.168.1.102), Dst: 128.119.245.12 (128.119.245.12) Transmission Control Protocol, Src Port: health-polling (1161), Dst Port: http (80), Seq: 1, Ack: 1, Len: 565 The IP address, and the TCP port, of the client computer is 192.168.1.102 and 1161, respectively. Question 2 The IP address, and the TCP port, of gaia.cs.umass.edu is 128.119.245.12 and 80, respectively. Question 3 I was not able to capture my own packet stream, because after quitting my BitTorrent client, I kept receiving lots of TCP packets. I didn’t want to confuse the two packet streams. I used the trace provided for download called tcp-ethereal-trace-1. Question 4 Frame 1 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Actionte_8a:70:1a (00:20:e0:8a:70:1a), Dst: LinksysG_da:af:73 (00:06:25:da:af:73) Internet Protocol, Src: 192.168.1.102 (192.168.1.102), Dst: 128.119.245.12 (128.119.245.12) Transmission Control Protocol, Src Port: health-polling (1161), Dst Port: http (80), Seq: 232129012, Len: 0 Source port: health-polling (1161) Destination port: http (80) Sequence number: 232129012 Header length: 28 bytes Flags: 0x02 (SYN) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...0 .... = Acknowledgment: Not set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 16384 Checksum: 0xf6e9 [correct] Options: (8 bytes) Since Wireshark modifies the sequence, and acknowledgement, to be relative, I had to change the settings so it shows the actual sequence, and acknowledgement numbers. The sequence number of the initiating machine is 232129012. A segment is a SYN segment if the SYN bit is set, no other flags are set. Question 5 Frame 2 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: LinksysG_da:af:73 (00:06:25:da:af:73), Dst: Actionte_8a:70:1a (00:20:e0:8a:70:1a) Internet Protocol, Src: 128.119.245.12 (128.119.245.12), Dst: 192.168.1.102 (192.168.1.102) Transmission Control Protocol, Src Port: http (80), Dst Port: health-polling (1161), Seq: 883061785, Ack: 232129013, Len: 0 Source port: http (80) Destination port: health-polling (1161) Sequence number: 883061785 Acknowledgement number: 232129013 Header length: 28 bytes Flags: 0x12 (SYN, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 5840 Checksum: 0x774d [correct] Options: (8 bytes) The sequence number of the SYNACK segment is 883061785. The value of the ACK number is 232129013. The bytes in a data stream are numbered. TCP divides the data stream into pieces depending on the size of the MSS. Each segment will encapsulate this piece of data, and the sequence number assigned to the segment will be the numeric location, with respect to the data stream, of the first byte of the piece it is encapsulating. Since the SYN segment has a sequence number of 232129012, and the length of data is 0, then gaia.cs.umass.edu knows that the next segment must have a sequence number of 232129013. SYNACK segment is identified by the ACK, and SYN, flags set to 1, and no other flags are set. Question 6 The sequence number of HTTP POST segment is 232129013. Question 7 Sequence Number 232129013 232129578 232131038 232132498 232133958 232135418 Time Sent Time ACK Received (hour:minute:seconds) (hour:minute:seconds) 09:44:20.596858 09:44:20.612118 09:44:20.624407 09:44:20.625071 09:44:20.647786 09:44:20.648538 09:44:20.624318 09:44:20.647675 09:44:20.694466 09:44:20.739499 09:44:20.787680 09:44:20.838183 EstimatedRTT_0 = 0.02746 seconds EstimatedRTT_1 = 0.875 * 0.02746 + 0.125 * 0.035557 = 0.028472125 seconds EstimatedRTT_2 EstimatedRTT_3 EstimatedRTT_4 EstimatedRTT_5 = = = = 0.875 0.875 0.875 0.875 Question 8 Sequence Number 232129013 232129578 232131038 232132498 232133958 232135418 * * * * 0.028472125 + 0.125 * 0.070059 = 0.0336704844 seconds 0.0336704844 + 0.125 * 0.114428 = 0.0437651738 seconds 0.0437651738 + 0.125 * 0.139894 = 0.0557812771 seconds 0.0557812771 + 0.125 * 0.189645 = 0.0725142425 seconds Lengths (Header Length + Data Length) Bytes 20 + 565 20 + 1460 20 + 1460 20 + 1460 20 + 1460 20 + 1460 = = = = = = 585 1480 1480 1480 1480 1480 Question 9 The window field of the TCP header contains the number of bytes the receiver is willing to receive. The minimum value advertised was when the receiver replied with a SYNACK packet. Frame 2 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: LinksysG_da:af:73 (00:06:25:da:af:73), Dst: Actionte_8a:70:1a (00:20:e0:8a:70:1a) Internet Protocol, Src: 128.119.245.12 (128.119.245.12), Dst: 192.168.1.102 (192.168.1.102) Transmission Control Protocol, Src Port: http (80), Dst Port: health-polling (1161), Seq: 883061785, Ack: 232129013, Len: 0 Source port: http (80) Destination port: health-polling (1161) Sequence number: 883061785 Acknowledgement number: 232129013 Header length: 28 bytes Flags: 0x12 (SYN, ACK) Window size: 5840 Checksum: 0x774d [correct] Options: (8 bytes) The minimum value was 5840 bytes. However, as the trace progresses it begins to significantly increase, and become stable at 62780. Frame 143 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: LinksysG_da:af:73 (00:06:25:da:af:73), Dst: Actionte_8a:70:1a (00:20:e0:8a:70:1a) Internet Protocol, Src: 128.119.245.12 (128.119.245.12), Dst: 192.168.1.102 (192.168.1.102) Transmission Control Protocol, Src Port: http (80), Dst Port: health-polling (1161), Seq: 883061786, Ack: 232244521, Len: 0 Source port: http (80) Destination port: health-polling (1161) Sequence number: 883061786 Acknowledgement number: 232244521 Header length: 20 bytes Flags: 0x10 (ACK) Window size: 62780 Checksum: 0x026f [correct] It doesn’t seem like the receiver throttles the sender, because the sender doesn’t send out more data than the window size. Usually, the sender sends out about 8000 bytes, and then the received acknowledges all of them. 192.168.1.102 128.119.245.12 TCP Seq=232146217 Ack=883061786 Win=17520 Len=1460 health-polling > http [ACK] 31 0 192.168.1.102 128.119.245.12 [ACK] Seq=232147677 Ack=883061786 Win=17520 Len=1460 TCP health-polling > http 32 0 192.168.1.102 128.119.245.12 [ACK] Seq=232149137 Ack=883061786 Win=17520 Len=1460 TCP health-polling > http 33 0 192.168.1.102 128.119.245.12 [ACK] Seq=232150597 Ack=883061786 Win=17520 Len=1460 TCP health-polling > http 34 0 192.168.1.102 128.119.245.12 [ACK] Seq=232152057 Ack=883061786 Win=17520 Len=1460 TCP health-polling > http 35 0 192.168.1.102 128.119.245.12 TCP [PSH, ACK] Seq=232153517 Ack=883061786 Win=17520 Len=892 health-polling > http 36 0 128.119.245.12 192.168.1.102 [ACK] Seq=883061786 Ack=232147677 Win=40880 Len=0 TCP http > health-polling 37 0 128.119.245.12 192.168.1.102 [ACK] Seq=883061786 Ack=232149137 Win=43800 Len=0 TCP http > health-polling 38 0 128.119.245.12 192.168.1.102 [ACK] Seq=883061786 Ack=232150597 Win=46720 Len=0 TCP http > health-polling 39 0 128.119.245.12 192.168.1.102 [ACK] Seq=883061786 Ack=232152057 Win=49640 Len=0 TCP http > health-polling 40 0 128.119.245.12 192.168.1.102 [ACK] Seq=883061786 Ack=232153517 Win=52560 Len=0 TCP http > health-polling 41 0 128.119.245.12 192.168.1.102 [ACK] Seq=883061786 Ack=232154409 Win=52560 Len=0 TCP http > health-polling From the above sample of data packets and ACK packets, one can see that sender sends out a total of bytes (all packets added together) which is less than the window size. Before the sender can send more data, the receiver usually acknowledges quickly. Question 10 When retransmission occurs, Wireshark usually color codes the retransmitted packet with red text. None of the packets are identified as such, therefore no retransmission occurred. Question 11 There are cases when the receiver acknowledges more than one packet at once, and then there are cases when the receiver acknowledges every packet. The following shows a trace when the receiver acknowledges two packets with one ACK: No. http http http http http Time Source 72 09:44:22 192.168.1.102 [ACK] Seq=232178985 Ack=883061786 73 09:44:22 192.168.1.102 [ACK] Seq=232180445 Ack=883061786 74 09:44:22 192.168.1.102 [ACK] Seq=232181905 Ack=883061786 75 09:44:22 192.168.1.102 [ACK] Seq=232183365 Ack=883061786 76 09:44:22 192.168.1.102 [ACK] Seq=232184825 Ack=883061786 Destination 128.119.245.12 Win=17520 Len=1460 128.119.245.12 Win=17520 Len=1460 128.119.245.12 Win=17520 Len=1460 128.119.245.12 Win=17520 Len=1460 128.119.245.12 Win=17520 Len=1460 Protocol Info TCP health-polling > TCP health-polling > TCP health-polling > TCP health-polling > TCP health-polling > 77 09:44:22 192.168.1.102 128.119.245.12 TCP http [PSH, ACK] Seq=232186285 Ack=883061786 Win=17520 Len=892 78 09:44:22 128.119.245.12 192.168.1.102 TCP polling [ACK] Seq=883061786 Ack=232181905 Win=62780 Len=0 health-polling > http > health- The blue ACK packet, acknowledges the two red data packets. The following shows a trace when the receiver acknowledges every packet with its own ACK: No. Time Source Destination Protocol 30 09:44:21 192.168.1.102 128.119.245.12 TCP http [ACK] Seq=232146217 Ack=883061786 Win=17520 Len=1460 31 09:44:21 192.168.1.102 128.119.245.12 TCP http [ACK] Seq=232147677 Ack=883061786 Win=17520 Len=1460 32 09:44:21 192.168.1.102 128.119.245.12 TCP http [ACK] Seq=232149137 Ack=883061786 Win=17520 Len=1460 33 09:44:21 192.168.1.102 128.119.245.12 TCP http [ACK] Seq=232150597 Ack=883061786 Win=17520 Len=1460 34 09:44:21 192.168.1.102 128.119.245.12 TCP http [ACK] Seq=232152057 Ack=883061786 Win=17520 Len=1460 35 09:44:21 192.168.1.102 128.119.245.12 TCP http [PSH, ACK] Seq=232153517 Ack=883061786 Win=17520 Len=892 36 09:44:21 128.119.245.12 192.168.1.102 TCP polling [ACK] Seq=883061786 Ack=232147677 Win=40880 Len=0 37 09:44:21 128.119.245.12 192.168.1.102 TCP polling [ACK] Seq=883061786 Ack=232149137 Win=43800 Len=0 38 09:44:21 128.119.245.12 192.168.1.102 TCP polling [ACK] Seq=883061786 Ack=232150597 Win=46720 Len=0 39 09:44:21 128.119.245.12 192.168.1.102 TCP polling [ACK] Seq=883061786 Ack=232152057 Win=49640 Len=0 40 09:44:21 128.119.245.12 192.168.1.102 TCP polling [ACK] Seq=883061786 Ack=232153517 Win=52560 Len=0 41 09:44:21 128.119.245.12 192.168.1.102 TCP polling [ACK] Seq=883061786 Ack=232154409 Win=52560 Len=0 Info health-polling > health-polling > health-polling > health-polling > health-polling > health-polling > http > healthhttp > healthhttp > healthhttp > healthhttp > healthhttp > health- ACK packets in blue, are acknowledging each packet in red. Question 12 The throughput can be calculated as the number of bytes transferred over the time it took to transfer it all. The file is 148KB, and the time it took to transfer the file is approximately 5 seconds. The first and the last packet captures by Wireshark: 1 0 192.168.1.102 128.119.245.12 Seq=232129012 Win=16384 Len=0 MSS=1460 206 5 192.168.1.102 128.119.245.12 [ACK] Seq=232293103 Ack=883062516 Win=16790 Len=0 TCP health-polling > http [SYN] TCP health-polling > http The throughput is 29.6/KBs Question 13 The slow start begins exponentially at the beginning, and this can be seen by an unusual curve plotted at time slightly above 0. Congestion avoidance takes place between the stacks. The plot is different than the idea graphs studied, because the stacks don’t seem to grow in a linear fashion, but instead seem to grow instantaneously. Ideal graphs start an exponential rise, drop, and then grow linearly from there on. Question 14 The graph I retrieved by uploading the file myself is shown above. It’s similar to the one show in question 13, except that the transfer rate is much faster. It’s hard to identify the slow start, but it seems to begin after 0.05 seconds. My graph does not grow linearly after congestion avoidance. It seems like it sends quick bursts of three packets, then stops.
