idnits 2.17.1 draft-ietf-tsvwg-mlef-concerns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2005) is 7018 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3326' is defined on line 653, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.pierce-ieprep-assured-service-arch' -- Possible downref: Normative reference to a draft: ref. 'I-D.pierce-ieprep-assured-service-req' -- Possible downref: Normative reference to a draft: ref. 'I-D.silverman-diffserv-mlefphb' ** Downref: Normative reference to an Informational RFC: RFC 2475 == Outdated reference: A later version (-10) exists of draft-ietf-sip-resource-priority-05 == Outdated reference: A later version (-04) exists of draft-ietf-sipping-reason-header-for-preemption-02 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group F. Baker 3 Internet-Draft J. Polk 4 Expires: August 11, 2005 Cisco Systems 5 February 7, 2005 7 MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements 8 draft-ietf-tsvwg-mlef-concerns-00 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 11, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The Defense Information Systems Agency of the United States 44 Department of Defense, with its contractors, has proposed a service 45 architecture for military (NATO and related agencies) telephone 46 systems. This is called the Assured Service, and is defined in two 47 documents: "Architecture for Assured Service Capabilities in Voice 48 over IP" and "Requirements for Assured Service Capabilities in Voice 49 over IP". Responding to these are three documents: "Extending the 50 Session Initiation Protocol Reason Header to account for Preemption 51 Events", "Communications Resource Priority for the Session Initiation 52 Protocol", and the "Multi-Level Expedited Forwarding Per Hop 53 Behavior" (MLEF PHB). MLEF, as currently defined, has serious 54 problems, which this draft seeks to discuss. 56 In short, our concern is that the Assured Service attempts to 57 implement MLPP in the Internet Architecture, but fails due to its 58 proposed implementation. It operates on the premise that packet 59 loss, rather than call loss, is sufficiently analogous to MLPP's 60 services for military use, and that if a caller cannot make himself 61 clear on the telephone, the caller will hang up and perform another 62 task. But the current TDM environment has trained the military 63 caller to expect that low call quality is a fault in the telephone 64 system, not an indication of the presence of higher priority calls. 65 The logical expectation is not that the caller will hang up and go 66 away; it is, especially under stressful conditions, that he or she 67 will hang up and call again. 69 MLEF does not satisfy the MLPP requirements for end user experience. 70 It can cause a breakdown in communications, increasing the likelihood 71 of grave consequences especially at times of crisis. 73 Table of Contents 75 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1 Multi-Level Preemption and Precedence . . . . . . . . . . 4 77 1.2 Multi-Level Expedited Forwarding . . . . . . . . . . . . . 6 79 2. The problem with MLEF . . . . . . . . . . . . . . . . . . . . 7 80 2.1 Codecs are not infinitely resilient to loss . . . . . . . 8 81 2.1.1 Issues with variable rate codecs . . . . . . . . . . . 9 82 2.2 MLEF induced packet loss severely impacts voice 83 quality for any affected class . . . . . . . . . . . . . . 9 84 2.3 Packet loss happens in tactical situations . . . . . . . . 10 85 2.4 MLEF increases end to end delay, can add jitter, and 86 can interfere with other traffic classes . . . . . . . . . 10 87 2.5 MLEF induced loss triggers congestive collapse . . . . . . 11 88 2.6 MLEF gives no preemption feedback notification . . . . . . 11 90 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 92 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 98 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 7.1 Normative References . . . . . . . . . . . . . . . . . . . 17 100 7.2 Informative References . . . . . . . . . . . . . . . . . . 17 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 104 Intellectual Property and Copyright Statements . . . . . . . . 20 106 1. Overview 108 The Defense Information Systems Agency of the United States 109 Department of Defense, with is contractors, has proposed a service 110 architecture for military (NATO and related agencies) telephone 111 systems. This is called the Assured Service, and is defined in two 112 documents: [I-D.pierce-ieprep-assured-service-arch] and 113 [I-D.pierce-ieprep-assured-service-req]. Responding to these are 114 three documents: [I-D.ietf-sipping-reason-header-for-preemption], 115 [I-D.ietf-sip-resource-priority], and 116 [I-D.silverman-diffserv-mlefphb] (MLEF PHB). MLEF, as currently 117 defined, has serious problems, which this draft seeks to discuss. 119 1.1 Multi-Level Preemption and Precedence 121 Let us discuss the problem that MLEF is intended to solve and the 122 architecture of the system. The Assured Service is designed as an IP 123 implementation of an existing ITU-T/NATO/DoD telephone system 124 architecture known as Multilevel Precedence and Preemption 125 [ITU.MLPP.1990][ANSI.MLPP.Spec][ANSI.MLPP.Supplement], or MLPP. MLPP 126 is an architecture for a prioritized call handling service such that 127 in times of emergency in the relevant NATO and DoD commands, the 128 relative importance of various kinds of communications is strictly 129 defined, allowing higher priority communication at the expense of 130 lower priority communications. These priorities, in descending 131 order, are: 133 Flash Override Override: used by the Commander in Chief, Secretary of 134 Defense, and Joint Chiefs of Staff, Commanders of combatant 135 commands when declaring the existence of a state of war. 136 Commanders of combatant commands when declaring Defense Condition 137 One or Defense Emergency or Air Defense Emergency and other 138 national authorities that the President may authorize in 139 conjunction with Worldwide Secure Voice Conferencing System 140 conferences. Flash Override Override cannot be preempted. 142 Flash Override: used by the Commander in Chief, Secretary of Defense, 143 and Joint Chiefs of Staff, Commanders of combatant commands when 144 declaring the existence of a state of war. Commanders of 145 combatant commands when declaring Defense Condition One or Defense 146 Emergency and other national authorities the President may 147 authorize. Flash Override cannot be preempted in the DSN. 149 Flash: reserved generally for telephone calls pertaining to command 150 and control of military forces essential to defense and 151 retaliation, critical intelligence essential to national survival, 152 conduct of diplomatic negotiations critical to the arresting or 153 limiting of hostilities, dissemination of critical civil alert 154 information essential to national survival, continuity of federal 155 government functions essential to national survival, fulfillment 156 of critical internal security functions essential to national 157 survival, or catastrophic events of national or international 158 significance. 160 Immediate: reserved generally for telephone calls pertaining to 161 situations that gravely affect the security of national and allied 162 forces, reconstitution of forces in a post-attack period, 163 intelligence essential to national security, conduct of diplomatic 164 negotiations to reduce or limit the threat of war, implementation 165 of federal government actions essential to national survival, 166 situations that gravely affect the internal security of the 167 nation, Civil Defense actions, disasters or events of extensive 168 seriousness having an immediate and detrimental effect on the 169 welfare of the population, or vital information having an 170 immediate effect on aircraft, spacecraft, or missile operations. 172 Priority: reserved generally for telephone calls requiring 173 expeditious action by called parties and/or furnishing essential 174 information for the conduct of government operations. 176 Routine: designation applied to those official government 177 communications that require rapid transmission by telephonic means 178 but do not require preferential handling. 180 The rule in MLPP is that more important calls override less important 181 calls when congestion occurs within a network. Station based 182 preemption is used when a more important call needs to be placed to 183 either party in an existing call. Trunk based preemption is used 184 when trunk bandwidth needs to be reallocated to facilitate a higher 185 precedence call over a given path in the network. In both station 186 and trunk based preemption scenarios, preempted parties are 187 positively notified, via preemption tone, that their call can no 188 longer be supported. The same preemption tone is used regardless of 189 whether calls are terminated for the purposes of station of trunk 190 based preemption. The remainder of this discussion focuses on trunk 191 based preemption issues. 193 MLPP is built as a proactive system in which callers must assign one 194 of the precedence levels listed above at call initiation; this 195 precedence level cannot be changed throughout that call. If 196 preemption is not assigned by a user at call initiation time, routine 197 is assumed. If there is end to end capacity to place a call, any 198 call may be placed at any time. However, when any trunk (in the 199 circuit world) or interface (in an IP world) reaches utilization 200 capacity, a choice must be made as to which call continues. The 201 system will seize the trunks or bandwidth necessary to place the more 202 important calls in preference to less important calls by preempting 203 an existing call (or calls) of lower precedence to permit a higher 204 precedence call to be placed. 206 More than one call might properly be preempted if more trunks or 207 bandwidth is necessary for this higher precedence call. A video call 208 (perhaps of 384 KBPS, or 6 trunks) competing with several lower 209 precedence voice calls is a good example of this situation. 211 1.2 Multi-Level Expedited Forwarding 213 The [RFC2475] defines a capability for systems to identify traffic 214 they originate or qualify using [RFC2474]. These DSCP values trigger 215 the application of a policy in the network called a Per Hop Behavior, 216 or PHB. 218 The Multi-Level Expedited Forwarding (MLEF) PHB builds on the 219 [RFC3246] PHB (EF). Like EF, it posits that sufficient bandwidth is 220 present to support the service, and therefore places correctly marked 221 traffic into a low jitter queue, with a form of traffic policing at 222 the ingress to the queue. It differs from EF in two fundamental 223 ways. First, while there is generally assumed to be enough capacity 224 for VoIP traffic in the general case, the probability of having 225 insufficient capacity is sufficiently high to force network 226 administration to think carefully about whose traffic is most 227 important. To deal with this issue, the Assured Service architecture 228 not only identifies call precedence in the SIP/H.323 signalling to 229 enable an endpoint to preempt a call in favor of a higher precedence 230 incoming call, but MLEF marks VoIP traffic with code points 231 corresponding to the various MLPP precedence levels, and assigns them 232 different loss probabilities comparable to the behavior of the 233 [RFC2597] (AF). Existing non-IP MLPP networks have five or more 234 precedence levels, therefore five or more different MLEF code points 235 are required. It is assumed that an SLA will be required between 236 MLPP networks with differing numbers of precedence levels. 238 The intended effect is to permit - during congestion - a higher 239 precedence call to reduce the call quality of lower precedence calls 240 by dropping packets that exceed the total rate assigned to the 241 aggregate. It assumes that the loss rate is in fact nominal, and 242 that the users of lower precedence calls will simply go away as their 243 call quality fades. There is no other active feedback like that in 244 Section 1.1 to users who experience this loss of quality. 246 2. The problem with MLEF 248 The problem with MLEF, in a nutshell, is that it implements a 249 different service than MLPP, and that service has a very different 250 effect. The basic function of MLPP is to cause some number of lower 251 precedence calls to be dropped, or not started, so that 253 o higher precedence calls get placed, 255 o remaining lower precedence calls stay at acceptable quality, 257 o parties on pre-empted calls receive clear feedback on why their 258 call is being dropped (e.g., due to pre-emption as opposed to 259 circuit failure or other trivial cause). 261 MLEF fails to achieve the second and third functions. Instead, MLEF 262 can create a situation where all lower precedence calls experience 263 reduced call quality, potentially becoming unintelligible, and thus 264 destroying most of the usefulness of the communications system. 265 [G711.2] considers a MOS/PESQ score below 3.6 to be "poor" and a MOS 266 score below 3.1 to be "bad". The effect of MLEF is to disrupt voice 267 quality (reduce MOS/PESQ scores below 3.6 and at times below 3.1) on 268 all calls at routine precedence and potentially other calls at the 269 Priority or Immediate precedence, causing their users to be unable to 270 conduct their business or to do so with increased difficulty. 272 The logical expectation of a military caller, who understands the 273 behavior of MLPP, who cannot place a call or whose call is clearly 274 preempted is that he or she will perform another task and retry the 275 call later. The logical expectation of a military caller is that 276 he/she either gets good service or no service, because that is what 277 he/she has gotten in the existing TDM environment. The logical 278 expectation of a caller who experiences degraded voice quality is not 279 that they will hang up and go away, however. 281 In a time of crisis, the rational expectation is that the caller will 282 attempt to continue using the service or will hang up and call again 283 fairly quickly since they have no (MLPP-like) audible signal 284 indicating that the call was preempted by lack of available 285 bandwidth, and since they are operating under stress. For all lower 286 precedence calls, in the worst case, MLEF creates congestive collapse 287 - 100% utilization with zero effectiveness of communication for all 288 calls of a certain class. 290 Within MLEF, there is a belief that congestion occurrences will 291 always be brief in time; that it is better to have momentary 292 interruptions in service (similar to cellular or mobile phone 293 service) than out right preemption events (where both parties are 294 informed of the event audibly). No accounting or analysis has been 295 done to show that congestion events in times of military emergency 296 will be milliseconds to seconds long (analogous to cell phone quality 297 service), verses seconds to minutes (or even hours) long. The 298 existence of the MLPP service itself argues against this assumption: 299 if congestion was routinely momentary, then returning a fast busy and 300 expecting the calling party to call again, or simply queuing the call 301 until bandwidth became available, would be sufficient. 303 It is possible that, in an MLEF world, the commander might give the 304 order to "launch the fleet", but the fleet be unable to place the 305 order to "raise the anchor", as the latter order is given by a more 306 junior officer whose call precedence level may be disrupted. 308 It is clear that MLEF falls short and does not satisfy the MLPP 309 requirements for end user experience. MLEF will cause breakdown in 310 communications increasing the likelihood of grave consequences 311 especially at times of crisis. 313 Following subsections provide more detail on the impacts of packet 314 loss, codec issues and users' experience in and MLEF environment. 316 2.1 Codecs are not infinitely resilient to loss 318 The issue of concern results from the nature of real time traffic and 319 the effect of packet loss on known codecs. 321 One of the world's most common and well known codecs is G.711; it is 322 the codec used in standard circuit switch voice networks throughout 323 the PSTN. Numerous [G711.1][G711.2][G711.3][G711.4][G711.5] exist 324 depicting the effect of traffic loss on G.711 in ATM and IP packet 325 switched environments. While they differ in the details of their 326 findings, they generally agree that a random packet loss rate on the 327 order of 1-2% has a serious effect on voice quality, and higher 328 packet loss rates essentially place speech beyond comprehension by 329 the human listener. [G711.2] states that "the packet loss rate of 5% 330 seems to be almost the quality threshold (low boundary) of the "poor" 331 QoS class", which is to say the boundary between 'poor', where most 332 users find it disruptive, and 'bad', where all users find it 333 disruptive. 335 The resilience of G.729A and the [RFC3951] (ILBC) have also been 336 studied in [ILBC]. G.729A is another common VoIP codec, which 337 provides a lower amount of generated bandwidth and has better 338 resilience than G.711. ILBC generates more bandwidth than G.729A, 339 and less than G.711, but includes with that traffic a variable 340 quantity of forward error correction data, which can be used in lossy 341 environments to further improve voice quality in the presence of 342 loss. However, like G.711, these codecs also have limits on their 343 resilience. In the presence of 15% loss, the ILBC reportedly loses 344 enough voice quality that it can be difficult to understand what it 345 said. [G711.3] indicates that G.729 systems drop to a MOS score 346 below 3.0 with 2% packet loss. 348 2.1.1 Issues with variable rate codecs 350 G.729A and ILBC are examples of codecs which increase their 351 throughput to carry forward error correction data when they are 352 experiencing loss, a behavior referred to as "protection coding". 353 This behavior - increasing offered load in situations where offered 354 load may be triggering the problem - has an additional characteristic 355 that will interact poorly with MLEF. Understand that this is not a 356 criticism of the codecs per se; as far as we know, the codecs are 357 fine codecs. But this characteristic has a serious side-effect in 358 MLEF environments. 360 ILBC generates on the order of 31.2 KBPS of traffic in the 20 ms 361 mode. However, when additional protection coding used (as in [ILBC]) 362 in response to RTCP reports of a high level of loss, it increases its 363 Forward Error Correction, expanding the bandwidth of the packets to 364 meet acceptable voice quality to the receiving end. This protective 365 feature of iLBC is the result of piggybacking additional copies of 366 what it calls critical voice samples in other packets of other voice 367 samples (this is how the bandwidth increases - the effective payload 368 for a series of packets increases by a factor of 2). ILBC with 369 protection will increase its bandwidth requirements from the no 370 protection rate of 31.2 KBPS to 35.6 KBPS in times of a packet loss 371 rate of 26%. ILBC further increases its bandwidth requirement to 372 45.6 KBPS (to raise a PESQ-MOS value from 2.38 to 3.0) in times where 373 30% of packets are lost. 375 Thus, in any situation where a codec using protection coding 376 experiences difficulty due to lack of available bandwidth in an MLEF 377 service discipline, it can be expected to compound the difficulty. 379 2.2 MLEF induced packet loss severely impacts voice quality for any 380 affected class 382 While MLEF protects flows for highest priority calls, it worsens the 383 quality of service for all others. In a case where a large number of 384 higher precedence calls are being placed, such as at the "Flash" 385 level, this may include calls at lower but still non-routine 386 precedences, such as at the "Priority" level. 388 Telephone systems are generally provisioned with enough bandwidth for 389 10% or less of their customers or potential users to simultaneously 390 place calls. In a small office with 250 persons in it, this means 391 that the ISDN access to the PSTN is often a single T-1 line, and for 392 larger offices a corresponding level of bandwidth is generally 393 available. If an Internet connection has enough bandwidth for 20 394 VoIP sessions, the simultaneous placement of 20 calls represents a 395 100% load that should be carried with at most nominal loss, but 21 396 calls represents a ~5% overload, and ~5% data loss may be expected to 397 be distributed evenly over all calls; in other words, each call may 398 be expected to experience 5% loss. Thus, in such a case, the 399 placement of a single call may be the difference between 20 routine 400 calls operating normally and 21 calls operating with a seriously 401 degraded MOS score. In larger installations, corresponding ratios 402 apply. In a network which protects some calls from loss, there is no 403 magic: the total loss will be the same, and will be concentrated on 404 those calls least protected. 406 In emergency situations, especially in command and control centers 407 such as the US Pentagon, a situation where the center is under attack 408 or where the command is given to go to war can easily result in a 409 high percentage of the senior staff needing to place such calls. 410 Under such cases, even calls at the "Priority" or "Immediate" 411 precedence level would be adversely affected. 413 2.3 Packet loss happens in tactical situations 415 MLEF is being considered in tactical deployments such as WIN-T, and 416 faces the same kinds of concerns. In radio environments, and in 417 mobile networks, a certain level of loss is normal. However, 418 bandwidth is usually limited. Any tactical situation which would 419 place a large number of soldiers on the telephone simultaneously can 420 be expected to result in congestive loss. 422 2.4 MLEF increases end to end delay, can add jitter, and can interfere 423 with other traffic classes 425 The MLEF PHB depends on the build-up of a queue for its operation: 426 when an MLEF queue becomes deep, traffic of the lowest precedence 427 starts to experience loss. This is contrary to the behavior of an EF 428 [RFC3246] queue, which is either engineered with a priority scheduler 429 or higher bandwidth than it actually uses in order to limit induced 430 delay. If the MLEF PHB is used in a priority queue, since it depends 431 on maintanence of a queue, it can lock out traffic classes of lower 432 priority for arbitrary periods. If it depends on WFQ/WRR, it will 433 force other classes to interleave, in cases waiting for a quantum of 434 traffic from each competing class before sending the next voice 435 packet, which affects voice quality for all call precedence levels. 437 2.5 MLEF induced loss triggers congestive collapse 439 The fundamental effect of non-negligible loss of traffic in a 440 precedence class, therefore, is the disruption of all calls in that 441 precedence class, especially if protection-based codecs are in use. 442 This is, definitively, congestive collapse - 100% utilization with 443 zero effectiveness of communication for all calls of a certain class. 445 When a call experiences congestion when MLEF is in use, the ILBC 446 codec (taking one example analyzed in [ILBC] ) will start replicating 447 voice samples to include in other RTP payload packets, increasing the 448 bandwidth required for just that one call. This will further congest 449 the network, causing ILBC to add more voice samples to other RTP 450 payloads in other packets, further congesting the network. If a 451 substantial number of calls in the same MLPP precedence level are 452 performing this same codec protection function, the network bandwidth 453 grows exponentially within that MLPP precedence level. This will 454 cause, as mentioned before, all calling parties within a MLPP level 455 to experience packet loss, disrupting or destroying the ability to 456 communicate, with no preemption indication to any one party. 457 Existing behavior would be to hang up and try again, because MLPP 458 domain personnel are trained to recognize a preemption event and know 459 that the system is experiencing congestion due to some emergency. 460 There is no such indication, in an MLEF environment, so it is 461 reasonable to conclude that some or most calling parties will merely 462 hang up and try again. The problem at this point is that MLEF does 463 not (and cannot) provide feedback to application layer multimedia 464 signaling protocols to inform those protocols that a new call attempt 465 is not such a good idea; nor will there be anything to prevent a new 466 call from being set up to the previous party (provided there is 467 enough bandwidth available for signaling packets within the network 468 through some mechanism such as CBWFQ. With the new call set up, and 469 the network too congested to transmit enough media packets 470 end-to-end, no calls within that MLPP level will function properly, 471 and no one will receive the proper feedback as to what is occurring. 473 2.6 MLEF gives no preemption feedback notification 475 One attribute of the current MLPP service is that when a user's call 476 is preempted, the user is told, via an audible signal, of the event. 477 In such a case, the user can be expected to find other tasks for a 478 period of time and try again later. However, that is not a typical 479 human response - especially the response of a human in an agitated 480 state of mind - to a noisy connection. The more typical response is 481 to hope that the circuit will improve as others vacate their calls, 482 or to hang up and call again in an attempt to "get another circuit". 483 As such, the MLEF PHB fails to signal to the user that sufficient 484 bandwidth is simply not available to support his call, so that the 485 user can be expected to respond to the situation in a different way. 486 There are three ways this can fail: 488 o If a call is placed when there is insufficient bandwidth, the 489 system does not give definitive feedback, 491 o If another call is set-up into a priority level that is at 492 capacity, the bandwidth for all calls at that level (and below) 493 are reduced, and there is no signal to any call parties indicating 494 this 496 o If policy is changed during a call, resulting in the necessity to 497 drop one or more calls, there is no signal. 499 A measurement-based counterpart to the MLPP procedure has been 500 proposed, in which calls experiencing significant loss treat this as 501 a signal from the network and drop the call. But if all calls at a 502 precedence level are experiencing loss, many and perhaps all calls at 503 the precedence level would be dropped by this heuristic; if many 504 calls are vying for service, the effect would be rolling call 505 disruption - a set of calls would be established, additional calls 506 would be established disrupting that class of calls, many of the 507 disrupted calls would drop, and then more of the competing calls 508 would be established - only to be disrupted when the first set 509 redialed. 511 This procedure would still require a forward looking mechanism, for 512 each precedence class, to disallow new calls, to prevent this rolling 513 call disruption. 515 3. Recommendation 517 Considering the nature of real-time traffic and the effect of packet 518 loss on known codecs, it is clear that degradation of voice quality 519 in an MLEF environment for lower precedence calls will be severe if 520 no form of bandwidth and routing-aware Call Admission Control (CAC) 521 is used. Even the advances in codec technology do not fix the 522 problem, and could make it worse. 524 The authors cannot in good conscience recommend its deployment as it 525 stands. It will protect the calls placed by senior officers and 526 constitutional officials, but it does not provide the same service 527 that MLPP provides to those who respond to their orders, and 528 therefore seriously and negatively affects the likelihood that those 529 orders will be efficiently disseminated and carried out. Considering 530 the environment this proposed mechanism is for, the potential 531 attractiveness for other environments, and that the effects could and 532 should compound upon themselves, the worst case scenario includes 533 loss of life due to communications failure. Nothing done here should 534 enhance this possibility. 536 4. IANA Considerations 538 IANA is not called upon to do anything with this document. 540 If this document is published as an RFC, the RFC Editor should remove 541 this section during the process of publication. 543 5. Security Considerations 545 This document exposes a problem, but it proposes neither a protocol 546 nor a procedure. As such, it does not directly affect the security 547 of the Internet. 549 6. Acknowledgements 551 This document was developed with the knowledge and input of many 552 people, far too numerous to be mentioned by name. They include at 553 least Alan Duric, Christopher Eagan, Francois Le Faucheur, Haluk 554 Keskiner, Julie Ann Connery, Marty Egan, Mike Pierce, Mike Tibodeau, 555 Pete Babendreier, Rohan Mahy, Scott Bradner, Scott Morrison, and 556 Subha Dhesikan. 558 7. References 560 7.1 Normative References 562 [I-D.pierce-ieprep-assured-service-arch] 563 Pierce, M. and D. Choi, "Architecture for Assured Service 564 Capabilities in Voice over IP", 565 . 567 [I-D.pierce-ieprep-assured-service-req] 568 Pierce, M. and D. Choi, "Requirements for Assured Service 569 Capabilities in Voice over IP", 570 Internet-Draft draft-pierce-ieprep-assured-service-req-02, 571 January 2004. 573 [I-D.silverman-diffserv-mlefphb] 574 Silverman, S., "Multi-Level Expedited Forwarding Per Hop 575 Behavior (MLEF PHB)", 576 Internet-Draft draft-silverman-diffserv-mlefphb-03, 577 February 2004. 579 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 580 and W. Weiss, "An Architecture for Differentiated 581 Services", RFC 2475, December 1998. 583 7.2 Informative References 585 [ANSI.MLPP.Spec] 586 American National Standards Institute, "Telecommunications 587 - Integrated Services Digital Network (ISDN) - Multi-Level 588 Precedence and Preemption (MLPP) Service Capability", 589 ANSI T1.619-1992 (R1999), 1992. 591 [ANSI.MLPP.Supplement] 592 American National Standards Institute, "MLPP Service 593 Domain Cause Value Changes", ANSI ANSI T1.619a-1994 594 (R1999), 1990. 596 [G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, 597 . 600 [G711.2] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July 601 1999, 602 . 605 [G711.3] Nortel Networks, "Packet Loss and Packet Loss 606 Concealment", 2000, 607 . 610 [G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and 611 Recency on Subjective Voice Quality", 2000, 612 . 615 [G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware 616 Support, MOS, and Negotiation", 2003, 617 . 620 [I-D.ietf-sip-resource-priority] 621 Schulzrinne, H. and J. Polk, "Communications Resource 622 Priority for the Session Initiation Protocol (SIP)", 623 Internet-Draft draft-ietf-sip-resource-priority-05, 624 October 2004. 626 [I-D.ietf-sipping-reason-header-for-preemption] 627 Polk, J., "Extending the Session Initiation Protocol 628 Reason Header for Preemption Events", 629 Internet-Draft draft-ietf-sipping-reason-header-for-preemption-02 630 , August 2004. 632 [ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over 633 Networks With Bursty Packet Loss", July 2003. 635 [ITU.MLPP.1990] 636 International Telecommunications Union, "Multilevel 637 Precedence and Preemption Service (MLPP)", 638 ITU-T Recommendation I.255.3, 1990. 640 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 641 "Definition of the Differentiated Services Field (DS 642 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 643 1998. 645 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, 646 "Assured Forwarding PHB Group", RFC 2597, June 1999. 648 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 649 J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, 650 "An Expedited Forwarding PHB (Per-Hop Behavior)", 651 RFC 3246, March 2002. 653 [RFC3326] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason 654 Header Field for the Session Initiation Protocol (SIP)", 655 RFC 3326, December 2002. 657 [RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W. 658 and J. Linden, "Internet Low Bit Rate Codec (iLBC)", 659 RFC 3951, December 2004. 661 Authors' Addresses 663 Fred Baker 664 Cisco Systems 665 1121 Via Del Rey 666 Santa Barbara, California 93117 667 USA 669 Phone: +1-408-526-4257 670 Fax: +1-413-473-2403 671 Email: fred@cisco.com 673 James Polk 674 Cisco Systems 675 2200 East President George Bush Turnpike 676 Richardson, Texas 75082 677 USA 679 Phone: +1-469-255-5208 680 Email: jmpolk@cisco.com 682 Intellectual Property Statement 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Disclaimer of Validity 708 This document and the information contained herein are provided on an 709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 711 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 712 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 713 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Copyright Statement 718 Copyright (C) The Internet Society (2005). This document is subject 719 to the rights, licenses and restrictions contained in BCP 78, and 720 except as set forth therein, the authors retain all their rights. 722 Acknowledgment 724 Funding for the RFC Editor function is currently provided by the 725 Internet Society.