idnits 2.17.1 draft-baker-tsvwg-mlef-concerns-02.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 16. -- 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 == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 17) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 36 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 (October 5, 2004) is 7141 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 657, 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-04 == Outdated reference: A later version (-04) exists of draft-ietf-sipping-reason-header-for-preemption-02 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Working Group F. Baker 2 Internet-Draft J. Polk 3 Expires: April 5, 2005 Cisco Systems 4 October 5, 2004 6 MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements 7 draft-baker-tsvwg-mlef-concerns-02 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 5, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 The Defense Information Systems Agency of the United States 43 Department of Defense, with its contractors, has proposed a service 44 architecture for military (NATO and related agencies) telephone 45 systems. This is called the Assured Service, and is defined in two 46 documents: "Architecture for Assured Service Capabilities in Voice 47 over IP" and "Requirements for Assured Service Capabilities in Voice 48 over IP". Responding to these are three documents: "Extending the 49 Session Initiation Protocol Reason Header to account for Preemption 50 Events", "Communications Resource Priority for the Session Initiation 51 Protocol", and the "Multi-Level Expedited Forwarding Per Hop 52 Behavior" (MLEF PHB). MLEF, as currently defined, has serious 53 problems, which this draft seeks to discuss. 55 In short, our concern is that the Assured Service attempts to 56 implement MLPP in the Internet Architecture, but fails due to its 57 proposed implementation. It operates on the premise that packet 58 loss, rather than call loss, is sufficiently analogous to MLPP's 59 services for military use, and that if a caller cannot make himself 60 clear on the telephone, the caller will hang up and perform another 61 task. But the current TDM environment has trained the military 62 caller to expect that low call quality is a fault in the telephone 63 system, not an indication of the presence of higher priority calls. 64 The logical expectation is not that the caller will hang up and go 65 away; it is, especially under stressful conditions, that he or she 66 will hang up and call again. 68 MLEF does not satisfy the MLPP requirements for end user experience. 69 It can cause a breakdown in communications, increasing the likelihood 70 of grave consequences especially at times of crisis. 72 Table of Contents 74 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1 Multi-Level Preemption and Precedence . . . . . . . . . . 4 76 1.2 Multi-Level Expedited Forwarding . . . . . . . . . . . . . 6 78 2. The problem with MLEF . . . . . . . . . . . . . . . . . . . . 7 79 2.1 Codecs are not infinitely resilient to loss . . . . . . . 8 80 2.1.1 Issues with variable rate codecs . . . . . . . . . . . 9 81 2.2 MLEF induced packet loss severely impacts voice 82 quality for any affected class . . . . . . . . . . . . . . 9 83 2.3 Packet loss happens in tactical situations . . . . . . . . 10 84 2.4 MLEF increases end to end delay, can add jitter, and 85 can interfere with other traffic classes . . . . . . . . . 10 86 2.5 MLEF induced loss triggers congestive collapse . . . . . . 11 87 2.6 MLEF gives no preemption feedback notification . . . . . . 11 89 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 91 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 99 7.2 Informative References . . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 103 Intellectual Property and Copyright Statements . . . . . . . . 20 105 1. Overview 107 The Defense Information Systems Agency of the United States 108 Department of Defense, with is contractors, has proposed a service 109 architecture for military (NATO and related agencies) telephone 110 systems. This is called the Assured Service, and is defined in two 111 documents: [I-D.pierce-ieprep-assured-service-arch] and 112 [I-D.pierce-ieprep-assured-service-req]. Responding to these are 113 three documents: [I-D.ietf-sipping-reason-header-for-preemption], 114 [I-D.ietf-sip-resource-priority], and 115 [I-D.silverman-diffserv-mlefphb] (MLEF PHB). MLEF, as currently 116 defined, has serious problems, which this draft seeks to discuss. 118 1.1 Multi-Level Preemption and Precedence 120 Let us discuss the problem that MLEF is intended to solve and the 121 architecture of the system. The Assured Service is designed as an IP 122 implementation of an existing ITU-T/NATO/DoD telephone system 123 architecture known as Multilevel Precedence and Preemption 124 [ITU.MLPP.1990][ANSI.MLPP.Spec][ANSI.MLPP.Supplement], or MLPP. MLPP 125 is an architecture for a prioritized call handling service such that 126 in times of emergency in the relevant NATO and DoD commands, the 127 relative importance of various kinds of communications is strictly 128 defined, allowing higher priority communication at the expense of 129 lower priority communications. These priorities, in descending 130 order, are: 132 Flash Override Override: used by the Commander in Chief, Secretary of 133 Defense, and Joint Chiefs of Staff, Commanders of combatant 134 commands when declaring the existence of a state of war. 135 Commanders of combatant commands when declaring Defense Condition 136 One or Defense Emergency or Air Defense Emergency and other 137 national authorities that the President may authorize in 138 conjunction with Worldwide Secure Voice Conferencing System 139 conferences. Flash Override Override cannot be preempted. 141 Flash Override: used by the Commander in Chief, Secretary of Defense, 142 and Joint Chiefs of Staff, Commanders of combatant commands when 143 declaring the existence of a state of war. Commanders of 144 combatant commands when declaring Defense Condition One or Defense 145 Emergency and other national authorities the President may 146 authorize. Flash Override cannot be preempted in the DSN. 148 Flash: reserved generally for telephone calls pertaining to command 149 and control of military forces essential to defense and 150 retaliation, critical intelligence essential to national survival, 151 conduct of diplomatic negotiations critical to the arresting or 152 limiting of hostilities, dissemination of critical civil alert 153 information essential to national survival, continuity of federal 154 government functions essential to national survival, fulfillment 155 of critical internal security functions essential to national 156 survival, or catastrophic events of national or international 157 significance. 159 Immediate: reserved generally for telephone calls pertaining to 160 situations that gravely affect the security of national and allied 161 forces, reconstitution of forces in a post-attack period, 162 intelligence essential to national security, conduct of diplomatic 163 negotiations to reduce or limit the threat of war, implementation 164 of federal government actions essential to national survival, 165 situations that gravely affect the internal security of the 166 nation, Civil Defense actions, disasters or events of extensive 167 seriousness having an immediate and detrimental effect on the 168 welfare of the population, or vital information having an 169 immediate effect on aircraft, spacecraft, or missile operations. 171 Priority: reserved generally for telephone calls requiring 172 expeditious action by called parties and/or furnishing essential 173 information for the conduct of government operations. 175 Routine: designation applied to those official government 176 communications that require rapid transmission by telephonic means 177 but do not require preferential handling. 179 The rule in MLPP is that more important calls override less important 180 calls when congestion occurs within a network. Station based 181 preemption is used when a more important call needs to be placed to 182 either party in an existing call. Trunk based preemption is used 183 when trunk bandwidth needs to be reallocated to facilitate a higher 184 precedence call over a given path in the network. In both station 185 and trunk based preemption scenarios, preempted parties are 186 positively notified, via preemption tone, that their call can no 187 longer be supported. The same preemption tone is used regardless of 188 whether calls are terminated for the purposes of station of trunk 189 based preemption. The remainder of this discussion focuses on trunk 190 based preemption issues. 192 MLPP is built as a proactive system in which callers must assign one 193 of the precedence levels listed above at call initiation; this 194 precedence level cannot be changed throughout that call. If 195 preemption is not assigned by a user at call initiation time, routine 196 is assumed. If there is end to end capacity to place a call, any 197 call may be placed at any time. However, when any trunk (in the 198 circuit world) or interface (in an IP world) reaches utilization 199 capacity, a choice must be made as to which call continues. The 200 system will seize the trunks or bandwidth necessary to place the more 201 important calls in preference to less important calls by preempting 202 an existing call (or calls) of lower precedence to permit a higher 203 precedence call to be placed. 205 More than one call might properly be preempted if more trunks or 206 bandwidth is necessary for this higher precedence call. A video call 207 (perhaps of 384 KBPS, or 6 trunks) competing with several lower 208 precedence voice calls is a good example of this situation. 210 1.2 Multi-Level Expedited Forwarding 212 The [RFC2475] defines a capability for systems to identify traffic 213 they originate or qualify using [RFC2474]. These DSCP values trigger 214 the application of a policy in the network called a Per Hop Behavior, 215 or PHB. 217 The Multi-Level Expedited Forwarding (MLEF) PHB builds on the 218 [RFC3246] PHB (EF). Like EF, it posits that sufficient bandwidth is 219 present to support the service, and therefore places correctly marked 220 traffic into a low jitter queue, with a form of traffic policing at 221 the ingress to the queue. It differs from EF in two fundamental 222 ways. First, while there is generally assumed to be enough capacity 223 for VoIP traffic in the general case, the probability of having 224 insufficient capacity is sufficiently high to force network 225 administration to think carefully about whose traffic is most 226 important. To deal with this issue, the Assured Service architecture 227 not only identifies call precedence in the SIP/H.323 signalling to 228 enable an endpoint to preempt a call in favor of a higher precedence 229 incoming call, but MLEF marks VoIP traffic with code points 230 corresponding to the various MLPP precedence levels, and assigns them 231 different loss probabilities comparable to the behavior of the 232 [RFC2597] (AF). Existing non-IP MLPP networks have five or more 233 precedence levels, therefore five or more different MLEF code points 234 are required. It is assumed that an SLA will be required between 235 MLPP networks with differing numbers of precedence levels. 237 The intended effect is to permit - during congestion - a higher 238 precedence call to reduce the call quality of lower precedence calls 239 by dropping packets that exceed the total rate assigned to the 240 aggregate. It assumes that the loss rate is in fact nominal, and 241 that the users of lower precedence calls will simply go away as their 242 call quality fades. There is no other active feedback like that in 243 Section 1.1 to users who experience this loss of quality. 245 2. The problem with MLEF 247 The problem with MLEF, in a nutshell, is that it implements a 248 different service than MLPP, and that service has a very different 249 effect. The basic function of MLPP is to cause some number of lower 250 precedence calls to be dropped, or not started, so that 252 o higher precedence calls get placed, 254 o remaining lower precedence calls stay at acceptable quality, 256 o parties on pre-empted calls receive clear feedback on why their 257 call is being dropped (e.g., due to pre-emption as opposed to 258 circuit failure or other trivial cause). 260 MLEF fails to achieve the second and third functions. Instead, MLEF 261 can create a situation where all lower precedence calls experience 262 reduced call quality, potentially becoming unintelligible, and thus 263 destroying most of the usefulness of the communications system. 264 [G711.2] considers a MOS/PESQ score below 3.6 to be "poor" and a MOS 265 score below 3.1 to be "bad". The effect of MLEF is to disrupt voice 266 quality (reduce MOS/PESQ scores below 3.6 and at times below 3.1) on 267 all calls at routine precedence and potentially other calls at the 268 Priority or Immediate precedence, causing their users to be unable to 269 conduct their business or to do so with increased difficulty. 271 The logical expectation of a military caller, who understands the 272 behavior of MLPP, who cannot place a call or whose call is clearly 273 preempted is that he or she will perform another task and retry the 274 call later. The logical expectation of a military caller is that he/ 275 she either gets good service or no service, because that is what he/ 276 she has gotten in the existing TDM environment. The logical 277 expectation of a caller who experiences degraded voice quality is not 278 that they will hang up and go away, however. 280 In a time of crisis, the rational expectation is that the caller will 281 attempt to continue using the service or will hang up and call again 282 fairly quickly since they have no (MLPP-like) audible signal 283 indicating that the call was preempted by lack of available 284 bandwidth, and since they are operating under stress. For all lower 285 precedence calls, in the worst case, MLEF creates congestive collapse 286 - 100% utilization with zero effectiveness of communication for all 287 calls of a certain class. 289 Within MLEF, there is a belief that congestion occurrences will 290 always be brief in time; that it is better to have momentary 291 interruptions in service (similar to cellular or mobile phone 292 service) than out right preemption events (where both parties are 293 informed of the event audibly). No accounting or analysis has been 294 done to show that congestion events in times of military emergency 295 will be milliseconds to seconds long (analogous to cell phone quality 296 service), verses seconds to minutes (or even hours) long. The 297 existence of the MLPP service itself argues against this assumption: 298 if congestion was routinely momentary, then returning a fast busy and 299 expecting the calling party to call again, or simply queuing the call 300 until bandwidth became available, would be sufficient. 302 It is possible that, in an MLEF world, the commander might give the 303 order to "launch the fleet", but the fleet be unable to place the 304 order to "raise the anchor", as the latter order is given by a more 305 junior officer whose call precedence level may be disrupted. 307 It is clear that MLEF falls short and does not satisfy the MLPP 308 requirements for end user experience. MLEF will cause breakdown in 309 communications increasing the likelihood of grave consequences 310 especially at times of crisis. 312 Following subsections provide more detail on the impacts of packet 313 loss, codec issues and users' experience in and MLEF environment. 315 2.1 Codecs are not infinitely resilient to loss 317 The issue of concern results from the nature of real time traffic and 318 the effect of packet loss on known codecs. 320 One of the world's most common and well known codecs is G.711; it is 321 the codec used in standard circuit switch voice networks throughout 322 the PSTN. Numerous [G711.1][G711.2][G711.3][G711.4][G711.5] exist 323 depicting the effect of traffic loss on G.711 in ATM and IP packet 324 switched environments. While they differ in the details of their 325 findings, they generally agree that a random packet loss rate on the 326 order of 1-2% has a serious effect on voice quality, and higher 327 packet loss rates essentially place speech beyond comprehension by 328 the human listener. [G711.2] states that "the packet loss rate of 5% 329 seems to be almost the quality threshold (low boundary) of the "poor" 330 QoS class", which is to say the boundary between 'poor', where most 331 users find it disruptive, and 'bad', where all users find it 332 disruptive. 334 The resilience of G.729A and the [I-D.ietf-avt-ilbc-codec] (ILBC) 335 have also been studied in [ILBC]. G.729A is another common VoIP 336 codec, which provides a lower amount of generated bandwidth and has 337 better resilience than G.711. ILBC generates more bandwidth than 338 G.729A, and less than G.711, but includes with that traffic a 339 variable quantity of forward error correction data, which can be used 340 in lossy environments to further improve voice quality in the 341 presence of loss. However, like G.711, these codecs also have limits 342 on their resilience. In the presence of 15% loss, the ILBC 343 reportedly loses enough voice quality that it can be difficult to 344 understand what it said. [G711.3] indicates that G.729 systems drop 345 to a MOS score below 3.0 with 2% packet loss. 347 2.1.1 Issues with variable rate codecs 349 G.729A and ILBC are examples of codecs which increase their 350 throughput to carry forward error correction data when they are 351 experiencing loss, a behavior referred to as "protection coding". 352 This behavior - increasing offered load in situations where offered 353 load may be triggering the problem - has an additional characteristic 354 that will interact poorly with MLEF. Understand that this is not a 355 criticism of the codecs per se; as far as we know, the codecs are 356 fine codecs. But this characteristic has a serious side-effect in 357 MLEF environments. 359 ILBC generates on the order of 31.2 KBPS of traffic in the 20 ms 360 mode. However, when additional protection coding used (as in [ILBC]) 361 in response to RTCP reports of a high level of loss, it increases its 362 Forward Error Correction, expanding the bandwidth of the packets to 363 meet acceptable voice quality to the receiving end. This protective 364 feature of iLBC is the result of piggybacking additional copies of 365 what it calls critical voice samples in other packets of other voice 366 samples (this is how the bandwidth increases - the effective payload 367 for a series of packets increases by a factor of 2). ILBC with 368 protection will increase its bandwidth requirements from the no 369 protection rate of 31.2 KBPS to 35.6 KBPS in times of a packet loss 370 rate of 26%. ILBC further increases its bandwidth requirement to 371 45.6 KBPS (to raise a PESQ-MOS value from 2.38 to 3.0) in times where 372 30% of packets are lost. 374 Thus, in any situation where a codec using protection coding 375 experiences difficulty due to lack of available bandwidth in an MLEF 376 service discipline, it can be expected to compound the difficulty. 378 2.2 MLEF induced packet loss severely impacts voice quality for any 379 affected class 381 While MLEF protects flows for highest priority calls, it worsens the 382 quality of service for all others. In a case where a large number of 383 higher precedence calls are being placed, such as at the "Flash" 384 level, this may include calls at lower but still non-routine 385 precedences, such as at the "Priority" level. 387 Telephone systems are generally provisioned with enough bandwidth for 388 10% or less of their customers or potential users to simultaneously 389 place calls. In a small office with 250 persons in it, this means 390 that the ISDN access to the PSTN is often a single T-1 line, and for 391 larger offices a corresponding level of bandwidth is generally 392 available. If an Internet connection has enough bandwidth for 20 393 VoIP sessions, the simultaneous placement of 20 calls represents a 394 100% load that should be carried with at most nominal loss, but 21 395 calls represents a ~5% overload, and ~5% data loss may be expected to 396 be distributed evenly over all calls; in other words, each call may 397 be expected to experience 5% loss. Thus, in such a case, the 398 placement of a single call may be the difference between 20 routine 399 calls operating normally and 21 calls operating with a seriously 400 degraded MOS score. In larger installations, corresponding ratios 401 apply. In a network which protects some calls from loss, there is no 402 magic: the total loss will be the same, and will be concentrated on 403 those calls least protected. 405 In emergency situations, especially in command and control centers 406 such as the US Pentagon, a situation where the center is under attack 407 or where the command is given to go to war can easily result in a 408 high percentage of the senior staff needing to place such calls. 409 Under such cases, even calls at the "Priority" or "Immediate" 410 precedence level would be adversely affected. 412 2.3 Packet loss happens in tactical situations 414 MLEF is being considered in tactical deployments such as WIN-T, and 415 faces the same kinds of concerns. In radio environments, and in 416 mobile networks, a certain level of loss is normal. However, 417 bandwidth is usually limited. Any tactical situation which would 418 place a large number of soldiers on the telephone simultaneously can 419 be expected to result in congestive loss. 421 2.4 MLEF increases end to end delay, can add jitter, and can interfere 422 with other traffic classes 424 The MLEF PHB depends on the build-up of a queue for its operation: 425 when an MLEF queue becomes deep, traffic of the lowest precedence 426 starts to experience loss. This is contrary to the behavior of an EF 427 [RFC3246] queue, which is either engineered with a priority scheduler 428 or higher bandwidth than it actually uses in order to limit induced 429 delay. If the MLEF PHB is used in a priority queue, since it depends 430 on maintanence of a queue, it can lock out traffic classes of lower 431 priority for arbitrary periods. If it depends on WFQ/WRR, it will 432 force other classes to interleave, in cases waiting for a quantum of 433 traffic from each competing class before sending the next voice 434 packet, which affects voice quality for all call precedence levels. 436 2.5 MLEF induced loss triggers congestive collapse 438 The fundamental effect of non-negligible loss of traffic in a 439 precedence class, therefore, is the disruption of all calls in that 440 precedence class, especially if protection-based codecs are in use. 441 This is, definitively, congestive collapse - 100% utilization with 442 zero effectiveness of communication for all calls of a certain class. 444 When a call experiences congestion when MLEF is in use, the ILBC 445 codec (taking one example analyzed in [ILBC] ) will start replicating 446 voice samples to include in other RTP payload packets, increasing the 447 bandwidth required for just that one call. This will further congest 448 the network, causing ILBC to add more voice samples to other RTP 449 payloads in other packets, further congesting the network. If a 450 substantial number of calls in the same MLPP precedence level are 451 performing this same codec protection function, the network bandwidth 452 grows exponentially within that MLPP precedence level. This will 453 cause, as mentioned before, all calling parties within a MLPP level 454 to experience packet loss, disrupting or destroying the ability to 455 communicate, with no preemption indication to any one party. 456 Existing behavior would be to hang up and try again, because MLPP 457 domain personnel are trained to recognize a preemption event and know 458 that the system is experiencing congestion due to some emergency. 459 There is no such indication, in an MLEF environment, so it is 460 reasonable to conclude that some or most calling parties will merely 461 hang up and try again. The problem at this point is that MLEF does 462 not (and cannot) provide feedback to application layer multimedia 463 signaling protocols to inform those protocols that a new call attempt 464 is not such a good idea; nor will there be anything to prevent a new 465 call from being set up to the previous party (provided there is 466 enough bandwidth available for signaling packets within the network 467 through some mechanism such as CBWFQ. With the new call set up, and 468 the network too congested to transmit enough media packets 469 end-to-end, no calls within that MLPP level will function properly, 470 and no one will receive the proper feedback as to what is occurring. 472 2.6 MLEF gives no preemption feedback notification 474 One attribute of the current MLPP service is that when a user's call 475 is preempted, the user is told, via an audible signal, of the event. 476 In such a case, the user can be expected to find other tasks for a 477 period of time and try again later. However, that is not a typical 478 human response - especially the response of a human in an agitated 479 state of mind - to a noisy connection. The more typical response is 480 to hope that the circuit will improve as others vacate their calls, 481 or to hang up and call again in an attempt to "get another circuit". 482 As such, the MLEF PHB fails to signal to the user that sufficient 483 bandwidth is simply not available to support his call, so that the 484 user can be expected to respond to the situation in a different way. 485 There are three ways this can fail: 487 o If a call is placed when there is insufficient bandwidth, the 488 system does not give definitive feedback, 490 o If another call is set-up into a priority level that is at 491 capacity, the bandwidth for all calls at that level (and below) 492 are reduced, and there is no signal to any call parties indicating 493 this 495 o If policy is changed during a call, resulting in the necessity to 496 drop one or more calls, there is no signal. 498 A measurement-based counterpart to the MLPP procedure has been 499 proposed, in which calls experiencing significant loss treat this as 500 a signal from the network and drop the call. But if all calls at a 501 precedence level are experiencing loss, many and perhaps all calls at 502 the precedence level would be dropped by this heuristic; if many 503 calls are vying for service, the effect would be rolling call 504 disruption - a set of calls would be established, additional calls 505 would be established disrupting that class of calls, many of the 506 disrupted calls would drop, and then more of the competing calls 507 would be established - only to be disrupted when the first set 508 redialed. 510 This procedure would still require a forward looking mechanism, for 511 each precedence class, to disallow new calls, to prevent this rolling 512 call disruption. 514 3. Recommendation 516 Considering the nature of real-time traffic and the effect of packet 517 loss on known codecs, it is clear that degradation of voice quality 518 in an MLEF environment for lower precedence calls will be severe if 519 no form of bandwidth and routing-aware Call Admission Control (CAC) 520 is used. Even the advances in codec technology do not fix the 521 problem, and could make it worse. 523 The authors cannot in good conscience recommend its deployment as it 524 stands. It will protect the calls placed by senior officers and 525 constitutional officials, but it does not provide the same service 526 that MLPP provides to those who respond to their orders, and 527 therefore seriously and negatively affects the likelihood that those 528 orders will be efficiently disseminated and carried out. Considering 529 the environment this proposed mechanism is for, the potential 530 attractiveness for other environments, and that the effects could and 531 should compound upon themselves, the worst case scenario includes 532 loss of life due to communications failure. Nothing done here should 533 enhance this possibility. 535 4. IANA Considerations 537 IANA is not called upon to do anything with this document. 539 If this document is published as an RFC, the RFC Editor should remove 540 this section during the process of publication. 542 5. Security Considerations 544 This document exposes a problem, but it proposes neither a protocol 545 nor a procedure. As such, it does not directly affect the security 546 of the Internet. 548 6. Acknowledgements 550 This document was developed with the knowledge and input of many 551 people, far too numerous to be mentioned by name. They include at 552 least Alan Duric, Christopher Eagan, Francois Le Faucheur, Haluk 553 Keskiner, Julie Ann Connery, Marty Egan, Mike Pierce, Mike Tibodeau, 554 Pete Babendreier, Rohan Mahy, Scott Bradner, Scott Morrison, and 555 Subha Dhesikan. 557 7. References 559 7.1 Normative References 561 [I-D.pierce-ieprep-assured-service-arch] 562 Pierce, M. and D. Choi, "Architecture for Assured Service 563 Capabilities in Voice over IP", 564 draft-pierce-ieprep-assured-service-arch-02 (work in 565 progress), January 2004. 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 draft-pierce-ieprep-assured-service-req-02 (work in 571 progress), January 2004. 573 [I-D.silverman-diffserv-mlefphb] 574 Silverman, S., "Multi-Level Expedited Forwarding Per Hop 575 Behavior (MLEF PHB)", draft-silverman-diffserv-mlefphb-03 576 (work in progress), February 2004. 578 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 579 and W. Weiss, "An Architecture for Differentiated 580 Services", RFC 2475, December 1998. 582 7.2 Informative References 584 [ANSI.MLPP.Spec] 585 American National Standards Institute, "Telecommunications 586 - Integrated Services Digital Network (ISDN) - Multi-Level 587 Precedence and Preemption (MLPP) Service Capability", ANSI 588 T1.619-1992 (R1999), 1992. 590 [ANSI.MLPP.Supplement] 591 American National Standards Institute, "MLPP Service 592 Domain Cause Value Changes", ANSI ANSI T1.619a-1994 593 (R1999), 1990. 595 [G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, 596 597 . 599 [G711.2] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July 600 1999, 601 602 . 604 [G711.3] Nortel Networks, "Packet Loss and Packet Loss 605 Concealment", 2000, 606 607 . 609 [G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and 610 Recency on Subjective Voice Quality", 2000, 611 612 . 614 [G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware 615 Support, MOS, and Negotiation", 2003, 616 617 . 619 [I-D.ietf-avt-ilbc-codec] 620 Andersen, S., "Internet Low Bit Rate Codec", 621 draft-ietf-avt-ilbc-codec-05 (work in progress), June 622 2004. 624 [I-D.ietf-sip-resource-priority] 625 Schulzrinne, H. and J. Polk, "Communications Resource 626 Priority for the Session Initiation Protocol (SIP)", 627 draft-ietf-sip-resource-priority-04 (work in progress), 628 September 2004. 630 [I-D.ietf-sipping-reason-header-for-preemption] 631 Polk, J., "Extending the Session Initiation Protocol 632 Reason Header for Preemption Events", 633 draft-ietf-sipping-reason-header-for-preemption-02 (work 634 in progress), August 2004. 636 [ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over 637 Networks With Bursty Packet Loss", July 2003. 639 [ITU.MLPP.1990] 640 International Telecommunications Union, "Multilevel 641 Precedence and Preemption Service (MLPP)", ITU-T 642 Recommendation I.255.3, 1990. 644 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 645 "Definition of the Differentiated Services Field (DS 646 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 647 1998. 649 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, 650 "Assured Forwarding PHB Group", RFC 2597, June 1999. 652 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 653 J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, 654 "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 655 3246, March 2002. 657 [RFC3326] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason 658 Header Field for the Session Initiation Protocol (SIP)", 659 RFC 3326, December 2002. 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 (2004). 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.