Quality of Service (QoS)-Part1
Timeline and history of QOS
Best Effort:Back to year 1992, earlier all TCP IP traffic was treated equally with the Best Effort system. Conventional Internet routers and LAN switches operates on a best effort basis. These equipment generally less expensive, less complex and faster and thus more popular than competing more complex technologies that provided QoS mechanisms. Moreover, ordinary applications that are not time sensitive or tend not to be “drop sensitive” flourished in this environment.
Essentially, the first person who get into the network and tries to send the data, got the bandwidth. And as more people came, they fought for the bandwidth and It became the survival of the fittest. That system works great and still works for the most of the application because applications have built in mechanism allow them to recover or slow down when bandwidth utilization at the peak. This system worked perfectly fine until the new applications came out that require priority traffic/bandwidth and need to get from source to destination very quickly.
Integrated Services: That was when the first QOS implementation was released known as Integrated Services (intServe). IETF came up with a protocol called RSVP or Resource Reservation Protocol. RSVP used to reserve bandwidth for specific applications. RSVP signals bandwidth and latency requirements for each discrete session or flow of traffic, and uses constant messaging to ensure the bandwidth and latency requirements can be maintained throughout the call. For example, you reserved bandwidth at every router for that particular type of application and it guarantees that no matter what bandwidth is reserved to that application. In case that application doesnt use that bandwidth, no other application can use that unused bandwidth. This method worked great, until a lot of application that needed bandwidth came out and there was a need felt to utilized that unused bandwidth. Moreover, The problem with this is that it’s not too scalable, especially when you are the service provider with lots of enterprise customers making hundreds of calls each, and then add on having to carry not only the calls but all the “state” information of RSVP on a per-call basis across your backbone.
Then in late 1993 and early 1994, something else began happening to enterprise customers. Hackers started pushing out malicious, time-based software to unknowing enterprise employees and launching this Trojan software on corporate laptops and workstations. Then, when the appropriate time hit in the Trojan software code, all these infected systems turned into an attack mechanism by sending massive amounts of traffic all at once to each other. The intention was to rob you of your ability to use your campus or remote site infrastructure, thus taking down your core and business applications.
This was not pretty, and quite a few very large corporations reported at one time or another, having their core down for up to 3 days. So then in 1994 corporations switched from the mentality of “I need QoS for voice and video”, to “I need QoS to protect my business applications”.
Differentiated Services:Seeing this was a big issue, the IETF drafters came up with DSCP or DiffServ (Differentiated Services) model. This is one of the most popular QoS method is still being used today. It can also be used with IntServe. Diff Serve gives a per hop mechanism. Means, every router you get to, will re-queue you and re-prioritise you based on different markings. Unlike RSVP, DSCP does not give any bandwidth or latency guarantees to individual traffic flows, but provides the same service hop-by-hop by using packet marking in type of Service header in your IP packet and would treat the traffic the same
way hop by hop. This allows more flexibility as you do not have reservations of bandwidth for a particular application that locked out all traffic abilities. Instead, you have the ability to prioritize at each point/router, and when priority traffic reach to certain level, you can go ahead and cut it off and keep it from overwhelming the network.This is scalable, however it lacks a Call Admission Control mechanism that was built into RSVP. In other words, no guarantees could be made when trying to make the call since there was not enough bandwidth, the call would be rejected.
MPLS/VPN QOS:Around year 2000, that was when we came out with MPLS/VPN Qos, MPLS is a method essentially route at layer 2. Service provided used MPLS to route the traffic from one end to another to the fastest way possible. With new QoS implementation, we were also able to use QoS in such MPLS networks and within VPN that allow people to connect from a home network with an IP phone or some sort of high priority traffic.
Auto QOS/Template:Around year 2002-2003, Cisco came out with something called as Auto Qos or Template Qos, which is essentially a automated system on Cisco routers and switches.It has a standard template filled with all required valued. But with auto QoS, there can still be lot of little tuning and tweaking that you might have to do depending on your specific network type/environment.
QOS for security:From year 2004-2005, Finally QoS is being used for security, we are seeing QoS service mechanism like NBAR. NBAR mechanism can recognize application itself instead of port numbers. This can be very helpful when any application with a traffic pattern, keep changing its port numbers and tries to get into the network.
Candidates for Quality of Service (QoS)
An interface experiences congestion when it is presented with more traffic than it can handle. Network congestion points are strong candidates for Quality of Service (QoS) mechanisms. The following is an example of typical congestion points:figure
Types of Traffic
Data
Data traffic can be smooth for a few application but can be burstly at the same time like FTP. An Application,
Voice is very smooth. It requires constant stream of bandwidth. It is benign, ,means when start consuming traffic, it doesn't ask for more. Voice traffic is very predictable.
For Example, audio codec G.711 (used for uncompressed stream), uses 80 kbps per call. For two calls, we need 160 kbps constant stream. But here we will not have sudden burst of traffic because it requires constant stream of bandwidth but it is very sesitive to any drop or delay.
This stream is very predictable and sensitive to drop and delay but bursty kind. Video traffic is very greedy based on a sudden burst of traffic. Nice thing is video is not as important as voice. In video conferencing, we can have voice call and sees somebodys video at the same time. But when comes to priority, voice get higher priority than video because if we drop a voice packet, people instantly notice.
If we have severe scarcity of bandwidth, QOS cannot help but QOS can work on these terms to improve the network performance.
Timeline and history of QOS
Best Effort:Back to year 1992, earlier all TCP IP traffic was treated equally with the Best Effort system. Conventional Internet routers and LAN switches operates on a best effort basis. These equipment generally less expensive, less complex and faster and thus more popular than competing more complex technologies that provided QoS mechanisms. Moreover, ordinary applications that are not time sensitive or tend not to be “drop sensitive” flourished in this environment.
Essentially, the first person who get into the network and tries to send the data, got the bandwidth. And as more people came, they fought for the bandwidth and It became the survival of the fittest. That system works great and still works for the most of the application because applications have built in mechanism allow them to recover or slow down when bandwidth utilization at the peak. This system worked perfectly fine until the new applications came out that require priority traffic/bandwidth and need to get from source to destination very quickly.
Integrated Services: That was when the first QOS implementation was released known as Integrated Services (intServe). IETF came up with a protocol called RSVP or Resource Reservation Protocol. RSVP used to reserve bandwidth for specific applications. RSVP signals bandwidth and latency requirements for each discrete session or flow of traffic, and uses constant messaging to ensure the bandwidth and latency requirements can be maintained throughout the call. For example, you reserved bandwidth at every router for that particular type of application and it guarantees that no matter what bandwidth is reserved to that application. In case that application doesnt use that bandwidth, no other application can use that unused bandwidth. This method worked great, until a lot of application that needed bandwidth came out and there was a need felt to utilized that unused bandwidth. Moreover, The problem with this is that it’s not too scalable, especially when you are the service provider with lots of enterprise customers making hundreds of calls each, and then add on having to carry not only the calls but all the “state” information of RSVP on a per-call basis across your backbone.
Then in late 1993 and early 1994, something else began happening to enterprise customers. Hackers started pushing out malicious, time-based software to unknowing enterprise employees and launching this Trojan software on corporate laptops and workstations. Then, when the appropriate time hit in the Trojan software code, all these infected systems turned into an attack mechanism by sending massive amounts of traffic all at once to each other. The intention was to rob you of your ability to use your campus or remote site infrastructure, thus taking down your core and business applications.
This was not pretty, and quite a few very large corporations reported at one time or another, having their core down for up to 3 days. So then in 1994 corporations switched from the mentality of “I need QoS for voice and video”, to “I need QoS to protect my business applications”.
Differentiated Services:Seeing this was a big issue, the IETF drafters came up with DSCP or DiffServ (Differentiated Services) model. This is one of the most popular QoS method is still being used today. It can also be used with IntServe. Diff Serve gives a per hop mechanism. Means, every router you get to, will re-queue you and re-prioritise you based on different markings. Unlike RSVP, DSCP does not give any bandwidth or latency guarantees to individual traffic flows, but provides the same service hop-by-hop by using packet marking in type of Service header in your IP packet and would treat the traffic the same
way hop by hop. This allows more flexibility as you do not have reservations of bandwidth for a particular application that locked out all traffic abilities. Instead, you have the ability to prioritize at each point/router, and when priority traffic reach to certain level, you can go ahead and cut it off and keep it from overwhelming the network.This is scalable, however it lacks a Call Admission Control mechanism that was built into RSVP. In other words, no guarantees could be made when trying to make the call since there was not enough bandwidth, the call would be rejected.
MPLS/VPN QOS:Around year 2000, that was when we came out with MPLS/VPN Qos, MPLS is a method essentially route at layer 2. Service provided used MPLS to route the traffic from one end to another to the fastest way possible. With new QoS implementation, we were also able to use QoS in such MPLS networks and within VPN that allow people to connect from a home network with an IP phone or some sort of high priority traffic.
Auto QOS/Template:Around year 2002-2003, Cisco came out with something called as Auto Qos or Template Qos, which is essentially a automated system on Cisco routers and switches.It has a standard template filled with all required valued. But with auto QoS, there can still be lot of little tuning and tweaking that you might have to do depending on your specific network type/environment.QOS for security:From year 2004-2005, Finally QoS is being used for security, we are seeing QoS service mechanism like NBAR. NBAR mechanism can recognize application itself instead of port numbers. This can be very helpful when any application with a traffic pattern, keep changing its port numbers and tries to get into the network.
Candidates for Quality of Service (QoS)
An interface experiences congestion when it is presented with more traffic than it can handle. Network congestion points are strong candidates for Quality of Service (QoS) mechanisms. The following is an example of typical congestion points:figure
Types of Traffic
Data
Data traffic can be smooth for a few application but can be burstly at the same time like FTP. An Application,
Cetrix is very sensitive to drop and delay but it is smooth and benign whereas FTP is greedy and bursty but not that sensitive to drop and delay.
- Citrix- Smooth, sensitive to drop
- FTP-Bursty, non-sesitive to drop
Voice is very smooth. It requires constant stream of bandwidth. It is benign, ,means when start consuming traffic, it doesn't ask for more. Voice traffic is very predictable.
For Example, audio codec G.711 (used for uncompressed stream), uses 80 kbps per call. For two calls, we need 160 kbps constant stream. But here we will not have sudden burst of traffic because it requires constant stream of bandwidth but it is very sesitive to any drop or delay.
- Smooth
- Not bursty
- Sensitive to drop/delay
- Highest priority
This stream is very predictable and sensitive to drop and delay but bursty kind. Video traffic is very greedy based on a sudden burst of traffic. Nice thing is video is not as important as voice. In video conferencing, we can have voice call and sees somebodys video at the same time. But when comes to priority, voice get higher priority than video because if we drop a voice packet, people instantly notice.
- Bursty
- Greedy
- Sensitive to drop/delay
- Not as critical as voice traffic.
If we have severe scarcity of bandwidth, QOS cannot help but QOS can work on these terms to improve the network performance.
- Packet Loss: Too much traffic in the network causes the network to drop packets
- Delay: Delay for packet delivery. Sometimes is referred as latency.
- Jitter= Variations in delay of packet delivery
- Best Effort Based
- Integrated Services (Int Serve)-IETF standard
- Differentiated Services (Diff Serve)-IETF standard
- Just like working without QOS
- No differenciation of traffic types-web traffic, FTP traffic, Peer-to Peer traffic (bit torrent)
- This is default queuing method
- No control on type of traffic
- Original design of Internet
- Provides guaranteed Delivery(No other application can use it)
- Model designed and optimized for application
- Not scalable, most of the bandwidth wasted if unused
- Identifies classes of Network Traffic
- Allows to choose the level of services for each class.
Continue.... Search for QOS- Part2 for more reading.
No comments:
Post a Comment