INTERNET-DRAFT Z. R. Turanyi draft-westberg-loadcntr-00.txt L. Westberg Ericsson Feb. 25, 1999 Load control of real-time traffic 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 This Internet Draft expires 25 August, 1999. Abstract Congestion control is known to be of outmost importance in the current Internet. However, the main targets of congestion or load control schemes were TCP and other adaptive applications, which can react to congestion signals by reducing their transmission rate. The purpose of this memo is to describe a method to block traffic belonging to other traffic classes or applications where it is not feasible or desired to reduce transmission rate below a certain point (such as voice). This method is intended mainly for diffserv capable backbone networks. 1. Introduction In recent years a significant amount of research effort has been spent on developing and refining congestion control methods to avoid congestion collapses of the Internet. draft-westberg-loadcntr [Page 1]
February 25, 1999 The majority of these methods are well suited to data transfer applications in a best-effort environment, where the primary goal is to keep utilisation high, provide low loss and achieve fairness among competing flows. The main tool for congestion avoidance is the decrease of the transmission rate of sources. Thus, if more sources are present, each will receive an equal but lower share of the resources. This is well acceptable for data transfer applications, where even receiving a relatively small amount of bandwidth has some utility. However, there are other applications or services, where receiving a bit fewer resources degrades the utility of the service a lot. It is even possible that certain applications cannot work at all in the absence of a minimal set of resources. The typical example of such service is telephony. Even if we apply adaptive coding the bandwidth usage cannot be decreased below a certain level without causing serious degradation of the voice quality. Traditionally the tool for solving congestion problems in such networks was call blocking, and not voice quality degradation. In addition, other types of services can be envisioned, where the ability to block some of the users is preferable to degrading the quality perceived by all. Examples may include: 1. low bitrate video, where compressing the signal beyond a certain point renders the picture useless; 2. real-time gaming, where the provider should carefully protect the quality of ongoing sessions as each loss may cause serious annoyment; 3. streaming media applications over UDP/RTP. The purpose of this memo is to describe a load control scheme for such real-time traffic classes. The major tool of the described scheme for avoiding congestion is the blocking of new users or flows. In the following we use the telephony example, as this is the most straight forward, but all reasoning is valid for the other examples as well. 2. Admission control In short, the method we propose for admission control is a simple exchange of test packets between the communicating parties. The routers along the path, mark the test packets if they experience the onset of resource exhaustion. The sources block the connection if the test packets get marked. draft-westberg-loadcntr [Page 2]
February 25, 1999 Assume that we have a diffserv capable network [2] and our application uses a DS class, which provides a low delay service. We also assume that routers have some means to communicate the onset of resource exhaustion in the DS class via simple marking in the packet header. Good examples include the use of the (not standardised) Explicit Congestion Notification (ECN) [1] field or a remappable DS codepoint. The actual implementation may vary depending on the possibilities, but the mechanism remains the same. The router can signal the exhaustion of resources by remarking the packet according to any local policy. It can send such blocking signals whenever it wishes to stop accepting new traffic from the given DS class. Using the above marking feature of the routers the end systems can check the availability of resources along the path in the following way. Before establishing the communication, the initiating party sends a test packet into the network which, belongs to the same DS class as the data packets will. The test packet passes through the same routers as the actual traffic will and is exposed to the marking function of the routers. When it reaches the destination node, its header will reflect the congestion status along that path. When the destination party receives the test packet it copies the congestion status into the payload of a reverse test packet and sends it back to the initiating party. Again, the reverse test packet belongs to the DS class this party will use, which may be different from the DS class of the forward direction. The reverse test packet returns to the initiating party and upon receipt its header reflects the congestion status of the DS class on the backward path. If the connection is to be established is bi-directional, then the initiating party blocks it if either of the test packets have been marked. Otherwise, it assumes that there is enough capacity in the network and proceeds with the connection. If the connection is unidirectional then the initiating party bases its decision on only one of the directions. If the communication is unidirectional and can be blocked by the receiver then no reverse test packet is needed (see section 4). After establishing the connection both parties ignore the resource exhaustion markings in incoming packets. This means that once a connection has been established it will not be dropped, other newly arriving connections are blocked instead. To make the scheme more robust, the initiating party starts a timer, when it sends the first test packet. If any of the test packets are lost, it simply retransmits on timeout. Selecting a precise value for the timer is not crucial. If the timer fires too draft-westberg-loadcntr [Page 3]
February 25, 1999 late, only the connection setup latency will increase. Setting the timer value too low will cause only unnecessary retransmissions of test packets, but the semantics of the scheme will not change. Note that this is not a new signalling protocol. Any packet will do as a forward or reverse test packet if it has at least one bit in the payload as a placeholder for the returned congestion status. Thus, message exchanges of existing protocols can be reused. The method is a very simple way to exercise some form of admission or load control in large backbones. It is scalable as the routers need to have only per class state. Per packet work is small and does not grow with the number of flows. The routers do not even need to identify test packets. It is also robust and can adapt to changing routing conditions. 3. Admission accuracy Using such a stateless load control scheme raises the issue of accuracy. Before discussing some of the issues we should point out that given its inherently measurement based nature the method aims to provide load control with some acceptable coarseness. As a large proportion of the traffic is still expected to be best-effort, a few percent more traffic on the high priority DS classes will cause minimal degradation of service. Also note that we traded high utilisation for simplicity of the admission control. One important issue with the scheme is that the router does not set aside resources when it admits a flow (lets the test packet through unmarked). This may cause admission inaccuracies, as in case of burst arrival connections the router may let too many test packets through untagged till the traffic belonging to those connections arrives and starts effecting the measurements. In the backbone, where connections from a large set of users are multiplexed, user initiated connection arrivals tend to be statistically well behaved (e.g. a Poisson process as in case of telephone calls on mbone multicast sessions [3]). We believe that by using a properly conservative marking function in the routers, the chance of admission errors can be controlled. Another issue is that this method is basically an admission control scheme, where sources do not specify any traffic parameters. This greatly helps to keep things simple, but again, it might lead to admission inaccuracies. However, if many connections can be served on the link even from the most bandwidth demanding ones then the error will be small compared to the total resources assigned to the draft-westberg-loadcntr [Page 4]
February 25, 1999 DS class. If a connection type uses so much bandwidth that only a few fits into the link, then we do not need the scalability benefits of this method and we should use something else (e.g. RSVP) for load control. 4. Interworking with RSVP If the network operator is a public service provider, it may not trust the end-systems to block connection attempts in response to marked test packets. In that case test packets could be used to check the availability of resources within the network of the provider and some more detailed mechanism can be utilised to communicate with the end systems. Ingress routers could generate the test packets and egress routers could listen and turn around them. Of course, boundary routers should enforce connection blocking as well. ___ ___/ \__ _/ \_ PATH / PATH msg \ PATH Source ------> R1 ===========> R2 ------> Dest \_ as test pkt_/ ?<----- \____/ \___/ RESV DS cloud This type of edge-to-edge usage can be applied in the diffserv backbone to co-operate with a possible RSVP access network. (See figure.) The RSVP PATH messages are perfect test packets and by traversing the DS cloud can collect information about the resource status. When the egress boundary RSVP router (R2) receives the test packets marked, it can go into blocking mode, refusing RESV messages of newly coming connections. Of course, RESV messages of calls already in progress (whose RESV messages have once been accepted) will not be refused. 5. Security issues Applying the above method implies the same security consequences as ECN. Possible man-in-the-middle attacks could tamper with the marking of packets causing unwanted blocking. Test packets and reverse test packets can be encrypted and authenticated by the hosts or edge devices if needed. No authentication of test packets is required in the intermediate routers however. 6. Conclusions In the current Internet, sophisticated congestion control solutions exist for elastic traffic. However, there are other applications or services, where receiving a bit fewer resources degrades the draft-westberg-loadcntr [Page 5]
February 25, 1999 utility of the service a lot. Connection blocking is a good way to exercise control over such type of traffic. A simple, robust and scalable scheme is presented that supports blocking. We believe that the scheme is highly flexible, introduces only tolerable errors under realistic conditions, and can be well deployed together with RSVP. 7. References [1] Ramakrishan, K., Floyd, S., "A Proposal to add Explicit Congestion Notification (ECN) to IP". RFC 2481, January 1999 [2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [3] Almeroth, K. C., Ammar, M. H., "Multicast Group Behavior in the Internet?s Multicast Backbone (MBone)", IEEE Communications, June 1997 Author's address Zoltan Richard Turanyi Ericcson Telecommunications Budapest, Laborc u. 1 H-1037 Hungary EMail: Zoltan.Turanyi@eth.ericsson.se Lars Westberg Ericsson Research Kistagangen 26 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@era-t.ericsson.se Expiration date: 25 August, 1999. draft-westberg-loadcntr [Page 6]