idnits 2.17.1 draft-jobert-tsvwg-pre-congest-notif-mobile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2309' is mentioned on line 245, but not defined ** Obsolete undefined reference: RFC 2309 (Obsoleted by RFC 7567) == Missing Reference: 'FJ93' is mentioned on line 264, but not defined == Missing Reference: '35' is mentioned on line 338, but not defined == Unused Reference: '1' is defined on line 596, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 612, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 641, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft S. Jobert 2 Intended status: Informational I. Hamchaoui 3 Expires: September 2012 France Telecom Orange 4 March 5, 2012 6 Pre-congestion notification in mobile networks 7 draft-jobert-tsvwg-pre-congest-notif-mobile-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This document may contain material from IETF Documents or IETF 15 Contributions published or made publicly available before November 16 10, 2008. The person(s) controlling the copyright in some of this 17 material may not have granted the IETF Trust the right to allow 18 modifications of such material outside the IETF Standards Process. 19 Without obtaining an adequate license from the person(s) controlling 20 the copyright in such materials, this document may not be modified 21 outside the IETF Standards Process, and derivative works of it may 22 not be created outside the IETF Standards Process, except to format 23 it for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on September 5, 2012. 44 in mobile networks 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. 58 Abstract 60 Mobile networks may be divided into two main segments: the radio 61 segment, and the wireline segment. This document highlights that the 62 algorithms leading to pre-congestion notification (e.g. ECN marking) 63 are usually significantly different for these two segments, and not 64 defined or documented in general over the radio segment. It also 65 explains that using ECN bits leads to having a unique signal for 66 notifying a pre-congestion related to two separate segments with 67 very different notification algorithms. Some consequences are 68 questioned, as well as the potential benefits of being able to 69 identify where the congestion comes from. This document finally 70 discusses the possibility to take into account the radio conditions 71 of the terminals when counting the volume of congestion over the 72 radio segment. 74 Table of Contents 76 1. Introduction ................................................ 3 77 2. Conventions used in this document............................ 4 78 3. Radio and wireline segments in mobile networks ............... 4 79 4. Pre-congestion notification in radio and wireline segments.... 5 80 4.1. Pre-congestion notification in wireline segment.......... 6 81 4.2. Pre-congestion notification in radio segment ............ 7 82 4.3. General remarks about pre-congestion notification in mobile 83 networks .................................................... 9 84 5. ECN bits in IP E2E layer: a single signal to carry pre-congestion 85 notification related to two separate segments ................... 9 86 6. Options for congestion-volume counting over the radio segment 11 87 7. Conclusions ................................................ 12 88 8. Security Considerations..................................... 13 89 9. IANA Considerations ........................................ 13 90 10. References ................................................ 14 91 10.1. Normative References.................................. 14 92 in mobile networks 94 10.2. Informative References................................ 14 95 11. Acknowledgments ........................................... 15 97 1. Introduction 99 Mobile networks may be divided into two main segments, very unlike 100 by nature: the radio segment, and the wireline segment. These two 101 portions of a mobile network may experience QoS degradation due to 102 excess traffic. Therefore, being able to notify about a so-called 103 pre-congestion (e.g. using ECN marking) can be considered as a 104 useful feature for these two segments. 106 This document highlights that the algorithms leading to pre- 107 congestion notification (e.g. ECN marking) are usually significantly 108 different for these two segments. In particular, they are in general 109 more complex on the radio segment, and not really defined or 110 documented. Depending on the intended purpose, different algorithms 111 might be designed over this segment and it is therefore important 112 that they are understood and documented somewhere before being 113 applied to a specific scenario. 115 This document also reminds the typical IP layers in presence in 116 mobile networks, e.g. due to the use of GTP tunnels. It highlights 117 that the standardized ECN coding in the header of IP packets leads 118 to having a unique signal for communicating to the receiver of the 119 flows pre-congestion information potentially related to two separate 120 segments with very different notification algorithms. The document 121 suggests that the consequences of a common interpretation of this 122 unique signal need to be assessed more in details and raises the 123 question of potential benefits in being able to identify where the 124 congestion comes from (e.g. using separated signals to inform about 125 pre-congestion over these two segments). 127 Finally, this document discusses the use of pre-congestion 128 notification over the radio segment in some use cases related to the 129 IETF ConEx WG, e.g. where the volume of congestion is counted. It 130 advocates that counting the number of bytes transmitted over the 131 radio segment during a pre-congestion period may not be the best 132 approach to provide incentive to reduce network usage during these 133 periods, because the terminals in bad radio conditions require more 134 radio resources compared to the terminals in good radio conditions 135 to reach the same rate. The possibility to take into account the 136 radio conditions of the terminals when counting the volume of 137 congestion over the radio segment is briefly introduced. 139 in mobile networks 141 2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC-2119 [RFC2119]. 147 In this document, these words will appear with that interpretation 148 only when in ALL CAPS. Lower case uses of these words are not to be 149 interpreted as carrying RFC-2119 significance. 151 IP E2E: the end-to-end IP layer related to the end application. 153 IP TNL: the transport IP layer supporting the GTP tunnel in mobile 154 networks. 156 UE: User Equipment 158 NB: NodeB 160 ECN: Early Congestion Notification 162 CQI: Channel Quality Indicator 164 AQM: Active Queue Management 166 RED: Random Early Detection 168 3. Radio and wireline segments in mobile networks 170 Mobile networks may be divided into two main segments, very 171 different by nature: the radio segment, and the wireline segment. 172 The figure 1 below illustrates these two segments with the example 173 of an LTE/EPC network, and also shows the two IP layers in presence 174 in the backhaul and core portions: 176 o IP E2E layer: the end-to-end IP layer related to the end 177 application 179 o IP TNL layer: the transport IP layer which supports the GTP 180 tunnel 181 in mobile networks 183 +------------------------------------------------------------------+ 184 | | 185 | .-----. .------. .----. .----. | 186 | / \ / \ / \ / \ | 187 |eUE- Radio --eNB- Backhaul -S-GW- Core -PDN-GW-Internet-Server| 188 | \ / \ / \ / \ / | 189 | '-----' '------' '----' '----' | 190 | | 191 |.-----. .-----. | 192 ||Appli| ------------------------------------------------- |Appli| | 193 ||-----| |-----| | 194 ||Sess | ------------------------------------------------- |Sess | | 195 ||-----| .-----.----. |-----| | 196 || IP | ---------------------------------- | IP | IP | - | IP | | 197 ||-----| .------.-----. .-----.-----. |-----+----| |-----| | 198 || | | | GTP | - | GTP | GTP | - | GTP | | | | | 199 || | | |-----| |-----+-----| |-----| | | | | 200 || L2 | - | L2 | UDP | - | UDP | UDP | - | UDP | | | | | 201 ||radio| | radio|-----| |-----+-----| |-----| L2 | - | L2 | | 202 || | | | IP | - | IP | IP | - | IP | | | | | 203 || | | |-----| |-----+-----| |-----| | | | | 204 || | | | L2 | - | L2 | L2 | - | L2 | | | | | 205 ||-----| |------+-----| |-----+-----| |-----+----| |-----| | 206 || L1 | - | L1 | L1 | - | L1 | L1 | - | L1 | L1 | | L1 | | 207 |'-----' '------'-----' '-----'-----' '-----'----' '-----' | 208 | | 209 |'-------v-------' '----------------------v---------------------' | 210 | Radio segment Wireline segment | 211 | | 212 +------------------------------------------------------------------+ 214 Figure 1 - Radio and wireline segments in mobile networks (LTE/EPC 215 example, data plane) 217 4. Pre-congestion notification in radio and wireline segments 219 The two portions of a mobile network shown in figure 1 may 220 experience QoS degradation due to excess traffic. Therefore, being 221 able to notify about a pre-congestion (e.g. using ECN marking) can 222 be considered as a useful feature for these two segments. 224 It is important to stress that the algorithms leading to pre- 225 congestion notification (e.g. ECN marking) are usually significantly 226 in mobile networks 228 different for these two segments. In particular, they are in general 229 more complex on the radio segment, and not really defined or 230 documented. Depending on the intended purpose, different algorithms 231 might be designed over this segment and it is therefore important 232 that they are understood and documented somewhere before being 233 applied to a specific scenario. 235 4.1. Pre-congestion notification in wireline segment 237 The algorithms for pre-congestion notification in an IP mobile 238 wireline network are pretty well documented in IETF documents. 239 Indeed, it is expected to correspond to classical ECN marking 240 algorithms in IP routers. 242 [RFC3168] (''The Addition of Explicit Congestion Notification (ECN) 243 to IP'') depicts the general ideas of ECN marking, which are based on 244 Active Queue Management (AQM) and for example Random Early Detection 245 (RED) principles (e.g. [RFC 2309], ''Recommendations on Queue 246 Management and Congestion Avoidance in the Internet''). 248 In particular, [RFC3168] mentions the following: 250 o ''AQM drops packets based on the average queue length exceeding a 251 threshold, rather than only when the queue overflows.'' 253 o ''AQM can set a Congestion Experienced (CE) codepoint in the 254 packet header instead of dropping the packet, when such a field 255 is provided in the IP header and understood by the transport 256 protocol.'' 258 o ''For a router, the CE codepoint of an ECN-Capable packet SHOULD 259 only be set if the router would otherwise have dropped the packet 260 as an indication of congestion to the end nodes.'' 262 o ''We expect that routers will set the CE codepoint in response to 263 incipient congestion as indicated by the average queue size, 264 using the RED algorithms suggested in [FJ93, RFC2309]. To the 265 best of our knowledge, this is the only proposal currently under 266 discussion in the IETF for routers to drop packets proactively, 267 before the buffer overflows. However, this document does not 268 attempt to specify a particular mechanism for active queue 269 management, leaving that endeavor, if needed, to other areas of 270 the IETF.'' 271 in mobile networks 273 These mechanisms aim mainly at interacting with TCP, in order to 274 reduce the bandwidth consumption when pre-congestion is detected. 276 4.2. Pre-congestion notification in radio segment 278 The algorithms for pre-congestion notification in the radio segment 279 of a mobile network are however expected to be significantly 280 different from the wireline segment and more complex in general. 282 Indeed, in the radio segment, a limited number of radio resources 283 are available for all User Equipment (UE) of a cell. Every TTI 284 (Transmission Time Interval), radio resources are dynamically 285 allocated by the radio scheduler to the active UEs of the cell. 287 In addition to the radio resources allocation, the quality of the 288 radio channel of a given UE is a key parameter determining the 289 achievable throughput for this UE: indeed, more complex and 290 efficient radio Modulation and Coding Schemes (MCS) can be used when 291 the UE is in very good radio conditions, leading to a higher 292 throughput per radio resource. On the contrary, for the same amount 293 of radio resources allocated, a UE in poor radio reception 294 conditions requires more robust and simpler MCS and will experience 295 lower bit rates than the same UE in good radio conditions. Hence, a 296 UE in poor radio conditions will need much more radio resources to 297 reach the same throughput compared to a UE in good radio conditions. 299 The radio conditions are measured over the downlink channel by the 300 UE and are reported to the mobile network, by means of Channel 301 Quality Indicator (CQI) values. 303 An algorithm aiming at notifying pre-congestion in the radio segment 304 is therefore expected to take into account different parameters, as 305 for instance: 307 o Average queue length exceeding a threshold, as for RED 309 o Amount of radio resources used by a particular UE and/or by all 310 the active UEs of the cell 312 o Radio conditions of a particular UE 313 in mobile networks 315 The details of the algorithm for ECN bits marking in the radio 316 segment, when supported, can however be considered as mainly 317 proprietary at the moment, and is not known in general by the 318 network operator. 320 On this aspect, [5] (draft ''Mobile Communication Congestion Exposure 321 Scenario'') presented in the IETF ConEx WG mentions the following: 323 o ''ECN is already partially introduced into 3GPP networks: Section 324 11.6 in [3GPP.36.300] specifies the usage of ECN for congestion 325 notification on the radio link (between eNB and UE), and 326 [3GPP.26.114] specifies how this can be leveraged for voice codec 327 adaptation.'' 329 However, when looking at these 3GPP documents, they give only 330 general information about the expected behavior at the UE (e.g. 331 codec rate reduction), but not about the details of the ECN marking 332 mechanism by the NB. For instance, the section 11.6 of [3] (TS 333 36.300) dealing with Explicit Congestion Notification is copied 334 below: 336 o ''The eNB and the UE support of the Explicit Congestion 337 Notification (ECN) is specified in Section 5 of [35] (i.e., the 338 normative part of [35] that applies to the end-to-end flow of IP 339 packets), and below. This enables the eNB to control the initial 340 codec rate selection and/or to trigger a codec rate reduction. 341 Thereby the eNB can increase capacity (e.g., in terms of number 342 of accepted VoIP calls), and improve coverage (e.g. for high bit 343 rate video sessions).'' 345 o ''The eNB should set the Congestion Experienced (CE) codepoint 346 ('11') in PDCP SDUs in the downlink direction to indicate 347 downlink (radio) congestion if those PDCP SDUs have one of the 348 two ECN-Capable Transport (ECT) codepoints set. The eNB should 349 set the Congestion Experienced (CE) codepoint ('11') in PDCP SDUs 350 in the uplink direction to indicate uplink (radio) congestion if 351 those PDCP SDUs have one of the two ECN-Capable Transport (ECT) 352 codepoints set.'' 354 Some algorithms for marking ECN bits in the radio segment can be 355 found in the literature; they may take into account some of the 356 parameters listed before. These algorithms may aim also at 357 interacting with TCP, in order to improve either the overall 358 capacity or the fairness between UEs, but other design choices are 359 also possible. 361 in mobile networks 363 Anyway, there is no well-identified default ECN marking algorithm 364 for the radio segment, so, it can be assumed that an actual 365 implementation will make certain design choices and favor certain 366 criteria compared to others (e.g. capacity vs fairness). 368 Those choices are not necessarily expected to meet the objectives of 369 a congestion-volume counting approach like discussed in the IETF 370 ConEx WG, especially when the exact algorithm is not known by the 371 network operator. They might not be the most optimal choices either. 373 4.3. General remarks about pre-congestion notification in mobile 374 networks 376 It has been shown that the criteria considered for pre-congestion 377 notification in the wireline segment and in the radio segment are 378 significantly different. 380 It has also been shown also that different algorithm designs are 381 possible for the pre-congestion notification over the radio segment, 382 and that the details are not necessarily known, which makes the 383 mechanism difficult to be applied to specific scenarios. 385 There might be benefits in particular in providing more details 386 about pre-congestion notification in the radio segment, in order to 387 better understand the scenario on which it is suitable. 389 As it will be explained in the next section, there might be also 390 benefits in being able to identify where the congestion happened 391 (radio vs wireline segment), in order to potentially take different 392 actions. 394 5. ECN bits in IP E2E layer: a single signal to carry pre-congestion 395 notification related to two separate segments 397 The figure 1 presented before reminds the typical IP layers in 398 presence in mobile networks (IP E2E and IP TNL), e.g. due to the use 399 of GTP tunnels. 401 This figure highlights that the standardized ECN coding in the 402 header of IP E2E layer packets leads to having a unique signal for 403 communicating to the receiver of the flows pre-congestion 404 information potentially related to two separate segments, with very 405 in mobile networks 407 different notification algorithms. Hence, pre-congestion located in 408 the radio segment cannot be distinguished from those of the wireline 409 segment. 411 As examples, the following cases may happen when pre-congestion 412 occurs in the downstream direction (i.e. from the server to the UE). 413 The behavior described in [RFC6040] ("Tunnelling of Explicit 414 Congestion Notification") consisting in propagating a 'CE' marking 415 at the output of the IP tunnel is assumed. 417 o Pre-congestion happened in the radio segment only: the ECN bits 418 of the IP E2E layer are expected to be marked to 'CE' by the NB 419 as to notify the UE about this radio pre-congestion. 421 o Pre-congestion happened in the wireline segment only: the ECN 422 bits of the IP TNL layer are expected to be marked to 'CE' by an 423 IP router in the wireline network. The NB is then expected to 424 propagate this 'CE' marking to the ECN bits of the IP E2E layer 425 as to notify the UE about this wireline pre-congestion. 427 o Pre-congestion happened in the radio segment and in the wireline 428 segment simultaneously: the ECN bits of the IP TNL layer are 429 expected to be marked to 'CE' by an IP router in the wireline 430 network. The ECN bits of the IP E2E layer are also expected to be 431 marked to 'CE' by the NB as to notify the UE about this radio 432 pre-congestion. 434 These illustrative examples show that the UE may not know where the 435 pre-congestion comes from when using the ECN bits of the IP E2E 436 layer. 438 One might argue that the UE is not interested in knowing the 439 location of the pre-congestion, and that the ECN marking is an end- 440 to-end mechanism. This is correct under the assumption that the ECN 441 marking criteria are consistent over the entire network. In the 442 examples of a mobile network provided before, it is not the case. 444 Therefore, an ECN marking could be misinterpreted by the UE (e.g. as 445 a wireline pre-congestion instead of a radio pre-congestion, or 446 vice-versa), with potentially inappropriate actions. A wireline pre- 447 congestion notification might also be ''erased'' by a radio pre- 448 congestion notification. 450 It is important to remind, as explained before, that the algorithms 451 leading to ECN marking are significantly different for these two 452 segments. The consequences of a common interpretation of this unique 453 in mobile networks 455 signal corresponding to the ECN marking in the IP E2E layer need 456 therefore to be assessed more in details, and probably depends on 457 the actions that are triggered (e.g. interaction with TCP, 458 congestion-volume counting...). 460 Based on this discussion, this document raises the question of 461 potential benefits in being able to identify where the congestion 462 comes from (e.g. using separated signals to inform about pre- 463 congestion over these two segments). 465 The main question is in particular to determine whether the ECN bits 466 of the IP E2E layer correspond to the best signal for indicating a 467 pre-congestion happening in the radio segment. 469 Indeed, the actions to be taken when a pre-congestion occurred may 470 depend on the location of the pre-congestion (ECN marking on the 471 radio could lead to less strict actions compared to a backhaul 472 congestion, depending on the details of the ECN marking algorithm 473 over the radio segment). Moreover, although not the main purpose of 474 the mechanism, it might be useful also for the network management to 475 identify where the congestions are located. 477 These arguments might be further developed in a future revision of 478 this paper, together with potential proposals to define separate 479 signals to indicate pre-congestion notification over these two 480 different segments of a mobile network. This type of approach would 481 be compared to the complexity of defining separate signals. 483 6. Options for congestion-volume counting over the radio segment 485 The current proposal in the IETF ConEx WG for counting congestion- 486 volume is as follows: ''the "congestion volume" is defined to be the 487 total number of bytes marked as congested'' (see [6] - draft 488 ''Congestion Exposure (ConEx) Concepts and Abstract Mechanism''). 490 As it has been explained in the paragraph 4.2, the radio conditions 491 of a UE are an important parameter which determines the amount of 492 radio resources required to reach a given throughput. Indeed, a UE 493 in poor radio conditions will need much more radio resources to 494 reach the same throughput compared to a UE in good radio conditions. 496 For this reason, when applying use cases related to ConEx where the 497 volume of congestion is counted, it could be of interest to take 498 into account the radio conditions of the UE. 500 in mobile networks 502 For example, each byte marked as pre-congested may be weighted by a 503 multiplicative factor depending on the UE radio conditions instead 504 of simply counting the number of bytes transmitted over the radio 505 segment during a pre-congestion period. 507 N thresholds (e.g. corresponding to different ranges of CQI values 508 reported by the UE) might for instance be defined to refine the way 509 the data volume is counted during pre-congestion periods. For 510 instance, if N=3: 512 o Excellent radio conditions: the congestion-volume is counted with 513 a factor F=1, i.e. the number of bytes transmitted over the radio 514 segment during a congestion period is counted 516 o Degraded radio conditions: the congestion-volume is weighted with 517 a factor F=2, i.e. twice the number of bytes transmitted over the 518 radio segment during a congestion period is counted 520 o Bad radio conditions: the congestion-volume is weighted with a 521 factor F=5, i.e. five times the number of bytes transmitted over 522 the radio segment during a congestion period is counted 524 Another alternative would be that the pre-congestion notification 525 probability (e.g. ECN marking probability) would take into account 526 the radio conditions of the UE. Basically, the packets of a UE in 527 bad radio conditions would be marked more often under pre-congestion 528 periods than those of a UE in good radio conditions. This would 529 provide an equivalent mechanism as the multiplicative factor 530 described above. 532 This type of mechanism would provide incentive to end users in bad 533 radio conditions to delay their non-urgent network consumptions. Of 534 course, the count would be only active when the cell is considered 535 as in pre-congestion (according to criteria to be further defined). 537 This proposal might be further developed in a future revision of 538 this paper. 540 7. Conclusions 542 This document has reminded that mobile networks may be divided into 543 two main segments, very different by nature: the radio segment, and 544 the wireline segment. It also highlighted that the algorithms 545 leading to pre-congestion notification (e.g. ECN marking) are 546 in mobile networks 548 usually significantly different for these two segments, and not 549 defined or documented in general over the radio segment. It also 550 explained that using ECN bits leads to having a unique signal for 551 notifying a pre-congestion related to two separate segments with 552 very different notification algorithms. Some consequences of a 553 common interpretation of this unique signal have been questioned, as 554 well as the potential benefits in being able of identifying where 555 the congestion comes. This document finally discussed the 556 possibility to take into account the radio conditions of the 557 terminals when counting the volume of congestion over the radio 558 segment. 560 This document proposes that: 562 o The main families of algorithms leading to pre-congestion 563 notification (e.g. ECN marking) in the radio segment would be 564 documented somewhere. This might involve Standard Development 565 Organisms beyond the IETF. It is however considered useful 566 information for IETF work. 568 o The signal indicating a pre-congestion over the radio segment 569 would be discussed. The main question is in particular to 570 determine whether the ECN bits of the IP E2E layer correspond to 571 the best signal or if a separate signal should be defined. 573 o For the use cases where congestion-volume are counted (as 574 discussed in the IETF ConEx WG), the radio conditions of the UE 575 are taken into account in the count, either via the introduction 576 of a multiplicative factor or with a pre-congestion notification 577 probability (e.g. ECN marking probability) taking into account 578 the radio conditions. 580 Some proposals contained in this document might be further developed 581 in a future revision of this paper. 583 8. Security Considerations 585 587 9. IANA Considerations 589 590 in mobile networks 592 10. References 594 10.1. Normative References 596 [1] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 600 Syntax Specifications: ABNF", RFC 2234, Internet Mail 601 Consortium and Demon Internet Ltd., November 1997. 603 [3] 3GPP TS 36.300 V11.0.0 "3rd Generation Partnership Project; 604 Technical Specification Group Radio Access Network; Evolved 605 Universal Terrestrial Radio Access (E-UTRA) and Evolved 606 Universal Terrestrial Radio Access Network (E-UTRAN); Overall 607 description; Stage 2 (Release 11)", December 2011. 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 613 Syntax Specifications: ABNF", RFC 2234, Internet Mail 614 Consortium and Demon Internet Ltd., November 1997. 616 [RFC3168] Ramakrishnan, Floyd, Black "The Addition of Explicit 617 Congestion Notification (ECN) to IP", RFC 3168, September 618 2001. 620 [RFC2309] Braden et al "Recommendations on Queue Management and 621 Congestion Avoidance in the Internet", RFC 2309, April 622 1998. 624 [RFC6040] Briscoe "Tunnelling of Explicit Congestion Notification", 625 RFC 6040, November 2010. 627 10.2. Informative References 629 [4] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 630 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 631 1583. 633 [5] Kutscher, Winter, Krishnan, Zhang "Mobile Communication 634 Congestion Exposure Scenario", October 2011. 636 in mobile networks 638 [6] Mathis, Briscoe "Congestion Exposure (ConEx) Concepts and 639 Abstract Mechanism", October 2011. 641 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 642 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 643 pp. 1573-1583. 645 11. Acknowledgments 647 This document was prepared using 2-Word-v2.0.template.dot. 649 Authors' Addresses 651 Sebastien Jobert 652 France Telecom Orange 653 2 avenue Pierre Marzin 654 22300 LANNION, FRANCE 656 Email: sebastien.jobert@orange.com 658 Isabelle Hamchaoui 659 France Telecom Orange 660 2 avenue Pierre Marzin 661 22300 LANNION, FRANCE 663 Email: isabelle.hamchaoui@orange.com