CS 533 - HOMEWORK 1 SOLUTION Page 1 ---------------------------- Version 3, Feb. 5, 2004 Problem 1 (0 Points) --------- a) C2 2F 15 82 (hex) ==> 194.47.21.130 (dotted decimal) Treat each pair of hexadecimal digits separately. For example, C2 = 12 x 16 + 2 = 194 b) Each of the decimal numbers in 192.168.172.23 needs to be converted to a hexadecimal number. In our case, Easy Way (Aside from using a calculator) ---------------------------------------- 192 ==> C0 [ From Part a since C2 ==> 194 ] 168 ==> A8 [ 160 = 10 x 16 or A0 ] 172 ==> AC [ Since 160 ==> A0 and 12 ==> C ] 23 ==> 17 [ Trivial conversion ] You can check this using the 'bc' command. For example, create the file 'bc.in' containing: obase=16 192; 168; 172; 23; and enter 'bc < bc.in'. Problem 2 (0 Points) --------- a) The one-way delay is given by approximately: T = D/c' + L/R where c' = 2c/3, c is the speed of light in a vacuum c' = 200 meter/usec. 1 KB = 1,024 bytes. 45 Mb/sec = 45,000,000 bits/sec. St. Louis to San Diego by road is about 1821 miles. 1 kilometer is 0.62 miles. So, the distance is 2937 kilometers (I'll assume 3000 kilometers). Then, for a 1 KB file, T = 3000 km /(200 m/usec) + 8 x 1024 / 45 Mb/sec = 15 msec + 182 usec = 15.2 ms i.e., the propagation delay is the dominant time component. So, let's make a table: File Prop. Transmission Time Total Time Size Delay at 45 Mbps (msec) (msec) =============================================================== 1 KB 15 msec 0.182 = t1 15.2 1 MB 15 msec 1,024 x t1 = 186 = t2 201 1 GB 15 msec 1,024 x t2 = 190841 190,856 (= 191 sec) In short, the propagation delay is the dominant time component except for large files. b) The one-way delay is given by approximately: T = (D1 + D2)/c' + 2L/R where D1 is the distance to Chicago and D2 is the distance from Chicago to San Diego. D1 = 289 miles, and D2 = 2,064 miles. So, D1+D2 = 2,353 miles or 3795 kilometers. This represents an additional 800 kilometers or an additional 4 msec. So, we add 4 msec to the propagation delay in Part a. Also, because of store-and-forward, the transmission time is doubled: File Prop. Transmission Time Total Time Size Delay at 45 Mbps (msec) (msec) =============================================================== 1 KB 19 msec 0.364 = t1 19.4 1 MB 19 msec 1,024 x t1 = 373 = t2 392 1 GB 19 msec 1,024 x t2 = 381682 381,682 (= 382 sec) c) This problem illustrates the effect of encapsulation overhead (but is not real since TCP has a number of protocol overheads which we will study later). Payload = 1,000 bytes Headers = 20 (TCP) + 20 (IP) + 20 (Frame) = 60 bytes Frame Size = 1,060 bytes At 45 Mbps, 1 frame transmission time = 1060 x 8 / 45 usec = 188.4 usec F = #Frames = ceil(File Size (in bytes) / 1000) Total Header Space = F x 60 Total Data Space = File Size Propagation Delay = 19 msec The "Total Time" is: Total Time = (Propogation Delay) + #Frames x (1-Frame Transmission Time) Total Space (Bytes) Transmission Total Time Size #Frames Header Data Time (sec) (sec) ============================================================================== 1 KB 2 120 1 KB 0.000377 0.019 1 MB 1,049 62,940 1 MB 0.198 0.217 1 GB 1,073,742 64,424,520 1 GB 202.293 202.302 Problem 3 (0 Points) --------- a) The worst-case propagation delay is: T = 2D/(c2/3) = 3D/c where D is the length of the cable and c is the speed of light in the bus medium. But I like to think of the magic number c' = 200 m/usec. So, T = 2D/c' [1] Since D = 1,600 meters and c' is 200 m/usec, T = 3,200/200 usec = 16 usec b) Since one bit time is 1 usec, T = 16 bit times. c) The bit times scale with the data rate: Data Rate usec Bit Times --------------------------------- 1 Mbps 16 16 10 Mbps 16 160 100 Mbps 16 1,600 1 Gbps 16 16,000 Problem 4 (0 Points) --------- a) My 'nslookup sarlacc.arl' output: Server: seasdns.wustl.edu Address: 128.252.133.45 Name: sarlacc.arl.wustl.edu Address: 128.252.153.16 b) 'ping -s HOSTNAME' on a Solaris system will send out packets with default size (64 bytes) once per second and output the RTT. To send out 100-byte packets to www.yahoo.com, use 'ping -s www.yahoo.com 100'. The command line arguments vary from one OS to another. The following output is from a NetBSD host which has produces the same output but the '-s' flag indicates the packet size: PING www.yahoo.akadns.net (216.109.118.67): 100 data bytes 108 bytes from 216.109.118.67: icmp_seq=0 ttl=48 time=32.541 ms 108 bytes from 216.109.118.67: icmp_seq=1 ttl=48 time=39.041 ms 108 bytes from 216.109.118.67: icmp_seq=2 ttl=48 time=33.355 ms 108 bytes from 216.109.118.67: icmp_seq=3 ttl=48 time=45.152 ms ^C ----www.yahoo.akadns.net PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 32.541/37.522/45.152 ms PING www.yahoo.akadns.net (216.109.118.70): 1000 data bytes 1008 bytes from 216.109.118.70: icmp_seq=0 ttl=48 time=33.647 ms 1008 bytes from 216.109.118.70: icmp_seq=1 ttl=48 time=34.229 ms 1008 bytes from 216.109.118.70: icmp_seq=2 ttl=48 time=34.082 ms ^C ----www.yahoo.akadns.net PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 33.647/33.986/34.229 ms The packet size doesn't seem to have much of an effect. c) 'ping -s HOSTNAME LENGTH' on a Solaris system will send out packets with size LENGTH bytes. This works fine until the size exceeds the MTU of some interface between the two endpoints. Most routers will send back an error message, but some will fragment the packet. On my NetBSD host, I was able to send 25152-byte packets. d) traceroute successively probes routers that are H hops away trying 3 times at each distance and reporting the RTTs. Unfortunately, traceroute support seems to be disabled from within Washington University! Problem 5 (0 Points) --------- The values of the struct members are shown below in various formats: Variable Plain Text Internal (Hex) ------------------------------------------------------------- myshort0 1 00 01 myshort1 256 01 00 mychar 'A' 41 mystr[10] "ABC123" 41 42 43 31 32 33 00 ?? ?? ?? Note the following: o The null character ('\0' or 00 (hex)) terminates the string mystr. o There are 3 extra characters following the null character. I have shown them each as containing ?? but some compilers might place zeros in those positions. o The internal representation of myshort0 and myshort1 show the most significant byte first. o There should be no alignment issues here since myshort1 ends on an address boundary which is evenly divisible by 4. However, the compiler may pad out the structure so that it is evenly divisible by 4; i.e., sizeof(foo) will return 16, not 15. It is actually easier to do Part b first since NBOis big-endian. b) So, our memory layout would be: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00 01 01 00 41 41 42 43 31 32 33 00 ?? ?? ?? ?? a) A little-endian transmitter will reverse the order of the bytes of the two shorts (changes are marked with '*'): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 01* 00* 00* 01* 41 41 42 43 31 32 33 00 ?? ?? ?? ?? c) Since the host is big-endian, there is no need to convert the incoming message. Problem 6 (5 Points) --------- a) Propagation delay = D/c' = 4,000 Km / (200 m/usec) = 20 msec Transmission time = L/R = 1 KB x 8 bits/byte / 1.5 Mbps = 1024 x 8 / 1.5 usec = 8.192/1.5 msec = 5.5 msec So, the propagation time dominates. b) A 1 GB file contains 2^20 packets of length 1 KB. It takes approximately 1 RTT to send and acknowledge 1 packet where a single RTT is approximately 40 msec. So, it will take about 2^20 x 40 = 41,943,040 msec = 41,943 sec ignoring the transmission time component. If we include the transmission time of the packet but not the acknowledgement packet, the total transmission time will be about: T = 2^20 x (40 + 5.5) msec = 47,710 sec c) The time will look like a sequence of transmissions followed by the propagation delay of the last bit. But since this propagation time will be small compared to the transmission time, the time will be approximately equal to the transmission time of the 1 GB or, T = 2^30 x 8 / 1.5 usec = 5726.6 sec a speed-up of about 8. Problem 7 (5 Points) --------- a) T1(L) = 2 (D1/c' + L/R1) where c' = 200 meters/usec, D1 is the distance between the source and the first hop router and R1 is the link rate in bytes per second. So, T1(0) = 2D1/c' Slope = 2/R1 b) If he/she is lucky, he will collect enough samples so that some times will include no queueing (the minimum values). Then, theoretically, we can recursively determine each link rate from source to destination since the time difference between hop k and k+1 is: Tk(L) = 2 (Dk/c' + L/Rk) The reciprocol of the slope of the curve will be the link rate of the kth link. [ Aside: Unfortunately, the calculations sometimes require the difference between two numbers that are different by one or two orders of magnitude and the data is noisy. For example, in going from 1.5 Mbps to 155 Mbps, the absolute difference calulation would be: (1/1.5 + 1/155 - 1/1.5) = 0.67311-0.66666. ] Problem 8 (2 Points) --------- a) Each frame is 640 x 480 pixels. So, the bandwidth needed will be: (640 x 480 pixels) x (3 bytes/pixel) x (8 bits/byte) x (30 frames/sec) or 221 Mb/s (= 221,184,000 bits/sec) b) Assume 1 byte/pixel and the horizontal and vertical resolution are both 72 pixels per inch. Each image is: (8 inch x 10 inch) x 72 pixels/inch x 72 pixels/inch x 8 bits/pixel = 3,317,760 or about 3.3 Mb/s Problem 9 (4 Points) --------- a) Packets can be delivered to the receiver as they arrive. Since there is a one-to-one correspondence between each packet and its ACK, each returning ACK triggers the transmission of the next packet. b) A 1-bit sequence number is sufficient. This means that that the sequence number space is {0, 1} and the receiver expects packets in the order 0, 1, 0, 1, 0, .... The sequence number is used to disambiguate the packets that arrive to the receiver. A retransmitted frame is seen as a duplicate sequence number at the receiver. Suppose that the receiver is waiting for sequence number X. If there is a retransmission, then, either 1) The previous ACK X was lost or delayed and the sender times out; or 2) Packet X was lost. In case 1, the arriving packet will have sequence number (X-1) mod 2, and the receiver will know that it has already been received. In case 2, the arriving packet will have sequence number X, and the receiver will know it is a new packet that should be delivered to the application. In order deal with a lost packet, the transmitter will stop waiting for an ACK after some time-out period and retransmit the lost or late ACK. The receiver should send an ACK any time it receives an undamaged packet since it doesn't know if it's previous ACKs have been lost or not. Note that we need some sequence number since successive ACK packets could be for the same packet. In the example above, the transmitter can send packet 1 after it receives ACK 1. Even if another ACK 1 arrives late, the transmitter knows that it is due to the reception of packet 0; i.e., it is an duplicate ACK and can be ignored. Problem 10 (9 Points) --------- (Solution given in class)