0 Replies Latest reply: Oct 16, 2017 12:09 AM by Juan RSS

    QoS architecture models: IntServ vs DiffServ


      There are three main models for providing QoS services in a network:


      • Best Effort.
      • Integrated Services (IntServ).
      • Differentiated Services (DiffServ). 


      The three models are differentiated by how each one enables applications to send data and the way the network handles data delivery within a specified level of service.

      Best Effort

      The Best Effort (BE) QoS model is the simplest of the three. It is the default QoS model used for Internet and it doesn’t implement any QoS mechanism at all, that is the reason why there isn’t any complexity associated to this QoS model.

      BE does not allow for resource reservation or any other mechanism related to asking for some kind of special treatment to the network. For this reason, BE model does not work very well will any emerging application with real-time (RT) traffic demands.

      This model should not be used when the network resources are not enough to fulfill the QoS application requirements in terms of the main indicators as bandwidth, delay, jitter, etc. In these cases, with applications competing for resources, the quality of the end-user experience could be very poor if there is no other mechanism in place to manage the unfairness.

      Integrated Services

      The Integrated Services (IntServ) model is also known as hard QoS model. It’s a model based on flows, i.e., source and destination IP addresses and ports.

      With the IntServ model, applications ask to the network for an explicit resource reservation per flow. Network devices keep track of all the flows traversing the nodes checking if new packets belong to an existing flow and if there are enough network resources available to accept the packet.

      By reserving resources on the network for each flow, applications obtain resources guarantees and a predictable behaviour of the network.

      IntServ model performs deterministic Admission Control (AC) based on resources requests vs. available resources.

      The implementation of this model requires the presence of IntServ capable routers in the network and uses RSVP for end-to-end resource reservation. RSVP enables a host to establish a connection over connectionless IP Internet:

      1. Applications request some level of service to the network before sending data.
      2. The network admits or rejects the reservation (per flow) based on available resources.
      3. Once cleared, the network expects the application to remain within the requested traffic profile.

      The scalability of this model is limited by the fact that exists a high resource consumption on network nodes caused by per flow processing and associated state. Remember that network nodes need to maintain the reservation state for each flow traversing the node.

      The fact that RSVP is a soft state protocol with continuous signaling load only aggravates the scalability problem.

      IntServ advantages


      • Good solution for managing flows in small networks.
      • Intserv enables hosts to request per-flow, quantifiable resources, along end-to-end data paths and to obtain feedback regarding admissibility of these requests.


      IntServ disadvantages


      • Poor scalability.
      • High resource consumption on the network nodes.
        • Per flow processing (CPU): signaling & processing load.
        • Per flow state (memory): to keep track of every flow traversing the node.
        • Continuous signaling (RSVP is a soft state protocol).
      • It’s very difficult to implement.


      Differentiated Services

      Differentiated Services (Diffserv) model is also known as a soft QoS model. It’s a model based in service classes and per hop behaviours associated to each class.

      In this case, there is no need for an explicit request for resource reservation by applications to the network. Differentiated Services is based on statistical preferences per traffic class.

      DiffServ allows end devices or hosts to classify packets into different treatment categories or Traffic Classes (TC), each of which will receive a different Per-Hop-Behaviour (PHB) at each hop from the source to the destination. Each network device on the path treats packets according to the locally defined PHB.

      PHB defines how a node deals with a TC. Network service policies can be specific to an entire QoS domain, some part of a network or even a single node.

      Priorities are marked in each packet using DSCP for traffic classification. This marking is performed per packet usually at the QoS domain boundary. The marking can be done at several levels of the networking layers (MPLS EXP, CoS).
      DiffServ model implements a statistic, class-based, AC.

      DiffServ advantages


      • Highly scalable QoS mechanism.
      • Does not require any resource reservation mechanism on end hosts.
      • Easy configuration, operation and maintenance.
      • Support complex traffic classification and conditioning at the edge.
      • Can aggregate multiple app flows into a limited number of TCs.
      • Reduced overhead associated to the maintenance of policies on a per flow basis.
      • Diffserv nodes can process traffic more easily than Intserv devices.
      • Diffserv is a distributed QoS service model. Resource allocation is distributed among all the routers of a Diffserv domain, allowing for a greater flexibility and efficiency in the routing process.

      DiffServ disadvantages


      • Coordination between domains in the QoS end-to-end service.
      • SPs QoS customization may affect the guaranteed QoS end-to-end service.



      The next table summarizes some of the main design differences among the three QoS models.


      QoS Service

      Best Effort




      No isolation

      Per flow isolation

      Per aggregation isolation


      No guarantee

      Per flow

      Per aggregation (Traffic Class)

      Service Scope



      Per domain


      No setup

      Per flow setup

      Long term setup


      Highly scalable

      Not scalable (each router maintains per flow state)

      Scalable (edge routers maintain per aggregate state; core routers per class state)

      Suitable for Real Time traffic


      Yes, resource reservation.

      Yes, LLQ.

      Admission Control


      Deterministic based on flows.

      Statistic based on Traffic Classes.


      Internet Default

      Small networks and flow aggregation scenarios.

      Networks of any size.

      Resource Reservation

      Not available

      Per flow on each node in the source-destination path.

      Per Traffic Class on every node in the domain.






      As it was introduced previously, IntServ model is focused on sharing the available network resources among the Flows requiring resources to the network. On the other side, DiffServ is focused in a less granular approach by sharing network resources among a set of previously defined Traffic Classes. The number of Traffic Classes that the network support is not a fixed value and it’s part of the design work to plan and implement as many classes as needed to fulfill the business application needs.


      The two QoS models are not mutually exclusive, on the other side, they are complementary and in some situations can be used at once on a given network: IntServ over DiffServ.


      Diffserv enables scalability across large networks. As DiffServ model is much more scalable than IntServ, it works much better in big network deployments. IntServ works well on small domains, where the number of flows and the size of the network is controlled.


      The reason about the improvement in scalability is given by the fact that Diffserv nodes can process traffic more easily than IntServ devices. With the IntServ model every routing device in the end-to-end path need to negotiate RSVP reservations (all intermediary routers) and there is a relevant state overhead associated to the RSVP reservations.


      On the other side, with the DiffServ model, the PHB sets how the packet is treated and different nodes on the network can provide the ‘same’ service without having to maintain any additional state for each flow traversing the network.

      I hope you find it useful.