Midterm CIS 656, 04/02/2005 Dr Ott 9:15 - 10:30. There will be class 10:40 - 12:10. 1. Draw, in detail, the header of a TCP packet without options. For each field give the size and a short explanation of what its function or role is. Where appropriate, give the units in which the field is expressed. (Liters, Bytes, bits, 32 bit words, miliseconds, etc). Try to get the TCP flags in the right order but do not worry if you get them in the wrong order. Make sure you explain their functions or roles. (Insofar I explained it in class: I did not cover ECN yet.) 2. Look at the tcpdump output on page ``zero''. a. What is the physical (ethernet) source address? What is the physical (ethernet) destination address? b. At the network level, what kind of packet is this? (IP? ARP? RARP? IPX? ... ?) Explain! c. At the transport level, what kind of packet is this? (ICMP? IGMP? UDP? TCP? ... ?) Explain! d. What is the TTL of this packet? Explain! e. What is the IP destination address? Explain! f. What is the source port? Explain! g. What service is this packet for? h. How large is the packet? (Exclude ethernet header and trailer.) 3. Look at the tcpdump output on the pages 1 - 10. To save you time I have marked all S (SYN), F (FIN) and R (Reset) packets. Language sometimes is complicated: sometimes I say ``pair of flows'' when I mean the two flows in different directions that belong together. Sometimes I say ``flow'' when I mean the pair. a. For the pair of flows that has a FIN at time 17:21:53.306709, find the ``original SYN''. Give its tcpdump time. b. Give the IP addresses of the two computers this flow is in-between. c. Which of these two computers wants to use the default MSS? (One? the other? both? none?) d. Which of these computers understands Selective Acknowledgements? e. Which of these computers understands TCP timestamps? f. What service is this flow for? g. Compute, with an error of not more than 5 bytes, how many data bytes are sent from server to client. 4. There is an FTP session going on between a pair of computers that do not use window scaling. The RTT is 100 msec. (Say NJ - CA). What is the highest possible effective data rate this FTP session could achieve (make sure to mention units: Bytes/sec or bits/sec or ...) assuming one link the connection uses has a data rate of OC12 (about 600 Mb/sec) and all others have OC 48 or higher. --- Solutions: Problem 1: see notes and book. --- Problem 2: a. The ethernet source address is 00:02:b3:cd:cd:c8 The ethernet destination address is 00:02:b3:d3:d4:8a b. The ``ethertype'' equals 0800 (hex), so the frames contains an IP v4 packet. (See the ``data'' pages.) (the ``4'' at the beginning of the packet is confirmation, but without the ethertype it is no garantee.) c The second octet in the third 32-bit word in the IPv4 header is 11 (hex), that is 17 (dec), do the transport protocol is UDP. (See ``data'' pages.). d. The first octet in ther third 32-bit word in the IPv4 header is 3e (hex). that is 48+14 = 62. The TTL is 62. e. The IP destination address is (0a0d 0001) = 10.13.0.1. Before we do the rest, we have to check the IP header Length. It is 5 (5 32-bit words, or 5 4-byte words. So the UDP header starts with (0035 8000). Since the UDP header always is 8 bytes, the whole UDP header is (0035 8000 00d2 4f30). f. The source port is (0035) (hex) = 48+5 = 53. g. Since one of the ports is 53 and the other is a high numbere (no need to compute it.), this is a packet for the Domain Name Service (DNS), or shortly Name Service. See data sheets. NB. The destination port is (8000) (hex) = 8x16x16x16 = 2^{15} = 32768. But you were not asked that. So do not tell me unless there is a reason! NB. The source port is 53 and the destination port is a high number, so this is a UDP packet from the server to the client: a response to a previous packet from the client to the server. But you were not asked this. So do not tell me unless there is a reason. h. The size of the erthernet frame is 244 Bytes. Hence, the IP packet must be 244 - 14 = 230 Bytes. Also, the ``Total Length'' field in the IP header is (00e6) (hex) = 14x16 + 6 = 230 . You can do it either way. Or both ways. to check your arithmetic. --- Problem 3. Several students did not know the difference between the ``TCPdump time'' (always there, that is the time at which the tcpdump program saw the packet zip by) and the ``TCP timestamp'' (there only when TCP timestamps the packet, and it is not really a time: It is counter TCP uses to keep track of time, but different computers use different counters). a. The FIN at time (tcpdump time) 17:21:53:306709 is between the computer with IP address 64.233.187.99. using port 80, to the computer with IP address 10.13.0.1, port 56450. So we must find the SYNs between 64.233.187.99.80 and 10.13.0.1.56450 . (That is easy: there are 2 of these, and the ``Original SYN'' is the earliest of the two.) In fact; it is even easier: Very often (almost always?) the client starts the connection. So we expect a SYN from 10.13.0.1.56450 to 64.233.187.99.80 . Indeed, the ``original SYN'' is at time 17:21:40.449957 . The SYN-ACK that belongs to the same three-way handshake is at time 17:21:40.452862, and the ACK that completes the three-way handshake is at time 17:21:40.453011. But I did not aske that! b. The flow is between 10.13.0.1 and 64.233.187.99 . See above. Note: The physical addresses 00:02:b3:d3:d4:8a and 00:02:b3:cd:cd:c8 must NOT be expected to be of the computers 10.13.0.1 and 64.233.187.99 ! The physical addresses are for one interface on the computer where I do the tcpdump, and the interface it is in direct contact with. (In fact, 10.13.0.1 has physical address 00:02:b3:d3:d4:8a, but I have no idea what the physical addresses are of 64.233.187.99. It might even not use ethernet.) 00:02:b3:cd:cd:c8 is one of the interfaces on marconi in the Internet Laboratory. c. In the ``original SYN'' we see that 10.13.0.1 wants an MSS of 1460 bytes; not the default of 536 bytes. In the SYN-ACK we see that 64.233.187.99 wants an MSS of 1380 bytes: not the default of 536 bytes, Neither computer wants to use the default MSS. d. Both computers use the ``SACK permitted'' option. (10.13.0.1 in the original SYN, 64.233.187.99 in th SYN-ACK). So both computers understand SACK. e. In the original SYN, 10.13.0.1 puts in a TCP timestamp. So it understands TCP timestamps. In the SYN-ACK, 64.233.187.99 does not include a TCP timestamp. So it ``does not understand'' TCP timestamps. Only 10.13.0.1 understands TCP timestamps. f. At the server side the TCP port is 80, so this is an http packet. (often called WWW). See the ``data pages''. Strictly speaking: http is the protocol, www is the service. Both are good answers. g. We want the amount data from server (64.233.187.99) to client (10.13.0.1) using ports 80 and 56450. So we must look at acknowledge numbers from 10.13.0.1, or sequence numbers in 64.233.187.99. The starting sequence number for 64.233.187.99.80 (for THIS flow (!)) is 2099633689 (in the SYN-ACK at time 17:21:40:452862). The acknowledgement number in the last packet from 10.13.0.1.56450 to 64.233.187.99.80 (that is the FIN at time 17:21:53.381516) is 2099648090 . Subtract: 14401 Bytes. However, I think one of these bytes is due to ++ in the numbers during take-down. So I think the correct answer is 14400 Bytes. Any number between 14395 and 14405 is considered correct. Obviously, if I had not thrown away lots of packets you could have computed the answer by adding up numbers of data bytes in the packets. In theory we could be off by 2^{32} Bytes. Not in my lab! (Highest speed 100 Mbit/sec, over 13 seconds: less than 1 GByte.) --- Problem 4. The throughput is at most equal to the (effective window) divided by the (RTT). The (effective window) is at most the minimum of (advertised_window, send_buffer, Congestion_Window). Of these I gave you information only about RTT (100 msec = .1 sec) and advertised window: Since the two computers are not using window scaling, their adverised windows are AT MOST 2^{16} - 1 = 65535 Bytes. So the thput (in any direction) is AT MOST 65535/(.1) = 655350 Bytes/sec If you prefer bits: AT MOST 655350x8 = 5242800 bits/sec. Or almost 5.25 Mbits/sec. So if the two ``sysad'' people forget to enable window scaling, the connection can get only at most 5.25 Mbit/sec, of the potentially 600 Mbit/sec the network might allow. ---