|
|
Using Premium Service to Provide Internet2 QoS Kathleen M. Nichols Abstract This paper presents a brief analysis of how the IP Differentiated Services end-to-end service known as "Premium Service" [1, 2, 3] can be utilized to meet the quality-of-service (QoS) needs of Internet 2 [4]. Differentiated Services offers the best means to widespread early deployment of IP QoS and has been designed to offer QoS where the policy decisions and QoS allocations can be made both on a domain-by-domain basis and hierarchically, an excellent match for the needs of Internet2. One of the Differentiated Services has a simple, well-defined implementation in the network and the end-to-end QoS it delivers can be easily measured. This service is known as Premium service. Premium service:
For these reasons, Premium is the ideal roll-out service for Internet2. 1. Introduction The QoS requirements for Internet2 are outlined in [4] and summarized as:
The differentiated services approach to providing IP QoS has been gaining attention in the past year. One end-to-end service within this framework was originally proposed by Van Jacobson [1,2] and called a "premium service". A somewhat more general architecture enabling premium service is described in [3]. The IETF's WG on differentiated services is proposing a framework that will encompass the premium service [5,13]. Premium service, and Jacobson's associated allocation architecture [6], is of particular interest to Internet2 because it meets the above-stated requirements so well. In Premium service, allocations are in terms of peak rate, as measured by a token bucket with a depth of one or two packets. The smallest unit of allocation is a single "flow" of packets as determined by a match on IP header fields of source address, destination address, ports, and protocol. Packets of the affected flow are marked in their packet headers for Premium service and shaped for conformance to the rate requirements at the edge of the network. This may be done by an edge network node, transparently to the host, or may be done by a host. In the latter case, the usual architecture would call for the first-hop edge network node to monitor that the marked traffic conforms to the allocation the network has recorded for that flow. A thorough description of Premium service is given in [3]. The marking that packets carry is used by subsequent network nodes to enqueue the packets for priority service at each output port. The combination of strict priority service, no bursts at the peak rate, and a requirement that the service not be oversubscribed means that packets will experience close to the minimum possible latency and jitter through the network. Since allocation is in terms of peak rate only, this single number can be used by allocation policies in an "add 'em up" fashion that facilitates early deployment and should be quite adequate for early uses, where the QoS applications are not expected to be a large percentage of the bottleneck network bandwidth. Further, this allows mixtures of static and dynamic allocation. For example, a completely dynamic QoS might be used within one campus, employing hosts that signal for QoS using RSVP. When that campus has packet traffic that crosses the boundary onto the Internet2 backbone, priority-marked traffic might be allocated from a static allocation across the boundary and policed to that level. In the same Internet2, another campus might use completely static allocations and another might use a mixture of static allocations and requests made directly to the network administrator. The choice of intradomain allocation is up to each domain. The choice of allocation across a boundary depends only on the agreement between the domains on each side of the boundary. 2. Meeting the Requirements This section reviews Internet2's QoS requirements and notes how Premium service can meet each one. 2.1 Enabling Advanced Applications Premium service can deliver latencies that are near network minimum since its packets are marked for priority service at each network node and the amount of packets permitted in that priority queue is strictly limited by the conservative allocation strategy. The maximum jitter seen is a single packet with respect to the subscribed service rate. The burst and rate limitations also make for small, predictable queues at each network node (on the order of the in-degree of each network node), thus there is no loss due to queue overflow. These are all the requirements that [4] has mentioned for Internet2's advanced applications. Although Premium service has low jitter and per-packet delay, it is entirely conceivable that some important applications will not require this feature, but will be focused instead on the fact that it is possible to bound the amount of time to transfer a large amount of data, since the peak bandwidth of the transfer is known and guaranteed. It is worth noting that this service can be provided to very low-rate flows (as in a voice over IP application) as well as high-rate flows. When there is a large amount of bandwidth available, as is expected in Internet2, Premium service allows for efficient use of of the bandwidth by permitting the use of the required portion of bandwidth by packets of Premium service, while permitting other packets to use the rest of the "pipe" as well as any allocated portion that is not in current use. 2.2 Multiple and Concatenatable Implementation The "core" behavior required to enable Premium service is network nodes that can look at the mark in the packet header and place a packet in a priority queue for output. Many manufacturers already offer priority queueing and are moving quickly toward the necessary classification functions. Other differentiated services being discussed either have more subtle features that could give somewhat different behavior in different implementations or are designed for intradomain traffic engineering, rather than for end-to-end services. For example, an Assured service has been proposed [3,7,8] whose characteristics depend on the implementation and particular parameters picked for a preferential drop mechanism implemented in every packet buffer in the network. Studies [9,10] show that the ratio of the delivered rate to the target rate in such a service can vary widely depending on several factors, such as round trip time of the connection, percentages of the bottleneck link allocated to Assured traffic, and particular TCP implementations. The Assured service does not provide a lower per-packet delay, except for any delay benefits that might accrue from using active queue management to keep average buffer sizes low. Thus, Premium service is the currently defined service most likely to be predictable across a variety of manufacturers' equipment and whose delivered performance can easily be quantified. The simplicity of this per-network-node forwarding behavior (what IETF's diffserv WG calls "per-hop behaviors" or PHBs), priority queueing, coupled with Premium service's "rule" that the bottleneck bandwidth of the network path must not be oversubscribed, means that the results of concatenating the behavior are well-understood. The behavior of other Differentiated Services under concatenation has not been well-explored. 2.3 Scales Differentiated services have been architected for scalability and Premium service obeys the architecture. Classification of packets on multiple fields in packet headers, along with shaping of the flows, is done at the network's edge where the number of flows that each network node must handle is much smaller than the number of QoS flows in the core of the network. All packets are aggregated into a single category (called a "behavior aggregate") denoted by a one-byte marking in the packet header. Core nodes classify packets only on a small number of possible values in that byte and output queue accordingly. Thus the allocations are also aggregated so that the agreement of a backbone offering Premium QoS is quite simple, e.g., campus A may send priority-marked packets at a rate R from 8 am to 5 pm every day. 2.4 Administratable Premium service has a simple allocation strategy (though more complex ones may emerge over time): only allocate up to some percentage of the bottleneck link of the network. Further, control of this is also fairly simple. Some trusted network element sets the first-hop network node (or edge device) to classify, mark, and shape a certain stream of packets at a set rate in the case of "unaware" hosts. In the case of "Qos aware" hosts, the edge device is set to police conformance of the already marked packet stream. (It is possible that some networks may not feel the need to do this policing of aware hosts.) A variety of implementations are possible for the "trusted network element", or Bandwidth Broker [1,2,3,6]. Very simple ones are possible, facilitating early deployment. 2.5 Measurable Service There are a number of types of differentiated services emerging, but only two of these have some "profile" or specification of the QoS requested, Premium and Assured. The "precedence" or "class" service proposed in [Baker] assigns relative shares of service at each network node and thus is dependent on the exact setting of the shares as well as the ouput bandwidth at each node and the additional traffic in the network. This might give services that "feel" less congested to their users and, over time, result in faster data transfers, but it is not apparent how to monitor received QoS vs. requested QoS. Thus, this does not appear to be well-suited for Internet2 requirements. Premium service is the most measurable of all currently defined differentiated services. As discussed previously, the Assured service has been shown to deliver rates that vary about the target profile with that variance depending on several network and host features. [9,10] An end-to-end flow which has been granted Premium service can be measured at the receiver to determine the packet rate and jitter to determine compliance. If a two-way Premium service is set up between two hosts, it is possible to measure the round-trip delay, which should be both minimal and have low variance. 2.6 Host Requirements It is possible to deploy Differentiated services in a network using legacy hosts that do not have special OS features that are aware that flows can be marked for the Premium service. Instead, flows can be earmarked for Premium service by some external configuration (see [3]). However, where RSVP is available in hosts, it should be possible to use it to signal for Premium service using an architecture such as that outlined in [11]. To see the full benefits of the Premium service, the applications must be sending at target rate and within the desired jitter bounds. It is not possible for any network service to deliver a better quality data stream than it was given for delivery. 2.7 Early and Incremental Deployment As mentioned in section 2.2, many of the required features are either already in vendor's equipment or should be available very soon. Prototypes of Premium service has already been deployed as a prototype in the Department of Energy's research network [12]. Since the service can be deployed with very simple and static allocations, many of the hard problems of QoS that have stalled the deployment of other proposed services can be worked out in parallel with deployment and gaining experience from the simple strategies. Further, a number of variations on allocation and a number of different local policies can co-exist in different campuses. 3. Conclusion Premium service is the most promising profile-based differentiated service to meet the demanding requirements of advanced Internet2 applications. Because it is the most easilly-understood PBDS and requires the simplest functionality in network elements, it is also the most promising service for early deployment in an Internet2 test bed. Acknowledgements Thanks to Ben Teitlebaum and the rest of the Internet2 QoS Working Group. References [1] Van Jacobson, "An Architecture for Differentiated Services", Talk
at IRTF End-to-end WG,
<ftp://ftp.ee.lbl.gov/talks/vj-e2e-jul97.pdf>, July 1997. [3] K. Nichols, V. Jacobson, L. Zhang, "A Two-bit Differentiated
Services Architecture for the Internet", Internet Draft
<draft-nichols-diff-svc>, [4] Ben Teitlebaum, "QoS Requirements for Internet2", Internet2 Technical Paper, 1998. [5] K. Nichols and S. Blake, "A Differentiated Services Operational", Internet Draft ,draft-nichols-dsopdef-00.txt>, February 1998. [6] Van Jacobson, "Differentiated Services and Bandwidth Brokers", Talk at Bay Networks, Santa Clara March 1998. [7] Dave Clark, Presentation at IETF Int-serv WG, August 1997. [8] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath, and J. Renwick, "IP Precedence in Differentiated Services Using the Assured Service", Internet Draft <draft-diff-serv-precedence-00.txt>, April 1998. [9] D.D. Clark, W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", http://diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf . [10] Wenjia Fang, "The 'Expected Capacity' Framework: Simulation Results", Princeton University Computer Science TR, January 1998. [11] Y. Bernet et. al., "A Framework for End-to-End QoS Combining RSVP/Intserv and Differentiated Services", draft-bernet-intdiff-00.txt, ftp://ds.internic.net/internet-drafts/draft-bernet-intdiff-00.txt, March 1998. [12] Van Jacobson, "Moving the Internet Beyond Best-effort", Talk at DOE LSN Research Workshop, <ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf>, January 5, 1998. [13] K. Nichols and S. Blake, Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers, Internet Draft draft-ietf-diffserv-00.txt, May, 1998. Author's Address Kathleen Nichols <knichols@baynetworks.com> |
 |
|
| [Home] [Overview] [Agenda] [Presentations] [Attendees] [Papers] [Electronic Forum] [Webcast] |