Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms

From: Susumu Harada (harada@cs.washington.edu)
Date: Mon Oct 25 2004 - 13:34:12 PDT

  • Next message: Erika Rice: "Review 10-27"

    "Supporting Real-Time Applications in an Integrated Services Packet
    Network: Architecture and Mechanisms"
    D. Clark, S. Shenker, and L. Zhang

    The paper presents a network architecture called the Integrated Services
    Packet Network (ISPN) which provides a mechanism for supporting both
    guaranteed and predicted services for real-time applications (as well as
    best effort services), with focus on play-back applications where a source
    host streams some media to be played back at the destination host where
    buffering and play-back point adjustment are used in an attempt to
    recreate the stream at the original rate despite jitters introduced by
    network delays.

    The key idea of the paper is that it combines several scheduling
    algorithms into one scheme that allows the network to support all three
    types of services mentioned above. It does this by using Weighted Fair
    Queuing (WFQ) as the overarching scheduling algorithm, which provides
    isolation among the guaranteed service flows plus one more flow, which is
    the flow containing all the predicted and best effort service flows.
    The predicted and best effort service flows are scheduled within that
    particular WFQ flow by the use of FIFO+ with priority classes, in which
    the best effort service flow is assigned the lowest priority. The idea
    behind FIFO+ algorithm is that packets that are running really late due to
    accumulated delays along a multi-hop path are given higher priority and
    thus sent first at a particular router even if it arrives later than some
    other packet with lower accumulated delay.

    I thought that the idea of embedding one scheduling policy within another
    to support multiple real time application needs was interesting, but one
    concern I have is the scalability of this solution as the number of flows
    increase and in situations when the ratio of the usage of the network by
    real-time applications versus non-real-time applications fluctuate a lot.
    I would like to know in such situations, whether the router will be able
    to handle the processing of all the flows and what the resulting network
    performance will be. There also seems to be a problem that in order for
    this architecture to provide real value, all the routers in the network
    will have to be upgraded with this capability, a very unlikely scenario.


  • Next message: Erika Rice: "Review 10-27"

    This archive was generated by hypermail 2.1.6 : Mon Oct 25 2004 - 13:34:13 PDT