A Survey of existing QoS issues of current existing transport level protocols

Challenges to Enable Quality of Service (QoS) in TCP

Student Name: Fung Yin Man (13120129d)
Yu
Hui CheungYu (13001663d)
Date: 17/10/2014

Contents 1. Introduction - the brief view of p4

2. Overview - the p4-8 1. p5 2. p6-7 3. p7-8

3. Description of main challenging issues and technologies P9-10

4. Review of existing ＿＿＿＿＿＿＿＿＿＿＿＿ and developments P11

5. Future develop direction of p12

6. Conclusion p13

7. Reference p13 7.

ABSTRACT

Nowadays, TCP is a widely used transport protocol at Layer 4 in the World Wide Web for internet connection because it provides flow control and traffic retransmission in case of packet loss. In order to fulfill the highly demand of the traffic and there has been a dramatic increase in the processing power of workstation together with bandwidth of high speed network, additional advanced control mechanism/technologies should be applied to govern and provide rules to guarantee the service level of different kind of application running in the internet. This paper will simply introduce the importance and provide overview of Quality of Service (QoS) for transport level protocol especially in the area of TCP. Also, we will discuss the challenge of implementing the QoS in TCP which include but not limit to the fairness of sharing the bottle neck, how to feedback the congestion, how to involve the Internet router in a unicast/multicast routing environment. Some other deployment of QoS beside the wired network, such as how to leverage QoS in wireless communication and MPLS will also be examined. At last, we will study the possibility of adopting the QoS in the today networking hot topic SDN, software defined network.

Introduction

Why QoS? First let’s define QoS as the capability to apply an identifier to a specific type of traffic so the network infrastructure can treat it uniquely from other types. The primary goals of QoS is to provide priority including dedicated bandwidth, controlled jitter and latency (required by some real-time and interactive traffic), and improved loss characteristics. Then, why we apply QoS to one of the transport layer protocol (TCP)? It is because about 90% of the traffic in today’s packet networks are handled by TCP sessions.
The current trend in the networking world is convergence, voice, data and video are combined and one network carrying traffic and delivering services is the key driver to save business cost. The largest IP network is, of course, the global internet. The Internet has grown exponentially during the past few years, as has its usage and the number of available Internet-based applications. As the Internet and corporate intranets continue to grow, applications other than traditional data, such as Voice over IP (VoIP) and video-conferencing, are envisioned. More and more users and applications are coming on the Internet each day, and the Internet needs the functionality to support both existing and emerging applications and services. Applications have different quality of service (QoS) requirements. For example, video-on-demand applications can tolerate moderate end-to-end delay but require high throughput and very low error rate. In contrast, Internet telephony needs very low end-to-end latency but needs moderate throughput and a slightly higher error rate is acceptable. The Internet, in the past, has provided only best effort service with no predictable performance. Hence, for a specific traffic type, two factors must be considered, characterizing the behavior that the traffic requires from the network and determining which QOS tools can be set in motion to deliver that behavior.

In order to apply QoS into TCP, we shall familiar with TCP so knowledge of how it works is always important. TCP is a reliable, connection-oriented, three way handshakes, full-duplex, byte-stream transport-layer-protocol, which support congestion control and flow control. It also has following characteristics, TCP is adaptive. The window size, timers and other parameters are not statically defined and can vary during a TCP communication based on feedback messages between source and destination. TCP is greedy. It always tries to increase the sending and receiving windows to transmit more quickly. TCP is robust. The detection of packet loss because of receipt of duplicate ACKs or timeouts will cause TCP to slow down, but it is very eager to jump back into the fast lane again.

Besides, there are some of the parameters in the TCP exchange that set the tone for the session’s performance. The Maximum Segment Size (MSS), the congestion window (cwnd) and the sliding window. So in the perfect world, and the perfect network, the session’s speed is ramped up to the receiver‘s window size and the sender‘s congestion window. Any issues with the delivery are handled by the sequence control in the ACKs received and with the timeout window. Therefore, before we talk about the issue of enabling QoS in TCP, we shall have the overview of how it achieves the quality of service and its tools and mechanism, no matter in which transport protocol.

Overview of Basic QoS Architecture

The basic architecture introduces the three fundamental pieces for QoS implementation * QoS identification and marking techniques for coordinating QoS from end to end between network elements * QoS within a single network element (for example, queuing, scheduling, and traffic-shaping tools) * QoS policy, management, and accounting functions to control and administer end-to-end traffic across a network

Service levels refer to the actual end-to-end QoS capabilities, meaning the capability of a network to deliver service needed by specific network traffic from end to end or edge to edge. The services differ in their level of QoS strictness, which describes how tightly the service can be bound by specific bandwidth, delay, jitter, and loss characteristics.

In order to do this the network should implement service models so that services are specific to the traffic they service.

Three service models have been proposed and implemented till date.
1. Best Effort services
2. Integrated/Guaranteed services
3. Differentiated services.
1. Best Effort services
Basic connectivity with no guarantee as to whether or when a packet is delivered to the destination, although a packet is usually dropped only when the router input or output buffer queues are exhausted.
Best-effort service is not really a part of QoS because no service or delivery guarantees are made in forwarding best-effort traffic. This is the only service the Internet offers today.
Most data applications, such as File Transfer Protocol (FTP), work correctly with best-effort service, albeit with degraded performance. To function well, all applications require certain network resource allocations in terms of bandwidth, delay, and minimal packet loss.

2. Integrated/Guaranteed services

A service that requires network resource reservation to ensure that the network meets a traffic flow's specific service requirements.
Guaranteed service requires prior network resource reservation over the connection path. Guaranteed service also is referred to as hard QoS because it requires rigid guarantees from the network.
Path reservations with a granularity of a single flow don't scale over the Internet backbone, which services thousands of flows at any given time. Aggregate reservations, however, which call for only a minimum state of information in the Internet core routers, should be a scalable means of offering this service.
Applications requiring such service include multimedia applications such as audio and video. Interactive voice applications over the Internet need to limit latency to 100 ms to meet human ergonomic needs. This latency also is acceptable to a large spectrum of multimedia applications. Internet telephony needs at a minimum an 8-Kbps bandwidth and a 100-ms round-trip delay. The network needs to reserve resources to be able to meet such guaranteed service requirements.
Resource Reservation Protocol (RSVP) is suggested as the signaling protocol that delivers end-to-end service requirements.

RSVP enables applications to signal per-flow QoS requirements to the network. Service parameters are used to specifically quantify these requirements for admission control.

RSVP is used in multicast applications such as audio/video conferencing and broadcasting. Although the initial target for RSVP is multimedia traffic, there is a clear interest in reserving bandwidth for unicast traffic such as Network File System (NFS), and for Virtual Private Network (VPN) management.

The RSVP daemon in a router communicates with two local decision modules—admission control and policy control—before making a resource reservation. Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control determines whether the user has administrative permission to make the reservation. If either check fails, the RSVP daemon sends an error notification to the application process that originated the request. If both checks succeed, the RSVP daemon sets parameters in a packet classifier and a packet scheduler to obtain the desired QoS. The packet classifier determines the QoS class for each packet, and the packet scheduler orders packet transmission based on its QoS class. The Weighted Fair Queuing (WFQ) and Weighted Random Early Detection (WRED) disciplines provide scheduler support for QoS.

3. Differentiated service

In differentiated service, traffic is grouped into classes based on their service requirements. Each traffic class is differentiated by the network and serviced according to the configured QOS mechanisms for the class. This scheme for delivering QOS is often referred to as COS.
Note that differentiated service doesn't give service guarantees per session. It only differentiates traffic and allows a preferential treatment of one traffic class over the other. For this reason, this service is also referred as soft QOS.
This QoS scheme works well for bandwidth-intensive data applications. It is important that network control traffic is differentiated from the rest of the data traffic and prioritized so as to ensure basic network connectivity all the time. Its aim is to define the differentiated services (DS) byte, the Type of Service (ToS) byte from the Internet Protocol (IP) Version 4 header and the Traffic Class byte from IP Version 6, and mark the standardized DS byte of the packet such that it receives a particular forwarding treatment, or per-hop behavior (PHB), at each network node. The performance level needed on a packet-by-packet basis by simply marking the packet's Differentiated Services Code Point (DSCP) field to a specific value. This value specifies the PHB given to the packet within the service provider network. Typically, the service provider and customer negotiate a profile describing the rate at which traffic can be submitted at each service level. Packets submitted in excess of the agreed profile might not be allotted the requested service level.
The IETF diffserv group is in the process of standardizing an effort that enables users to mark 6 bits of the ToS byte in the IP header with a DSCP. The lowest-order 2 bits are currently unused (CU). DSCP is an extension to 3 bits used by IP precedence. Like IP precedence, you can use DSCP to provide differential treatment to packets marked appropriately. We can specify PHBs in terms of their relative priority in access to resources, or in terms of their relative traffic performance characteristics. Two PHBs, EF and AF, are defined. EF is targeted at real-time applications, such as VoIP. AF provides different forwarding assurance levels for packets based on their DSCP field.

Both 3-bit IP precedence and 6-bit DSCP fields are used in exactly the same purpose in a diffserv network: for marking packets at the network edge and triggering specific packet queuing/discard behavior in the network. Further, the DSCP field definition is backward-compatible with the IP precedence values. Hence, DSCP field support doesn't require any change in the existing basic functionality and architecture. Soon, all IP QoS functions will support the DSCP field along with IP precedence.

So, how QoS can be applied in these model or architecture in details? Let’s focus on the analysis of TCP transport protocol to demonstrate different approach.

TCP Congestion Mechanism

TCP uses a mechanism called slow-start to increase the congestion window after a connection is initialized. It starts with a window of one to two times the MSS. Although the initial rate is low, it increases rapidly. For every packet acknowledged, the congestion window increases until the sending or receiving window is full. If an ACK is not received within the expected time, the TCP stack reduces its speed by reverting to slow start state, and the whole process starts all over again. Congestion avoidance is based on how a node reacts to duplicate ACKs. The behavior of Tahoe and Reno differ in how they detect and react to packet loss.

Tahoe detects loss when a timeout expires before an ACK is received or if three duplicate ACKs are received (four, if the first ACK has been counted). Tahoe then reduces the congestion window to 1 MSS and resets to the slow-start state. The server instantly starts retransmitting older unacknowledged packets, presuming they have also been lost.

Reno begins with the same behavior. However, if three duplicate ACKs are received
(four, if the first ACK has been counted), Reno halves the congestion window to the slow - start threshold (ssthresh) and performs a fast retransmission. The term “fast retransmission” is actually misleading; it’s more of a delayed retransmission so when the node has received a duplicate ACK, it does not immediately respond and retransmit; instead, it waits for more than three duplicate ACK before retransmitting the packet. The reason for this is to possibly save bandwidth and throughput in case the packet was reordered and not really dropped. Reno also enters a phase called Fast Recovery. If an ACK times out, slow - start is used, as with Tahoe.

TCP always try to get more, with the result that it will be taken to school by the network and be shaped due to jitter in arrival, reorder of segments, drops, or session RTT timeouts. The TCP throughput and congestion avoidance tools are tightly bound to each other when it comes to the performance of TCP sessions. With current operating systems, a single drop or reordering of a segment does not cause too much harm to the sessions. The rate and size of both the receiver window and the sender cwnd are maintained very effectively and can be rapidly adjusted in response to duplicate ACKs.

Several features and tools are designed to handle pacing of TCP sessions, for example, RED, token bucket policing, and leaky bucket shaping. Some of these tools are TCP-friendly, while others are link and service-based. These tools can be used to configure whether a certain burst is allowed, thereby allowing the packet rate peak to exceed a certain bandwidth threshold to maintain predictable rates and stability, or whether the burst should be strictly controlled to stop possible issues associated with misconfigured or misbehaving sources as close to the source as possible. These tools can also be used to configure whether buffers are large, to allow as much of burst as possible to avoid retransmissions and keep up the rate, or small, to avoid delay, jitter and the build-up of massive windows, which result in massive amounts of retransmissions and reordering later on.

The random early detection (RED) algorithms are designed to avoid congestion in internetworks before it becomes a problem. RED works by monitoring traffic load at points in the network and stochastically discarding packets if the congestion begins to increase. The result of the drop is that the source detects the dropped traffic and slows its transmission. RED is primarily designed to work with TCP in IP internetwork environments.

The precedence levels can be defined with token bucket control mechanism. Token bucket is a control mechanism that dictates when traffic can be transmitted based on the precedence of tokens in bucket. This provides means to control bursts. Tokens are specified in number of bytes. Thresholds can be set for the bursts of traffic. In case of a burst the token bucket mechanism slows down the traffic. In token bucket mechanism the incoming IP packets are queued for processing per flow basis. In the queue it is checked that their allowed amount / time is not exceeded. If not, then the packets are sent, if exceeded the behavior is not yet standardized. The common possibilities are best effort, discard or marking the packet so that it can be discarded in the future.