QoS Building Blocks
Let’s now take a look at some of the building blocks of QoS.
There are a wide range of QoS services. Queuing, traffic shaping,
and filtering are essential to traffic prioritization and congestion control,
determining how a router or switch handles incoming and outgoing traffic. QoS
signaling services determine how network nodes communicate to deliver the specific
end-to-end service required by applications, flows, or sets of users.
Let’s take a look at a few of these.
Let’s take a look at a few of these.
Classification
- IP Precedence- Committed Access Rate (CAR)
- Diff-Serv Code Point (DSCP)
- IP-to-ATM Class of Service
- Network-Based Application Recognition (NBAR)
- Resource Reservation Protocol (RSVP)
Policing
- Committed Access Rate (CAR)
- Class-Based Weighted Fair Queuing (CB WFQ)
- Weighted Fair Queuing (WFQ)
- Committed Access Rate (CAR)
- Class-Based Weighted Fair Queuing (CB WFQ)
- Weighted Fair Queuing (WFQ)
Shaping
- Generic Traffic Shaping (GTS)
- Distributed Traffic Shaping (DTS)
- Frame Relay Traffic Shaping (FRTS)
- Generic Traffic Shaping (GTS)
- Distributed Traffic Shaping (DTS)
- Frame Relay Traffic Shaping (FRTS)
Congestion Avoidance
- Weighted Random Early Detection (WRED)
- Flow-Based WRED (Flow RED)
- Weighted Random Early Detection (WRED)
- Flow-Based WRED (Flow RED)
Congestion Management— Fancy Queuing
Weighted fair queuing is another queuing
mechanism that ensures high priority for sessions that are
delay sensitive, while ensuring that other applications also
get fair treatment.
For instance, in the Cisco network, Oracle SQLnet traffic, which consumes relatively low bandwidth, jumps straight to the head of the queue, while video and HTTP are serviced as well. This works out very well because these applications do not require a lot of bandwidth as long as they meet their delay requirements.
A sophisticated algorithm looks at the size and frequency of packets to determine whether a specific session has a heavy traffic flow or a light traffic flow. It then treats the respective queues of each session accordingly.
For instance, in the Cisco network, Oracle SQLnet traffic, which consumes relatively low bandwidth, jumps straight to the head of the queue, while video and HTTP are serviced as well. This works out very well because these applications do not require a lot of bandwidth as long as they meet their delay requirements.
A sophisticated algorithm looks at the size and frequency of packets to determine whether a specific session has a heavy traffic flow or a light traffic flow. It then treats the respective queues of each session accordingly.
Weighted fair queuing is self-configuring and dynamic. It is also turned on by default when routers are shipped.
Other options include:
- Priority queuing assigns different priority levels to traffic according to traffic types or source and destination addresses. Priority queuing does not allow any traffic of a lower priority to pass until all packets of high priority have passed. This works very well in certain situations. For instance, it has been very successfully implemented in Systems Network Architecture (SNA) environments, which are very sensitive to delay.
- Custom queuing provides a guaranteed level of bandwidth to each application, in the same way that a time-division multiplexer (TDM) divides bandwidth among channels. The advantage of custom queuing is that if a specific application is not using all the bandwidth it is allotted, other applications can use it. This assures that mission-critical applications receive the bandwidth they need to run efficiently, while other applications do not time out either.
This has been implemented especially effectively in applications where SNA leased lines have been replaced to provide guaranteed transmission times for very time-sensitive SNA traffic. What does “no bandwidth wasted” mean?Traffic loads are redirected when and if space becomes available. If there is space and there is traffic, the bandwidth is used.
Random Early Detection (RED)
Random Early Detection (RED) is a congestion
avoidance mechanism designed for packet switched networks
that aims to control the average queue size by indicating
to the end hosts when they should temporarily stop sending
packets. RED takes advantage of TCP’s congestion control
mechanism. By randomly dropping packets prior to periods of
high congestion, RED tells the packet source to decrease its
transmission rate.
Assuming the packet source is using TCP, it will decrease its transmission rate until all the packets reach their destination, indicating that the congestion is cleared. You can use RED as a way to cause TCP to back off traffic. TCP not only pauses, but it also restarts quickly and adapts its transmission rate to the rate that the network can support.
RED distributes losses in time and maintains normally low queue depth while absorbing spikes. When enabled on an interface, RED begins dropping packets when congestion occurs at a rate you select during configuration.
RED is recommended only for TCP/IP networks. RED is not recommended for protocols, such as AppleTalk or Novell Netware, that respond to dropped packets by retransmitting the packets at the same rate.
Assuming the packet source is using TCP, it will decrease its transmission rate until all the packets reach their destination, indicating that the congestion is cleared. You can use RED as a way to cause TCP to back off traffic. TCP not only pauses, but it also restarts quickly and adapts its transmission rate to the rate that the network can support.
RED distributes losses in time and maintains normally low queue depth while absorbing spikes. When enabled on an interface, RED begins dropping packets when congestion occurs at a rate you select during configuration.
RED is recommended only for TCP/IP networks. RED is not recommended for protocols, such as AppleTalk or Novell Netware, that respond to dropped packets by retransmitting the packets at the same rate.
No comments:
Post a Comment