Transport Working Group                                         F. Baker
Internet-Draft                                                   J. Polk
Expires: August 11, 2005                                   Cisco Systems
                                                        February 7, 2005


   MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements
                   draft-ietf-tsvwg-mlef-concerns-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 11, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Baker & Polk             Expires August 11, 2005                [Page 1]


Internet-Draft           MLEF Considered Harmful           February 2005


   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.

   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 11, 2005                [Page 2]


Internet-Draft           MLEF Considered Harmful           February 2005


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 increases end to end delay, can add jitter, and
           can interfere with other traffic classes . . . . . . . . . 10
     2.5   MLEF induced loss triggers congestive collapse . . . . . . 11
     2.6   MLEF gives no preemption feedback notification . . . . . . 11

   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13

   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15

   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 17
     7.2   Informative References . . . . . . . . . . . . . . . . . . 17

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19

       Intellectual Property and Copyright Statements . . . . . . . . 20



















Baker & Polk             Expires August 11, 2005                [Page 3]


Internet-Draft           MLEF Considered Harmful           February 2005


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
   [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 Multilevel Precedence and Preemption
   [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 11, 2005                [Page 4]


Internet-Draft           MLEF Considered Harmful           February 2005


      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



Baker & Polk             Expires August 11, 2005                [Page 5]


Internet-Draft           MLEF Considered Harmful           February 2005


   important calls 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 five or more
   precedence levels, therefore five 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 11, 2005                [Page 6]


Internet-Draft           MLEF Considered Harmful           February 2005


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 11, 2005                [Page 7]


Internet-Draft           MLEF Considered Harmful           February 2005


   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 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 [RFC3951] (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 more bandwidth than G.729A,
   and less than 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



Baker & Polk             Expires August 11, 2005                [Page 8]


Internet-Draft           MLEF Considered Harmful           February 2005


   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 in the 20 ms
   mode.  However, when additional protection coding used (as in [ILBC])
   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.

   Telephone systems are generally provisioned with enough bandwidth for
   10% or less of their customers or potential users to simultaneously



Baker & Polk             Expires August 11, 2005                [Page 9]


Internet-Draft           MLEF Considered Harmful           February 2005


   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,
   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 increases end to end delay, can add jitter, and can interfere
    with other traffic classes

   The MLEF PHB depends on the build-up of a queue for its operation:
   when an MLEF queue becomes deep, traffic of the lowest precedence
   starts to experience loss.  This is contrary to the behavior of an EF
   [RFC3246] queue, which is either engineered with a priority scheduler
   or higher bandwidth than it actually uses in order to limit induced
   delay.  If the MLEF PHB is used in a priority queue, since it depends
   on maintanence of a queue, it can lock out traffic classes of lower
   priority for arbitrary periods.  If it depends on WFQ/WRR, it will
   force other classes to interleave, in cases waiting for a quantum of
   traffic from each competing class before sending the next voice
   packet, which affects voice quality for all call precedence levels.





Baker & Polk             Expires August 11, 2005               [Page 10]


Internet-Draft           MLEF Considered Harmful           February 2005


2.5  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
   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.6  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



Baker & Polk             Expires August 11, 2005               [Page 11]


Internet-Draft           MLEF Considered Harmful           February 2005


   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.

   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 11, 2005               [Page 12]


Internet-Draft           MLEF Considered Harmful           February 2005


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 11, 2005               [Page 13]


Internet-Draft           MLEF Considered Harmful           February 2005


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 11, 2005               [Page 14]


Internet-Draft           MLEF Considered Harmful           February 2005


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 11, 2005               [Page 15]


Internet-Draft           MLEF Considered Harmful           February 2005


6.  Acknowledgements

   This document was developed with the knowledge and input of many
   people, far too numerous to be mentioned by name.  They include at
   least Alan Duric, Christopher Eagan, Francois Le Faucheur, Haluk
   Keskiner, Julie Ann Connery, Marty Egan, Mike Pierce, Mike Tibodeau,
   Pete Babendreier, Rohan Mahy, Scott Bradner, Scott Morrison, and
   Subha Dhesikan.











































Baker & Polk             Expires August 11, 2005               [Page 16]


Internet-Draft           MLEF Considered Harmful           February 2005


7.  References

7.1  Normative References

   [I-D.pierce-ieprep-assured-service-arch]
              Pierce, M. and D. Choi, "Architecture for Assured Service
              Capabilities in Voice over IP",
              Internet-Draft draft-pierce-ieprep-assured-service-arch-02, January 2004
              .

   [I-D.pierce-ieprep-assured-service-req]
              Pierce, M. and D. Choi, "Requirements for Assured Service
              Capabilities in Voice over IP",
              Internet-Draft draft-pierce-ieprep-assured-service-req-02,
              January 2004.

   [I-D.silverman-diffserv-mlefphb]
              Silverman, S., "Multi-Level Expedited Forwarding Per Hop
              Behavior (MLEF PHB)",
              Internet-Draft draft-silverman-diffserv-mlefphb-03,
              February 2004.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

7.2  Informative 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,
              <http://www.sygnusdata.co.uk/white_papers/viola/netally_vo
              ip_sample_report_preliminary.pdf>.

   [G711.2]   ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July
              1999,
              <http://docbox.etsi.org/tiphon/tiphon/archives/1999/05-990
              7-Amsterdam/14TD113.pdf>.




Baker & Polk             Expires August 11, 2005               [Page 17]


Internet-Draft           MLEF Considered Harmful           February 2005


   [G711.3]   Nortel Networks, "Packet Loss and Packet Loss
              Concealment", 2000,
              <http://www.nortelnetworks.com/products/01/succession/es/c
              ollateral/tb_pktloss.pdf>.

   [G711.4]   Clark, A., "Modeling the Effects of Burt Packet Loss and
              Recency on Subjective Voice Quality", 2000,
              <http://www.telchemy.com/references/tech_papers/iptel2001.
              pdf>.

   [G711.5]   Cisco Systems, "Understanding Codecs: Complexity, Hardware
              Support, MOS, and Negotiation", 2003,
              <http://www.cisco.com/en/US/tech/tk652/tk701/technologies_
              tech_note09186a00800b6710.shtml#mos>.

   [I-D.ietf-sip-resource-priority]
              Schulzrinne, H. and J. Polk, "Communications Resource
              Priority for the Session Initiation Protocol (SIP)",
              Internet-Draft draft-ietf-sip-resource-priority-05,
              October 2004.

   [I-D.ietf-sipping-reason-header-for-preemption]
              Polk, J., "Extending the Session Initiation Protocol
              Reason Header for Preemption  Events",
              Internet-Draft draft-ietf-sipping-reason-header-for-preemption-02
              , August 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.

   [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.




Baker & Polk             Expires August 11, 2005               [Page 18]


Internet-Draft           MLEF Considered Harmful           February 2005


   [RFC3326]  Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, December 2002.

   [RFC3951]  Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W.
              and J. Linden, "Internet Low Bit Rate Codec (iLBC)",
              RFC 3951, December 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 11, 2005               [Page 19]


Internet-Draft           MLEF Considered Harmful           February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Baker & Polk             Expires August 11, 2005               [Page 20]