section 4, and 5, we analyze the EF jitter in a DiffServ network serves aggregates through a single and multiple class service discipline. In section 6, we interpret.
Expedited Forwarding End To End Delay Jitter In The Differentiated Services Networks Hamada Alshaer1 and Eric Horlait1 Lip6,UPMC, 8 rue Capitaine Scott, 75015 Paris, France {hamada.alshaer,eric.horlait}@lip6.fr http://www-rp.lip6.fr
Abstract. An end to end (e2e) packet delay jitter has a negative impact on the offered QoS in IP networks. Therefore, in this paper we clarify this passive impact, and discuss the delay jitter that is based on the analysis done in [1]. However, here we focus on the expedited forwarding (EF) class in the differentiated services network (DiffServ). EF flows are represented by renewal periodic ON-OFF flows, and the background (BG) flows by Poisson process. We analyze the jitter effects of these BG flows on EF flows patterns when they are serviced by a single class scheduling discipline, such as FIFO, and a multicalss scheduling discipline, such as static priority service discipline (SPS). Thus, we have simulated a DiffServ network, where different users were provided with different service classes. Consequently, along the simulations different scenarios were formed to see the impact of BG flows and their characteristics on EF flows. As a result, we have found out from these simulations that the EF Per-Hop Behaviors (PHBs) configuration according to RFC 2598 can’t stand alone in guaranteeing the EF flows delay jitter. Therefore, playout buffers must be added to the DiffServ network for handling the EF delay jitter problem.
Keywords :DiffServ,expedited forwarding, e2e jitter,playout buffers.
1
Introduction
Nowadays the networks with guaranteed quality of service (QoS) are greatly paid attention. These networks will offer alternatives to the existent ones, which offer a single service class called best effort. An example of such networks is the Internet network, where the end-users have no guarantee on the quality of their required services. Therefore, service models such as asynchronous transfer mode (ATM), integrated service (IntServ), and DiffServ have been developed to support new service classes with varying traffic characteristics and QoS requirements. Recently, the efforts in the world have been intensified on redefining, and improving the design of the DiffServ, so that it supports better the QoS of the supported service classes. Hence, the new demand of QoS ( i.e, stringent delay, delay variations, and loss) required for real time applications, such as video
streaming, audio, and IP telephony are abstracted in the real time service classes offered by these service models. Furthermore, new management algorithms have been embedded in the control mechanisms in these service models, to manage efficiently the dramatic increase in the network capacity. In spite of these control mechanisms, still at a given time instant, the cumulative peak rates of the connections supported in the previous service models exceed the network capacity, where serious congestions may occur, resulting in QoS degradation. Even though, network congestion can be controlled by source traffic shaping or regulating in order to reduce the traffic burstiness, the series of traffic connections multiplexing in the network core recreate once again the traffic burstiness causing traffic distortion. In DiffServ network as shown in Figure 1; EF flows are statistically multiplexed with the BE flows. Thereby, packets belong to the EF flows experience different individual delays at the servers along their paths toward their destinations, which cause distortion in the timing sequence of the real time applications flows serviced as EF flows, arising from their packets delay variations. This can be measured at each node traversed by EF flow through computing the difference between the inter departure and inter arrival times of two consecutive packets belong to the EF flow. ηi = |(di − di−1 ) − (ai − ai−1 )|
(1)
Also, packets delay variations can be measured by another parameter, rate jitter, which is the rate of difference between the minimum inter arrival and maximum inter arrival times. This parameter is very convenient for measuring video broadcast over the DiffServ domain, since a slight deviation of rate is translated to only a small paly out delay[6]. (ai − ai−1 )max − (aj − aj−1 )min (2) δi = lim t−>∞ t Thus, playout buffers at the end users are needed to reorganize the time sequence of the interactive applications flows. These de-jitter buffers have been considered the main solution for compensating the packets delay variations in their flows. However, their design still causes a major challenge in dealing with the delay jitter. This challenge has been represented in two points: the first point is the playout buffer mechanism choice, so that if it is a static playout buffer, then the playout instants are chosen according to the first packet arrival in its flow, however if it is adaptive playout buffer, then the playout instants change according to the packets arrivals instants. The second point in the challenge is the playout buffer depth; for example if it is small, then this increases the packets loss probability. However, if it is long, then this adds a significant delay to the flows delay budget, which is not tolerated by the real time flows. Therefore, an optimal choice for the playout buffer’s depth, and play out buffer mechanism are required. Nevertheless, the choice is an application dependent [5, 2–4]. The rest of this paper is organized as follows: In section 2, we discuss some of the most important works that have been done around the EF jitter, and we
DiffServ domain Egress router
EF flow t0+t
t1
t2
t3
t4 …... tn
t0+t
t1 t2 t3 t4 ….. tn
HP Play out Buffer
X
Ingress route r LP
BE flow ftp Ft0
Ft1
Ft2 …………. Ftn
t0 +t+x+f (e)
t1 t2 t3 t4 …... tn
EF Destination
BE Destination
Fig. 1: Delay jitter in Differentiated Services Network
clarify the problem to be treated in this paper. In section 3, and 3.1 we describe the simulation environment, different traffic classes, and its characteristics. In section 4, and 5, we analyze the EF jitter in a DiffServ network serves aggregates through a single and multiple class service discipline. In section 6, we interpret the delay jitter results of the different EF flows in the DiffServ network shown in Figure 2, and finally, section 7 will include a conclusion to this paper.
2
Related Work & Problem Statement
A relationship between a customer and an IP telephony Operator works on the DiffServ network is controlled in two directions. In one direction the customer is committed to inject his traffic within specific traffic bounds, such as, peak rate and burst size. And, the network operator is designed to guarantee the signed QoS service in a contract; such as, delay, delay variation, and loss rate. Furthermore, the network operator supports different connections with different characteristics, where service overlapping can be occurred at any node in the network core causing jitter for the user flows as shown in Figure 1. Therefore, some regulators are installed at each node in the network core in order to hold a packet in a buffer until its eligibility time for transmission to the next node. In [6] Y.Mansour, and B.Patt-Shamir propose to install a bounded buffer size at each core node to regulate the input traffic to the node, and thus eliminating the jitter at its output. Furthermore, in [8] R.Landry, and I.Stavrakakis introduce a scheduling service discipline called peak output rate enforcement( PORE), which recognizes at the network core nodes the traffic profiles carried out at the edge routers, for each flow, or each traffic class. Then, according to these profiles, it guarantees the periodicity of the flows through keeping their packets at minimum space of time units at each output core node, which results in keeping the flows time sequences organized along their traversals toward their destinations. Nevertheless, packets inter arrivals and inter departures might be randomly changed due to the statistical multiplexing with other different flows. But, this random change can be characterized by a stochastic process, where certain statistical functions are derived to characterize the distribution of this randomness. This represents in turn the jitter distribution of the flows to which the packets belong. The jitter distribution function might be based on markov chain as it is introduced in [8], by forming a markov chain of the points representing the eligi-
bility times and service times of the tagged packets. Further statistical analysis around the jitter is done in [9], which derives the first order statistical function, that provides information about the jitter length of the different flows in a traffic aggregate, and packets that constitute these flows. Furthermore, it derives the second order statistical functions characterized with the autocorrelation function (ACF), Which provides information about the neighboring packets jitters in their periodic flows. DiffServ network is an example of multiple traffic classes’ networks. It supports three traffic classes: expedited forwarding(EF), assured forwarding “AF”, and best effort “BE”. The EF class is the key ingredient in the DiffServ for providing a low delay, jitter, and loss. According to RFC 2598 [13], EF is defined as a forwarding treatment for a DiffServ aggregate, where its aggregate’s departure rate from any DiffServ node must equal or exceed the configured rate of this node. However, the coexistence of multiple traffic classes in the network makes the different traffic flows to compete for the limited resources, which creates the randomness in the interarrivals and interdeparture of the packets belong to the EF traffic class. Therefore, EF flows suffer from delay jitter in the network. This problem is analyzed in [10] by Jean C.R.Bennett, and J.Yves Le Boudec through analyzing a method to reorganize the structure of the Diffserv network traffic flows, such that EF flows suffer from very limited minimum jitter. However, we see that this approach is hard to be realized. Because, the arrivals and departures of the different flows belonging to the different traffic classes at the different network nodes are random. Furthermore, their routes intersections are totally random. As well as, we see the rearrangement of the EF flows in a tree structure as it is introduced in [10] is nearly impossible. Therefore, we consider the EF delay jitter still needs more clarifications, and in this paper we analyze this problem based on the previous analysis done on the delay jitter in ATM networks [1]. Then, we analyze it through real simulations done on the DiffServ network shown in Figure 2.
3
Network Topology
In order to investigate the e2e delay variations of EF flows, and the effect of other classes properties on this class, a simulation environment of DiffServ network has been developed using NS-2 simulator [11]. The sources and destinations are connected through multiple paths, where a circular traffic can occur. For example, if we follow the arrows in Figure 2, we can notice that: the traffic flows generated from source 2,3 form quasi circular traffic. Furthermore, this network can support more users by connecting them through edges connected to core D,C shown in Figure 2. All the routers output links have the same capcity“C0 ”, except the links connect core router 54, core A - edge 7, and core edge router B-dge 6 have a capacity equivalent to 34 ∗ C0 . Since, they have been considered the network bottleneck, where the DiffServ network shows its real functionality, and at which we have analyzed the different queuing systems in order to choose the one that meets our study goal.
AF Source 2 EF Source 2 BE Dest 3 BE Source 2 Edge 7 Edge 5
AF Dest 3 EF Dest 3
EF source 1 AF source 1 BE source 1
Core A
Core C
Core F
Core2
Core3
Core 4
Core B
Core D
Core G
EF Dest1
Edge 1 Edge 2
Core 1
Core 5
Edge 3
Edge 6 EF Dest 2
AF Dest 1
BE Dest 1
Edge 8 BE Dest 2
AF Dest 2
Edge 4
BE Source 3
EF Source 3 AF Source 3
Fig. 2: Differentiated Services Topology
3.1
Network Traffic
Network traffic is divided into three classes {CEF , CAF , CBE }, where CEF , and CAF contains a determined number of flows {1, 2.., NEF }, and {1, 2.., NAF } respectively. However, the number of flows in class CBE is kept unknown, and they don’t receive a special treatment by the DiffServ nodes. Therefore, this type of traffic can be injected by any network user at any time. Nevertheless, we have kept it under control along the simulations, to see their effects on the EF flows. Along our analysis we focus on the EF class under the varying effects of BE characteristics, burstiness and peak rate on this class. The AF class hasn’t been paid attention to, but it is remained as a future point to guarantee its bandwidth requirement. Nine users divided into three groups according to their Edge routers have been allowed to inject these different traffic classes in the DiffServ domain as shown in Figure 2. A static priority scheduler serves these different classes at the routers output links. Therefore, each class has its own priority queue, and reserved bandwidth. A limited controlled number of tagged flows belong to EF class enter the network through the ingress router 1,5 and 8 as shown in figure 2, until they reach their EF destinations 1,2 and 3 respectively, as shown in the same figure. The tagged flows are those whose e2e delay variations have been monitored, and calculated from their sources until their destinations. The flows that belong to AF and EF class have the same characteristics, peak rate ρ, burst σ, and packet size. While, the flows belong to BE class has different characteristics, and we have changed these from worst case until the optimal case in order to see the impact of this class on e2e delay variations of EF flows.
4
Jitter In Single Class Service Discipline
Scheduling service disciplines(S.S.D) have been considered the main tool in reducing, and improving the delay variations of the traffic flows. Therefore, some S.S.D’s have been supplied with further equipments, such as clocks for stamping the different packets. Then, the packets stamps are used by next S.S.D’s along their paths to hold the delayed or earliest packets in their regulators to become
eligible for transmission. This keeps in turn the flows sequence time of the different flows, which eliminates the jitter of these flows. However, there is a big gap between what have been theoretically discussed about the scheduling service disciplines, and what is really implemented in the real networks. FIFO scheduling service discipline is mostly used in the actual networks. This service discipline is used due to its simplicity and availability. However, it causes distortion for a real time traffic class, whenever it supports this class with another one. This distortion is represented in the delay variations of packets belonging to the real traffic flows, which is explained deeply in [1]. However, in this paper we adopt the results of this important reference for analyzing the delay jitter in DiffServ network that support the EF traffic class and others through FIFO S.S.D. Therefore, if we replace the static priority S.S.D’s by FIFO S.S.D’s, and disable the AF traffic sources in the network shown in Figure 2, two traffic aggregates compete for the service on the link capacity at the nodes outputs: real time periodic traffic flows ( EF ), and background traffic “BG”(BE). Furthermore, EF packets are given a priority higher than BG packets. Thus, EF packets are served a head of BG packets that arrive at the same time. Therefore, the delay jitter of EF packets at mth node equals to the difference of BG backlog times measured at two EF consecutive packets instants, if we consider the fluid queuing system. However, in this paper, we consider the discrete queuing time model, where FIFO server serves a packet each time unit. consequently, EF delay jitter is the difference of backlogged BG packets numbers seen by two ), and their inter arrival time is EF consecutive packets (QnBGn+1 ,mth ,Qn+1 BGn ,mth In,n+1 th
m JEF = Qn+1 − QnBGn ,mth + In,n+1 BGn+1 ,mth
(3)
Henceforth, delay jitter analysis is coincided with the analysis of the variations of the queue size at the arrival instants of EF packets. From [1], The queue size in Z-domain can be expressed at the arrival instants of EF packets as follows : (1 − z −1 )(B(z)/z)k (1 − zGEF (B(z)/z) K [((z/B(z)) − (rk /(B(rk ))] πk=1 × K [1 − (r /B(r ))] πk=1 k k
Q(z) = G‘EF (1)(1 − ρtotal )
(4)
Where, G‘EF (1) = (∂GEF (z)/z)z=1 . k = Gmax − 2 , ρtotal = ρBG + ρEF is the total load at the server. The inter arrival time (I) of EF flows has finite supports; Gmin , and Gmax , where 1 ≤ Gmin , ≤ Gmax ≺ ∞. B(z) is the probability generating function (p.g.f) of the random variable corresponding to the BG batch size. And, GEF (z) is the (p.g.f) of the integer random variable I, which can be expressed as follows : GEF (z) =
G max i=Gmin
i
P r(I = i)z =
G max i=Gmin
gi z i
(5)
kth JEF (Z)
=
G max
gi Ji (z)
(6)
i=Gmin
where, Ji (z) = z(B(z))i + (B(z))i−1 (z − 1)
i−1
(B(z)/z)−k φ(z −1 ; k)
(7)
k=1
φ(z −1 ; k) =
k−1
z L πk (0; L)P r(Q = L)
∀1 ≤ k ≤ i − 1
(8)
L=0
where, πk (0; L) is the probability that the queue is empty at the K th time instant following the arrival of EF packet, after all the new arrivals at this time instant have been counted. It is immediate that πk (0; L) = 0 for 1 ≤ k ≤ min(L, Gmax − 1). Hence, πk (0; L) = P r(Q(k) + B = 0|Q(0) = L).
5
Jitter In Multicalss Service Discipline
Multiclass S.S.D’s are often employed in multicalss networks to isolate the different traffic classes from one to another, and manage the output link capacity among the backlogged traffic flows belonging to the different traffic classes according to their QoS requirements. However, the real time traffic flows are subjected at any node in a network to be delayed or their sequence times to be distorted due to other traffic classes’ characteristics. In the network shown in Figure 2 the static priority scheduling (SPS) has been chosen to manage the priorities, and to serve the different traffic classes in the DiffServ domain. We have changed the SPS parameters values such as the EF traffic flows will have absolute priority over the background ( BE )flows. Nevertheless, EF flows still suffer from the problem of delay jitter as we are going to see in the simulation section. This problem can be analyzed or interpreted in the following three scenarios: First, when the packets belong to EF class 1 in the DiffServ network shown in Figure 2 arrive to the server of core router 1, while it is busy in servicing a packet belongs to BE transmitted by BE source 1 or 2. Then, as long as this server doesn’t finish servicing the BE packet, other EF packets belong to other EF sources probably arrive, where two sources of delay variations can be underlined in this situation: one due to the BE packet that is being currently serviced by the server. Which, results in a worst delay jitter equivalent Lmax min . This jitter source forms the second scenario which , to max C0L−C C0 −CEF EF is similar to that we have explained in section 4. However, in this case the back ground for EF flows generated by EF source 1 are other EF packets generated by other EF sources 2,3 in the DiffServ shown in Figure 2. Nevertheless, we can apply the same analysis of the previous section, but we have to change to the followingtow equations respectively: the values of G max , Gmin according Lmax Lmin Lmax min Gmax = max C0L−C , = min , , and G . min C −C C −C C −C EF 0 EF 0 EF 0 EF
Third, when the EF packets transmitted by EF source 1 arrive to the server of core router 2 in Figure 2, where the probability of BG packets arrival rate is around zero. Then, the BG distribution can be characterized by the Taylor series around ρBE = 0. Hence, the EF queue size Q(z, ρBG ) at the EF packets arrival instants can be characterized through the expression clarified in the theorem 1, [1, 12]: Theorem 1 (Light Back Ground Traffic). Given B(z, ρ) = 1 + ρ(a(z) − A max ai z i ,then if Amax ≺ Gmin ⇒ Q(z, ρ) = 1 + 1) + O(ρ)2 ,and a(z) = i=0 + O(ρ2 ) ρ (a(z)−z) z−1 Where, Amax is the upper bound on the minimum spacing of arriving EF packets. Which, is determined by the characteristics of the BG traffic. Then, the EF flows jitter can be characterized through the expression clarified in the theorem 2, [12]: Theorem 2 (EF Flows Jitter). If Amax ≺ Gmin ⇒ J(z) = G(z) 1 + ρ2 (f1 (z) − 1) + O(ρ2 ).where, f1 (z) = a(z)−1 z−1 In our simulations, we have used FTP application, whose Poisson distribution as a back ground traffic. Z-transform of Poisson distributed batches can be described as follows: (9) B(z) = eρ(z−1) Then, by using taylor series we can expand this as follows : B(z) = 1 + ρ(z − 1) + ρ2
(z − 1)2 + O(ρ3 ) 2
(10)
Then from theorem 1, and background taylor expansion 10, we get a(z) = z, then from theorem 2, f(z) = 1, thus JEF (z) = G(z) + O(ρ2 ) if Gmin 1
(11)
where, we see no effect for the first order term appeared in expression 10. So fare, we have focused on a single node analysis. Nevertheless, the previous results form the base in the analysis of jitter in a multiple nodes. Since, if we approximate the departure process of the EF traffic flows from any node in the DiffServ domain shown in Figure2 as a renewal process, the marginal distribution of the departure process of EF flows from node k is approximated by a renewal process with the interarrival time distribution identical to Jk (i). Denote the sequence Gk+1 (i) as the probability of inter arrival time of EF flows entering node k + 1 to be i time service units. Gk+1 (i) = Jk (i)
1≤k ≤N −1
(12)
1≤k ≤N −1
(13)
and in the Z-domaine, we have Gk+1 (z) = Jk (z)
Consequently, once the EF arrival process at the first node of the network is periodic, then we simply have G1 (z) = Z T . Therefore, if we track the EF flows’ jitter from their sources to destinations, then their exact marginal jitter distribution can be obtained.
6
Simulation And Results
In this section, some simulations are provided on the e2e delay jitter of the different EF flows generated by the different EF sources in the network shown in Figure 2. The EF traffic sources are periodic ON-OFF. The Background traffic generated by the different BE traffic sources are identical. Furthermore, they are characterized by the same statistical distribution described in the expression 9. The BE ( BG ) , AF, and EF sources are controlled at their traffic generation starting times in order to form different scenarios, where different traffic flows generated from the different sources arrive at the same time at the network core nodes. Afterward, we focused on analyzing the EF flows jitters due to other traffic flows’ existence through measuring their delay jitter using the expression 1. Among the different scenarios that have been realized, we focus on only four scenarios due to space limitation. In the first scenario, all the traffic sources, AF,BE and EF are allowed to generate traffic at the same time. In the second scenario, we disabled the AF source, and allowed the BE and EF to generate traffic at the same time. In the third scenario, we changed the burstiness of the BE flows, and we allowed only the BE and EF sources to generate traffic in the network, while keeping the AF sources disabled. In the fourth scenario, we disabled the AF and BE sources, and allowed only the EF sources to generate traffic. The behaviors of the different EF flows e2e delay jitters along the previous Four scenarios are described in the Figures shown in 3, 4, 5, 6,and 7. From Figure 3, we see that the EF flows from source 1 keep their jitter bounds within small limits, however when they arrived at core router 1, a spike is formed, which represents the delay jitter of these EF flows, due to other traffic coming from source 2, and 3. Afterward, their delay jitter increases as they traverse more nodes, but with decreasing probability, since the background traffic load rate is decreasing. Furthermore, we see that when we increase the BG burstiness in the third scenario, the probability of EF delay jitter is increased. From Figure 4, we see that EF flows from source 1 suffer from a very small jitter at the core router 1 when they meet other EF flows coming from source 2, 3, however, after their delay jitter almost approach zero in the network core. From the figures shown in 5, and 6 we see that the behaviors of EF flows of source 2, and 3 along the three scenarios are almost similar. However, if we look carefully in these two figures, we find out that the probabilities of delay jitter of EF flows of source 3 are greater than those of source 2. This can be referred to that the EF source 2 started to generate traffic before the EF source 3. Therefore, the EF flows from source 2 are mostly served before the ones generated from source 3 at core B, core 1, and core A , where both of these EF flows, and other
1
0
10
Scenario 4
Scenario 3 Scenario 1 Scenario 2
0.9
0.8
−1
10
P( EF e2e jitter = K ms )
P(EF e2e jitter = K ms)
0.7
−2
10
−3
10
0.6
0.5
0.4
0.3
−4
0.2
10
0.1 −5
10
0
0.2
0.4
0.6
0.8
1
1.2
0
1.4
0
1
2
3
4
5
6
7
8 −3
x 10
EF e2e jitter (ms)
EF e2e jitter (ms)
Fig. 3: EF e2e jitter distribution of the EF flows generated by EF source 1
Fig. 4: EF e2e jitter distribution of the EF flows generated by EF source 1
0
0
10
10
Scenario 1 Scenario 3 Scenario 2
Scenario 1 Scenario 3 Scenario 2
−1
−1
10
P(EF e2e jitter = k ms)
P( e2e jitter = K ms )
10
−2
10
−3
10
−4
−3
10
−4
10
10
−5
10
−2
10
−5
0
5
10
15
20
25
30
35
EF e2e jitter ( ms )
Fig. 5: EF e2e jitter distribution of the EF flows generated by EF source 2
10
0
5
10
15
20
25
30
35
EF e2e jitter (ms)
Fig. 6: EF e2e jitter distribution of the EF flows generated by EF source 3
Scenario 4 0.7
Source 2 −Destination 2 Source 3 − Destination 3 0.6
P( EF e2e jitter = k ms)
0.5
0.4
0.3
0.2
0.1
0
0
1
2
3
4
5
6
7 −3
EF e2e jitter ( ms )
x 10
Fig. 7: EF e2e jitter distribution of the EF flows generated by EF source 2 and 3
BE flows compete for the service at these servers. However, the spikes in these two figures, which represent the delay jitter of the EF flows are formed due to their meeting at the links that connect core B and core 1, and core 1 and core A. After that the probability of delay jitter decreases rapidly until they arrive around the probability of delay jitter steady state, then their delay jitter stays within certain jitter bounds. However, From figure shown in 7, the delay jitter of EF flows of sources 2,3 approach almost zero, because the back ground load rate is decreased to arrive around zero. Nevertheless, a number of spikes are formed, because both of EF flows of source 2, and 3 compete for the common resources along their path.
7
Conclusion
In this paper, we analyzed the EF e2e delay jitter in the DiffServ network shown in Figure 2. This network was designed according to the DiffServ norms defined in ns-2, and further the EF aggregate departure rate was configured according to RFC 2598[13]. Therefore, we thought that the EF flows would not suffer from any delay jitter, since through this configuration they will be isolated from other traffic classes. However, we found out from the simulations carried out on the network that they are not isolated, and they are affected by other traffic class characteristics as we have seen in the different shown Figures, the effect of BE on the e2e delay jitter of EF flows. Furthermore, the different Figures in section 5 show us clearly that the EF flows are affected by the existence of other traffic classes through their traversals to their destinations. Therefore, the DiffServ norms in ns-2, and RFC 2598 configuration can’t stand alone in guaranteeing the QoS demanded by real time traffic offered the EF service class. Thus, playout buffers as shown in Figure 1 must be added to the DiffServ network for compensation the delay jitter of EF flows. Furthermore, we found out that delay jitter of EF flows depend on the back ground traffic intensity in the
network. In this, we have seen in Figures 3, 5, 6, that when the different traffic flows meet at the core router 1 some spikes are formed in the three scenarios. Therefore, the background traffic intensity must be controlled to guarantee the EF delay jitter. Consequently, there are two points that require further studies: – From the different simulations results we see that the DiffServ network requires de-jitter buffers to improve the QoS offered through Expedited service class to the real time applications. – Adding a control mechanism that controls the best effort ( BG ) traffic intensity in the DiffServ network to guarantee the QoS offered to EF flows .
References 1. Matragi,W.,Bisdikian,C.,Sohraby,K.: Jitter Calculus in ATM networks: Single Node Case. INFOCOM. 1994. 2. Sreenan,C.,Chen,J.,Agrawa,P.,Narendran,B.: Delay reduction techniques for playout buffering. IEEE Trans. Multimedia 2(2). (2000)88-100. 3. Ramjee,R.,Kurose,J.,Towsley,D.,Schulzrinne,H.: Adaptive delay mechanisms for packetized audio applications in wide-area networks. Proc. of the IEEE infocom. Toronto, Canada. June 1994,pp.680-688. 4. Jacobson,V.: Congestion avoidance and control. Proc. ACM SIGGCOMM, August. 1998,pp.314-329. 5. Fujimoto,K.,Ata,S.,Murata,M.. Adaptive Playout Buffer Algorithm for Enhancing Perceived Quality of Streaming Applications. To appear in Telecommunication Systems. January 2004. 6. Mansour,Y.,Shamir,B.P.: Jitter Control in QoS Networks. IEEE/ACM Trans. on Networking. 9(4):492-502, 2000. 7. Belenki,S.: An Enforced Inter-Admission Delay Performance- Driven connection Admission Control Algorithm. ACM SIGCOM,Computer communication review. Vol.32, No.2, April 2002. 8. Landry,R.,Stavrakakis,I.: Study delay Jitter with and without peak rate enforcement. IEEE/ACM Trans. on Networking. Vol.5, No.4, August 1997. 9. Fulton,C.A.,Li,S.Q.: Delay Jitter First Order and Second Order Statistical Functions of General Traffic on High Speed Multimedia Networks. IEEE/ACM Trans. on Networking. Vol.6, No.2, April 1998. 10. Bennett,J.C.R.,Benson,K.,Charny,A.,Courtney,W.F,Le Boudec,J.Y.: Delay Jitter Bounds and Packet Scale Rate Guarnatee for Expedited Forwarding. IEEE/ACM Trans. on Networking. Vol.10, No.4,Auguust 2002. 11. Altman,E,Jim´enez,T.: NS simulator for beginners. In Lecture notes. Automn 2002. 12. Matragi,W,Bisdikian,C,Sohraby,K.: Light Traffic Analysis of jitter in ATM multiplexers. IBM Research Report, RC 19413, 1993. 13. Jacaobson, V., Nicohols, K.,Poduri,K.: Expedited Forwarding PHB. IETF RFC 2598. June 1999.
