With the introduction of the Quality of Service (QoS), the Internet can provide other classes of services that the best effort service. In the same way, the multipoint transmission is introduced to share sessions between the distant members of the same group. Consequently, the objective of QoS is to support services of communication having specific qualitative requirements.
The protocol Received driven Layered multicast (RLM) is the first protocol
of control of congestion for the multi-media transmission (Aiguo
and Gerla, 2000). Moreover, differentiated services (DiffServ) (Blake
et al., 1998) is a model of multiples services which can fulfil the
requirements of QoS.
The aim of this research is summarized with the study of the association of multicast multi-layer transmission, ensured by RLM, with differentiated services. How to make the cohabitation of these two architectures?
THE DIFFERENTIATED SERVICES MODEL (DIFFSERV)
The differentiated services are IP-QoS architecture, based on the marking of the packages, using information of priority: differentiated services code point (DSCP). During the congestion period, the packages of weak priority will be eliminated before the packages of high priority. Consequently, the DiffServ model processed the traffic in the form of classes of QoS. The DiffServ routers are Per-Hop Behavior (PHB) according to the DSCP value. Three PHB are defined: Best effort, Expedited Forwarding (EF) and Assured Forwarding (AF).
Expedited Forwarding (EF) (Davie et al., 2002)
represent the Premium service (Nichols et al., 1999),
intended for the applications asking a very weak time and jitter.
The AF specification (Heinanen et al., 1999)
defines 4 classes and 3 levels of priority for each class. Each class can be
seen as a separate queue. This allows the resource sharing between flows, by
holding a class AF for each traffic. So flows will be isolated by scheduling
algorithm. Many methods to assign one of the three priorities were proposed.
Most common is the three colors marker.
The Three Colors Marker (TCM) uses two token buckets. The first is used to
check the conformity of flow with CR (Committed Rate) and the second to test
conformity with PR (Peak Rate). If a package is not in conformity with the second
token bucket it is marked in red (high priority of rejection). If it is in conformity
with the second but not with the first, the second level of priority will be
assigned: yellow. When the package is in conformity with the two token buckets
it is marked in green (Heinanen and Guerin, 1994). By
handling the TCM parameters, it is possible to control the flow for each of
the three colors.
The RLM (Receiver-driven Layered multicast) is a protocol with cumulative layers,
no independent, oriented receivers (McCanne and Vetterli,
1996). The source created a flow in layers, which each one of them bring
a refinement compared to the preceding ones. Each one of these layers will be
associated with a group multicast. The receiver will determine the quality which
it can receive while subscribing gradually with these layers. This approach
is extensible and solves the problem of implosion of feedback.
The principle is encoder, to cut out and transmit a multi-media flow in K cumulative
layers (C1, C2, Ck-1, Ck (McCanne and Vetterli, 1996).
To reach the adaptation, a receiver RLM must determine if its current level of subscription is too high or low. By definition, the level is too high if it causes congestion, the latter is easily detectable by the loss of packages or the deterioration of the quality.
Moreover, when the level of subscription is too low, receiver RLM must add the layers spontaneously, at moments that he considers favorable, until he causes congestion. There it hastens to destroy the last added layer.
The spontaneous subscription for the next layer in the hierarchy is called join-experiment.
However, these attempts can cause a transitory congestion which can deteriorate the quality of the delivered signal. To avoid that, RLM should be seek to minimize the frequency and the duration of the join-experiments without having impact neither on the convergence of the protocol towards the good flow, nor on the capacity of algorithm to react to the changes of the state of the network. For that, each receiver has on each level of subscription a join-timer which it multiplies by a factor α (higher than 1) when the level of subscription becomes problematic.
We define the detection-time by the necessary duration to the network to react to the attempt at adhesion and so that the receiver is advised. If the attempt lasts longer than the time of detection, without getting congestion, then the receiver deduces that the attempt at adhesion succeeded. If not the attempt would failed and the join-timer for this layer will be increased.
DIFFSERV AND MULTICAST
DiffServ is orientated source architecture, while multicast is orientated destination.
The routing of multicast traffics, in DiffServ domain, encountered difficulties.
The NRS problem (Neglected Reserved Subtree) (Bless and Wehrle,
2003) results from the replication of multicast packages, which generates
new traffics in the DiffServ domain, from where the increase in the consumption
of the resources. Since, DiffServ makes a control of traffic on the level of
the edge routers and that these traffics are treated by aggregations, other
traffics can then suffer from elimination.
The suggested solution is presented in the form of an orientated destination
architecture (Aiguo and Gerla, 2000) which it consists
to separate the control plan from the traffic plan, in addition to use of the
Bandwidth Broker entity (BB) to make control. The BB was proposed like unit
of management of DiffServ domain (Zhang et al., 2000,
2001), which is a responsible agent to hold the resources
required by the users and to configure the routers. It lays down also policies
based on the SLS (Service Level Specification). In this architecture, the BB
treats the multicast control messages (join/leave) and it maintains control
Description of simulation: We simulate the behavior of the flow under NS2, in the case of a heterogeneous network with and without DiffServ. Two sources (S1 and S2) are in competition on a central link.
The capacities of the nodes were selected in such way that the losses occur only on the central link.
Emitted packages TCP are of 1 Kb. A RLM source, respectively emits seven layers with a flow of 128, 256, 512, 1024, 2048, 4096, 8192 Kb sec-1 for each layer.
The RLM constants (McCanne and Vetterli, 1996) have
the following values:
For the differentiated services the PHB used is AF, marking is carried out
independently for each source and destination by using TCM marker.
Equity intra protocol: The sources S1, S2 emit CBR flows on UDP with RLM.
The destination dest1 (RLM Receiver) joined RLM sessions of the S1 source.
The destination dest2 (RLM Receiver) joined RLM sessions of the S2 source (Fig. 1).
Behavior of RLM receivers in a network without DiffServ: The RLM receiver (dest1) tried to be subscribed with failure to layer 5 to approximately 59 sec, it has succeeds in stabilizing ourselves with this layer in its second attempt with approximately 82 sec; It makes three attempts to be subscribed to the 6th layer between 166 and 190 sec without success.
The RLM receiver (dest2) was stabilized only with the 3rd layer since 52 sec, with 4 attempts at subscription for the 4th layer between 62 and 127 sec without success.
Moreover, the first abandonment of the 5th layer by the receiver (dest1) is
due to the attempt at subscription of the other receiver for the 4th layer,
which caused the congestion of the bottleneck, therefore the abandonment of
the layers in the course of experimentation.
|| Topology of simulation
The receiver (dest1) is been useful better, where as it is identical to the
receiver (dest2) (Fig. 2).
Behavior of RLM receivers in a network with DiffServ: Packages RLM are marked same class AF with same initial precedence for the TCM. Figure 3 shows the results of simulation for two receivers RLM (dest1 and dest2).
The receiver (dest1) is subscribed to the 4th layer at the moment 42 sec with 5 attempts at subscription without success for the 5th layer.
The RLM receiver (dest2) is also stabilized with the 4th layer since 46 sec, with 4 attempts at subscription for the 5th layer.
||Levels of subscriptions of receivers RLM without DiffServ
||Levels of subscriptions of RLM receivers with DiffServ
Two RLM receivers are stabilized with the same layer with recorded moments
before for the subscriptions; they are almost equitably been useful.
Synthesis: These two simulations, we conclude that, in a network without DiffServ, equity intra protocol for RLM is not assured. DiffServ ensures equity between RLM sessions, in fact that it guaranteed the same treatment for standard flows in the same way.
Equity inter protocol: The S1 source emits CBR flows on UDP with RLM.
The S2 source emits ftp flow on TCP towards dest2.
The receiver dest2 (RLM Receiver) joined RLM sessions of the S1 source.
Behavior RLM/TCP in a network without DiffServ: Figures
4a and b show the results of simulation for RLM receiver
(dets1) and TCP receiver (dest2), respectively.
Thr RLM Receiver (Fig. 4a) is subscribed to the 5th layer
at the moment of 62 sec with four attempts without success of subscription for
layer 6 between 72 sec and 114 sec; it is stabilized with the 5th layer.
||RLM/TCP without DiffServ. (a) Subscription of the RLM and
(b) Behavior of the TCP
The rate of flow TCP (Fig. 4b) receipt reaches 22.210 packages with a retransmission of the lost packages (negligible) which are due to the attempts at subscription of receiver RLM for the 6th layer.
Behavior RLM/TCP in a network with DiffServ: Four scenarios of PHB attribution
||RLM and TCP flows assigned to two different classes AF
||RLM and TCP flows assigned to same class AF and marked same initial precedence
||RLM and TCP flows assigned to same class AF and flow TCP are marked initially
in the third precedence which corresponds to the file red of the TCM, therefore
RLM flows pertaining to the first and the second precedence (priority)
||RLM and TCP flows are assigned to same class AF and RLM flows are marked
initially in the third precedence which corresponds to the file red of the
TCM, therefore TCP flow belong to the first and the second precedence (priority)
We summarize results (level of subscription, moment of subscription and Received
TCP packages) of four scenarios as follows (Table 1).
We compare the results of four scenarios with and without DiffServ. We notice that there is a difference in the time of subscription for the layer of stabilization and received TCP packages.
We summarize the difference of the results of the scenarios with DiffServ with regard to the scenarios without DiffServ as follows (Table 2).
|| Four scenarios of behavior RLM/TCP with DiffServ
|| Compared results with and without Diffserv
The RLM Layers are considered as independent. As we marked them for the same class AF and even initial precedence for the TCM, DiffServ ensures the same quality of service for these flows. Thus the layers of high levels are likely not to satisfy the criteria of the Green precedence over the TCM, which makes them more exposed to the losses. On the contrary, in the behavior without DiffServ the losses are random for all the layers. The results of simulations affirm that the differentiated services (DiffServ) ensures equity between RLM sessions, from where equity intra-protocols.
For equity inter-protocols, the assignment of a class to each type of RLM flow and TCP represents a solution because the pathological behavior related to RLM in the Internet is due to the conflict between RLM and TCP control congestion mechanisms. The problem is that TCP congestions are considered as RLM congestion by RLM receivers, which causes abound them of the subscriptions for the layers in course of experimentation, even if they are not the cause of this congestion. Therefore, one classes for each type of flow it possible to solve this conflict, because each class is treated independently. The solution with two classes AF is interesting.
However, the use of only one class AF for RLM and TCP do not enable us to combine the optimization of two flows, it is thus necessary to choose the model of priority according to negotiated quality of service.
By separation of the control aspect from the traffic aspect, the cohabitation of DiffServ architecture with multicast architecture is possible. It is a promising solution to ensure negotiated QoS.