hidden node scenario - pearson web viewstart opnet it guru. open the scenario. select file/open. ......

NETW310 Network Flow Control and Error Control Pg. 1

Part 1 - Flow ControlLab ObjectiveTo observe common flow control and error control mechanisms used in networks.You will examine how TCP works in order to demonstrate the method it uses to control the rate of transmission or flow control. All protocols have methods to assure that transmitted information will not overrun the receiver. We will watch the sliding windows form and grow through the process of slow start.

Explanation and BackgroundThe TCP/IP Protocol Suite has two protocols at the Transport layer, both of which are designed to operate with applications on the upper layers.UDP (User Datagram Protocol) is a datagram service, designed to carry small messages between applications with as little overhead as possible. The only information carried in the UDP header is for the source and destination port numbers, the length of the datagram and a checksum. UDP makes no guarantees about whether the data will arrive, how quickly it will arrive, or whether it will arrive in any particular order. It is called a pass-through protocol because it does nothing other than pass the data it is given. It is used for audio, video, and other real-time data because of the lack of overhead and because packets missed in such data flows must be ignored anyway.TCP (Transmission Control Protocol), on the other hand, is a byte stream service that guarantees that a stream of bytes of any length received at the source will be exactly duplicated at the destination. To do this, TCP offers several services.Segmentation: TCP splits the byte stream up into pieces referred to as segments that will traverse the network. The size of these segments is usually controlled by the layer two protocol being used (i.e., Ethernet) and is referred to as the Maximum Segment Size or MSS. The MSS is agreed to as part of the initial handshake when TCP sets up the connection between source and destination.Packet Ordering: Packets are sent in order, and that order is maintained and restored at the destination, even when packets arrive at odd times or are missing, which they may do since they are carried by IP.Data Integrity: TCP executes a full CRC checksum on each segment which must be verified at the destination. If data is corrupt, the segment is discarded and resent. Duplicated packets are destroyed.Acknowledgement: By default, TCP uses a cumulative acknowledgement scheme in which it acknowledges receipt of the entire data stream up to that point. This scheme is the primary means of error control when packets are lost or corrupted.The scheme most commonly used is actually selective acknowledgement or SACK. SACK allows the program to specify blocks of segments as having been received while requesting retransmission of missing segments. It is much more efficient but can only be used when both ends stipulate it. Fortunately, most TCP/IP stacks these days support this option.


In addition, there are some additional flavors of TCP/IP, most notably Tahoe and Reno, which support different options.Retransmission: TCP will retransmit any packets/segments not acknowledged or received in error.Flow Control: TCP uses what is called the sliding window within buffers to coordinate sending the data between the source and the receiver. If packets are sent too fast and buffers fill at the destination, causing packets to be discarded, the source will detect this through the acknowledgements and will slow its transmission, usually by half. When acknowledgements are received again, transmission will speed up.Congestion Control: This is a set of processes for TCP to avoid congesting the network and is sometimes referred to as Network Congestion Control. TCP uses several algorithms for sending data depending on the conditions on the network. In Slow Start, for instance, TCP starts a byte stream by sending one packet and waiting for a response. When it receives the acknowledgement, it will send two packets and wait, etc. Normally, a TCP receiver will acknowledge every third or fourth packet. In addition to getting the acknowledgement, TCP has put a time-stamp on the packet and gets the Round Trip Time, or RTT, which is the amount of time it took for the packet to get to the destination and the acknowledgement to return to the sender. The RTT is used to help set the Retransmission timer, a clock that starts for each packet sent. If that clock expires and no acknowledgment has been received, the packet is resent in a retransmission.Network managers monitor TCP retransmissions very carefully since a rising number of them is a primary indicator of network congestion or other problems.ProcedureExecute the steps as shown.

When you encounter an asterisk “” in these instructions, a question is being asked that you must answer on your lab report. When you have answered every question and provided all required information and screenshots, your lab is complete. When your lab report is complete, insert it into the Dropbox for the week for grading by your Instructor. The symbol denotes a note or a sidebar that you should pay attention to.


ProcedureStart OPNET IT GuruOpen the scenario1. Select File/Open.2. Select Project.3. You will need to navigate to your f:/ drive. That’s your drive in the iLab

environment. You will see your D number in the title.4. Choose “f:/op_models”. All ITGuru projects are stored in this folder and, if you

ever start a new project, be sure to start it in this folder.5. Open the folder NETW310. Select the FlowErrorTCP.project directory and double-

click “FlowErrorTCP.prj”, the project file.6. The project should open. There are two scenarios in this project,

TCP_FlowControl and TCP_ErrorControl. We want to use the TCP_FlowControl scenario first.

7. If you do not see this scenario, you will need to switch to it by going to the Tool Bar and selecting Scenarios > Switch to Scenario > TCP_FlowControl.


1. When TCP starts a byte stream, it needs to make certain that the client and the server are on the same page; it does several things to accomplish this. Maximum Segment Size: TCP’s segment size is computed by subtracting 20 bytes for the IP header and 20 bytes for the TCP header from the MSS. The default MSS for IP is 876 bytes (RFC 879), and subtracting 40 bytes from that gives us 836 bytes. This is an inefficient size when dealing with large files. We prefer using a larger MSS.

Ethernet’s MSS is 1500 bytes (Ethernet II, the default frame for TCP/IP), a more attractive size. When we subtract 40 bytes, we have 1460 bytes, almost twice the default. The MSS size for the client and server can be determined in a couple of ways, but the most common is to inquire at the local interface about the Layer two protocol present. Each then advertises its MSS in the options field of the IP header, and the smaller of the two is chosen.

TCP Window Size: The two byte Window Size field in the TCP header allows nodes to exchange information about their Window size, the size of the buffer available. This is the total amount of data the node can accept without discarding packets. Remember that the node is processing segments out of the buffer and, ideally, we would like data to arrive at about the same rate as it is being processed. Using this field, the node can set a window size of between 2 and 65,535 bytes. This is often inefficient when more memory is available, so the TCP Window Scale option can be used (RFC1323). This factor can be set from 0 to 14, with 0 being no change.

2. The network for this lab is about as simple as it can get, a client and a server. You can look at how this scenario is set up. To see the Attributes of an object, you can click it to select it, then right-click to see the pop-up menu. You can also double-click the object. Do one of the two on the Application Config object, and then select Edit Attributes from the menu.

You should see the (Application Config) Attributes window.


3. IT Guru’s Attributes are stored in a tree structure, so expand the Application Definitions tree by clicking the + sign to the left of the name. By the same token, expand Row 0 and Description.

4. Click on the ellipse (…) in the Value column next to FTP. From the pop-up menu, select Edit. You will see the (Ftp) Table window.

5. Here we see that there will be one GET (100% command mix); we are going to move a 1.6MB file, and we will be using Best Effort (that’s the IP default). Click OK twice to close these windows.


6. Now open the Edit Attributes window for the Profile Config object. We configure the applications we are going to use in the Application Config object, and then we use this object to configure the users. We set up user profiles that we can place on the nodes to generate activity like real users. Expand the Profile Configuration tree as shown below.

7. Note that there is a profile named FTP Traffic and it will be using the File Transfer application set up in the Application Config object. This profile will kick off 100 seconds into the simulation and execute once. Click OK to close the window.

8. Open the Attributes window on the client node. Expand the Applications tree as shown below and note that the FTP Traffic profile has been placed on this node. A profile acts as a user, so we have one user on this node using FTP. Click OK to close.


9. Open the Attributes window for the server object. Note that there are no supported profiles on the server. This is because FTP is a service on this node. Click on the ellipse beside Application: Supported Services. Select Edit. The (Application: Supported Services) Table shows you that File Transfer is listed as a service. Thus, this node is a server. Nodes can act as both clients and servers by supporting both profiles and services. This would be the case in a peer-to-peer situation.

10.Click OK or Cancel on the two windows to close them. We are now ready to choose what statistics to gather during our run.


Gathering the Information1. To specify stats to be collected in the simulation, right-click anywhere in the

work area. Select Choose Individual DES Statistics from the pop-up menu.

2. You will see the Choose Results window (below, showing the top only). Here we have a tree structure for the attributes. There are three types; Global for the entire scenario, Node for particular nodes, and Link for the links connecting the nodes. You select or unselect the stats you want by clicking on the grey boxes. Click on the + sign beside Global.

3. The tree will expand, showing that we have selected stats from the TCP entry. Click on the + beside TCP and note that we have selected Delay (sec), Retransmission Count, and Segment Delay. We do not expect any surprises in these particular stats since we are running only the two nodes and one application, but delay, retransmission count, and segment delay will be counted wherever they occur in the network.


4. Close the Global tree and open the Node tree. A statistic has been selected for Client FTP, so expand that link. We are going to monitor for Download Response Time because this will give us an idea about whether this parameter has changed due to something in the scenario. Close the Client FTP tree and scroll down.


5. We have selected stats from the TCP and the TCP Connection trees, so expand those trees. These are large trees with a number of stats.

6. Under TCP, we have selected Load (bytes), Retransmission Count, and Segment Delay (sec) although, as previously, we do not expect to see much.

The stats of real interest are under TCP Connection, and we are especially concerned with the Congestion Window Size (bytes) and the Flight Size (bytes). You will find that if you select the stat (be careful not to change the X), you will see a definition of the stat in the upper right window. Don’t be surprised if you’ve never heard of Flight Size. It is defined in RFC 2581, which sets out the rules for TCP Congestion Control. It is defined as the amount of data received in a buffer which has not been acknowledged. There is a good summary of this RFC at http://www.opalsoft.net/qos/TCP-1010.htm for those who are interested.

We also are getting the Received Segment ACK Number and the Sent Segment Sequence Number (scroll down some more). These two numbers should run in parallel; when they do not, there has been a retransmission. Review the events in the TCP Three-part Handshake if you are foggy about these numbers.

7. Click OK to close this window. We are now ready to run the simulation.

http://www.opalsoft.net/qos/TCP-1010.htm


Run the Simulation

1. Click on the Configure/Run Discrete Event Simulation (DES) button on the tool bar (the running man).

2. The Configure/Run DES: window will open, showing that we are running TCP_FlowControl. Make sure that your values are the same as these. Click Run.


3. The Simulation Execution Window will open, showing the progress of the simulation. This simulation will run very quickly and, in only a few seconds, you should see the completed window.

4. Click Close and we can look at the stats.


Results Analysis1. To the right of the running man icon is the View Results icon. You can click that

or you can right-click anywhere in the work area and, from the menu, select View Results. The Results Browser will open.

In the lower left pane, open the Object Statistics Tree. Open Logical Network > client >TCP Connection and click on Congestion Window.

2. The following graph should appear in the right window.

3. This certainly isn’t very impressive, but we need to look at it much more closely. To do so, click on the Show button on the lower right. A new panel will appear. The function here is to hold down the left mouse button and draw a rectangle around the piece we are interested in. When we get the rectangle correct and release the button, the area we selected now fills the panel.


4. Do it again.

5. Now you can see that the transmission started about 100 seconds into the simulation and the congestion window on the client started out about 4,400 bytes. Actually it started at 4,380 bytes because 1,460 x 3 is 4,360 and the buffer started large enough for 3 segments. If this is still a little mysterious, review the material in the first lab on MSS.

6. The transmission of this file took slightly over 11 seconds and the Congestion Window on the client increased the entire time. This is due to slow start. The more packets the client receives and acknowledges without error or loss, the larger this window will grow. The client can steadily take more and more data until it gets to the point at which it is processing out about as much as it is taking in. Get rid of this window by clicking the X in the upper right window and then tell the prompt to delete the window.


7. Now let’s look at the server side. Close the client tree and open the server tree and TCP Connection. Select Congestion Window Size and Flight Size from the available stats.

8. Let’s again make this more readable. First, in the Presentation panel in the lower right, click the arrow to the right of As Is and select time_average from the large pop-up. This changes the Flight size in an interesting fashion. Now change the Stacked Statistics in the lower right to Overlaid Statistics and we can see them superimposed on each other. Now let’s work some magic… click the Show button and zoom the main area of the resulting panel.


9. You should see:


10. Repeat this operation until you get close to this. This panel covers about 15 seconds of the timeline, especially the 11 seconds of the transmission. The Server’s Congestion window is doing something entirely different than the client since it is moving information into the buffers in preparation for sending. The last thing we want to do is wait for the server while it’s loading up its buffer.

11. Now it’s time for your first question.

1. Looking at the above graph, write a short paragraph on what is happening here with the congestion window and the flight size.

12.Get rid of this window. You might want to hide it rather than delete it so you can look at it later.


13.Deselect the current statistics in the left pane and select Received Segment Ack Number and Sent Segment Ack Number on the server.


14. This small blip needs to be magnified; do so until you see something like this.

15.Both the server and the client maintain the Sequence Number and the Acknowledgement Number. Both of these begin with the random selection of the Initial Sequence Number on each end. Both are 32 bit random numbers (and the more random the better since, if they are not, hackers can guess them and highjack the byte stream) which are then incremented by the number of bytes sent/acknowledged. In the graph above, think of the red line as the sequence number going out and the blue line as the acknowledged sequence number coming back. The growing separation of the lines as the stream moves from left to right is caused by the fact that more and more packets are being sent between acknowledgements and TCP only acknowledges the most recent. Remember that once the stream gets underway, TCP normally acknowledges about every 3-5 packets; you see the stream of sent and received numbers separate as more packets are sent before acknowledgement occurs. This is a graphic demonstration of Slow Start and flow control in TCP.

The slope remains fairly constant through most of the transmission until it nears the end. The steep upward slant at that point is the end process since the final segments are sent and acknowledged and the connection is broken.This particular graph will be of special interest in the next lab, so Hide this window rather than delete it.

Results Analysis


When you answer these questions, include in your answer the name of the statistics panel you used to derive the answer. Remember that each of the panels has a name in the top bar.

2. In the Results Browser, bring up the Global TCP statistics for Delay (sec) and Segment Delay sec). In a short paragraph, comment on the delay graph. 3. Overlay the statistics for Client Received Segment Ack Number and Sent Segment Ack Number. Zoom until you see a definite separation and shapes as below. Write a short paragraph explaining why the Client numbers are so different from the servers and a description of what is happening.


Part 1 of the lab is complete. Continue on to Part 2.

Part 2 - Error ControlLab ObjectiveTo observe common error discovery mechanisms used in networks. You will examine how errors in TCP causing retransmission affect the data stream and the network. We will use a very simple setup that will start a TCP byte stream and then discard packets in transit. The reaction of TCP and how it affects the network will be shown.

MethodologyThis lab requires that you are to have completed the Flow Control lab already. If you have not, you will need to before starting this lab. There are many references used in this lab which were explained in the previous lab and will not be repeated.

Explanation and BackgroundTCP (Transmission Control Protocol): A byte stream service that guarantees that a stream of bytes of any length received at the source will be accurately duplicated at the destination. To do this, TCP offers several services, including a couple aimed at Error Control.Packet Ordering: Packets are sent in order and that order is maintained and restored at the destination, even when packets arrive at odd times or are missing, which they may do since they are carried by IP.Data Integrity: TCP executes a full CRC checksum on each segment, which must be verified at the destination. If data is corrupt, the segment is resent. Duplicated packets are destroyed.Acknowledgement: By default, TCP uses a cumulative acknowledgement scheme in which it acknowledges receipt of the entire data stream up to that point. This scheme is the primary means of error control when packets are lost or corrupted.The scheme most commonly used is selective acknowledgement or SACK. SACK allows the program to specify specific blocks of segments as having been received while requesting retransmission of missing segments. It is much more efficient but can only be used when both ends stipulate it. Fortunately, these days most TCP/IP stacks support this option.In addition, there are some additional “flavors” of TCP/IP, most notably Tahoe and Reno which support different options.Retransmission: TCP will retransmit any packets/segments not acknowledged.


Modus OperandiExecute the steps as shown. In some instances, you may need to refer to the OPNET documentation; to obtain additional information you may need to execute a step, solve a problem, or build the simulation. In other instances, you may need to do some research in your text or online resources to understand and answer a question.

When you encounter an asterisk in these instructions, a question is being asked that you must answer on your lab report. When you have answered every question and provided all the required information and screenshots, your lab is complete. When your lab report is complete, insert it into the Week 6 Dropbox for grading by your Instructor. The symbol denotes a note or a sidebar that you should pay attention to.


ProcedureStart OPNET IT GuruOpen the scenario8. Select File/Open.9. Select Project.10.You will need to navigate to your f:/ drive. That’s your drive in the iLab

environment and you will see your D number in the title.11.Choose f:/op_models. All ITGuru projects are stored in this folder and, if you ever

start a new project, be sure to start it in this folder.12.Open the folder NETW310. Select the FlowErrorTCP.project directory and double-

click FlowErrorTCP.prj, the project file.13.The project should open. There are two scenarios in this project,

TCP_FlowControl and TCP_ErrorControl. For this lab, use the TCP_ErrorControl scenario.

14.If you do not see this scenario, you will need to switch to it by going to the Tool Bar and selecting Scenarios > Switch to Scenario > TCP_ErrorControl.

Part 2 – Error Control


11.Since TCP is a byte stream service that guarantees the perfect duplication of a byte stream of any length, it has some extensive features used to catch errors. These can catch errors of omission (a segment, or segments, is missing), integrity (the segment is corrupted and must be discarded), and order (the segment received is out of order). This lab will look at what happens when a segment either does not arrive or is corrupted and must be discarded. When this happens, a retransmission is necessary. In addition to being inefficient, sending the same data twice or more is a problem that can greatly affect the performance of your network. It is so busy handling TCP retransmissions (remember, it’s a guaranteed service), that other traffic suffers.

While this lab scenario is simple and designed only to show the error control, a larger scenario with additional nodes and traffic would reflect the problem in greater detail. You will see this very problem in a future OPNET “15” lab in another class.

12.The network for this lab is about as simple as it can get, a client and a server, just as in the previous lab. There are two interesting changes, however. First, the single link from the first lab has been replaced with two one-way links. Second, the link from the server to the client now has an object inserted called a Packet Discarder. This is just what the name implies, an object that discards packets at a particular time.

13.With the two exceptions above, this scenario is set up exactly as the first one. Take a quick look at the Packet Discarder by double-clicking it to select Edit Attributes.

s

14.Expand Packet Discard Configuration and all three of the rows under it. The discarder is set to toss packets at three points in the simulation, dropping a


single packet once and then three packets twice. We will then examine the effects of this. Click OK or Cancel to leave this window.

Gathering the Information8. There is almost no difference in statistics between this lab and the previous lab.

Review the statistics by right-clicking in the work area and select Choose Individual DES Statistics. Note that Global and Node stats both include Delay. Close the Choose window by clicking OK or Cancel.

Run the Simulation5. As before, click the Running Man icon on the Tool Bar to run the simulation.

When the Configure/Run DES window appears, click the Run button.6. As before, the simulation will run very quickly. When the Close button lights up,

click it to leave the window.7. Click Close and we can look at the stats.


Results analysis16.To the right of the Running icon is the View Results icon. You can click that or

you can right-click anywhere in the work area and, from the menu, select View Results. The Results Browser will open.

17.This time, it is required that you copy windows from the program into your Word document of answers. To do this, make sure the window or panel you want to copy is selected (this is the case when the top Title Bar on the window is blue. Press <Alt><Prtscr> and the selected window will be copied into the Windows Clipboard. Paste it into your Word Document with <Ctrl><v> or select paste from the Word menu.

18.First, look at the Congestion Window on the server.


19.Click Show to get the separate panel and blow it up. You should do this until you see something like the following:


Question 1: Given the configuration of the Packet Discarder, write a short paragraph explaining why the server’s Congestion Window size has this variation. Paste a copy of this window into your lab report. When finished, hide or delete the panel.

20.Select the Sent Segment Ack Number and the Received Segment Sequence number for the server; set them on Time_average and Overlaid Statistics. Put them into a Show panel and blow it up to see something like the following:

Continue this operation until you have located the three ”blips” on the slanting line representing the three discards. Paste a panel clearly showing each one into your lab report with a short line describing what is happening. Question 2: Examine the statistics for the client node. Have the packet drops affected anything on the client that you can tell?

Question 3: Examine the Delay stats for the entire network (Global) and for the nodes. Can you see any delay caused by these drops?

21.Now, return to the Results Browser and on the upper left, you will see a small window labeled Results for:. It is set to Current Scenario. Click the menu arrow on the right and select Current Project. Make sure you still have Overlaid Statistics selected and select the Server congestion window. You should see the following window in the browser:


7. Click Show and zoom in until you see a window that looks something like this:

Question 4: Copy this window to your lab report and, in a short paragraph, explain why the congestion window sizes are different in the two scenarios. Complete

hidden node scenario - pearson web viewstart opnet it guru. open the scenario. select file/open. ......

Documents