[an error occurred while processing this directive]

Internet2 QoS Working Group Charter

February 13th, 2001

Mission
The mission of the Internet2 QoS Working Group is to support the development and deployment of advanced network applications through the use of IP traffic differentiation. This stems directly from the overall mission of the Internet2 project: "to develop and deploy advanced network applications and technologies, accelerating the creation of tomorrow's Internet"[i2Mission]. The working group will focus on two distinct approaches to applying network traffic differentiation.

The first approach the working group will explore recognizes that, while many new applications simply require higher bandwidths, others have qualitatively different expectations of network performance. In particular, certain applications need absolute assurances from the network that they will receive performance within certain well-defined end-to-end transmission parameters. In this model, there exists a covenant between an application and the network; the application agrees to produce a load within a well-specified traffic profile (usually characterized by a leaky bucket) and, in turn, the network agrees to transmit offered packets to their destination with well-specified bounds on one or more performance metrics (e.g. one-way delay, packet loss, inter-packet jitter). This approach to QoS seeks to enable new applications directly by providing them with assurances that their performance needs will be met.

The second approach the working group will explore is the use of relative differentiation to provide different applications or users with two or more classes of service (CoS) having different relative performance levels. Deployment of such mechanisms could support traffic engineering techniques tool that could be used to aid in the provisioning of high performance best effort services to meet key application needs. The motivating observation here is that Internet2 networks carry a broad spectrum of traffic that varies both in its sensitivity to network performance (e.g. audio conferencing versus server-to-server NNTP) and in its relevance to the teaching and research missions of Internet2 institutions (e.g. remote use of scientific instruments versus peer-to-peer exchanges of personal music files). Traffic differentiation techniques of this second type typically offer only relative and/or probabilistic assurances to applications, but are often much more scalable and incrementally deployable than solutions in the first space. Background
Since its inception in fall 1997, the Working Group has made a number of contributions towards focusing Internet2 QoS activity. The WG studied the QoS requirements of Internet2 applications, obstacles to deploying QoS in campus, gigaPoP, and backbone environments, and evaluated the state of IETF standards activities in the area.

In May 1998, the WG recommended that Internet2 deploy services that leverage the then newly-emergent differentiated services (DiffServ) architecture for IP QoS [twoBit]. The DiffServ model of QoS was (and remains) attractive for its simplicity and scalability. It emphasizes pushing complexity to the edge of the network (where there are slower link speeds and more processing power) and achieving scalable differentiated treatment inside the network by having interior routers respect packet markings applied at the edge to indicate which of a small number of well-specific per-hop behaviors (PHBs) is to be applied to each packet. PHBs are designed to be implementable by various scheduling disciplines commonly available in modern routers.

DiffServ continues to be an important enabling technology. The IETF Differentiated Services Working Group [ietfDiffServ] has made steady progress on standardizing the layout of the DiffServ code point (DSCP) [rfc2474] and standardizing several per-hop behaviors (PHBs) [rfc2474], [rfc2597], [rfc2598]. The IETF working group is now engaged in standardizing a MIB and a PIB for DiffServ nodes and in developing a format for precisely describing various per-domain behaviors (PDBs) defining the edge-to-edge treatment of a DiffServ aggregate across a domain. In addition to the progress in the IETF, most routers vendors are aggressively implementing diffServ forwarding capabilities, as well as DiffServ conditioners (shapers, markers, and policers) in their products.

In May 1998, the WG further recommended that Internet2 focus on deploying the "Premium" service described by Van Jacobson [bayWorkshop]. Premium is defined by a service model that has been described as a "virtual leased line" or "virtual wire" and was judged by the WG to offer the best hope of supporting new classes of real-time interactive applications that require stringent bounds on loss and jitter. Applications with "softer" QoS requirements were judged by the WG as likely to thrive in an over-provisioned best-effort environment.

A second major contribution of the WG has been the creation of the QBone initiative and architecture [qboneArch]. The QBone initiative has brought together a number of leading Internet2 networkers and application developers to specify an architecture for an interdomain DiffServ testbed and to facilitate its deployment through a series of workshops and exchanges of deployment experiences.

The QBone architecture specifies the requirements for an Internet2 network to be a QBone domain, specifies the QBone Premium Service (QPS), defines the notion of a QPS reservation, defines a set of measurement collection and reporting standards to support end-to-end debugging and auditing of QPS reservations, and specifies a common set of operational practices and procedures to be followed by network operators when requesting and responding to reservation requests. In August 1999, the QBone Architecture was frozen at v1.0 [qboneArch], awaiting further deployment experience and the recommendations of QBone Bandwidth Broker Advisory Committee (QBBAC) (now the QBone Signaling Design Team [qboneSignaling]).

With the exception of the organization of one major workshop [houstonWorkshop] and ongoing work by the QBBAC on the design of an experimental signaling protocol for possible inclusion in the QBone architecture, the WG has been mostly idle since summer 1999. This is largely due to the extent to which progress on the QBone architecture has out-paced progress on deployment. The time has come, however, to re-energize the working group to address a number of challenges facing Internet2 QoS. Objectives
Going forward, the working group will be guided by the following objectives and goals. These are listed in no particular order and, in the absence of adequate resources and work commitments from WG members, do not necessarily translate into specific work items. An explicit work program for the working group is given in the following section.

Design Teams
Consistent with the operating guidelines for Internet2 working groups [wgGuidelines], the bulk of the actual "work" of the working group will be executed by "design team" sub-groups. With rough consensus from the Internet2 QoS Working Group as a whole, the deliverables of the design teams (documents, workshops, recommendations, etc) will become official outputs of the working group.

Design teams will be created to address a variety of needs as they arise and are expected to have typical lifespans that are short relative to the expected lifespan of this charter. Consequently, it does not make sense to maintain a roster of design teams and their charters here. Instead, a current list of active design teams, their chairs, and their charters will be maintained on the WG web site [qosWGSite].

References

[bayWorkshop] First Internet2 Joint Applications/Engineering QoS Workshop, http://www.internet2.edu/qos/may98Workshop/, Santa Clara, CA, May 1998
[houstonWorkshop] First Joint Internet2 / DOE QoS Workshop - QBone: Early Experiences and the Road Ahead, http://qbone.internet2.edu/meetings/houston2000/, Houston, TX, February 2000.
[i2Mission] Internet2 Mission, http://www.internet2.edu/html/about.html.
[ietfDiffServ] IETF DiffServ Working Group, http://www.ietf.org/html.charters/diffserv-charter.html.
[qboneArch] QBone Architecture, version 1.0, http://www.internet2.edu/qos/wg/papers/qbArch/, August, 1999.
[qboneSignaling] QBone Signaling Design Team, http://qbone.internet2.edu/bb/index.shtml.
[qosWGSite] QoS Working Group Home Page, http://www.internet2.edu/qos/wg/.
[rfc2474] Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, K. Nichols, S. Blake, F. Baker, D. Black, IETF Proposed Standard RFC 2474, December 1998.
[rfc2597] Assured Forwarding PHB Group, J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, IETF Proposed Standard RFC 2597, June 1999.
[rfc2598] An Expedited Fowarding PHB, V. Jacobson, K. Nichols, K. Poduri, IETF Proposed Standard RFC 2598, June 1999.
[twoBit] A Two-bit Differentiated Services Architecture for the Internet, K. Nichols, V. Jacobson, and L. Zhang, IETF Informational RFC 2638, July, 1999.
[wgGuidelines] Internet2 Working Group Guidelines, version 1.8, http://www.internet2.edu/resources/Internet2WG-Guide.pdf , Sptember, 2000.
[an error occurred while processing this directive]