OPNET IT Guru: Quality of Service

For Lab 5 of TCP/IP we are studying Quality of Service (QoS) and the Impact of Queuing Policy using OPNET IT Guru Academic Edition 9.1.

OPNET is a network simulation tool with many capabilities. It can simulate several different types of networks in its entirety and predict the outcome its events. Events such as QoS, network performance other measures.

Quality of Service (QoS) gives routers the ability to classify packets into different queues based on their priority level.

For this lab two FTP applications are to be created each running on its own client workstation with different priorities, one higher one lower. The Type of Service (ToS) set for the first application will be Best Effort, which has the lowest priority level. The second application will have its ToS set to Excellent Effort. Although Excellent Effort is not the highest priority it is certainty higher than Best Effort. In addition to the two clients, two routers will be setup. On of the routers is just a regular router and the outer denoted as a QoS router. The two routers are connected to each other via PPP_DS1 links, while the QoS router is connected to a FTP Server via a PPP_DS3 link. The speed of the DS1 link is 1.5 Mbps (made of 24 DS0s, 64Kbps)and the speed of the DS3 link is 44.7 Mbps (the number of DS0s is a lot!). DS3 is short for Digital Signal Level. Both routers are configured to have the same QoS scheme of Priority Queuing. Different packets originating from two different applications will have their ToS field in its IP header checked to determine which will get the higher priority.

With the FIFO QoS Scheme the higher priority application always took precedence. It waited in the queue buffer much less than the lower priority packets. Jitter was experienced hardly ever experienced. And, the length of time to wait in the queue was pretty much never, because for as long as their are packets waiting in the this high priority queue packets in the low priority are never sent out.

:::snip:::
Due to time I have to finish this lab before it is due within the next few days. Coincidently, while working on this Lab my professor steped in the advanced lab and found me working on it. To his surprise I was the only one who did not have trouble with this lab. He himself had problems actually getting this lab to function as the tutorial stated.

Random Quote

A wise man once said: "Anything you learn can and may be used for or against you in the future. So learn wisely my son. This is where greed is a good thing!".

"The TCP Three-Way Handshake gone stale"

In response to my previous post I take it anything good can be used for bad? That does not even sound right. The TCP three-way handshake when used incorrectly, known as the TCP SYN Attack, can render services useless on a particular target system. I like the concise description given on Cicso's site:

When a normal TCP connection starts, a destination host receives a SYN (synchronize/start) packet from a source host and sends back a SYN ACK (synchronize acknowledge). The destination host must then hear an ACK (acknowledge) of the SYN ACK before the connection is established. This is referred to as the "TCP three-way handshake."

While waiting for the ACK to the SYN ACK, a connection queue of finite size on the destination host keeps track of connections waiting to be completed. This queue typically empties quickly since the ACK is expected to arrive a few milliseconds after the SYN ACK.

The TCP SYN attack exploits this design by having an attacking source host generate TCP SYN packets with random source addresses toward a victim host. The victim destination host sends a SYN ACK back to the random source address and adds an entry to the connection queue. Since the SYN ACK is destined for an incorrect or non-existent host, the last part of the "three-way handshake" is never completed and the entry remains in the connection queue until a timer expires, typically for about one minute. By generating phony TCP SYN packets from random IP addresses at a rapid rate, it is possible to fill up the connection queue and deny TCP services (such as e-mail, file transfer, or WWW) to legitimate users.

IP Spoofing has its good uses

I am over here doing an article on IP Spoofing for my TCP/IP class and came across some very interesting information. Although IP Spoofing is only used for bad things, spoofing has its good uses. I never thought Spoofing could be used for something good. This excerpt on dictionary.com reads:

One of the good uses for Spoofing is to reduce the required bandwidth on network by having devices such as bridges or routers answer for remote devices. This is done to fool (spoof) a LAN device into thinking a remote host is still connected to the network when in actually this host could be disconnected from the network. This saves bandwidth because no packet is ever sent out on the WAN. ["Network Spoofing" by Jeffrey Fritz, BYTE, December 1994, pages 221 - 224].

This is good to know because IP Spoofing always has associated with it negative connotations.