Internet Engineering Task Force Walter Weiss Internet Draft Lucent Technologies Expiration: September 1998 March 1998 Providing Differentiated Services through Cooperative Dropping and Delay Indication Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract The current state of the Internet only supports a single class of service. To further the success of the Internet, new capabilities must be deployed which allow for deterministic end to end behavior irrespective of location or the number of domains along the path. Experience with existing signaling based protocols have proven diffi- cult to deploy due to technical and economic factors. This document proposes using in-band frame marking to support a diverse set of ser- vices. In addition, the mechanisms described here will provide end users and/or enterprise backbones with new capabilities such as ser- vice validation, congestion localization, and uniform service irrespective of the type of service contract. For ISPs this document proposes mechanisms providing more available bandwidth by creating strong incentives for adaptive behavior in applications as well as mechanisms for providing both sender based and receiver based service contracts. Weiss Expiration: May 1998 [Page 1] Internet Draft Cooperative Dropping Nov 1997 1. Introduction It is widely recognized that there are many types of services which can be offered and many means for providing them. These services can be reduced to three basic components: the control of the bandwidth, the control of the delay, and the control of delay variation. The control of delay variation requires frame scheduling at the granular- ity of flows. This, in turn, requires per flow state in each hop along the path of the flow. This capability requires configured or signaled reservations. Therefore the management of delay variation is beyond the scope of this document. Although in-band delay variation is too difficult to support within a Differentiated Services framework, it is feasible to provide bandwidth and delay management using a less sophisticated model. However, any model which attempts to satisfy service contracts without an awareness of available network capacities along the path faces two issues. First of all, how can end to end (or edge to edge) bandwidth guaran- tees be satisfied when the capacity and available bandwidth of down- stream links are unknown? Some indication of capacity can be gleaned through routing protocols like OSPF. However, there is no effective mechanism for detecting the level of persistent downstream conges- tion, as a result of capacity limits like cross-oceanic links or because of singular but long lasting events such as NASA's "Life on Mars" announcement. Thus, attempting to use a profile to promise even minimal bandwidth guarantees is virtually impossible, given factors of such as distance, time of day, the specific path taken and link consumption. VPN and Virtual Leased Line services can be supported by configuring reserved capacity. However, this does not deminish the benefits of congestion awareness. As with traditional network links, Virtual Networks have a large cross section of applications using them at any given time. Some applications may need to reserve strict bandwidth and delay guarantees. However, there are other applications which can adapt to changes in available bandwidth. These adaptive applica- tions are dependent on effective congestion awareness to operate properly. In addition, ISPs need service differentiation to deploy Electronic Commerce solutions. ISPs desire the ability to provide individual users with different service offerings. In these cases bandwidth cannot be pre-allocated because the destinations for these services are not pinned. Therefore congestion awareness is crucial to antici- pating and adapting to available bandwidth along the path to a desti- nation. Weiss Expiration: May 1998 [Page 2] Internet Draft Cooperative Dropping Nov 1997 The second issue with a service contract model that does not employ signaling is that one router is not aware of another router's conges- tion control actions. Hence, when congestion occurs on multiple hops along the path of a particular flow, individual congestion control algorithms could independently drop frames. But far worse, they could collectively drop a sequence of frames, causing stalling or slow start behavior. Hence, to the end user, the service is per- ceived as erratic. Even if a customer is guaranteed more bandwidth with a more expensive profile, the "perceived" benefit is greatly deminished with choppy service. This document describes a differentiated services architecture that allows maximal flexibility for specifying bandwidth and delay sensi- tive policies while reducing or eliminating the choppy behavior as it exists in the Internet today. 2. The Differentiated Services service model 2.1. Congestion Control Differentiated services without the use of signaling relies on two basic components: a user or group profile specifying the level of service to which the flow, user, or group is entitled and a means for encoding this profile into each packet on which the profile is applied. To provide consistency in the network, all traffic within a routing domain must be administered with an associated traffic pro- file. The most economic way of enforcing this requirement is to apply or enforce the profile on all edges of the domain as described in Clark/Wroclawski [1]. Network Edge devices are defined in this document to be those devices capable of metering, assigning and enforcing bandwidth profiles and delay profiles. Because the amount of traffic on the egress link at any given time is non-deterministic, the encoding of the profile in each packet pro- vides an effective means for taking appropriate action on each packet. By comparing current congestion conditions of a link with the profile associated with the packet a consistent action can be applied to the packet. Possible actions on the packet could range from dropping the packet to giving it preferential access to the out- bound link. This document proposes using the TOS octet in the IP header to encode a profile into the packet stream of each session. The profile will be capable of specifying a delay priority as well as a relative bandwidth share. Relative bandwidth share is the relative bandwidth to which the profile's owner is entitled relative to other profiles. Through a combination of profile enforcement and the judicious use of Weiss Expiration: May 1998 [Page 3] Internet Draft Cooperative Dropping Nov 1997 the TOS octet, share-based bandwidth sharing, as described in USD [2], can be provided without proliferating individual profiles to each router in the network. The problem of coordinating dropping policies between routers on a per flow basis is too complex to be feasible. However, to provide effective coordination, each router does not need to know what pack- ets other routers have dropped. Instead, a router can create a set of hierarchical drop Priority Classes for each link. These Priority Classes are only for congestion control; they do not affect the ord- ering of packets. A new 3 bit field called the Priority Class field, is provided in the TOS octet to allow Priority Class assignment on a per packet basis. A flow distributes packets evenly to each Priority Class by having the Priority Class value assigned to the 3 bit field in the TOS octet. When a congestion threshold is reached, dropping will be initiated for the lowest Priority Class. As congestion increases more and more packets will be dropped from this Priority Class. If congestion con- tinues to increase, all packets in the Priority Class will be dropped and partial dropping will begin in the next higher Priority Class. However, the packets in the flow that use the remaining, higher Priority Classes will be unaffected. Dropping packets only within a single Priority Class creates many beneficial side effects. First, routers today have difficulty deter- mining how to drop packets fairly across all flows. The main issue is that routers have no knowledge of the profiles of individual flows, so they also have no knowledge of the relative amount of bandwidth to which the flow is entitled. Also, most drop algorithms are based on a random discard model. Without per flow state it is possible (probable for high bandwidth apps) for multiple and succes- sive drops to be performed against the same flow. Even algorithms with per flow state have limitations due to a lack of profile aware- ness. However, the Priority Class encoding mechanism described in this document allows routers to drop packets fairly based on the pro- file encoded in each flow. Further, this approach provides implicit cooperation between routers. If two or more routers along the path of a flow are dropping packets in the lowest Priority Class, all traffic in the higher Priority Classes is protected irrespective of the number of routers which experience congestion. This provides much more predictable service irrespective of the location or the current condition of the network as a whole. Also, with profiles which limit the number of packets that can be sent in each Priority Class (or alternatively the time interval Weiss Expiration: May 1998 [Page 4] Internet Draft Cooperative Dropping Nov 1997 between packets in a given Priority Class), a bandwidth share is implicitly assigned to each user. The proportional share to which each user is entitled remains constant irrespective of the level of congestion or the number of flows on the link. This model provides an implicit congestion notification mechanism to senders for TCP based applications. When a sender keeps track of the Priority Classes of sent packets, TCP acknowledgments provide infor- mation on the level of congestion along the path. This provides end users with an easy tool for service contract verification. Further, it provides equivalent functionality to ECN [3] without consuming additional bits in the TOS header. When routers are only dropping packets up to a specific Priority Class, the other Priority Classes are implicitly protected. This allows Service Providers to charge more accurately for end-to-end Goodput rather than Throughput. This mechanism can greatly reduce or eliminate bandwidth consumed by packets that will be dropped somewhere along the path. With implicit congestion notification, applications can stop sending packets in Priority Classes that they know will be dropped. In fact, if an application knows that packets in a given Priority Class are guaranteed to be dropped, it benefits by not sending the packets because it can use the in-profile bandwidth in that Priority Class for a different flow to an uncongested destination. If the edge routers which enforce profiles also snoop the TCP sessions (or use the Congestion Check mechanism described below), they could perform aggressive policing by dropping packets in unavailable Priority Classes, thus providing additional network bandwidth and encouraging adaptive behavior in end systems. While congestion awareness can be used to restrict aggressive or abusive bandwidth consumption, it can also be used to allow bandwidth to grow beyond normal limits when there is no congestion. This can have the effect of maximizing available bandwidth when it is avail- able. Using this mechanism in conjunction with TraceRoute, end users and network administrators could verify service contracts by identifying the precise location of the highest level of congestion. This clearly fixes blame when service contracts are not met and also easily identifies those links which need to be upgraded. Current TCP congestion control algorithms grow bandwidth incremen- tally and cut bandwidth in half when congestion occurs. With an awareness of which Priority Classes are being dropped, TCP growth and cutback algorithms could be applied to the same Priority Class that Weiss Expiration: May 1998 [Page 5] Internet Draft Cooperative Dropping Nov 1997 is performing the partial drop. This smoothes the bandwidth in the flow while still adjusting to current bandwidth availability as it increases and decreases. Another benefit is that the Priority Class assignment can be sequenced in any order based on transport specific criteria. If it is desirable to lose a sequence of packets with congestion, a sequence such as 0,1,2,3,4,5,6,7 would drop a block of packets based on the current congestion level. If it is desirable to spread the dropping of packets out, a sequence such as 0,4,1,5,2,6,3,7 provides a very high probability that two packets will not be dropped in a row. If it is desirable to distinguish important packets from less important ones, Priority Class can be assigned in a more discretion- ary manner. The last benefit is that this model is extremely efficient and simple to implement in routers. A router only needs to set a congestion threshold and apply a dropper algorithm to that single Priority Class. If congestion increases, all packets in the current Priority Class are dropped and the dropper algorithm is applied to the next higher Priority Class. 2.2. Delay Control The other mechanism necessary to support Quality of Service is a means for controlling link access based on a combination of service contract and profile. This document proposes using a 2 bit field in the TOS octet to provide up to 4 Delay Classes. It is believed that 4 classes are adequate for current needs. Vendors may choose to map these classes to at least 2 delay classes. There are two issues that must be addressed when providing control over packet delay. One is how the packet scheduling is handled across delay classes. For example, both Class Based and Priority Queuing provide specific features. These capabilities may be more or less appropriate depending on customer needs. Therefore, it is left to vendors to choose the technology most appropriate to the specific market. The other issue is how Delay Classes and Priority Classes work together. Is it better to for Priority Class droppers to operate autonomously in each Delay Class or is it better to have a single Priority Class dropper that is indifferent to which Delay Class a frame belongs to? This issue is in reality identical to the CBQ vs. Priority Queuing issue. The former creates specific bandwidth limits thereby creating specific delay limits. The latter allows more flexible/dynamic bandwidth allocations at the expense of possible starvation and looser delay guarantees. In certain environments like Weiss Expiration: May 1998 [Page 6] Internet Draft Cooperative Dropping Nov 1997 the Internet, where the number of hops is fairly non-deterministic, it may make more sense to use a single Priority Class dropper across all Delay Classes. However, in most private networks where the number of hops is deterministic, it is feasible to provide specific delay limits. Therefore it also makes sense to support independent Priority Class droppers within each Delay Class. It is therefore left to the vendor to choose the model most appropriate to their market and customers. 3. The TOS octet This document proposes using the 8-bit TOS field in the IPv4[4] header to provide differentiated services. The identical format would also be used in the Class field of the IPv6[5] header. The format of the TOS field is shown below. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | CC| TC | RR| DC | RB| +---+---+---+---+---+---+---+---+ CC: Congestion Check PC: Priority Class RR: Request/Response DC: Delay Class RB: Receiver Billing The Priority Class field is used to provide congestion control as described earlier. This field allows for 8 possible values. From a congestion management prospective, this provides congestion/traffic management in 12.5% chunks. The Priority Class semantics are as fol- lows: 7: Least likely to be dropped . . . 0: Most likely to be dropped The Delay Class field is used to specify the delay sensitivity of the packet. It is strongly recommended that a flow not use different Delay Class values. This would create packet ordering problems and make effective congestion management more difficult. The Delay Class semantics are as follows: 3: Low delay (most delay sensitive) 2: Moderate delay Weiss Expiration: May 1998 [Page 7] Internet Draft Cooperative Dropping Nov 1997 1: Modest delay 0: High delay (indifferent to delay) The Congestion Check bit is used as an efficient means for determin- ing the current congestion level along the path to a destination. When this bit is set, each hop will assign the congestion level of the (downstream) target link in the Priority Class field if the congestion level is greater than the value currently assigned to the Priority Class field. When the packet arrives at the destination, the Priority Class field should contain the highest Priority Class on which packets are being dropped. The usage of the Congestion Check bit is sensitive to the value of the Delay Class field. The Priority Class field will be assigned to the congestion level of the delay class specified in the Delay Class field. This bit could be set during connection establishment to optimize the initial windowing and congestion control algorithms. The Priority Class for this packet should be considered to have a value of 7 and should be charged against sender profiles accordingly. When both the Congestion Check bit and the Request/Response bit are set, this is an indication that the contents of the Priority Class field is the congestion level of traffic in the opposite direction. The Request/Response bit is used to indicate that the current Prior- ity Class value is a response to a Congestion Check request. The Priority Class field is to be ignored by intermediate routers and the Priority Class for this packet should be treated as if it contained a value of 7. It is possible for the response capability to be provided out of band. However, if the end station is not capable of supporting the new TOS octet and the edge router wants to perform the TOS byte assignments on behalf of the end station (or is performing aggressive dropping), this is an effective mechanism for snooping congestion levels without new protocols or extra bandwidth. Because this Congestion Check request and response mechanism behaves as a packet with a Priority Class of 7, profile meters should treat (and charge for) these packets as Priority Class 7 packets to prevent abuse. Further, because congestion checking is sensitive to the Receiver Billing bit, these request and response packets are always charged to the sender. The Receiver Billing bit is provided to indicate that bandwidth will be charged to the receiver. This bit may only be set when the receiver's bandwidth profile has been provided to the sender. The mechanisms or protocol extensions used to propagate bandwidth pro- files to senders are beyond the scope of this document. Weiss Expiration: May 1998 [Page 8] Internet Draft Cooperative Dropping Nov 1997 Because Receiver Billing requires a different profile and Priority Class based dropping may be applied because a profile has been exceeded, two types of Congestion Checks are possible: one for sender billing and one for receiver billing. The Receiver Billing bit is set in conjunction with the Congestion Check bit, to determine the congestion level for Receiver Billing packets. More details on pro- file based dropping and Receiver Billing will be provided later in this document. It is not clear at this time whether charging of a Congestion Check Response packet should be against the sender or receiver. It makes sense to charge Congestion Check Request to the sender when the Receiver Billing bit is reset and charge to the receiver when the Receiver Billing bit is set. However, if Congestion Check Response packets are charged based on the value of the Receiver Billing bit, then it may preclude concurrent sender and receiver charging within the same flow. This new use of the IPv4 TOS octet subsumes the previous functional- ity of this field as described in RFC1349[4] and similarly in IPv6[5]. Current usage of this field leaves little room for the coexistence of the original semantics with the semantics described in this document. This document concurs with Nichols et. al.[6] in requiring the remarking of packets between differentiated services networks and non-differentiated services networks. This will minimally require configuration support to demarcate differentiated services network boundaries. 4. Operational Model The operational model is based on the assumption that all traffic entering a network domain will be verified against a user or group profile. This profile has a number of potential components. One component is the allowable Delay Class(es). Another component may be the maximum bandwidth allocation. Maximum bandwidth allocation is particularly important for receiver billing to prevent excessive sending and overcharging. Another component may be a maximum bandwidth allocation for each given Priority Class. It is generally more useful to distribute bandwidth evenly among all Priority Classes. However, some policy models may choose to block or reserve certain Priority Classes for specific applications. Alternatively a policy may provide more bandwidth to a specific Priority Class to support specialized services such as premium service as described in Nichols[7]. Weiss Expiration: May 1998 [Page 9] Internet Draft Cooperative Dropping Nov 1997 4.1 Inter-Domain Edge devices An Inter-Domain Edge Device is defined in this document as a dif- ferentiated services capable device that is part of one differen- tiated services aware network and connected to another network domain. As service contracts between Inter-Domain Edge Devices usu- ally assume a statistical limit on the bandwidth between domains, the actual bandwidth may be higher or lower at any given time depending on the number of sessions active at the time. When bandwidth falls below the specified service contract, it can be beneficial to increase the Priority Class values on some or all pack- ets to take optimal advantage of service agreements. This can allow the packets a higher probability of getting through. However, there is only marginal benefit in increasing Priority Class values because the congestion check mechanism would be unaware of this action and would not increase the bandwidth to take full advantage of this option. If the service contract between the two domains is exceeded, the correct behavior must be to begin dropping packets in the lowest Priority Class. If the Priority Class values in packets were decre- mented, there would be potential anomalies between the Congestion Check algorithm and the original Priority Class values assigned to packets. 4.2. Between the End Station and Network Edge devices End Stations can choose to use the new TOS octet semantics or not. Network Edge devices should be aware of the End Station's TOS field semantics assumptions. If the Network Edge device knows that con- nected End Stations are performing TOS octet assignments themselves, then the Network Edge device must operate as a profile meter. Profile meters are forwarding devices that match each packet with the appropriate profile and verify that the TOS octet assignments are within the profile associated with the user, group, or application. Their behavior should be identical to that of Inter-Domain Edge Dev- ices. When packets are arriving below the bandwidth profile, profile meters may choose to increase the Priority Class of some or all pack- ets. If the packets arriving exceed a maximum bandwidth profile(if any), packets in all Priority Classes must be dropped. When Network Edge Devices receive packets destined to an End Station which does not support differentiated services and the bandwidth exceeds the capabilities of the End Station, the Network Edge device connected to the End Station should treat this as congestion and begin dropping low Priority Class packets. Weiss Expiration: May 1998 [Page 10] Internet Draft Cooperative Dropping Nov 1997 4.3. Bandwidth Scaling It is important for bandwidth to be able to grow and shrink across the Priority Classes. For example, a server may have a very large bandwidth profile, but the clients it connects to may have drasti- cally different bandwidth limits. Traditionally bandwidth grows until congestion occurs and is then cut back. So far, there has been detailed discussion about how congestion can be managed. However, there still needs to be a mechanism to determine what measure of bandwidth each end of a connection can tolerate. The best way to achieve this is to gradually increase the bandwidth across all Priority Classes up to the limit of the profile. In the past, when the receiver became incapable of keeping up with the sender, it usually began dropping packets. This mechanism needs to be refined so that a sender can be notified that a bandwidth limit has been reached. For this scenario, it is reasonable for a receiver to absorb all packets up to its capability. After that point, it begins to randomly drop packets. When a sender discovers that pack- ets are randomly being discarded, it will throttle its bandwidth back evenly across all Priority Classes. Some research will be required to determine the most appropriate bandwidth growth and cutback rates. 4.4. Receiver Billing Receiver based billing is a model that charges bandwidth and delay services to the receiver's profile rather than the sender's. This is an important capability because a service is usually bought or given. The cost of a telephone conversation is not typically shared between both parties. It is usually paid for by the caller or by the callee (an 800 number). There are three main issues with a Receiver Billing model. First, the sender must know what the profile limits of the receiver are. Second, the receiver must be charged for the traffic that fits the profile. Third, a receiver must be protected from excessive bandwidth sent by a malicious sender. As mentioned earlier, a sender should not be allowed to set the Receiver Billing bit unless it has received the sender's profile. The means for sending this profile is beyond the scope of this docu- ment. However, there are a number of alternate mechanisms including static configuration, a standardized profile header in the TCP options header, or extensions to application headers. In order for the receiver to be charged for the traffic, profiles must be defined in bi-directional terms. It is conceivable that a single profile is an aggregation of both the bandwidth sent and the Weiss Expiration: May 1998 [Page 11] Internet Draft Cooperative Dropping Nov 1997 bandwidth received. However, usually the amount of bandwidth sent is different from the bandwidth received. Therefore, independent accounting will be required at a minimum. Because traffic through a Domain Edge could be charged to a sender or a receiver, different accounting may be required for each. As mentioned earlier, the traffic sent and the traffic received are seldom symmetric. Therefore, when sender and receiver billing pro- files are specifically defined, a Priority Class dropper will need to be supported for each. By providing receiver based bandwidth manage- ment, a solution to the second issue is provided. The malicious sender is a sender that sends packets using the receiver's bandwidth. This is a difficult problem to solve because it requires all networks along the path between the sender and the receiver to be aware of the sender's right to send using receiver billing. This problem can really be broken up into three problems. One is malicious deterioration of the end receiver's bandwidth with no interest in the data. Another is malicious deterioration of intermediate ISP bandwidth with no interest in the data. The last is an attempt to charge bandwidth to the receiver without the receiver's consent with an interest in the data. The problem of dealing with users who are incorrectly attempting to reverse charges for services is fairly easy to solve. When a receiver determines that a packet is sent with Receiver Billing set and the receiver did not ask for it, the packet can be dropped. This is in effect denial of service. If a receiver determines it is worth receiving the packet, it can accept it. The issue of determining when Receiver Billing is and is not acceptable will need to be resolved when mechanisms are put in place for propagating profiles to senders. The first and second problems associated with malicious deterioration of bandwidth exists in the Internet today. A subset of these cases can be handled by terminating the session. For other cases, this problem will likely require a protocol between Network Edge Devices which propagate denial of service between the sender and receiver back to the source. This type of protocol is likely to be required irrespective of the Receiver Billing issue to resolve current possi- bilities for malicious Internet abuse. 5. Supported Service Models There are a number of services that have been suggested by the Dif- ferentiated Services Working Group. One type of service, described by Clark/Wroclawski[1], has been commonly referred to as Assured Weiss Expiration: May 1998 [Page 12] Internet Draft Cooperative Dropping Nov 1997 Service. The premise for this service is that packets can be marked as either "in" profile or "out" of profile. During congestion, the packets marked as out of profile are dropped. The proposals in this document support Assured Service directly using the same model. The only distinction is that this document provides layers or classes of assurance. As mentioned earlier, this proposal has the unique, addi- tional benefit of allowing cooperative congestion control between forwarding devices. Another service model, described by Van Jacobson[7], is called prem- ium service. This service provides preferential treatment for all traffic marked as premium. All unmarked traffic would continue to be treated as Best Effort. On the other hand, premium traffic would have a guarantee of delivery, provided that the traffic is within profile. All traffic exceeding the profile would be dropped by the profile meter. The mechanisms described in this document can satisfy the service described by Van through a combination of forced dropping at the profile meter and by setting packets to higher (or the highest) Priority Classes as congestion occurs. Premium Service also gives preferential access to all links over Best Effort traffic. This aspect could be accommodated using high Delay Classes. In addition, other service models can also be supported. When congestion occurs along the path of a flow, Congestion Check can be used to prevent the sending of all packets which fall below the current highest congestion level. This would leave additional bandwidth available in the profile that could be used to communicate with destinations experiencing less congestion or no congestion. This strategy provides very flexible and optimized communication throughout the Internet. Further, any combination of Priority Class values are possible. For connections that are considered less impor- tant but which must be kept alive, packets with higher Priority Class values could be used to keep the session alive while lower Priority Class values would be used to send data when congestion decreased enough to permit it. Another possible service model that provides bandwidth guarantees irrespective of the level of congestion could be supported through a combination of Congestion Checking and adaptive assignment of the Priority Class values by the End Station. Various combinations of the services described above can be supported as well. 6. Acknowledgments This document is a collection of ideas taken from David Clark, Van Jacobson, Zheng Wang, Kalevi Kilkki, Paul Ferguson and Kathleen Weiss Expiration: May 1998 [Page 13] Internet Draft Cooperative Dropping Nov 1997 Nichols. In addition the many opportunities described in this docu- ment were inspired by the issues surfaced on the Diff-Serv mailing list. 7. References [1] D. Clark and J. Wroclawski, "An Approach to Service Allocation in the Internet", Internet Draft , July 1997. [2] Z. Wang, "User-Share Differentiation (USD), Scalable bandwidth allocation for differentiated services", Internet Draft , May 1998. [3] S. Floyd, "TCP and Explicit Congestion Notification", ACM Computer Communications Review, Vol. 24 no. 5, pp. 10-23, October 1994. [4] RFC1349, "Type of Service in the Internet Protocol Suite", P. Almquist. July 1992. [5] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Internet Draft , November 1997. [6] Nichols, et. al., "Differentiated Services Operational Model and Definitions", Internet Draft , August 1998. [7] K. Nichols, V. Jacobson, L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", Internet Draft , May 1998. 8. Author's address Walter Weiss Lucent Technologies 300 Baker Avenue, Suite 100, Concord, MA USA 01742-2168 Email: wweiss@lucent.com Weiss Expiration: May 1998 [Page 14]