Transport Working Group F. Baker Internet-Draft J. Polk Expires: August 15, 2004 Cisco Systems February 15, 2004 MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements draft-baker-tsvwg-mlef-concerns-01 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 will expire on August 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Defense Information Systems Agency of the United States Department of Defense, with its contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: "Architecture for Assured Service Capabilities in Voice over IP" and "Requirements for Assured Service Capabilities in Voice over IP". Responding to these are three documents: "Extending the Session Initiation Protocol Reason Header to account for Preemption Events", "Communications Resource Priority for the Session Initiation Protocol", and the "Multi-Level Expedited Forwarding Per Hop Behavior" (MLEF PHB). MLEF, as currently defined, has serious problems, which this draft seeks to discuss. Baker & Polk Expires August 15, 2004 [Page 1] Internet-Draft MLEF Considered Harmful February 2004 In short, our concern is that the Assured Service attempts to implement MLPP in the Internet Architecture, but fails due to its proposed implementation. It operates on the premise that packet loss, rather than call loss, is sufficiently analogous to MLPP's services for military use, and that if a caller cannot make himself clear on the telephone, the caller will hang up and perform another task. But the current TDM environment has trained the military caller to expect that low call quality is a fault in the telephone system, not an indication of the presence of higher priority calls. The logical expectation is not that the caller will hang up and go away; it is, especially under stressful conditions, that he or she will hang up and call again. MLEF does not satisfy the MLPP requirements for end user experience. It can cause a breakdown in communications, increasing the likelihood of grave consequences especially at times of crisis. Baker & Polk Expires August 15, 2004 [Page 2] Internet-Draft MLEF Considered Harmful February 2004 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Multi-Level Preemption and Precedence . . . . . . . . . . . 4 1.2 Multi-Level Expedited Forwarding . . . . . . . . . . . . . . 6 2. The problem with MLEF . . . . . . . . . . . . . . . . . . . 7 2.1 Codecs are not infinitely resilient to loss . . . . . . . . 8 2.1.1 Issues with variable rate codecs . . . . . . . . . . . . . . 9 2.2 MLEF induced packet loss severely impacts voice quality for any affected class . . . . . . . . . . . . . . . . . . . 9 2.3 Packet loss happens in tactical situations . . . . . . . . . 10 2.4 MLEF induced loss triggers congestive collapse . . . . . . . 10 2.5 MLEF gives no preemption feedback notification . . . . . . . 11 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . 20 Baker & Polk Expires August 15, 2004 [Page 3] Internet-Draft MLEF Considered Harmful February 2004 1. Overview The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: [I-D.pierce-ieprep-assured-service-arch] and [I-D.pierce-ieprep-assured-service-req]. Responding to these are three documents: [I-D.ietf-sipping-reason-header-for-preemption], [I-D.ietf-sip-resource-priority], and the [I-D.silverman-diffserv-mlefphb] (MLEF PHB). MLEF, as currently defined, has serious problems, which this draft seeks to discuss. 1.1 Multi-Level Preemption and Precedence Let us discuss the problem that MLEF is intended to solve and the architecture of the system. The Assured Service is designed as an IP implementation of an existing ITU-T/NATO/DoD telephone system architecture known as [ITU.MLPP.1990][ANSI.MLPP.Spec][ANSI.MLPP.Supplement], or MLPP. MLPP is an architecture for a prioritized call handling service such that in times of emergency in the relevant NATO and DoD commands, the relative importance of various kinds of communications is strictly defined, allowing higher priority communication at the expense of lower priority communications. These priorities, in descending order, are: Flash Override Override: used by the Commander in Chief, Secretary of Defense, and Joint Chiefs of Staff, Commanders of combatant commands when declaring the existence of a state of war. Commanders of combatant commands when declaring Defense Condition One or Defense Emergency or Air Defense Emergency and other national authorities that the President may authorize in conjunction with Worldwide Secure Voice Conferencing System conferences. Flash Override Override cannot be preempted. Flash Override: used by the Commander in Chief, Secretary of Defense, and Joint Chiefs of Staff, Commanders of combatant commands when declaring the existence of a state of war. Commanders of combatant commands when declaring Defense Condition One or Defense Emergency and other national authorities the President may authorize. Flash Override cannot be preempted in the DSN. Flash: reserved generally for telephone calls pertaining to command and control of military forces essential to defense and retaliation, critical intelligence essential to national survival, conduct of diplomatic negotiations critical to the arresting or limiting of hostilities, dissemination of critical civil alert Baker & Polk Expires August 15, 2004 [Page 4] Internet-Draft MLEF Considered Harmful February 2004 information essential to national survival, continuity of federal government functions essential to national survival, fulfillment of critical internal security functions essential to national survival, or catastrophic events of national or international significance. Immediate: reserved generally for telephone calls pertaining to situations that gravely affect the security of national and allied forces, reconstitution of forces in a post-attack period, intelligence essential to national security, conduct of diplomatic negotiations to reduce or limit the threat of war, implementation of federal government actions essential to national survival, situations that gravely affect the internal security of the nation, Civil Defense actions, disasters or events of extensive seriousness having an immediate and detrimental effect on the welfare of the population, or vital information having an immediate effect on aircraft, spacecraft, or missile operations. Priority: reserved generally for telephone calls requiring expeditious action by called parties and/or furnishing essential information for the conduct of government operations. Routine: designation applied to those official government communications that require rapid transmission by telephonic means but do not require preferential handling. The rule in MLPP is that more important calls override less important calls when congestion occurs within a network. Station based preemption is used when a more important call needs to be placed to either party in an existing call. Trunk based preemption is used when trunk bandwidth needs to be reallocated to facilitate a higher precedence call over a given path in the network. In both station and trunk based preemption scenarios, preempted parties are positively notified, via preemption tone, that their call can no longer be supported. The same preemption tone is used regardless of whether calls are terminated for the purposes of station of trunk based preemption. The remainder of this discussion focuses on trunk based preemption issues. MLPP is built as a proactive system in which callers must assign one of the precedence levels listed above at call initiation; this precedence level cannot be changed throughout that call. If preemption is not assigned by a user at call initiation time, routine is assumed. If there is end to end capacity to place a call, any call may be placed at any time. However, when any trunk (in the circuit world) or interface (in an IP world) reaches utilization capacity, a choice must be made as to which call continues. The system will seize the trunks or bandwidth necessary to place the more important calls Baker & Polk Expires August 15, 2004 [Page 5] Internet-Draft MLEF Considered Harmful February 2004 in preference to less important calls by preempting an existing call (or calls) of lower precedence to permit a higher precedence call to be placed. More than one call might properly be preempted if more trunks or bandwidth is necessary for this higher precedence call. A video call (perhaps of 384 KBPS, or 6 trunks) competing with several lower precedence voice calls is a good example of this situation. 1.2 Multi-Level Expedited Forwarding The [RFC2475] defines a capability for systems to identify traffic they originate or qualify using [RFC2474]. These DSCP values trigger the application of a policy in the network called a Per Hop Behavior, or PHB. The Multi-Level Expedited Forwarding (MLEF) PHB builds on the [RFC3246] PHB (EF). Like EF, it posits that sufficient bandwidth is present to support the service, and therefore places correctly marked traffic into a low jitter queue, with a form of traffic policing at the ingress to the queue. It differs from EF in two fundamental ways. First, while there is generally assumed to be enough capacity for VoIP traffic in the general case, the probability of having insufficient capacity is sufficiently high to force network administration to think carefully about whose traffic is most important. To deal with this issue, the Assured Service architecture not only identifies call precedence in the SIP/H.323 signalling to enable an endpoint to preempt a call in favor of a higher precedence incoming call, but MLEF marks VoIP traffic with code points corresponding to the various MLPP precedence levels, and assigns them different loss probabilities comparable to the behavior of the [RFC2597] (AF). Existing non-IP MLPP networks have 5 or more precedence levels, therefore 5 or more different MLEF code points are required. It is assumed that an SLA will be required between MLPP networks with differing numbers of precedence levels. The intended effect is to permit - during congestion - a higher precedence call to reduce the call quality of lower precedence calls by dropping packets that exceed the total rate assigned to the aggregate. It assumes that the loss rate is in fact nominal, and that the users of lower precedence calls will simply go away as their call quality fades. There is no other active feedback like that in Section 1.1 to users who experience this loss of quality. Baker & Polk Expires August 15, 2004 [Page 6] Internet-Draft MLEF Considered Harmful February 2004 2. The problem with MLEF The problem with MLEF, in a nutshell, is that it implements a different service than MLPP, and that service has a very different effect. The basic function of MLPP is to cause some number of lower precedence calls to be dropped, or not started, so that o higher precedence calls get placed, o remaining lower precedence calls stay at acceptable quality, o parties on pre-empted calls receive clear feedback on why their call is being dropped (e.g., due to pre-emption as opposed to circuit failure or other trivial cause). MLEF fails to achieve the second and third functions. Instead, MLEF can create a situation where all lower precedence calls experience reduced call quality, potentially becoming unintelligible, and thus destroying most of the usefulness of the communications system. [G711.2] considers a MOS/PESQ score below 3.6 to be "poor" and a MOS score below 3.1 to be "bad". The effect of MLEF is to disrupt voice quality (reduce MOS/PESQ scores below 3.6 and at times below 3.1) on all calls at routine precedence and potentially other calls at the Priority or Immediate precedence, causing their users to be unable to conduct their business or to do so with increased difficulty. The logical expectation of a military caller, who understands the behavior of MLPP, who cannot place a call or whose call is clearly preempted is that he or she will perform another task and retry the call later. The logical expectation of a military caller is that he/ she either gets good service or no service, because that is what he/ she has gotten in the existing TDM environment. The logical expectation of a caller who experiences degraded voice quality is not that they will hang up and go away, however. In a time of crisis, the rational expectation is that the caller will attempt to continue using the service or will hang up and call again fairly quickly since they have no (MLPP-like) audible signal indicating that the call was preempted by lack of available bandwidth, and since they are operating under stress. For all lower precedence calls, in the worst case, MLEF creates congestive collapse - 100% utilization with zero effectiveness of communication for all calls of a certain class. Within MLEF, there is a belief that congestion occurrences will always be brief in time; that it is better to have momentary interruptions in service (similar to cellular or mobile phone service) than out right preemption events (where both parties are Baker & Polk Expires August 15, 2004 [Page 7] Internet-Draft MLEF Considered Harmful February 2004 informed of the event audibly). No accounting or analysis has been done to show that congestion events in times of military emergency will be milliseconds to seconds long (analogous to cell phone quality service), verses seconds to minutes (or even hours) long. The existence of the MLPP service itself argues against this assumption: if congestion was routinely momentary, then returning a fast busy and expecting the calling party to call again, or simply queuing the call until bandwidth became available, would be sufficient. It is possible that, in an MLEF world, the commander might give the order to "launch the fleet", but the fleet be unable to place the order to "raise the anchor", as the latter order is given by a more junior officer whose call precedence level may be disrupted. It is reported that such an occurrence once happened in the Swedish Navy; due to a communication failure, a ship ordered to immediately put to sea took its pier with it. It is clear that MLEF falls short and does not satisfy the MLPP requirements for end user experience. MLEF will cause breakdown in communications increasing the likelihood of grave consequences especially at times of crisis. Following subsections provide more detail on the impacts of packet loss, codec issues and users' experience in and MLEF environment. 2.1 Codecs are not infinitely resilient to loss The issue of concern results from the nature of real time traffic and the effect of packet loss on known codecs. One of the world's most common and well known codecs is G.711; it is the codec used in standard circuit switch voice networks throughout the PSTN. Numerous [G711.1][G711.2][G711.3][G711.4][G711.5] exist depicting the effect of traffic loss on G.711 in ATM and IP packet switched environments. While they differ in the details of their findings, they generally agree that a random packet loss rate on the order of 1-2% has a serious effect on voice quality, and higher packet loss rates essentially place speech beyond comprehension by the human listener. [G711.2] states that "the packet loss rate of 5% seems to be almost the quality threshold (low boundary) of the "poor" QoS class, which is to say the boundary between "poor", where most users find it disruptive, and "bad", where all users find it disruptive. The resilience of G.729A and the [I-D.ietf-avt-ilbc-codec] (ILBC) have also been studied in [ILBC]. G.729A is another common VoIP codec, which provides a lower amount of generated bandwidth and has better resilience than G.711. ILBC generates a bandwidth between Baker & Polk Expires August 15, 2004 [Page 8] Internet-Draft MLEF Considered Harmful February 2004 G.729A and G.711, but includes with that traffic a variable quantity of forward error correction data, which can be used in lossy environments to further improve voice quality in the presence of loss. However, like G.711, these codecs also have limits on their resilience. In the presence of 15% loss, the ILBC reportedly loses enough voice quality that it can be difficult to understand what it said. [G711.3] indicates that G.729 systems drop to a MOS score below 3.0 with 2% packet loss. 2.1.1 Issues with variable rate codecs G.729A and ILBC are examples of codecs which increase their throughput to carry forward error correction data when they are experiencing loss, a behavior referred to as "protection coding". This behavior - increasing offered load in situations where offered load may be triggering the problem - has an additional characteristic that will interact poorly with MLEF. Understand that this is not a criticism of the codecs per se; as far as we know, the codecs are fine codecs. But this characteristic has a serious side-effect in MLEF environments. ILBC generates on the order of 31.2 KBPS of traffic under normal situations. However, in response to RTCP reports of a high level of loss, it increases its Forward Error Correction, expanding the bandwidth of the packets to meet acceptable voice quality to the receiving end. This protective feature of iLBC is the result of piggybacking additional copies of what it calls critical voice samples in other packets of other voice samples (this is how the bandwidth increases - the effective payload for a series of packets increases by a factor of 2). ILBC with protection will increase its bandwidth requirements from the no protection rate of 31.2 KBPS to 35.6 KBPS in times of a packet loss rate of 26%. ILBC further increases its bandwidth requirement to 45.6 KBPS (to raise a PESQ-MOS value from 2.38 to 3.0) in times where 30% of packets are lost. Thus, in any situation where a codec using protection coding experiences difficulty due to lack of available bandwidth in an MLEF service discipline, it can be expected to compound the difficulty. 2.2 MLEF induced packet loss severely impacts voice quality for any affected class While MLEF protects flows for highest priority calls, it worsens the quality of service for all others. In a case where a large number of higher precedence calls are being placed, such as at the "Flash" level, this may include calls at lower but still non-routine precedences, such as at the "Priority" level. Baker & Polk Expires August 15, 2004 [Page 9] Internet-Draft MLEF Considered Harmful February 2004 Telephone systems are generally provisioned with enough bandwidth for 10% or less of their customers or potential users to simultaneously place calls. In a small office with 250 persons in it, this means that the ISDN access to the PSTN is often a single T-1 line, and for larger offices a corresponding level of bandwidth is generally available. If an Internet connection has enough bandwidth for 20 VoIP sessions, the simultaneous placement of 20 calls represents a 100% load that should be carried with at most nominal loss, but 21 calls represents a ~5% overload, and ~5% data loss may be expected to be distributed evenly over all calls; in other words, each call may be expected to experience 5% loss. Thus, in such a case, the placement of a single call may be the difference between 20 routine calls operating normally and 21 calls operating with a seriously degraded MOS score. In larger installations, corresponding ratios apply. In a network which protects some calls from loss, there is no magic: the total loss will be the same, and will be concentrated on those calls least protected. In emergency situations, especially in command and control centers such as the US Pentagon, a situation where the center is under attack or where the command is given to go to war can easily result in a high percentage of the senior staff needing to place such calls. Under such cases, even calls at the "Priority" or "Immediate" precedence level would be adversely affected. 2.3 Packet loss happens in tactical situations MLEF is being considered in tactical deployments such as WIN-T, and faces the same kinds of concerns. In radio environments, and in mobile networks, a certain level of loss is normal. However, due to the heavy demands of encryption, bandwidth is usually limited. Any tactical situation which would place a large number of soldiers on the telephone simultaneously can be expected to result in congestive loss. 2.4 MLEF induced loss triggers congestive collapse The fundamental effect of non-negligible loss of traffic in a precedence class, therefore, is the disruption of all calls in that precedence class, especially if protection-based codecs are in use. This is, definitively, congestive collapse - 100% utilization with zero effectiveness of communication for all calls of a certain class. When a call experiences congestion when MLEF is in use, the ILBC codec (taking one example analyzed in [ILBC] ) will start replicating voice samples to include in other RTP payload packets, increasing the bandwidth required for just that one call. This will further congest the network, causing ILBC to add more voice samples to other RTP Baker & Polk Expires August 15, 2004 [Page 10] Internet-Draft MLEF Considered Harmful February 2004 payloads in other packets, further congesting the network. If a substantial number of calls in the same MLPP precedence level are performing this same codec protection function, the network bandwidth grows exponentially within that MLPP precedence level. This will cause, as mentioned before, all calling parties within a MLPP level to experience packet loss, disrupting or destroying the ability to communicate, with no preemption indication to any one party. Existing behavior would be to hang up and try again, because MLPP domain personnel are trained to recognize a preemption event and know that the system is experiencing congestion due to some emergency. There is no such indication, in an MLEF environment, so it is reasonable to conclude that some or most calling parties will merely hang up and try again. The problem at this point is that MLEF does not (and cannot) provide feedback to application layer multimedia signaling protocols to inform those protocols that a new call attempt is not such a good idea; nor will there be anything to prevent a new call from being set up to the previous party (provided there is enough bandwidth available for signaling packets within the network through some mechanism such as CBWFQ. With the new call set up, and the network too congested to transmit enough media packets end-to-end, no calls within that MLPP level will function properly, and no one will receive the proper feedback as to what is occurring. 2.5 MLEF gives no preemption feedback notification One attribute of the current MLPP service is that when a user's call is preempted, the user is told, via an audible signal, of the event. In such a case, the user can be expected to find other tasks for a period of time and try again later. However, that is not a typical human response - especially the response of a human in an agitated state of mind - to a noisy connection. The more typical response is to hope that the circuit will improve as others vacate their calls, or to hang up and call again in an attempt to "get another circuit". As such, the MLEF PHB fails to signal to the user that sufficient bandwidth is simply not available to support his call, so that the user can be expected to respond to the situation in a different way. There are three ways this can fail: o If a call is placed when there is insufficient bandwidth, the system does not give definitive feedback, o If another call is set-up into a priority level that is at capacity, the bandwidth for all calls at that level (and below) are reduced, and there is no signal to any call parties indicating this o If policy is changed during a call, resulting in the necessity to drop one or more calls, there is no signal. Baker & Polk Expires August 15, 2004 [Page 11] Internet-Draft MLEF Considered Harmful February 2004 A measurement-based counterpart to the MLPP procedure has been proposed, in which calls experiencing significant loss treat this as a signal from the network and drop the call. But if all calls at a precedence level are experiencing loss, many and perhaps all calls at the precedence level would be dropped by this heuristic; if many calls are vying for service, the effect would be rolling call disruption - a set of calls would be established, additional calls would be established disrupting that class of calls, many of the disrupted calls would drop, and then more of the competing calls would be established - only to be disrupted when the first set redialed. This procedure would still require a forward looking mechanism, for each precedence class, to disallow new calls, to prevent this rolling call disruption. Baker & Polk Expires August 15, 2004 [Page 12] Internet-Draft MLEF Considered Harmful February 2004 3. Recommendation Considering the nature of real-time traffic and the effect of packet loss on known codecs, it is clear that degradation of voice quality in an MLEF environment for lower precedence calls will be severe if no form of bandwidth and routing-aware Call Admission Control (CAC) is used. Even the advances in codec technology do not fix the problem, and could make it worse. The authors cannot in good conscience recommend its deployment as it stands. It will protect the calls placed by senior officers and constitutional officials, but it does not provide the same service that MLPP provides to those who respond to their orders, and therefore seriously and negatively affects the likelihood that those orders will be efficiently disseminated and carried out. Considering the environment this proposed mechanism is for, the potential attractiveness for other environments, and that the effects could and should compound upon themselves, the worst case scenario includes loss of life due to communications failure. Nothing done here should enhance this possibility. Baker & Polk Expires August 15, 2004 [Page 13] Internet-Draft MLEF Considered Harmful February 2004 4. IANA Considerations IANA is not called upon to do anything with this document. If this document is published as an RFC, the RFC Editor should remove this section during the process of publication. Baker & Polk Expires August 15, 2004 [Page 14] Internet-Draft MLEF Considered Harmful February 2004 5. Security Considerations This document exposes a problem, but it proposes neither a protocol nor a procedure. As such, it does not directly affect the security of the Internet. Baker & Polk Expires August 15, 2004 [Page 15] Internet-Draft MLEF Considered Harmful February 2004 6. Acknowledgements This document was developed with the knowledge and input of many people, far too numerous to be mentioned by name. Key contributors of thoughts include, however, Francois Le Faucheur, Rohan Mahy, Scott Bradner, Scott Morrison, and Subha Dhesikan. Mike Tibodeau, Haluk Keskiner and Pete Babendreier made particularly valuable contributions. Christopher Eagan, Marty Egan, and Mike Pierce also commented extensively. Baker & Polk Expires August 15, 2004 [Page 16] Internet-Draft MLEF Considered Harmful February 2004 References [ANSI.MLPP.Spec] American National Standards Institute, "Telecommunications - Integrated Services Digital Network (ISDN) - Multi-Level Precedence and Preemption (MLPP) Service Capability", ANSI T1.619-1992 (R1999), 1992. [ANSI.MLPP.Supplement] American National Standards Institute, "MLPP Service Domain Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990. [G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, . [G711.2] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July 1999, . [G711.3] Nortel Networks, "Packet Loss and Packet Loss Concealment", 2000, . [G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and Recency on Subjective Voice Quality", 2000, . [G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware Support, MOS, and Negotiation", 2003, . [I-D.ietf-avt-ilbc-codec] Andersen, S., "Internet Low Bit Rate Codec", draft-ietf-avt-ilbc-codec-04 (work in progress), December 2003. [I-D.ietf-sip-resource-priority] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", draft-ietf-sip-resource-priority-01 (work in progress), July 2003. [I-D.ietf-sipping-reason-header-for-preemption] Polk, J., "Extending the Session Initiation Protocol Reason Header for Preemption Events", Baker & Polk Expires August 15, 2004 [Page 17] Internet-Draft MLEF Considered Harmful February 2004 draft-ietf-sipping-reason-header-for-preemption-00 (work in progress), January 2004. [I-D.pierce-ieprep-assured-service-arch] Pierce, M. and D. Choi, "Architecture for Assured Service Capabilities in Voice over IP", draft-pierce-ieprep-assured-service-arch-02 (work in progress), January 2004. [I-D.pierce-ieprep-assured-service-req] Pierce, M. and D. Choi, "Requirements for Assured Service Capabilities in Voice over IP", draft-pierce-ieprep-assured-service-req-02 (work in progress), January 2004. [I-D.silverman-diffserv-mlefphb] Silverman, S., "Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB)", draft-silverman-diffserv-mlefphb-03 (work in progress), February 2004. [ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over Networks With Bursty Packet Loss", July 2003. [ITU.MLPP.1990] International Telecommunications Union, "Multilevel Precedence and Preemption Service (MLPP)", ITU-T Recommendation I.255.3, 1990. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3326] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. Baker & Polk Expires August 15, 2004 [Page 18] Internet-Draft MLEF Considered Harmful February 2004 Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Phone: +1-469-255-5208 EMail: jmpolk@cisco.com Baker & Polk Expires August 15, 2004 [Page 19] Internet-Draft MLEF Considered Harmful February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Baker & Polk Expires August 15, 2004 [Page 20] Internet-Draft MLEF Considered Harmful February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baker & Polk Expires August 15, 2004 [Page 21]