CPSC 3600 HW #4 Solutions Fall 2017 Last update: 12/10/2017 Please work together with your project group (3 members)

Transcription

1 CPSC 3600 HW #4 Solutions Fall 2017 Last update: 12/10/2017 Please work together with your project group (3 members) Name: Q 1 Kurose chapter 3, review question R14 (20 points) Solution: a) false b) false c) true d) false e) true f) false g) false Q 2 Kurose chapter 3, review question R15 (20 points) Solution: a) 20 bytes b) ack number = 90 1

2 Q 3 Kurose chapter 3, review question R17 (10 points) Solution: R/2 2

3 Q4 (20 pts) As a group, you will repeat Exercise 5. This time, see if you can view a 4K content. If you can t, just chose any video your group agrees to watch. In your writeup, make sure to note the content you chose and the time of day that you viewed the video. Repeat exercise 5, although capture a bit more data- at least 15 minutes of a video. Make sure to capture the very beginning of the video. Have everyone in your group watch the video at the same time (using the same laptop). Everyone at the end of the session should give an overall assessment of the video quality - poor, acceptable, good, excellent. During the viewing, everyone should look for any specific artifacts such as glitches, strange distortions, or rebuffering events. In your writeup, everyone should include their overall assessment and a list of any observed artifacts. In a manner similar to Exercise 5, o Summarize the tcpdump trace file- Number of packets, number of tcp and udp sessions, total trace time. o What was the aggregate bandwidth consumed by the video session (in the time you viewed and traced it)- show the DS and US result separately. o Provide the DS.flowcounts file sorted by the IP addresses that were involved in the most number of flows. In addition please do the following o Identify the 10 flows that consumed the most DS bandwidth. o Plot the aggregate bandwidth consumed for the viewing session plot the 1 sec and 10 sec bandwidth sample output files produced by timeslice. Overlay the two curves please label each curve. Note: a 15 minute packet trace of a video can be very large (approaching 1 Gbyte). Make sure to use a computer with sufficient disk space. You might need to do this on a department Linux machine. Solution: (5 points for each of these 4 components): Captured a video as required (duration at least 10 minutes, includes beginning of video session) Team submitted an assessment of the quality? Did this include a list of specific artifacts (if the quality assessment reflects quality was not ideal)? Ex 5 results - o Trace file summarized: #packets, #tcp and udp sessions, total trace time? o Aggregate bandwidth- DS and US shown separately? o DS flowcounts file provided? Beyond Ex 5, o Id the top 10 flows that consumed the most DS bandwidth? o Plot of the aggregated BW for the session? This is a plot of the two data files produced by timeslice (named something like BW1SEC.dat and BW10SEC.dat). A plot for EACH of the data sets should be on the same graph. 3

4 Q5 (30 points with an additional 10 points extra credit possible) Programming question. You should use the code HW4.tar.gz as the starting point for this program. We will build upon the latest UDPEcho program, adding a third mode of operation that implements a simple window-based rate control algorithm. The mode of operation emulates an application with infinite demand and that attempts to use all available bandwidth over the path between the two socket endpoints. The mode implements a simplified version of TCP s slow start congestion control. It adapts the window in two ways. First, it grows the window in an effort to allow the flow to utilize all available bandwidth. Specifically, it initializes the window to a value equivalent to 1 message and increases the window by a value of 1 with each NEW ACK that arrives. A NEW ACK is an ACK message that conveys a Rx Sequence Number that the sender has not yet seen. An ACK message is either a NEW ACK or a DUPLICATE ACK. The latter implies the receiver has issues the same Rx Sequence Number one or more times. Second, the new mode will reduce the window in response to observed network congestion. We adopt TCP/IP s method of using packet loss as implicit indicators of network congestion. The protocol implements an adaptive sliding window protocol that deals with loss recovery using a go-back-n policy. To briefly illustrate the error recovery imagine the sender s window at a given point in time to be 10 packets (or messages). Messages with sequence numbers are in flight. If packet loss does not occur, the sender will receive 10 ACK messages with Rx Sequence Numbers of If the very first message is lost (seq number 100), the sender will receive 9 ACK messages all with an Rx Sequence Number of 100. Once the sender deduces that packet sequence number 100 was dropped, it will reduce the window to 1 and begin retransmitting beginning with sequence number 100. The go-back-n in this case refers to a loss recovery that requires the sender to effectively slide the window backwards to retransmit everything beginning with the first packet that was dropped. Clearly this is not the most efficient, as in our example, the retransmissions of sequence numbers are not necessary. But, this is a very simple protocol to implement and serves as a good example of a widely used protocol. We use the term message to mean a transmission from either the client or server. We can assume the term is synonymous with the terms packet or segment. There are two messages. The client (which we will call the sender) sends DATA messages. The server (which we will call the receiver) sends ACK messages. A DATA message is similar to what is used in the other modes, but it adds the time the message is sent to the message. DATA send by the client in Mode 2 Sequence number (32 bit unsigned int) : The sequence number of this message. Mode : (16 bit unsigned int) as with all modes, this indicates the session mode. For mode 2, this is set to a value of 2. 4

5 Timestamp seconds (32 bit unsigned int) : The timestamp when the data msg is sent. This first field represents the seconds. Timestamp microseconds (32 bit unsigned int). the second field of the timestamp contains the microseconds of the timestamp. Data- char [] - the client s message size specifies how many octets of data are contained in a DATA message Note: you can modify the data message format as you see fit. The messages.c code released as a part of ExtraCredit2 has an internal representation of a DataMsg through a structure and then this code laid out the DataMessage in a network buffer slightly differently (Sequence number, Mode, MsgType, Timestamps seconds/useconds, MsgSize, DataSize, and then the octets representing the message data. ACK- this is sent by the server in response to DATA messages from clients in Mode 2. It includes the Rx Sequence number, the mode of operation, and the timestamp from the most recent DATA Message. Rx Sequence number (32 bit unsigned int) : Reflects the sequence number the server side expects next. For example, if a data message with sequence number 100 arrives, the server should issue an ACK with an Rx Sequence Number of 101. Mode : (16 bit unsigned int) should be a value of 2 to reflect window mode Timestamp seconds (32 bit unsigned int): Echoes back the timestamp in the data message that triggers this ACK. Timestamp microseconds (32 bit unsigned int) As noted above, you can modify the ACK message as you see fit. The messages.c code arranged the network buffer in the same manner as the DataMsg but without the DataSize and data octets. We introduce several terms and concepts relevant to how the receiver generates ACK messages. A duplicate ACK is an ACK sent by the receiver that contains an Rx Sequence Number that has already been sent in a previous ACK message. Similarly, a new ACK is an ACK received by the sender that acknowledges a DATA message that has not been acknowledged before. This allows the window to advance. ACKs are cumulative in the sense that an ACK might contain a Rx Sequence number that acknowledges multiple packets. This also makes ACKs tolerant to loss (i.e., a dropped ACK message might not make any difference). The ACK strategy specifies how frequently the receiver issues an ACK. Your program will assume that the receiver is to issue an ACK with each new DATA message that arrives. It is possible to change this behavior and to reduce the number of ACKs by implementing a delayed ACK. The receiver will wait for a configured number of DATA messages to arrive, and then issue one ACK that 5

6 acknowledges all of the messages received. Your program does NOT have to support a delayed ACK. The receiver sends an ACK message for each data message that is received. The ACK message contains the Sequence Number that it expects next, consequently we refer to the sequence number in an ACK message as the Rx Sequence Number. Both DATA and ACK messages might be dropped in the network. When the receiver detects loss, it discards any data that arrives that is NOT the DATA message containing the next expected sequence number. This go-back-n behavior is not exactly what TCP does but it simplifies our protocol. When the sender deduces that a DATA message has been dropped, it simulates retransmission of the DATA message that was dropped by sending a DATA message with the sequence number of the packet that was dropped. The sender maintains a window variable (W) that specifies the number of messages that can be outstanding in the network. Once W messages have been sent, the sender waits for ACKs. The sender must maintain a retransmission timeout on only one message at a time. If the sender s window is 10 and DATA messages with sequence numbers of are in flight, the sender s timeout is based on the transmission of sequence number of 50. The sender deduces loss has occurred when one of two events occurs. The retransmission timer pops. The sender retransmits the message that has the lowest sequence number. For example, if the sender s window is 5 and it sends messages with sequence numbers of 10, 11, 12, 13, 14 but all 5 are dropped in the network. The sender stalls meaning no new data will be clocked out until the retransmission timer pops. When the timer pops, the sender should retransmit DATA message sequence number 10 and the window is reduced to 1. A duplicate ACK event - if the sender observes a duplicate ACK, it assumes the DATA message that has the lowest sequence number of all messages in the current window was dropped. This DATA message is retransmit and the window is reduced to 1. (NOTE: TCP waits until 3 duplicate ACKs arrive, and the loss event is referred to as a triple duplicate ack ) As explained below, either loss event will cause the sender to reduce the cwnd to 1. If the same DATA message is retransmitted a total of five consecutive times (i.e., the same message is attempted to be sent a total of 6 times), the sender should assume the session has failed and it should terminate the program. The sender maintains a variable called the congestion window (cwnd). It is in units of packets. It is initialized to 1 packet. The client program is variable called maximum window (maintained as variable maxw) This is in units of packets. The parameter allows us to limit the sending rate of the sender. If the value is 0, there is no limit to the sending rate. You can implement this in different ways you can ignore the maxw if it s 0 or if the configured maxw is 0, you can set the internal value very large, like 10,000,000. The cwnd would be reduced in response to packet loss well before the window approached a very large maxw. 6

7 The slow start algorithm involves the following variables: cwnd: the current congestion window maxw : the max allowed Window (a program parameter) W: The current window in use by the sender. It is updated each time a new ACK arrives: W= min(cwnd, maxw). RTO : Retransmission Timeout the duration of the retransmission timeout. This is defined to be twice the average of the 3 most recent RTT samples RTT the round trip time sample based on the currect Rx Sequence Number in an ACK message. It should be calculated based on the difference between the current time and the timestamp contained in the ACK. This must NOT be computed if the ACK is a duplicate. avgrtt the average RTT based on the most recent 3 samples. nextseqnumber the next seq number to be used highestseqnumberinflight tracks the upper edge of the window lowestseqnumberinflight tracks the lower edge of the window. This would be the next expected Rx Sequence Number. highestmsgacked the sequence number most recently ACKed. The simplified slow start algorithm is summarized as follows (note- this is incomplete it is meant just to illustrate the main points of slow start). At init time, nextseqnumber=1 highestseqnumberinflight=1 lowestseqnumberinflight=1 Cwnd=1 maxw initialized to the program parameter. If 0, it is set to 10,000,000 W=1 Init the initial RTO to 1 seconds Client sends the first message Each time an ACK arrives, Retrieve Rx Sequence Number from the message If it is a new ACK: o Adjust the seq number pointers to slide the window forward o cwnd++ o W=min(cwnd,maxW) o Send as many messages allowed (based on the updated W) o Retrieve the timestamp from the ACK. Compute a RTT sample by taking the difference from Timestamp in the ACK message from the current time. If it is a duplicate ACK o cwnd=1 o W=1 7

8 o Restart the timer, retransmit the DATA message that was dropped o Do not obtain an RTT sample when the sending side is in a recovery mode (i.e., it has detected one or more duplicate ACKs). 3 When a timeout occurs cwnd=1 W=1 Restart the timer, retransmit the message that was dropped. The server is a very simple extension to the current server. We are adding one new parameter (the third parameter) to the server that specifies the value of a random loss process that will be used for testing purposes. The parameter range is and represents the average loss rate the server should apply in the form of a random packet loss process. If a data segment arrives with a mode value of 2, it must respond by sending an ACK message that contains 4 bytes of data representing the sequence number of the data that is being acknowledged (i.e., the sequence number of the data just received). The server must continue to maintain per session statistics and display a summary of each session when the program terminates. The client parameters are as follows. : 1. Server IPv4 address as a domain name or in dotted quad format 2. Server port : specifies the server port 3. 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. 4. 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). 5. Debug flag - Same as the server parameter except the sample log file is RTT.dat. 6. Mode : 0 is RTT_MODE (original ECHO mode), 1 is CBR mode, 2 is the new windowed protocol mode. 7. This parameter depends on the Mode parameter a. Mode 0 : Iteration delay: Number of microseconds between iterations b. Mode 1 : Target send rate: The target client sending rate in bits per seconds c. Mode 2 : Maximum Window size allowed. This is in units of packets. A value of 0 indicates there is no maximum. Output monitoring : If the traceflag parameter is set to 1 for either the client or the server, the results of a monitoring process is to be displayed to standard out. The client and server monitor will be almost identical. This applies ONLY when running the new window mode of operation. The traceflag is set with the debugflag parameter on both the client and server. The debugflag contains two pieces of information - If the 8 th bit of 8

9 the lowest byte is set, the traceflag is set. The remaining 7 bits represent the debuglevel. For example, the debugflag value of 1 corresponds to a traceflag clear and a debuglevel of 1 (which is minimum debug info sent to standard out). A debugflag parameter of 129 corresponds to the traceflag set and a debuglevel of 1. The output monitoring idea is similar to how iperf works it periodically shows the average throughput at periodic time interval (which is 1 second by default and can be set by a program parameter). We will assume a monitor interval (we call the value monitortimeperiod) of 1 second. You are to maintain statistics for each interval. The results displayed each monitortimeperiod are based on observed behavior in the last interval time period. Please format the monitor output to something that is brief, all numeric. The client and server can use similar formats but there are important differences. The client should show the following lines every interval time. ClientIP clientport Timestamp avgrtt avgsendrate We define each field as follows: Client IP: The clients IP address in dotted decimal format Client port: The clients port number Timestamp: the current time of the update avgrtt : the average RTT based on the average of all RTT samples that were obtained in the current monitor interval. Please show in units of seconds with a precision of 6 digits after the decimal (i.e., microsecond precision). avgthroughput : the average sending rate during the interval. The server is to behave with no changes for mode 0 or mode 1 sessions. For mode 2 sessions, the server should create and maintain entries in the session state list as currently done. If the server is invoked with the traceflag set (e.g., debugflag of 129 ), it should maintain a subset of the monitor statistics shown by the client. The monitor stats should be based on the aggregate of all session traffic. Timestamp (seconds with microsecond precision): the current time of the update. avgthroughput (bps) : The average throughput observed by the receiver during an interval. During each interval, the server counts the total number of bytes received by all sessions. The avgthroughput is simply the interval byte count (multiplied by 8) divided by the time since the last statistic update. End of program summary information: For Mode 2, the client and server should display appropriate summary information upon termination. Client displays the following based on the results of session from start to end: o SessionDuration TotalPkts TotalBytes avgsendrate avgrtt avglossrate Server displays the same information displayed for mode 1 sessions. 9

10 Test and Validation: You are to create a set of test cases to validate the program functionality works. Your validation must involve the use of tcpdump and the netem/tc tools. Netem/tc is to be used to create test scenarios involving realistic levels of latency and loss. NEW. Let s look at how our protocol s loss recovery is to work. The sender s window is. Let s say seq number 1 is dropped by the 3 other packets are received. Let s also assume the sender sent sequence number 0 and received the RxSeqnumber 1 before line 1 occurs.let s say that the sender has No more data to send. Once it receives the ACK for all 4 packets, it is finished. Sender Cwnd=4 receiver seq number XXXX seq number seq number seq number RTT delay Cwnd= RxseqNumber 1 (first dup) seq number Rx ed seq RxseqNumber RxseqNumber RTT delay =============RxSeqNumber 2 (new ack) Cwnd= seq number Rx ed seq seq number Rx ed seq RTT delay

11 Cwnd= RxseqNumber seq number RxseqNumber seq number RxseqNumber seq number seq number RxseqNumber Lines 1-5 represent the sender sending 5 packets. safely. The first is dropped, the next 4 arrive Line 6 is representing the Round Trip Time we can assume that the time it takes to send the 5 packets is tiny compared to the RTT Line7 is when the first duplicate ACK arrives. Our sender sets cwnd to 1 and retransmits Seq Number 1 and ignores the three other ACK msgs that arrive. Line 12 illustrates the relatively long RTT before the sender might see a response from the receiver (for the retransmit of seq number 1) Solution : Refer to HW4V3-sol.tar.gz (if not currently on our web page, it will be soon) Grading: The grading will reflect that this programming assignment was quite challenging. The base grading will be designed to assess the team made a decent effort. Extra credit (added to this homework grade) will be used to reward the teams that worked extremely hard to get a solution that has partially working functions (described below) Base grading: (30 points) 1. (5) Team submitted code that clearly reflects they added code to the starting HW4 code. 2. (5) Team submitted a writeup that attempts to describe what they have implemented and what works and what does not work. 3. (5) Testing/validation the team included in their writeup the approach to test/validation. o Identifies specific test cases o Includes results for at least one test case (did not need to successfully use netem in a test case for these points) 11

12 4. (15) Base grade that is based on their code and writeup o (5) Running the code submission in modes 0, 1: After a download, the standard make clean, make creates two executables. The client and server support modes 0 and 1 as before Test mode 0 on a VM: should run and give a result at the client, server and produces two output files; RTT.dat and EchoServer.dat o./server o./client localhost Test mode 1 on a VM run for 30 seconds or so, cnt-c both server and client. Just check the client standard out that reflects an actual send rate of about (lots of variability in what you might see but should be at least ). o./server o./client localhost o Run in the new mode: (5 points for each of the three tests) Test 1 run 10 iterations :./server /client localhost Grading items : o Produce output monitoring to standard out at both the client and server o While running, does it appear the client/server are exchanging messages? o Does it stop after 10 iterations? o After it stops, does it appear like the cwnd/currentwindow starts at 1 and increases with each ACK? Grading items for misc. errors: o Seg faults but nothing appears to work o Runs, appears to do something, ends in seg fault. o Runs, appears to do something, ends possibly with an error Test 2 run with iterations 0 :./server /client localhost Grading items : o Produce output monitoring to standard out at both the client and server o While running, does it appear the client/server are exchanging messages? o Does it stop after 10 iterations? Test 3 run with maxw set to 1 :./server

13 ./client localhost Grading items : o Does it appear to operate correctly in this stop-andwait mode of operation? o Code inspection - Only necessary if the above tests are not sufficient to determine how much of mode 2 was implemented and successfully tested. To calibrate the base grading, it is possible to get a 30 (full credit) if a subset of the full mode 2 protocol is successfully implemented. Note that none of the mode 2 tests involved loss. Beyond Base grading: If the submission clearly exceeds the base grading, we will allocate up to 10 points extra credit. So the following should apply only for those implementations that have come close to satisfying tests 1,2,3. So the extra credit can still be allocated if the base grade is let s say at least If the implementation successfully passes tests 1,2,3 AND if we can determine that Data and ACK messages are correctly sent/received, AND we see that the cwnd/window correctly grows, AND the group submitted a good writeup - allocate 5 extra credit points. 2. Independent of the extra credit test 1 above, if the submission appears to correctly handle loss in a reasonable manner, allocate 5 extra credit points. The basic result to look for is that the output monitor should show the client sending at a rate that oscillates from something low to something high. And after several minutes after a CNT-C, the client should show an average sending rate of something that seems to make sense o./server //Adds 10% artificial loss o./client localhost For projects that have satisfied both #1 and #2 extra credit options allocate 10 points extra credit 13