When the ACK message arrives at the client, it computes an RTT sample and then immediately sends the next message.

Transcription

1 CPSC 3600 HW #2 s Fall 2017 Last update: 10/12/2017 Please submit your written answers as a PDF using canvas And your modified UDPEcho.tar.gz using handin Please work independently Name: 1 (10) Two nodes communicate over the following network. Link 1 Link 2 Link 3 Node Gbps Ethernet --Router Mbps Link---Router -1Gbps Ethernet ---Node 2 1 microsecond 30 millisecond 1 microsecond The link propagation delay: 1 us, 30 ms, 1 us The only active application is a file transfer application based on UDP. The client sends messages that contain 1472 bytes of application data. The first 4 octets of each message contains the sequence number (let s call this the application protocol header) followed by 1468 bytes of application data. The size of the frame that gets sent over each link (between the client and the server) is exactly 1520 bytes : Application data: 1468 bytes Application header (sequence number): 4 bytes UDP protocol header : 8 bytes IP protocol header: 20 bytes MAC header: 20 bytes The server simply sends a ACK message that contains only the sequence number of the message that just arrived. Therefore, each ACK is exactly 52 bytes large (4 bytes application header, 8 bytes UDP header, 20 bytes IP header, 20 bytes MAC header). When the ACK message arrives at the client, it computes an RTT sample and then immediately sends the next message. The application needs to transfer 5 GBytes of data (i.e., 5,000,000,000 bytes) of application data from Node 1 to Node 2. The application protocol is a simple stop and wait. A retransmission timeout of 2 seconds is used if an ACK does not arrive. At which time, the last message is retransmitted. The client protocol will attempt to transmit a message up to 5 times (the first transmission followed by up to 4 retransmissions). If 5 attempts fail, the client terminates. Please have your answers in units of seconds with microsecond precision. 1

2 1.1 Compute the best case RTT the client observes. Assume the best case implies no packet loss, no processing delays, and no other traffic competing for bandwidth. In the best case, every RTT sample computed by the client should be identical with the possible exception of the very last message which might not be the same size as all the others. Ignore the last RTT sample for all your answers to each part of Question 1 in the homework. : Identify the following: The transmission delays in the Node 1 to Node 2 direction for links 1, 2, 3 as T1-1, T2-1, T3-1 The transmission delays in the reverse direction for links 1,2,3 as T1-2, T2-2, T3-2. The propagation delays for each direction for links 1,2,3 as Tprop1, Tprop2, Tprop3. T1-1= 1520*8/ = 12 microseconds T2-1=1520*8/ = seconds = 8107 microseconds T3-1 = same as T1-1 T1-2 = 52*8/ = 0.4 microsecond T2-2 = 52*8/ = seconds = 277 microseconds T3-2= sames as T1-2 RTT = T1-1+Tprop1 + T2-1+Tprop2 + T3-1+Tprop3 + T1-2+Tprop1 + T2-2+Tprop2 + T3-3+Tprop3 = 12us+1us usecs +12 us +1us + 0.4us + 1us + 277us us = microseconds = seconds Note that the 30ms prop delay is by far the biggest component of the delay. 2

3 1.2 Exactly how long will it take before all 5 GBytes are successfully received and acknowledged? Assume the best case implies no packet loss, no processing delays, and no other traffic competing for bandwidth. Total frame size is 1520 bytes. But each frame can only hold 1468 bytes. Let s define Ni as the number of iterations that are required. Niters = ceil(5,000,000,000 / 1468 ) Niters= 3,405,995 transmissions, with the last holding only 808 bytes. The easiest way to do this is to use the previous result and to assume the error caused by assuming the final transmission is neglible. Ttransfer= Niters*RTT= * = 233, seconds. Is the error caused by the final transmission significant? The RTT of the last iteration would be different due to the Tx delay in the Node 1 to Node 2 direction. The frame size would be bytes = 560 bytes T1-1= 860*8/ = 6.88 microseconds or rounded up to 7 microseconds T2-1=860*8/ = seconds = 4587 microseconds T3-1 = same as T1-1 RTT(last)= = The difference is 3538 useconds which is significant. The Ttransfer result that accounts for the reduced RTT on the last iteration: Ttransfer= (Niters-1)*RTT= * = seconds. 1.3 Same problem as 1.2 except you now must consider a non-zero random packet loss process in effect. Assume the loss process can be modeled using a Bernoulli Loss Model with an average loss rate of 0.05 (or 5%). Find the total time it takes to successfully transfer the 5GBytes of data subject to a random 5% packet loss process. To simplify, assume the following: For the N transmissions, assume that exactly 0.05*N packets are dropped and consequently require retransmission. Further, assume that all retransmissions do NOT experience packet loss. : The assumption that retransmissions are not subject to packet loss greatly simplifies the problem. Let X be a random variable that represents the iteration time. 3

4 The domain (sample space or the set of all possible values of X), Sx : {RTT, TimeoutTime+RTT} Where the value is either the RTT time (the case of no loss) of RTT-time + Timeout (the case when loss occurs). Knowing that the retransmission timer starts just before the send, the recovery takes the duration of the timeout plus the time to transmit and receive the retransmitted message. We will further simplify by assuming the very last iteration will always be the same size as all other messages. Probability of P(X=RTT) = 0.95, P(X=RTT+Timeout) = 0.05 Expected value of X : E[X] = RTT* (RTT+2.0)*0.05 = 0.95* * E[X]= seconds= seconds Ttransfer= Niters*RTT= * = Another way to do the problem: we know that the Ttransfer will require the previous Ttransfer for successful iterations. And then 0.05* * 2.0 amount of additional time for each unsuccessful iteration. So the cost of errors: Terrors= 0.05* *2.0 = The modified transfer time (we use the Ttransfer that assumes the last message same size): Ttransfer time= = What is the probability that the session fails? Same problem as 1.3 except we now consider the possibility that retransmissions are dropped. Hint: This is where we make use of the Bernoulli Loss Model. Loss events are uncorrelated and therefore we can apply the Binomial Probability Law to solve the problem. Each time the client sends a message and waits for the ACK is an iteration. Each iteration can be viewed as a Bernoulli event- it either succeeds or fails. 4

5 : A session fails if 5 sequential iterations fail. We can model each iteration as a Bernoulli event. We can then use the Binomial probability model to obtain the probability of k successes in n trials (where we define a success as a iteration failure which occurs with probability p). To review, the binomial probability model offers a simple but very useful model appropriate for sequential experiments involving Bernoulli events. A Bernoulli event is an experiment that has an outcome of exactly two possibilities: SUCCESS or FAILURE where the probability of a success is p and the probability of a failure is (1-p). Suppose we have n Bernoulli trials and p is the probability of success of a trial. Then this is a binomial model if The Bernoulli trials are independent of one another. The probability of success, p, remains the same from trial to trial. We can model the protocol failure simply by finding the probability of 5 successes in 5 attempts. We can solve the probability model using the formula. It reduces to p to the 5 th. So a very small number! Prob(5 successes in 5 attempts) = pexp5 = 0.05 * 0.05 * 0.05 * 0.5 * 0.5 = 3 *10EXP-7 Question 2 Problem P1 from Chapter 2 Kurose a) F b) T c) F d) F e) F Question 3 Problem P4 from Chapter a) The document request was The Host : field indicates the server's name and /cs453/index.html indicates the file name. b) The browser is running HTTP version 1.1, as indicated just before the first <cr><lf> 5

6 pair. c) The browser is requesting a persistent connection, as indicated by the Connection: keep-alive. d) This is a trick question. This information is not contained in an HTTP message anywhere. So there is no way to tell this from looking at the exchange of HTTP messages alone. One would need information from the IP datagrams (that carried the TCP segment that carried the HTTP GET request) to answer this question. e) Mozilla/5.0. The browser type information is needed by the server to send different versions of the same object to different types of browsers. Question 4 Problem P5 from Chapter 2 a) The status code of 200 and the phrase OK indicate that the server was able to locate the document successfully. The reply was provided on Tuesday, 07 Mar :39:45 Greenwich Mean Time. b) The document index.html was last modified on Saturday 10 Dec :27:46 GMT. c) There are 3874 bytes in the document being returned. d) The first five bytes of the returned document are : <!doc. The server agreed to a persistent connection, as indicated by the Connection: Keep-Alive field Question 5 Problem P6 except examine the latest HTTP RFC 7230 (this has replaced RFC 2616). a) Persistent connections are discussed in section 8 of RFC 2616 (the real goal of this question was to get you to retrieve and read an RFC). Sections and of the RFC indicate that either the client or the server can indicate to the other that it is going to close the persistent connection. It does so by including the connection-token "close" in the Connection-header field of the http request/reply. b) HTTP does not provide any encryption services. 6

7 c) (From RFC 2616) Clients that use persistent connections should limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. d) Yes. (From RFC 2616) A client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress. Question 6 Problem P18 from Chapter 2 (Hint: I suggest using ). a) For a given input of domain name (such as ccn.com), IP address or network administrator name, the whois database can be used to locate the corresponding registrar, whois server, DNS server, and so on. b) NS4.YAHOO.COM from NS1.MSFT.NET from ww.register.com c) Local Domain: Web servers : , , , , , , , Mail Servers : mx1.mindspring.com ( ) mx2.mindspring.com ( ) mx3.mindspring.com ( ) mx4.mindspring.com ( ) Name Servers: itchy.earthlink.net ( ) scratchy.earthlink.net ( ) Web Servers: ( , ) Mail Servers: a.mx.mail.yahoo.com ( ) b.mx.mail.yahoo.com ( ) c.mx.mail.yahoo.com ( , ) d.mx.mail.yahoo.com ( ) e.mx.mail.yahoo.com ( ) f.mx.mail.yahoo.com ( , ) g.mx.mail.yahoo.com ( , ) Name Servers: ns1.yahoo.com ( ) ns2.yahoo.com ( ) ns3.yahoo.com ( ) ns4.yahoo.com ( ) ns5.yahoo.com ( ) 7

8 ns8.yahoo.com ( ) ns9.yahoo.com ( ) Web Servers: ( , ) Mail Servers: mx1.hotmail.com ( , , ) mx2.hotmail.com ( , , ) mx3.hotmail.com ( , , ) mx4.hotmail.com ( , , ) Name Servers: ns1.msft.net ( ) ns2.msft.net ( ) ns3.msft.net ( ) ns4.msft.net ( ) ns5.msft.net ( ) d) The yahoo web server has multiple IP addresses ( , ) e) The address range for Polytechnic University: f) An attacker can use the whois database and nslookup tool to determine the IP address ranges, DNS server addresses, etc., for the target institution. g) By analyzing the source address of attack packets, the victim can use whois to obtain information about domain from which the attack is coming and possibly inform the administrators of the origin domain. Question 7- programming question This will be a redo of part 2 of the program from HW1. You are to start with the UDPEcho posted as the partial solution from HW1. This incorporates the session manager code at the server. The client code for CBR mode has been added, however you are to make a trivial config parameter change. The CBR support has NOT been added at the server. The server parameters are the same as before: Server side port number Debug Flag - controls the amount of information displayed to standard out by the server. The parameter conveys two logging settings: 8

9 o The 8 th bit of the lowest octet specifies if the server is to log iteration samples to the file EchoServer.dat (a 1 is yes). o The lower 7 bits encodes the debuglevel which controls how much tracing information is displayed to standard out. A value of 0 displays errors, a value of 1 displays start and stop information, a value of 2 displays iteration results and a value of 3 displays debugging information. Note that the original code does not appear to correctly deal with a value of 2. If you want to see information related to each iteration (as perceived by the server), specify the debugflag to be 129. This will create EchoServer.dat file. This file format is based on the following fprintf in the server code: o fprintf(newfile,"%f %d %d %d %d %d\n", curtime,rxseqnumber,recvmsgsize,largestseqrecv, receivedcount,errorcount); The client parameters are to be slightly modified: Server IPv4 address as a domain name or in dotted quad format Server port : specifies the server port Message size: specifies the number of application bytes to place in each message. In order to ensure a message fits in one IP packet, you should assume a message size can not exceed 1472 bytes. Number iterations: specifies the number of iterations (i.e., data samples) to perform (or obtain). If 0, the client should run forever (or until a CNT-C). Debug flag - Same as the server parameter except the sample log file is RTT.dat. Mode : 0 is RTT_MODE (original ECHO mode), 1 is CBR mode. If Mode 0, o Iteration delay: Number of microseconds between iterations If Mode 1, o Target send rate: The target client sending rate in bits per seconds The client and server should operate in RTT_MODE as currently implemented in the starting code for the program, with the exception of the minor parameter change to the client as explained above. The starting code does include the server support for keeping track of individual client sessions. You are to add support for CBR_MODE in the server. In CBR mode, the client sends fixed size messages at a constant packet rate, approximating a constant bit rate (CBR) traffic generator. The server does NOT send anything back. The Message size and the Target send rate parameters determine the frequency at which packets are sent. Specifically, the delay between sequential client transmissions is: Tdelay= (M*8)/R seconds where M: message size; R: Target send rate Note that when the client operates in ECHO mode (mode 0), the delay between transmissions is specified by the Iteration Delay client program parameter. The client places the following fields in the first 6 octets of each message: Sequence number (32 bit unsigned int) Mode : 16 bit unsigned int 9

10 In mode 0, when the client terminates, it should display the statistics that the code currently displays. When the server terminates, it should display a summary of each session. The starting code correctly displays the end of program information so you do not need to modify the code for this function. When a client session terminates that had been using CBR mode, it should display For client sessions using CBR mode, the client should display the duration of the session, the number of packets sent and the actual sending rate (bits per second). The code to print the end of program statistics for both client and server has been incorporated in the starting code so you do not need to modify the code for this function. As an example, we run the client and server on a VM from two different terminal sessions. The following shows the client invocation and the results after a CNT-C. The client is configured to run forever at a target sending rate of 5Mbps. It achieves less than the target due to overhead of the system. In CBR mode, even if the debugflag 8 th bit is set, neither the client or server create the output trace file (the RTT.dat or EchoServer.dat)../client localhost UDPEchoClient(#args:9): debuglevel:1 debugflag:129 createflag:1 UDPEchoClient(./client): IP:port:localhost:5000 #params: ^CUDPEcho2Client:( ):CBR_MODE: SentMsgs:5599 TotalBytes: actualsendrate: The server invocation and result:./server UDPEchoServer(#args:3): port:5000 debuglevel:1 debugflag:129 createflag:1 ^CUDPEcho2Server: receivedcount:5599, numbersessions: The server learns the client session mode through the mode field in the messages. Note that the server must support multiple clients that might be in either mode. The server maintains the session statistics as described in the previous section and is to display a summary of each session at program termination (the latter code already exists in the server). Validation You are to conduct an analysis that includes the following activities. The writeup for this problem just needs to include your answers to the following activities. Client in Mode 0 on your VM, Server running on a department Linux machine. Use netem on your VM and set a latency of 10ms and a random loss rate of 5% for all outbound packets (destined for the campus network). Run the client for 30 minutes specifying a iteration delay of In a second terminal session on your VM, run ping (i.e., the standard ping application) to the same server concurrently. Show the summary statistics for the client and for ping. Summarize in a few sentences what you see. If there are significant differences between the 10

11 results from the two tools, try to explain what you see. Your answer can be based solely on the summary results displayed by each program when you issue a CNT- C. Copy and paste the results (after the CNT-C terminates the three programs) from the ping output and from the UDPEcho client and server to your writeup. Client in Mode 1 on your VM, server running on a department Linux machine. o Test 1: Without netem active, run the client with a message size of 1000 bytes, a target send rate of bps and for number of iterations of 0 (so until you issue a CNT-C). Compare the send rate at the client with the observed receiving rate at the server. o Test 2: Repeat test 1, but run for 1000 iterations. Prior to running, issue a tcpdump (or wireshark) on your VM (or the Host) to capture the packets associated with your UDPEcho CBR session. Analyze the output file. Write a program or script to obtain a data file containing the time between each CBR packet. Then plot the distribution of this time series. Explain what you see.is it what we expect? If not, try to explain what might be happening. o Test 3: Repeat test 1, but this time have netem setup to add a 10ms latency and a 5% packet loss. Compare the summary results between the send and receive sides. Try to explain any differences. Test1 - The client send about 2138 messages, ping sends slightly more probable because I did not attempt to start the two programs at exactly the same time. UDPEcho observes and avg RTT of 16.3 ms and ping observes This difference could be due to minor differences between a UDP and an ICMP application. The UDPEcho program observes an avg loss rate of 4.8%, while ping observes a loss rate of 5%. I would if we ran for multiple hours we would see the same loss rate to within a fraction of a percent. ^CUDPEcho2Client:( ):RTT_MODE: Sent:2138 meancurrtt: (avgping:16692) smoothedrtt: , avgloss: , actualsendrate: 7518./server UDPEchoServer(#args:3): port:5000 debuglevel:1 debugflag:129 createflag:1 ^CUDPEcho2Server: receivedcount:2036, numbersessions: koala4.cs.clemson.edu ping statistics packets transmitted, 2172 received, 5% packet loss, time ms rtt min/avg/max/mdev = /16.985/ / ms 11