INTERNET DRAFT Paul Hurley Diffserv Working Group Jean-Yves Le Boudec Expires: December 2000 Swiss Federal Institute of Technology, Lausanne June 2000 The Alternative Best-Effort Service draft-hurley-alternative-best-effort-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before December 5th 2000. Distribution of this draft is unlimited. Abstract Alternative Best-Effort (ABE) is a novel service for IP networks. It offers applications the choice between receiving a lower end-to-end delay and receiving more overall throughput. Every best effort packet is tagged as either green or blue. Green packets receive a low, bounded queueing delay. To ensure blue packets do not suffer as a result, green flows receive less throughput during bouts of congestion. The unique combination of lower delay with reduced throughput for green makes it different from existing differentiated service proposals such as expedited forwarding [5] and assured forwarding [6]. The incentive to choose one or other is based on the nature of one's traffic and on traffic conditions. Typically, green flows have real-time deadlines (e.g. interactive audio), while blue traffic (e.g. bulk data transfer) seeks to minimise overall transfer time. There is benefit for all traffic in that green traffic achieves Hurley, Le Boudec. Expires: December 2000 [page 1] INTERNET-DRAFT draft-ietf-alternative-best-effort-01.txt May 2000 a low delay and blue traffic will receive at least as much throughput as it would in a flat best-effort network and usually more. Neither traffic type can be said to be better, thus flat rate pricing may be maintained, and there is no need for reservations or profiles. In this document we define the ABE service, discuss its usefulness, and describe the requirements of router algorithms for ABE support. ABE is not restricted to any specific implementation. One FIFO based implementation is described in [10]. Other implementations such as per-flow queueing based ones are certainly do-able. We invite universities and research centres to define other implementations. 1. Introduction Alternative Best-Effort (ABE) is a new IP service, whose goals are (1) to provide a low queueing delay service and (2) to operate in best effort mode, requiring no usage control. The first requirement is for applications with stringent real time constraints, such as interactive audio. The second requirement is to maintain the simplicity of the original Internet. With ABE, it is not required to police how much traffic uses the low delay capability. The service is designed to operate equally well in all traffic scenarios. ABE is designed primarily for rate-adaptive multimedia applications, applications that adapt to network state. The rate is reduced when negative feedback is received, and increased with positive feedback. In today's Internet, feedback is based on packet drop. In future, binary feedback based on Explicit Congestion Notification (ECN) [7] will be used. This document approaches ABE from both the ECN and loss-based feedback points of view. Note that ABE would be even more attractive with ECN. As is required in the Internet, rate adaptation should be performed such that the application is TCP-friendly [1], namely, it does not receive more throughput than a TCP flow would. It has been established that it is possible to implement adaptive multimedia applications, which perform across a wide range of network conditions [8, 9]. In this context, the key idea of ABE is to provide low-delay at the expense of maybe less throughput. This is fundamental to ensure ABE requires no usage control. ABE operates as follows. Best effort IP packets are partitioned into either low delay packets, called green packets, and other best effort packets, called blue packets. The choice of the terms blue and green, two primary colours of equal warmth, is to indicate that none of the two has priority over the other, while green, the colour of the traffic light signal for go, indicates low queueing delay. Green packets are given the guarantee of a low bounded delay in every router. In exchange, if, as now, packet loss is used as the source of feedback, these packets receive more losses during bouts of congestion than blue packets. If ECN is used, then green packets are more likely to be marked with the congestion bit than blue packets. Hurley, Le Boudec. Expires: December 2000 [page 2] INTERNET-DRAFT draft-ietf-alternative-best-effort-01.txt May 2000 ABE addresses a different market than existing differentiated or integrated services. Unlike these services, ABE does not offer any guarantee, or even indication of guarantee, on throughput. A highly loaded network offering ABE will give little throughput to all best effort flows, no matter whether green or blue. However, ABE enables a moderately loaded network to offer low delay to some applications (typically, adaptive multimedia applications), as long as such applications are satisfied with the throughput they receive. Traditional byte transfer oriented applications would probably find it more beneficial to use only blue packets. 2. ABE Service Requirements ABE is an Internet service characterized by the following set of requirements: 1. ABE packets are tagged as either green or blue. 2. Green packets receive a low, bounded delay at every hop, the value of the per-hop delay bound configured by the operator. 3. Applications are expected to control their rate in a TCP-friendly manner. Blue and green packets are considered to belong to the same flow, not two distinct flows. 4. (Transparency to Blue) If some sources decide to tag some of its packets green rather than blue, then the throughput of sources that have all blue packets remains the same or increases. 5. All ABE packets belong to one single best effort class. If the total load is high, then every source may receive little throughput. However, entirely green sources may experience less throughput than entirely blue sources sharing the same network resources. Requirement 4 that green do not hurt blue is important. If some sources send green rather than blue packets, there should be no negative impact on the throughput of those sources which remain blue. In particular, an entirely blue flow receives at least as good average throughput as it would in a flat best-effort network i.e. if all packets were blue. As a result, there is benefit to all. If some application decides to tag some packets green, then it must do so because it values the low delay more than a potential decrease in throughput; otherwise, it would tag its packets blue. In all cases, there is no penalty for other applications which might choose to tag all their packets blue. Flat rate charging may be applied if the marketing department so decides. Requirement 5, the single class, ensures no policing of colour tagging is required. In a network with a large number of blue sources, a green source receives little throughput. Conversely, in a network with many green sources, a blue source also receives little Hurley, Le Boudec. Expires: December 2000 [page 3] INTERNET-DRAFT draft-ietf-alternative-best-effort-01.txt May 2000 throughput. This is not because the green sources are green, but because there are many of them. If they were blue, the blue source would probably get less throughput. However, it does get more than if it were green. Lastly, a network where all sources are blue behaves as a flat best effort network. Conversely, a network with only green sources behaves like a flat best effort network with smaller buffers. 3. Router Requirements There may be many different implementations of ABE. One implementation is described in [10]. We provide here generic router requirements for any implementation, which are as follows: 1. Provide low, bounded delay to green packets. 2. Provide transparency to blue packets. 3. Drop or mark green packets with higher probability than blue, such that an entirely green flow gets a lesser or equal throughput than if it were blue. 4. Minimise green packet dropping or marking, subject to the above requirements. The first three requirements directly map from service requirements 2, 4 and 5. The last requirement is because an implementation should try to minimise green packet loss or marking, in order to make the service attractive. Enforcement of TCP-friendliness within a router is not specified. Methods for enforcement are discussed in [3, 2] amongst others. We expect in the future to see some implementations that would combine the support of ABE with the enforcement of TCP-friendliness. 4. Source Aspects A source is required to be TCP-friendly. Within this constraint, it is perfectly permissible and considered normal practice for a source to attempt to maximise its utility by employing a colour mixing strategy, where they would send some green packets and some blue. Apart from possibly policing TCP- friendliness, the network supporting ABE does not need to analyse individual flows. Source strategies would typically be performed at the application level as expected by Application Layer Framing (ALF) [11]. To illustrate the ABE service, we discuss now a very simple scenario. Assume we have multimedia source, that is rate-adaptive, and has a required minimum rate R0 in order to function properly, for a given loss pattern in the network. If ECN is not used, the source forward-correct packet losses, as long as the minimum rate is achieved (see [8] for such an application example). The application Hurley, Le Boudec. Expires: December 2000 [page 4] INTERNET-DRAFT draft-ietf-alternative-best-effort-01.txt May 2000 must choose between green or blue. The choice it makes depends on its utility function u(R; D), for a given throughput R and end-to-end network delay D. In many situations today throughput is the major impediment. However, once a minimum rate R0 is achieved which provides enough intelligibility, delay becomes the major impediment. Thus, we assume that the source utility function is such that it is 0 when R < R0 and is a decreasing function of D when R <= R0. For such a source, the optimal strategy is to be green when the load is such that the minimum throughput can be received, blue when load means the minimum throughput cannot be received as green, and to cease to operate when the load is too high to do anything useful. ABE opens up a new region of operation for the best-effort network. In low load scenarios, a source may decide to obtain less throughput for the benefit of low delay. In a flat best effort network, a network without the ABE service, there is no such option; by refraining from sending at a higher rate, there is in general no impact on the queueing delay, because of external sources. This example is of course oversimplified. In general we expect more complex utility functions to be used, for example as specified in [12]. Note that the detection of which region the source is currently operating in has to be made automatically by the source itself. Following immediately from the definition of the service, a blue source has at least as high a throughput as a green one. Unlike the multimedia source above, a source using TCP is more interested in its throughput and would probably find it more beneficial to tag all its packets blue. 5. Codepoint Requirements An implementation of ABE using AF codepoints is not practical for the following reasons. Firstly, if we map blue and green within the same AF class, we would give green a high precedence level in order for it to receive a low delay. However this would contradict the requirement that blue sources receive at least as much as it would if green. Secondly, if we map blue and green to different AF classes, we would need to coordinate packet dropping across the two classes, which appears to contradict RFC2597. An allocation of codepoints to support ABE is thus needed. There are two possibilities for codepoint provision. The first considers blue packets as normal best-effort packets, which use the predefined DSCP value 0. ABE packet classification can be achieved by introducing a new PHB for green. The DSCP value for green specification should satisfy the following: o It should be in one of the experimental/local use pools defined in RFC2474: xxxx11 binary and xxxx01 binary. Hurley, Le Boudec. Expires: December 2000 [page 5] INTERNET-DRAFT draft-ietf-alternative-best-effort-01.txt May 2000 o It should be smaller than 0x38 (otherwise, privileges are required to set them at the source using the IP_TOS socket option) Routers without an ABE implementation will simply treat blue and green packets in the same way. The second possibility is for ABE to have a traffic class of its own with 2 codepoints. We leave for future discussion as to which of the two possibilities would be preferable. 6. Conclusions We described ABE, a new service which enables best-effort traffic to experience a low delay, at the expense of possibly more throughput. ABE is targeted at supporting rate-adaptive multimedia applications, with no concept of reservation or signalling and while retaining the spirit of a flat rate network. The service choice of green or blue is self-policing since the user/application will be coaxed into choosing one or the other or indeed a mixture of both, based on its traffic profile objectives. ABE allows a collection of rate-adaptive multimedia applications to drive the network into a region of moderately high load and low delay. It also allows such an application to trade reduced throughput for low delay, thus in some cases increasing its utility. It should be stressed that ABE is a new service in its own right and not a substitute for reservation or priority services. In contrast, with ABE, both delay sensitive (green) and throughput sensitive (blue) traffic share the same resources, and high load in any of the two pools affects the other. 7. References [1] TCP friendly web site. http://www.psc.edu=networking=tcp_friendly.html [2] Floyd, S., and Fall, K. Promoting the Use of End-to-End Congestion Control in the Internet. [3] B. Suter, T.V. Lakshman, D. Stiliadis, A. Choudhury. Design Considerations for Supporting TCP with Per-flow Queueing. Proceedings of IEEE INFOCOM 98. [4] Floyd, S., and Jacobson, V. Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p.397-413. [5] V. Jacobson, K. Nichols and K. Poduri. An Expedited Forwarding PHB. RFC2598. [6] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. Assured Forwarding PHB Group. RFC2597. Hurley, Le Boudec. Expires: December 2000 [page 6] INTERNET-DRAFT draft-ietf-alternative-best-effort-01.txt May 2000 [7] Floyd, S. TCP and Explicit Congestion Notification. ACM Computer Communication Review. V. 24 N. 5, October 1994, p. 10-23. [8] J. Bolot, S. Fosse-Parisis, D. Towsley. Adaptive FEC-Based Error Control for Interactive Audio in the Internet. Proceedings of IEEE Infocom 99. [9] C. Diot, C. Huitema, T. Turletti. Multimedia Application should be Adaptive. HPCS, Aug. 1995. [10] P. Hurley, J-Y Le Boudec, P. Thiran. The Alternative Best-Effort Service. Technical Report no. SSC/1999/036 http://dscwww.epfl.ch/Pages/publications/ps_files/tr99_036.zip [11] D. Clark, D. L. Tennenhouse. Architectural considerations for a new generation of protocols. Computer Communications Review, vol. 20, Sept. 1990. [12] L. Breslau and S. Shenker. Best-Effort versus Reservations: A Simple Comparative Analysis. SIGCOMM 1998. 7. Authors' Address Paul Hurley (contact author) Jean-Yves Le Boudec EPFL - DSC - ICA IN Ecublens CH-1015 Lausanne Switzerland Email: paul.hurley,Jean-Yves.Leboudec@epfl.ch