idnits 2.17.1 draft-conet-aeon-use-cases-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-conet-aeon-problem-statement-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. George 3 Internet-Draft Time Warner Cable 4 Intended status: Informational P. Fan 5 Expires: January 5, 2015 China Mobile 6 S. Matsushima 7 SoftBank Telecom 8 T. Reddy 9 C. Eckel 10 Cisco Systems, Inc. 11 July 4, 2014 13 Application Enabled Collaborative Networking Use Cases 14 draft-conet-aeon-use-cases-01 16 Abstract 18 This document describes application enabled collaborative networking 19 use cases. Application enabled collaborative networking has 20 applications explicitly signal their flow characteristics to the 21 network. This provides network nodes with visibility of the 22 application flow characteristics, which enables them to apply the 23 correct flow treatment and provide feedback to applications. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 5, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Firewall Traversal: Identification of new applications . 5 62 2.1.1. Description of Problem . . . . . . . . . . . . . . . 5 63 2.1.2. Proposed Solution . . . . . . . . . . . . . . . . . . 5 64 2.1.3. User/Application Benefit . . . . . . . . . . . . . . 6 65 2.1.4. Operator Benefit . . . . . . . . . . . . . . . . . . 6 66 2.1.5. Flow characteristics provided by application . . . . 6 67 2.1.6. Action taken by firewall as result of receiving flow 68 characteristics . . . . . . . . . . . . . . . . . . . 6 69 2.1.7. Feedback provided by firewall . . . . . . . . . . . . 6 70 2.1.8. Security and Privacy Considerations . . . . . . . . . 6 71 2.2. Efficient Capacity Usage . . . . . . . . . . . . . . . . 6 72 2.2.1. Description of Problem . . . . . . . . . . . . . . . 6 73 2.2.2. Proposed Solution . . . . . . . . . . . . . . . . . . 8 74 2.2.3. User/Application Benefit . . . . . . . . . . . . . . 9 75 2.2.4. Operator Benefit . . . . . . . . . . . . . . . . . . 9 76 2.2.5. Flow characteristics provided by application . . . . 9 77 2.2.6. Action taken by network as result of receiving flow 78 characteristics . . . . . . . . . . . . . . . . . . . 9 79 2.2.7. Feedback provided by network . . . . . . . . . . . . 9 80 2.2.8. Security and Privacy Considerations . . . . . . . . . 10 81 2.3. Video Adaptation . . . . . . . . . . . . . . . . . . . . 10 82 2.3.1. Description of Problem . . . . . . . . . . . . . . . 10 83 2.3.2. Proposed Solution . . . . . . . . . . . . . . . . . . 11 84 2.3.3. User/Application Benefit . . . . . . . . . . . . . . 11 85 2.3.4. Operator Benefit . . . . . . . . . . . . . . . . . . 11 86 2.3.5. Flow characteristics provided by application . . . . 11 87 2.3.6. Action taken by network as result of receiving flow 88 characteristics . . . . . . . . . . . . . . . . . . . 12 89 2.3.7. Feedback provided by network . . . . . . . . . . . . 12 90 2.3.8. Security and Privacy Considerations . . . . . . . . . 12 91 2.4. Multi-interface selection: Use metadata to help interface 92 selection or prioritization . . . . . . . . . . . . . . . 12 93 2.4.1. Description of Problem . . . . . . . . . . . . . . . 12 94 2.4.2. Proposed Solution . . . . . . . . . . . . . . . . . . 12 95 2.4.3. User/Application Benefit . . . . . . . . . . . . . . 12 96 2.4.4. Operator Benefit . . . . . . . . . . . . . . . . . . 13 97 2.4.5. Flow characteristics provided by application . . . . 13 98 2.4.6. Action taken by network as result of receiving flow 99 characteristics . . . . . . . . . . . . . . . . . . . 13 100 2.4.7. Feedback provided by network . . . . . . . . . . . . 13 101 2.4.8. Security and Privacy Considerations . . . . . . . . . 13 102 2.5. Session Identification: Identification of multiple media 103 flows belonging to a common application session . . . . . 13 104 2.5.1. Description of Problem . . . . . . . . . . . . . . . 13 105 2.5.2. Proposed Solution . . . . . . . . . . . . . . . . . . 14 106 2.5.3. User/Application Benefit . . . . . . . . . . . . . . 14 107 2.5.4. Operator Benefit . . . . . . . . . . . . . . . . . . 14 108 2.5.5. Flow characteristics provided by application . . . . 14 109 2.5.6. Action taken by network as result of receiving flow 110 characteristics . . . . . . . . . . . . . . . . . . . 15 111 2.5.7. Feedback provided by network . . . . . . . . . . . . 15 112 2.5.8. Security and Privacy Considerations . . . . . . . . . 15 113 2.6. Content Based Charging . . . . . . . . . . . . . . . . . 15 114 2.6.1. Description of Problem . . . . . . . . . . . . . . . 15 115 2.6.2. Proposed Solution . . . . . . . . . . . . . . . . . . 15 116 2.6.3. User/Application Benefit . . . . . . . . . . . . . . 16 117 2.6.4. Operator Benefit . . . . . . . . . . . . . . . . . . 16 118 2.6.5. Flow characteristics provided by application . . . . 16 119 2.6.6. Action taken by network as result of receiving flow 120 characteristics . . . . . . . . . . . . . . . . . . . 16 121 2.6.7. Feedback provided by network . . . . . . . . . . . . 16 122 2.6.8. Security and Privacy Considerations . . . . . . . . . 16 123 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 124 4. Informative References . . . . . . . . . . . . . . . . . . . 17 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 127 1. Introduction 129 Identification and treatment of application flows are important to 130 many application providers and network operators. They often rely on 131 these capabilities to deploy and/or support a wide range of 132 applications. These applications, and the packet flows they generate 133 and consume, may require specific bandwidth, latency, etc., that can 134 be better met if made known to the network. Historically, this 135 functionality has been implemented to the extent possible using 136 heuristics, which inspect and infer flow characteristics. Heuristics 137 may be based on port ranges, network separation (e.g. subnets or 138 VLANs, Deep Flow Inspection (DFI), or Deep Packet Inspection (DPI). 139 But many application flows in current usages are dynamic, adaptive, 140 time-bound, encrypted, peer-to-peer, asymmetric, used on multipurpose 141 devices, and have different priorities depending on direction of 142 flow, user preferences, and other factors. Any combination of these 143 properties renders heuristic based techniques less effective and may 144 result in compromises to application security or user privacy, as 145 described in detail in [I-D.conet-aeon-problem-statement]. 147 Application enabled collaborative networking allows applications to 148 explicitly signal their flow characteristics to the network. This 149 provides network nodes with visibility of the application flow 150 characteristics. These network nodes may take action based on this 151 visibility and/or contribute to the flow description. The resulting 152 flow description may be communicated as feedback from the network to 153 applications. This proposes a way of building collaborative 154 connections for network operators and application providers, 155 benefiting both of them as well as users. Network provider is able 156 to manage the traffic going through the network more effectively, and 157 application provider utilizes action taken by network on its traffic 158 to meet user requirement and expectation. 160 This document describes a set of use cases addressable by application 161 enabled collaborative networking. 163 2. Use Cases 165 The following use cases have been identified. 167 1. Firewall Traversal: Identification of new applications 169 2. Efficient Capacity Usage 171 3. Video Adaptation 173 4. Multi-interface selection: Use metadata to help interface 174 selection or prioritization. 176 5. Session Identification: Identification of multiple media flows 177 belonging to a common application session. 179 6. Content Based Charging 181 In describing each use case, the following information is provided. 183 o description of the problem 185 o proposed solution 187 o user/application benefit 189 o operator benefit 191 o flow characteristics provided by application 192 o action taken by network as result of receiving flow 193 characteristics 195 o feedback provided by network 197 o security and privacy considerations 199 2.1. Firewall Traversal: Identification of new applications 201 2.1.1. Description of Problem 203 Modern firewalls use application-layer gateways (ALGs) to perform 204 policy enforcement. For example firewalls implement SIP-aware 205 Application Layer Gateway function, which examines the SIP signaling 206 and opens the appropriate pinholes for the RTP media. In particular 207 firewall extracts media transport addresses, transport protocol and 208 ports from session description and creates a dynamic mapping for 209 media to flow through. This model will not work in the following 210 cases: 212 1. Session signaling is end-to-end encrypted (say, using TLS). 214 2. Firewall does not understand the session signaling protocol, or 215 extensions to the protocol, used by the endpoints (e.g. WebRTC 216 signaling protocols). 218 3. Session signaling and media traverse different firewalls (e.g., 219 signaling exits a network via one firewall whereas media exits a 220 network via a different firewall). 222 Enterprise networks that use firewalls with restrictive policies 223 block new applications like WebRTC and delay deployment of killer 224 applications. 226 2.1.2. Proposed Solution 228 These problems can be addressed by the host providing authorization 229 it received from an application server that is trusted by the network 230 to authorize flows and associated actions (e.g., policies). PCP 231 third party authorization ([I-D.wing-pcp-third-party-authz]) solves 232 this problem by associating the media session with the signaling 233 session. This is done by sending a cryptographic token in the 234 signaling which authorizes the firewall mapping for the media 235 session. 237 2.1.3. User/Application Benefit 239 Enterprise networks that use firewalls with restrictive policies can 240 deploy new applications at a faster rate for user benefit. 242 2.1.4. Operator Benefit 244 Enterprise firewalls can enforce restrictive policies without the 245 need to be enhanced to perform ALG on new applications. For example 246 Enterprise firewall could have granular policies to permit peer-to- 247 peer UDP media session only when the call is initiated using the 248 selected WebRTC server (Dr. Good) it trusts and block others (Dr. 249 Evil). PCP-aware firewalls can enforce such granular security 250 policies without performing ALG on the session signaling protocols. 251 This mechanism can be used by any other Application Function trusted 252 by the network to permit time-bound, encrypted, peer-to-peer traffic. 254 2.1.5. Flow characteristics provided by application 256 The client requests dynamic mappings to permit flows required by the 257 application. This request includes a cryptographic token and 258 characteristics of the flow, such as the anticipated bandwidth needs 259 as well as the tolerance to delay, loss, and jitter. 261 2.1.6. Action taken by firewall as result of receiving flow 262 characteristics 264 The firewall uses the client request to permit and prioritize the 265 traffic associated with those flows. The cryptographic token 266 provides authorization for the flows and their prioritization. 268 2.1.7. Feedback provided by firewall 270 Firewall matches the authorization data with what is requested in the 271 request sent by the client. If the authorization sets match, the 272 firewall processes the request made by the client. If the token is 273 invalid or the request exceeds what is authorized by the token then 274 firewall rejects the request. 276 2.1.8. Security and Privacy Considerations 278 2.2. Efficient Capacity Usage 280 2.2.1. Description of Problem 282 Network traffic is bursty and often follows diurnal usage patterns 283 such that there are times of day where traffic levels are at a peak, 284 and other times of day where they are at a valley. Networks that are 285 properly capacity planned need to have enough capacity to service the 286 traffic demands at peak. In a network with consistent demand and 287 usage patterns, keeping up with demand is a matter of building 288 capacity at a faster rate than the growth of the peak, in conjunction 289 with any requirements for diversity and fault tolerance as well as 290 any SLA for performance (latency, jitter, packet loss, etc) that may 291 inform which traffic is passed, which is prioritized, and which may 292 be dropped during periods of congestion. However, there are several 293 problems to consider in this context: 295 1. Simply building enough capacity for peak usage is not always 296 efficient and cost-effective, because not all traffic is the same 297 in terms of its need to transit the network at the exact moment 298 it is currently doing so, but few tools exist to provide 299 applications with the information they need to make more 300 intelligent decisions on demand, and thus they default to "as 301 soon as possible." For example, those watching streaming video 302 or doing real time communication or head to head gaming need 303 immediate access, while less real-time activities such as data 304 synchronization with the cloud for backups, or downloading 305 software updates, or preloading content onto a CDN could 306 potentially be deferred to times when more capacity is available, 307 but today, all of that traffic competes for the same capacity at 308 the same time. 310 2. QoS is not a substitute for capacity, and often a network 311 designed for long periods of congested operation provides a poor 312 user experience, since QoS ultimately is a method to identify 313 which traffic should be dropped first. 315 3. When the network is not at peak usage, there is capacity sitting 316 idle. Even in a well-used network capacity is built in 317 increments that may not match up with growth rate i.e. if a 318 network adds capacity in increments of 10G or 100G, but only 319 needed a small fraction of that until growth catches up. This 320 inefficiency is magnified when one considers the spare capacity 321 designed into most networks to address the need to tolerate one 322 or more failures in the network with minimal traffic impact. In 323 many cases, the idle capacity even at peak may be up to 50%, and 324 at off peak, it could be much higher. 326 4. Few networks have truly consistent demand and usage patterns. 327 While the average usage may follow a rough pattern, this does not 328 always provide for flash demands, where a large number of users 329 are simultaneously downloading an OS update, or all watching the 330 same event via streaming video, or more heavily using the network 331 due to being stuck at home during a snowstorm, etc. The average 332 usage patterns also do not take into account the effects of 333 outages at shifting large volumes of traffic around in the 334 network, and so managing these exception events either requires 335 further spare capacity, or acknowledgement that some traffic will 336 be dropped due to congestion, with the attendant impact to end 337 user experience. 339 2.2.2. Proposed Solution 341 Addressing this problem requires a multi-part solution: 343 o Provide a mechanism for the network to communicate to applications 344 when the network is busy and when it is not so that individual 345 applications can manage their demand based on the nature of the 346 application and its needs. This demand management helps to smooth 347 the traffic at peak by redirecting some of the demand to off-peak, 348 and has an analog in the power utility industry where demand based 349 pricing or smart grid technology signals devices that use a large 350 amount of power so that they can be intelligent about those 351 demands and reduce the burden on the available capacity of the 352 electrical grid. 354 o Similarly, provide a means for applications to communicate their 355 required performance envelope, as well as any data on how flexible 356 the time of data transmission can be, i.e. "I need this transfer 357 to complete by $time on $day" or "I need this transfer to complete 358 within 12 hours" etc. This information can be used by the network 359 to compute the best way to deliver the requested service, or to 360 identify when it cannot provide the request and suggest an 361 alternate. 363 o Provide a means for "below best effort" or scavenger class data 364 transmission so that traffic marked as scavenger will be carried 365 in periods where no congestion is present, but may be discarded 366 during periods of congestion due to either peak usage or outages. 368 This solution could also be used in conjunction with defined paths 369 through the network (TE, Segment Routing, etc) to provide capacity 370 for traffic that has specific performance requirements, or is not 371 sensitive to using a sub-optimal path. i.e. capacity exists on this 372 backup path that is much longer, so since this traffic does not care 373 about a few 10s of milliseconds of additional latency, it should be 374 marked to use the non-optimal path even if that path is not seen as 375 best by the routing protocol. 377 2.2.3. User/Application Benefit 379 Key user benefits include: 381 o Best service for real-time and other interactive applications 382 (less interference from non real-time or non-interactive traffic) 384 o More control over application bandwidth usage, potential for 385 service guarantees for important applications 387 2.2.4. Operator Benefit 389 Reduced cost via better/more efficient management of capacity/growth 390 while still providing first-class service to customers. 392 2.2.5. Flow characteristics provided by application 394 An application signals one or more of the following to the network: 396 o level of service required (e.g. guaranteed service, best-effort, 397 or below best effort) 399 o minimum requirement for transmission rate/throughput 401 o that it is tolerant/intolerant of high latency, high jitter, high 402 packet loss 404 o a request in the form "I need to deliver this data by X, when 405 should I send, and how should I identify the flow?" 407 2.2.6. Action taken by network as result of receiving flow 408 characteristics 410 Potential action taken by the network include: 412 o Identify path through network that meets flow service requirements 414 o Treat marked traffic according to identified service type (e.g. 415 scavenger class carried in periods of low usage, and/or dropped 416 during congestion) 418 2.2.7. Feedback provided by network 420 Feedback provided by the network includes: 422 o Peak demand times, either proactively (e.g. this network peaks 423 daily between the hours of X and Y) or reactively through 424 something like Explicit Congestion Notification (this network is 425 at peak or is experiencing congestion right now) 427 o ACK/NACK for requested level of service, throughput, etc. 429 2.2.8. Security and Privacy Considerations 431 This requires a trust model between application and network so that 432 the information communicated about performance envelope requirements 433 can be trusted. In the case where there are different costs, 434 charging rates, tonnage limits by type of traffic, there is 435 opportunity for abuse (maliciously marking all traffic such that it 436 incurs additional cost, or such that it is dropped when it should not 437 be, etc). Even simpler data such as IP Precedence is often remarked 438 at the boundaries between networks as untrusted, so carrying this 439 sort of metadata likely requires a method to ensure that it was set 440 by a trusted entity and not manipulated in transit. 442 2.3. Video Adaptation 444 HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP- 445 based streaming technologies that allow a client to adaptively switch 446 between multiple bitrates, depending on current network conditions. 447 HAS client first requests and receives a Manifest File, and then, 448 after parsing the information in the Manifest File, proceeds with 449 sequentially requesting the chunks listed in the Manifest File. 451 2.3.1. Description of Problem 453 The problems with HAS are: 455 o HAS client selects the initial bitrate without knowing the current 456 network conditions which could cause start-up delay and frame 457 freezes while a lower bitrate chunk is being retrieved. HAS 458 client does not have a mechanism to signal the flow 459 characteristics and desired treatment to the network. 461 o HAS server can mark the packets appropriately but setting DSCP has 462 limitations. DSCP value may not be preserved or honored over the 463 Internet and operating system may not allow to set DSCP values. 465 o Content Providers may need a mechanism to convey the flow 466 characteristics and desired treatment to the ISP. Existing 467 mechanisms and the associated limitations are: 469 1. ISP can be configured with the IP addresses of content 470 providers to identify the traffic originating from those 471 servers. The limitations with this approach are ISP has to 472 keep track of content providers IP addresses. With CDNI 473 (Content Delivery Network InterConnection) content could be 474 served either from uCDN (upstream CDN) or any of a number of 475 dCDNs (downstream CDN) and it will not be possible to manually 476 track the IP addresses of all the CDN surrogates. There is 477 also no way to differentiate content which could be available 478 in different bitrates. 480 2. If HAS client is behind NAT and content provider uses RESTful 481 API (OneAPI) to install differentiated QoS then ISP will 482 struggle to find the pre-NAT information. Content provider 483 also needs to be aware of the ISP to which the client is 484 attached and the IP address of the Policy Decision Point (PDP) 485 in the ISP to which it needs to signal the flow 486 characteristics. 488 o ISP can use DPI to identify one-way video streaming content but is 489 expensive and fails if the traffic is encrypted. 491 2.3.2. Proposed Solution 493 HAS client can use third party authorization to request network 494 resources. At a high level, this authorization works by the client 495 first obtaining a cryptographic token from the authorizing network 496 element, then including that token in the request along with relevant 497 flow characteristics. ISP validates the token and grants the 498 request. 500 2.3.3. User/Application Benefit 502 This solution helps increase the average play quality, reduces the 503 start-up delay and frame freezes by avoiding attempt to retrieve a 504 too high-bit rate chunk etc thus improving the quality of experience 505 for end user. 507 2.3.4. Operator Benefit 509 Network operators can better recognize and treat one-way video 510 streaming content. 512 2.3.5. Flow characteristics provided by application 514 HAS client signals the flow characteristics such as the anticipated 515 bandwidth needs as well as the tolerance to delay, loss, and jitter. 517 2.3.6. Action taken by network as result of receiving flow 518 characteristics 520 Subject to local policies, a network node might perform bandwidth 521 counting, or reconfigure the underlying network so that additional 522 bandwidth is made available for this particular flow, or might 523 perform other actions. 525 2.3.7. Feedback provided by network 527 The network responds that the client request can be fully or 528 partially accommodated. It also notifies the client when conditions 529 change. 531 2.3.8. Security and Privacy Considerations 533 2.4. Multi-interface selection: Use metadata to help interface 534 selection or prioritization 536 2.4.1. Description of Problem 538 An increasing number of hosts are operating in multiple-interface 539 environments and a host with multiple interfaces needs to choose the 540 best interface for communication. Oftentimes, this decision is based 541 on a static configuration and does not consider the link 542 characteristics of that interface, which may affect the user 543 experience. The network interfaces may have different link 544 characteristics, but that will not be known without the awareness of 545 the upstream and downstream characteristics of the access link. 547 2.4.2. Proposed Solution 549 The problem can be solved if a mechanism is provided for the 550 applications to communicate required flow characteristics with the 551 available interfaces, and know about network condition of each 552 interface, or to what extent application requirement of flow 553 characteristics can be met by each interface. Application can then 554 prioritize the interfaces based on information gathered and select 555 one or more interfaces that best meet its requirement. 557 2.4.3. User/Application Benefit 559 Applications can choose the interface that best meets their 560 requirements for communication. User experience is improved because 561 of the consistency between flow characteristics requested by 562 application and network ability provided by the selected interface. 564 2.4.4. Operator Benefit 566 The network that can provide the requested flow characteristics will 567 be selected by the application thus increasing the subscriber base of 568 the operator. 570 2.4.5. Flow characteristics provided by application 572 Application signals flow characteristics over multiple interfaces and 573 based on the response from its various interfaces sorts the source 574 addresses according to the link capacity characteristics. Source 575 addresses from the interface which best fulfills the desired flow 576 characteristics are assigned the highest priority and would be tried 577 first to communicate with the server or remote peer. For example 578 [I-D.reddy-mmusic-ice-best-interface-pcp] explains the mechanism 579 where Interactive Connectivity Establishment (ICE) agent on a host 580 with multiple interfaces determines the link characteristics of the 581 host's interfaces, which influences the ICE candidate priority. 582 Similarly [I-D.wing-mptcp-pcp] explains how Multipath TCP (MPTCP) can 583 select the best path when multiple paths are available. 585 2.4.6. Action taken by network as result of receiving flow 586 characteristics 588 Network identifies flow characteristics requested by applications, 589 and decides whether the request can be met or not. 591 2.4.7. Feedback provided by network 593 Link characteristics and ACK/NACK for flow requirement can be 594 provided as feedback by network. 596 2.4.8. Security and Privacy Considerations 598 Users/applications are expected to consider security of interfaces, 599 e.g. an untrusted public wifi access point will have lower priority 600 than a trusted VPN tunnel, when prioritizing and selecting the 601 interfaces. 603 2.5. Session Identification: Identification of multiple media flows 604 belonging to a common application session 606 2.5.1. Description of Problem 608 Many end-to-end application sessions involve multiple application 609 protocols, devices and administrative domains. These sessions 610 involve multiple media flows (e.g. an audio flow and a video flow for 611 a video call, media flows between different entities in a 612 supplementary service session consisting of multiple SIP dialogs or 613 H.323 calls). Media flows may be added/removed from a application 614 session during the lifetime of the session. From within the network, 615 determining which media flows are associated with each application 616 session is often difficult, making it hard to provide application 617 level troubleshooting, traffic analysis, and QoS. 619 2.5.2. Proposed Solution 621 Including a session identifier (e.g. as defined in [RFC7206]) in the 622 flow characteristics communicated by the application to the network 623 would allow the network to identify media flows belonging to a common 624 application session. This visibility would enable the following: 626 o network troubleshooting and traffic analysis tools to correctly 627 associate media flows with application sessions 629 o media flows that are part of established application sessions to 630 be identified (e.g. the triggered call in the case of a transfer) 631 and given dedicated QoS. Preserving established sessions 632 generally is higher priority than setting up new sessions (except 633 when there is some form of multi-level preemption). Giving more 634 bandwidth to additional flows on established sessions might cause 635 some newer sessions to fail due to resource unavailability while 636 established sessions continue without degradation, which is the 637 preferred outcome in most cases. 639 2.5.3. User/Application Benefit 641 Users receive more predictable and reliable QoS for their application 642 sessions. 644 2.5.4. Operator Benefit 646 Operators are able to perform traffic analysis and troubleshooting at 647 the application level, and they are able to provide QoS at the 648 application level rather than only at the media flow level. 650 2.5.5. Flow characteristics provided by application 652 The application provides a common session id as metadata for all its 653 media flows throughout the lifetime of the session. 655 2.5.6. Action taken by network as result of receiving flow 656 characteristics 658 The network identifies all media flows associated with a given 659 session. This information may be used to provide application level 660 QoS, preserving established sessions and/or giving more bandwidth to 661 additional flows on established sessions. 663 2.5.7. Feedback provided by network 665 The network may provide feedback to the application indicating the 666 amount of bandwidth it expects to be able to provide for its session. 667 It may also be provide indications of the expected amount of delay, 668 jitter, and loss the application should be prepared to tolerate. 670 2.5.8. Security and Privacy Considerations 672 2.6. Content Based Charging 674 2.6.1. Description of Problem 676 Commonly used billing method for internet subscribers, e.g. volume 677 based charging, does not distinguish usage from the angle of 678 applications. Under this billing model ISP cannot apply different 679 pricing strategies to the applications it carries, users may hesitate 680 to use certain types of applications, e.g. mobile apps consuming 681 large volume, and application developers also have to strive for 682 volume apart from user preference and usage time. Content based 683 charging is an emerging billing method that takes content related 684 information into account and enables smarter pricing strategy. 685 Operators can place different prices for different types of traffic, 686 and help content providers build tight relationship with their users, 687 e.g. wholesaling the data volume of an application to its developer 688 content provider so that users can use the application free of 689 charge. Content based charging is required to precisely identify 690 traffic that belongs to a certain pricing category in a way that is 691 flexible and easy to manage, and granularity of traffic may range 692 from types of applications to a detailed service function within an 693 application. Those requirements reflex limitations in the current 694 heuristics. 696 2.6.2. Proposed Solution 698 In order to address this problem a mechanism is needed to allow 699 applications to notify its existence to the network by describing 700 traffic flows needing a certain charging method. Network will then 701 have direct visibility into the traffic and identify targeted traffic 702 accordingly. This billing model usually involves collaboration 703 between network and content providers. The notification needs to go 704 through an authentication function to guarantee the application is 705 reliable and probably an identifier for network to identify the 706 application that has service agreement with ISP. ISP will identify 707 traffic based on characteristics notified by application and apply 708 designated billing strategy. 710 2.6.3. User/Application Benefit 712 Users take advantage of the granular and customized charging model, 713 and pay for different types of traffic at different rate. This 714 charging model will reduce volume expense for users and stimulate 715 internet usage. Content provider can benefit from providing users 716 with exclusive payment function, e.g. pay for traffic volume or 717 provide cheap volume package, and increase user enthusiasm and time 718 to use its applications. 720 2.6.4. Operator Benefit 722 The solution will provide operators with a method to precisely 723 identify and charge traffic based on content, and to agilely manage 724 charging strategy of applications. Operators are able to cooperate 725 with content providers to provide this new billing service to users 726 and encourage encourage traffic consumption. 728 2.6.5. Flow characteristics provided by application 730 Application notifies network of its identifier and traffic 731 description to enable network to recognize its traffic accordingly. 732 Application may also signal its intended charging model as a request 733 to the network. 735 2.6.6. Action taken by network as result of receiving flow 736 characteristics 738 Network identifies traffic flows notified by the application and 739 applies the designated billing model based on application request and 740 business agreement with the content provider providing the 741 application. 743 2.6.7. Feedback provided by network 745 2.6.8. Security and Privacy Considerations 747 There needs to be an authentication mechanism so as to ensure that 748 traffic characteristics provider is right the authorized application 749 the ISP has the charging agreement with. 751 3. Acknowledgements 753 The authors thank the attendees of the Bar BoF for contributing 754 towards this set of use cases. 756 4. Informative References 758 [I-D.conet-aeon-problem-statement] 759 Fan, P., Deng, H., Boucadair, M., Reddy, T., and C. Eckel, 760 "Application Enabled Collaborative Networking: Problem 761 Statement and Requirements", draft-conet-aeon-problem- 762 statement-00 (work in progress), May 2014. 764 [I-D.reddy-mmusic-ice-best-interface-pcp] 765 Reddy, T., Wing, D., Steeg, B., Penno, R., and V. Varun, 766 "Improving ICE Interface Selection Using Port Control 767 Protocol (PCP) Flow Extension", draft-reddy-mmusic-ice- 768 best-interface-pcp-00 (work in progress), October 2013. 770 [I-D.wing-mptcp-pcp] 771 Wing, D., R, R., Reddy, T., Ford, A., and R. Penno, 772 "Multipath TCP (MPTCP) Path Selection using PCP", draft- 773 wing-mptcp-pcp-00 (work in progress), October 2013. 775 [I-D.wing-pcp-third-party-authz] 776 Wing, D., Reddy, T., Patil, P., and R. Penno, "PCP 777 Extension for Third Party Authorization", draft-wing-pcp- 778 third-party-authz-03 (work in progress), April 2014. 780 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 781 Kaplan, "Requirements for an End-to-End Session 782 Identification in IP-Based Multimedia Communication 783 Networks", RFC 7206, May 2014. 785 Authors' Addresses 787 Wesley George 788 Time Warner Cable 789 13820 Sunrise Valley Drive 790 Herndon, VA 20171 791 US 793 Email: wesley.george@twcable.com 794 Peng Fan 795 China Mobile 796 32 Xuanwumen West Street 797 Beijing 100053 798 China 800 Email: fanpeng@chinamobile.com 802 Satoru Matsushima 803 SoftBank Telecom 804 1-9-1 Higashi-Shinbashi, Munato-ku 805 Tokyo 806 Japan 808 Email: satoru.matsushima@g.softbank.co.jp 810 Tirumaleswar Reddy 811 Cisco Systems, Inc. 812 Cessna Business Park, Varthur Hobli 813 Sarjapur Marathalli Outer Ring Road 814 Bangalore, Karnataka 560103 815 India 817 Email: tireddy@cisco.com 819 Charles Eckel 820 Cisco Systems, Inc. 821 170 West Tasman Drive 822 San Jose, CA 95134 823 US 825 Email: eckelcu@cisco.com