1. Introduction

  • What’s QoS ?

    (1) User perspective : Assurance of end-to-end service, e.g., Guaranteed delay (VoIP), Guaranteed bandwidth (VPN).

    • Relaxed definition:
      • Service differentiation: different packets is treated differently.
      • End-to-end service guarantees may be achieved by provisioning. E.g. only a small portion of high priority packets.

    (2) Networking perspective : In the field of computer networking and other packet-switched telecommunication networks, quality of service refers to traffic prioritization and resource reservation control mechanisms rather than the achieved service quality. Quality of service is the ability to provide different priority to different applications, users, or data flows, or to guarantee a certain level of performance to a data flow.

    (3) Per flow QoS guarantees vs. aggregate QoS guarantees.

    (4) Statistical QoS guarantees vs. deterministic QoS guarantees.

  • Why do we need QoS?

    (1) Do we really need QoS?

    • Alternative: buy excessive bandwidth. Everything is simple in the Internet without QoS (?), everything seems to be much harder in the Internet with QoS support (!).
    • What is the main problem?
      • Complexity and scalability of QoS mechanisms
      • Which is cheaper: higher network speed or network with QoS support.
    • Where is the balance?
      • A guess: Some form of QoS support will be there, per flow QoS guarantee may or may not ever be deployed.

    (2) Why do we need QoS?

    • To match network service to application requirements?
      • Resolve conflicts when network is overloaded, e.g.,
        • Interactive services want minimum delay
        • File transfer & email want maximum throughput
        • Web users want both (!?)
    • Or to make some users more unequal than others?
      • Goverment / Military want higher priority.
      • ISPs want to sell premium service to corporations and government agencies that can afford it.
      • Free-market approach – “QoS Knob”. “-Download too slow? Increase your cost per minute.
  • Applications

    (1) VoIP, Online games, Industrial control systems: bounded delay

    (2) VPN: bounded bandwidth

    (3) Skype, Zoom: bounded delay and bounded loss rate

    (4) Application classes

    • Elastic: applications that can work fine without guarantees of timely delivery of data

      • Telnet, FTP, email, Web browser, etc.
    • Real-time: sensitive to timeliness of data

      • Late data is completely worthless
      • Voice and video applications, industrial control, etc.
      • Hard real-time: data late => disaster
        • Service contract
          • Network to client: guarantee a deterministic upper bound on delay for each packet in a session
          • Client to network: the session does not send more than it specifies
        • Algorithm support
          • Admission control based on worst-case analysis
          • Per flow classification/scheduling at routers
      • Soft real-time: data late => headache
        • Service contract:
          • Network to client: similar performance as an unloaded best-effort network
          • Client to network: the session does not send more than it specifies
        • Algorithm Support
          • Admission control based on measurement of aggregates
          • Scheduling for aggregate possible
    • Taxonomy of Real-time Applications

      • Tolerance of data loss (loss = late or lost packets)

        • Tolerant: can tolerate occasional loss, e.g. can interpolate to overcome loss of a single packet in audio stream with little effect
        • Intolerant: even single lost packet is problematic, e.g. industrial control “shut-down”packet
        • Note real-time can be more tolerant than non-real-time (consider FTP)
      • Adaptability

        • Delay-adaptiveapplications: can adjust playback point, e.g. can (and do) adjust playback point in audio stream slightly while executing
        • Rate-adaptiveapplications: can trade off bit rate versus quality, e.g. video apps can use coding algorithms with parameters that can be set for differing levels of quality
      • Internet service model good for elastics, but obviously not good for the rest of the crowd

      • Applications
        ├── Elastic
        │   ├── Asynchronous
        │   ├── Interactive
        │   └── Interactive-bulk
        └── Real-time
            ├── Intolerant
            │   ├── Nonadaptive
            │   └── Rate-adaptive
            └── Tolerant
                ├── Adaptive
                │   ├── Delay-adaptive
                │   └── Rate-adaptive
                └── Nonadaptive
        

    (5) More

  • Challenges

    (1) Existing IP networks only support best effort service. Adding service differentiation is non-trivial.

    (2) How do you define the service?

    • By its effect? Service attributes observable by users in end systems
      • ISPs want to write contracts, called “Service-level agreements” (SLAs), and charge money.
    • Or by mechanism? Specific queueing mechanisms in routers
    • Effect vs. Mechanism
      • Suppose your ISP says: “For an extra ¥10/month I will give your packets priority over packets from users who don’t pay extra.”
        • Priority is a mechanism; what would its service**effectbe?
      • It’s quite hard to connect: effect <=> mechanism
        • Internet traffic does not follow any simple statistical laws; it can be very BURSTY.
        • Generally, to build a mechanism matching a useful service model requires traffic shaping/policing mechanisms to place a bound on the burstiness.
          • Delay or drop non-conformant packets in each user stream
          • Most common: token bucketshaper/policer.

    (3) You can build mechanisms that operate packet strictly, butto make any QoS guarantee requires per-flow state in routers.

    • Violates the Internet religion: “Forward IP datagrams using stateless routers.” This religion provided simplicity, robustness, generality, and scalability – not to be given up lightly.
    • There are also resource and scalability issues.

    (4) QoS requires accounting / feedback (e.g., charging) to avoid a tragedy of the commons.

    • Many technical, business, legal, social problems…
  • Metrics

    (1) Delay/delay varation(jitter)

    (2) Bandwidth (throughput)

    (3) Error rate: bit error rate, packet loss rate, and connection establishment failure probability etc.

  • To support QoS, we need

    • Between the network and its clients: Traffic contract. Traffic specification / desired QoS / supported QoS
    • At network edge:
      • Signaling and admission control: if everything is allowed, QoS cannot be guaranteed. Signaling is usually needed to setup the network so that QoS can be guaranteed.
      • Packet classification/marking: What kind of service do you want to apply to the packet?
      • Traffic shaping: traffic with a certain shape is easier to guarantee service (Packet classification/marking and traffic shaping is also called traffic conditioning.)
      • Traffic policing: packets out of the service agreement should be stopped at the edge.
    • At core routers:
      • classification and scheduling: FCFS won’t work, need more advanced packet scheduling scheme (Fair Queuing)
      • Routing algorithm need to improve: find a path that satisfies QoS constraints (QoS/policy/constraint based routing).
      • Buffer management.
      • Traffic monitoring: find problems as early as possible
      • Traffic reshaping(at merge and fork points)
  • Approaches (Refer to xumingwei’s ppt)

    • Fine-grained: provide QoS to individual apps or flows
      • Integrated Services: developed by IETF and typically associated with the Resource Reservation Protocol (RSVP)
    • Coarse-grained: provide QoS to large classes of data or aggregated traffic
      • Differentiated Services

2. History

​ A number of attempts for layer 2 technologies that add QoS tags to the data have gained popularity in the past. Examples are frame relay, asynchronous transfer mode (ATM) and multiprotocol label switching (MPLS) (a technique between layer 2 and 3). Despite these network technologies remaining in use today, this kind of network lost attention after the advent of Ethernet networks. Today Ethernet is, by far, the most popular layer 2 technology. Conventional Internet routers and LAN switches operate on a best effort basis. This equipment is less expensive, less complex and faster and thus more popular than earlier more complex technologies that provide QoS mechanisms.

Ethernet optionally uses 802.1p to signal the priority of a frame.

There were four type of service bits and three precedence bits originally provided in each IP packet header, but they were not generally respected. These bits were later re-defined as Differentiated services code points (DSCP).

With the advent of IPTV and IP telephony, QoS mechanisms are increasingly available to the end user. (From wiki

3. Architecture

  •   \             /-----------------------------------\
        \         /                                       \
          \     /                                           \
     F      \ /         /--------------- R                    \
     L-----> | /----- R                    \-------\           |
     O-----> R1         \                            R         |
     W-----> | \--------- R-----------\------------/           |
     S      / \             \          R --------/            /
          /     \             R ------/                     / 
        /         \                            Domain     /
      /             \-----------------------------------/                R : Router
    
    1. Manage the Access (R1) :
      1. Identify a flow to get QoS
      2. Verify and control the flow to insure it is within agreed parameters
    2. Manage the routing domain / AS
      1. Select a path through the network that will give the quality needed
      2. Perform traffic engineering to assure efficient use of resources
    3. Manage the inter-domain gateway
      1. Manage relations between Autonomous Systems to provide end-to-end QoS
      2. Provide network management and accounting, especially between Autonomous Systems