Network Working Group Y. Lee (Huawei) G. Bernstein (Grotto) S. Hares (Huawei) Internet Draft F. Xia (Huawei) K. Shiomoto (NTT) Oscar Gonzalez de Dios (Telefonica) N. So (Verizon) Intended status: Informational Expires: July 2011 January 3, 2011 Problem Statement for Cross-Layer Optimization draft-lee-cross-layer-optimization-problem-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 3, 2011. Copyright Notice Lee, et al. Expires July 3, 2011 [Page 1] Internet-Draft Cross-Layer Optimization (CLO) January 2011 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Due to the lack of layer interaction between networked applications and the network during service provisioning, many end user applications and services cannot efficiently utilize the network capabilities, nor can achieve the desired quality of service objectives. This document describes the general problem of cross layer optimization. Cross-layer optimization (CLO) involves the overall optimization of application layer and network resources by providing an interface for interactions and exchanges between the two layers. The potential gains of cross layer optimization are illustrated via examples from content delivery systems, video on demand systems, and grid computing. Table of Contents 1. Introduction........................................ 3 1.1. Multi-domain, Multi-technology deployments............ 3 1.2. Short Statement of Problem......................... 4 1.3. Document Plan.................................... 4 2. Terms and Profiles.................................... 5 2.1. Terminology..................................... 5 2.2. Application Resource Categories..................... 5 2.3. Application Service Profiles ....................... 6 2.4. Network Capabilities categories..................... 7 2.5. Network Profile Information........................ 7 3. Network Application Examples ........................... 8 3.1. File Distribution Systems and Internet Content......... 9 3.1.1. Cache and Mirror placement problems ............. 9 3.1.2. Efficient Transfer of content to servers ........ 10 3.1.3. Client to server assignment problem ............ 10 3.2. Streaming Content Distribution Systems.............. 11 3.2.1. Live Streaming Issues........................ 11 3.2.2. On-Demand Streaming Issues.................... 11 3.3. Conferencing and Gaming .......................... 12 3.4. Grid Computing.................................. 12 Lee Expires July 3, 2011 [Page 2] Internet-Draft Cross-Layer Optimization (CLO) January 2011 4. Problem Statement ................................... 13 4.1. Synchronized Reception of Multiple Real-Time Topology and Traffic Engineering Related databases................... 13 4.2. Cross-Layer Cooperative Load and Traffic Monitoring Process14 4.3. Cross-Layer Synchronization of Configuration Changes... 15 4.4. Cross-layer Provisioning Process................... 15 5. Existing Solutions................................... 15 5.1. SNMPv3 Access models............................. 16 5.2. Netconf/yang ................................... 16 5.3. MPLS OAM....................................... 17 5.4. ITU........................................... 17 6. Security Considerations............................... 17 7. References......................................... 17 Author's Addresses..................................... 21 Intellectual Property Statement .......................... 21 Disclaimer of Validity.................................. 22 1. Introduction Application layer services by their very nature utilize application layer resources, and the underlying network resources. Application layer services can involve a variety of application layer resources such as data storage, computation, specialized server capabilities, and large data sets. However, the provisioning of network applications typically includes minimal or no information about the state of underlying network capabilities and resources. For example if an application client can obtain a desired large data set (file, video, database, etc...) from a choice of many different servers, the application service will take into account the current status and load on the servers but only minimal network considerations, such as topological proximity, connectivity, ping latency, rather than current link bandwidth utilization or other quality of service parameters (e.g., delay and jitter). 1.1. Multi-domain, Multi-technology deployments Application services may make significant demands on network resources such as bandwidth and may have a variety of quality of service requirements. Due to the lack of cross layer interaction between networked applications and the underlying networks during service provisioning, many application services make poor use of network resources or not achieve their overall quality of service objectives and/or being denied of service provisioning pre-maturely. As more applications begin to be fielded in "cloud computing" environments, the applications are being deployed on network resources across multiple domains on multiple types of network Lee Expires July 3, 2011 [Page 3] Internet-Draft Cross-Layer Optimization (CLO) January 2011 hardware. This trend to place more applications in "cloud" environments is project to grow. This document describes the general problem of cross layer optimization. Cross-layer optimization (CLO) involves the overall optimization of application layer and network resources by providing an interface for interactions and exchanges between the two layers. The potential gains of cross layer optimization are illustrated via examples from content delivery systems, video on demand systems, and grid computing. 1.2. Short Statement of Problem The lack of communication interface between the application layer and the network layer does not allow cross-layer optimization to be specified atomically and/or simultaneously to allow the following: a. Coordinated query of application and network requirements to available computing and network resources; b. Quick re-optimization based on policy of the application- network upon failures; and c. Coordinated cross-layer monitoring and provisioning process enabled based on synchronized application and network layer resource availability. Without linked management (OAM and monitoring) at multiple layers, the network operation of large applications causes churn at application layer to network layer. 1.3. Document Plan The document is organized as follows: o Terms and Profiles (section 2) o Network Application Examples (section 3) o Problem Statements (section 4) o Existing Solution (section 5) Lee Expires July 3, 2011 [Page 4] Internet-Draft Cross-Layer Optimization (CLO) January 2011 2. Terms and Profiles This section describes the basic terminology associated with cross- layer optimization, and provides descriptions on application profile, network capabilities and cross-layer profile information. 2.1. Terminology Application Layer -- The highest layer in the OSI or TCP/IP protocol models. Application Profile -- The characteristics of the application from a network traffic perspective and the QoS requirements that the application service will require from the network. Application Resources -- Non-network resources critical to achieving the application service functionality. Examples include: caches, mirrors, application specific servers, content, large data sets, and computing power. Application Service -- A networked application offered to a variety of clients. Network Layer -- All layers below and including layer 3 in the OSI protocol model that can contribute to meeting the requirements of an application service. This includes MPLS and GMPLS controlled networks. Network Resources -- Resources of any layer 3 or below such as bandwidth, connections, links, connection processing (creation, deletion, and management), and network databases. 2.2. Application Resource Categories Current and emerging application resources can be grouped into a number of categories as follows: o Live data sources -- such as video or audio from live sporting or entertainment events, data feeds from radio telescopes used in very long baseline interferometry, large particle physics experiments such as the LHC, or large chemistry databases. o Processing Resources -- such as raw computational capability for cloud computing, transactional capabilities for e-commerce, transcoding capabilities for video and audio. Lee Expires July 3, 2011 [Page 5] Internet-Draft Cross-Layer Optimization (CLO) January 2011 o Storage Resources -- such as disk spaces, tape libraries, online storage in memory, or in network storage, o Content/Data Sets -- the actual content of video, audio, commercial records (accounting, customer bases, employee records), or scientific data sets). These application resources may reside, and be stored and distributed around multiple networks to multiple users and clients. The geographical scope of a network application can be within a building, an enterprise, an autonomous system and/or be distributed amongst multiple autonomous systems. 2.3. Application Service Profiles An application service profile defines characteristics of the application from a network perspective and the QoS requirements that the service will require from the network. Each application is associated with the sources from which the application resources originate and the consuming locations (e.g., client locations) of the application resources. Application service profiles can be summarized into the following categories: o Security Profile: (i) dedicated end-to-end VPN-like resource allocation; (ii) dedicated physical resource allocation o Location profile: locations of both the clients and the sources o QoS profile: (i) Delay Tolerance Bound; (ii) Jitter Tolerance Bound; (iii) Packet Delivery Ratio Tolerance; (iv) Network Availability, etc. o Connectivity profile: (i) P-P; (ii) P-MP; (iii) MP-MP; (iv) Any cast, etc. o Directionality profile: (i) uni-directional; (ii) bi-directional o Bandwidth profile: Maximum, average, and minimum bandwidth requirements for the connectivity, maximum burst rate, maximum burst duration, etc. o Duration of service profile: service time of the application o Network media profile: (i) optical only; (ii) no microwave, etc. o Restoration profile: (i) Reroute required; (ii) do not re-route, etc. Lee Expires July 3, 2011 [Page 6] Internet-Draft Cross-Layer Optimization (CLO) January 2011 2.4. Network Capabilities categories Depending on the application, its nature, and related quality of service, the underlying network is required to have different capabilities. For our purposes here, network resources and capabilities can be summarized into the following categories: o Bandwidth capabilities --- the ability of the network to meet bandwidth profile requirements of the application service; o QoS and SLA -- the ability of the network to deliver according to the QoS profile requirements and the corresponding service level agreements (SLA). o Configurability -- the ability to reconfigure/re-optimize various aspects of the network and the timeliness in which changes can occur; and o Adaptability --- the ability to adapt changes due to changes of service demand or application/network congestion/failure. 2.5. Network Profile Information The ability to optimize the utilization of both application layer resources and network resources while meeting service goals will be highly dependent on the nature of the application and the properties of the network. The network profile information differs from the application service profile (described in section 2.3). The application service profile describes the characteristics of lower layers (transport and IP network) that the application requires. The network profile information describes the characteristics of the underlying IP network that is associated with application (IP, MPLS). The following is a non-exhaustive list of some underlying network types over which application services are transported and the information that could be shared to promote cross layer optimization: 1. Raw best effort IP network a. Location mapping of network resources for clients and application resources, and b. Available bandwidth by time of day; 2. Raw best effort IP network with tunable weights: Lee Expires July 3, 2011 [Page 7] Internet-Draft Cross-Layer Optimization (CLO) January 2011 In addition to basic network resource related location information as mentioned above, the following information can be shared between the layers. a. Data path with prioritization for traffic (IGP weights to request for application), b. Estimated offered load for each of the data paths, and c. Delay matrix allowable for these data paths; 3. Differentiated Services (Diff-Serve) capable network profiles a. Filtering linked to PHB profiles for data paths b. Estimated offered load for each of Diff-serve paths, and c. Policy on pre-emption of existing paths via Diff-Serv methodology or OAM; 4. MPLS-TE and/or GMPLS enabled networks: a. Ingress/Egress filters (QoS and Bandwidth), b. QoS and bandwidth requirements for the label switched path, c. Types of reroute/backup mandated, and d. Policies for inter-domain MPLS-TE linkage. 3. Network Application Examples Normally, a specification starts with the definition of the problem and applies it to applications. However, since the application drives the needs in the network, this discussion starts with the application. Application are grouped together in ascending order based in complexity on its QoS profile requirements and resource optimization. In the following examples, we'll start with the simpler problems in file distribution systems. From this point, we'll take up the real- time needs of streaming content distribution systems (live and on- demand) and grid computing applications. Lee Expires July 3, 2011 [Page 8] Internet-Draft Cross-Layer Optimization (CLO) January 2011 3.1. File Distribution Systems and Internet Content File distribution systems have been used in the Internet and have been accelerated by the download of web pages, particularly those with images. These systems have also expanded to include software, audio and, video file delivery available via the network. These are also known as content distribution systems, but we will use the name file distribution system to emphasize that these are concerned with the transfer of entire files and are not concerned with streaming services (covered in the next section). The applications distributing full files have the fewest network QoS requirements. Optimization goals of these systems include: o Reduction of latency to clients, o Offloading originating server, and o Conservation of network resources. File Distribution systems have been set up as overlays on existing network infrastructures. Commonly encountered optimization problems with network implications include: o Cache and Mirror placement problem o Efficient transfer of content to servers o Client to server assignment problem 3.1.1. Cache and Mirror placement problems The cache placement problem is concerned with what content to allocate to which cache servers based on their proximity to clients and their loading[Cache]. Mirrors differ from caches in that a client is only directed to a mirror if it has the desired content [Mirror]. The mirror or server replica placement problem is concerned with where to place a number of server given a fixed number of possible sites [Mirror],[Replica]. Depending upon the relationship between the file distribution service provider and the network provider the cache assignment problem comes in two flavors, o a general problem formulation with relatively arbitrary server placement, Lee Expires July 3, 2011 [Page 9] Internet-Draft Cross-Layer Optimization (CLO) January 2011 o and a specific formulation for Transparent En-Route Caches which are placed along the route from the client to the originating file server and work transparently from the client perspective [Cache]. All the processing placement optimizations work with knowledge of application topology some type of network topological information, e.g., relative link cost network models. Synchronization of the application and network (transport and IP) topological information is key to optimization. One note - exact network models are not always necessary to achieve significant performance improvements [Topo]. 3.1.2. Efficient Transfer of content to servers The efficient transport of the original content to the "replication" servers may be important for optimization when the amount of material becomes large. When dealing with a large set of replication servers and a large amount of data, original content delivery to replication servers benefits from point-to-multipoint concurrent path optimized for network loading conditions. To optimize these paths taken, the cross- layer optimizing process must have visibility into the underlying network resources. Synchronized optimization at multiple layers (application, transport and network) is necessary to create efficient transport of the original content to the replication servers. We will revisit this issue in the grid computing applications section. 3.1.3. Client to server assignment problem In assignment or selection of a content server for a particular client one would ideally take into account both current server load (application layer) and network latency between client and server [Topo]. In the streaming case bandwidth and QoS shall be taken into account. The streaming case increases the need for synchronized multi-layer monitoring and configuration. Lee Expires July 3, 2011 [Page 10] Internet-Draft Cross-Layer Optimization (CLO) January 2011 3.2. Streaming Content Distribution Systems Steaming services come in two basic flavors, live and on-demand. In addition many variants in between these two extremes are created when pause or replay functionality is included in a live streaming service. Streaming services are different from file download in a number of ways. First, the commencement of content consumption does not require an entire file to be downloaded. Second minimum bandwidth and QoS requirements are needed between the client and the server to render such services viable. Hence such services have a non-trivial service profile. 3.2.1. Live Streaming Issues By "live streaming" here we mean that the client is willing to receive the stream at its current play out point rather than at some pre-existing start point. A key network issue for live streaming services is whether multi-casting takes place at the application or network level. For example in carrier operated IPTV networks IP multi-casting is beginning to be used [IPTV]. In the case of an independent live video distribution service, one may make use of an overlay network of servers that provide the multi-casting. Examples of optimization problems for a live streaming service include: o Server selection problem (application based multi-cast) or leaf attachment problem (network based multi-cast)[ServMulti] o Server placement problem (application based multi-cast) or tree construction (network based multi-cast). 3.2.2. On-Demand Streaming Issues On-demand services provide additional technical challenges. Service providers wish to avoid long start up service delays to retain customers, while at the same time batch together requests to save on server costs. A number of additional optimization decisions and problems typically arise in the on-demand applications in addition to those seen in live streaming: o Client stream sharing technique o Batch or Multicast Server selection problem The on-demand streaming services problems are similar to those seen in file distribution. These problems are:(a) data allocation problem (when and where should we pre-stock video files), (b) on-demand Lee Expires July 3, 2011 [Page 11] Internet-Draft Cross-Layer Optimization (CLO) January 2011 server placement problem (where to put and how much capacity), and (c) efficient (cost effective and timely) transfer of content to servers. 3.3. Conferencing and Gaming Conferencing and gaming increase the complexity of the overall application connectivity, and the need for cross-layer synchronization of monitoring, configuration, and OAM. First, the issues associated with streaming discussed in Section 3.2 are also present with conferencing and gaming. Second, both conferencing and gaming are characterized by bi- directional connection and asymmetric bandwidth between the server and the user locations. Thirdly, the games require connectivity which is multipoint-to- multipoint with hard QoS constraint on latency. This change in complexity over the point-to-multipoint scenario of streaming content distribution brings additional problems as follows: o Data path formation and reformation for multipoint-to-multipoint can be very inefficient without considering the underlying network resources o QoS constraint on latency and bandwidth guarantee for multipoint- to-multipoint connectivity require coordination across the layers in terms of both path estimation and path reservation. Gaming, in particular massively multi-player online games (MMOGs), has the connectivity and QoS requirements of conferencing but many more issues related to the scale of application. Note that as a part of game play many gamers utilize audio conferencing services such as Ventrilo [VENT] and hence would generate well modeled audio conferencing traffic. Due to scalability concerns [GameServ] and the player desires [MPSel] server selection can be more complicated than that in the streaming content distribution case. 3.4. Grid Computing Grid computing supports extremely large transfers of files and data- streamed (live or on-demand). This large bandwidth requirement in volume and time differentiate this application profile. Lee Expires July 3, 2011 [Page 12] Internet-Draft Cross-Layer Optimization (CLO) January 2011 The volume of the traffic makes it critical to synchronize changes to the application and network. In addition grid computing may have a "streaming" requirement similar to the streaming content distribution systems but again with significantly reduced fan-out and sometimes extremely large bandwidth requirements. For example current estimates of the streaming traffic produce by one antenna in the proposed Square Kilometer Array (SKA) [SKA] is approximately 160Gbps with the array consisting of approximately 3000 antennas. Key issues associated with grid computing include: o Instantiation of the connectivity with high data rates and/or data set size o Controlling very high speed network Reference [GFD-122] details a number of grid use cases including visualization, large data streaming coordinated with job execution, High Energy Physics file replica management -- this is LHC related -- , health care, distributed manufacturing and maintenance, super computing, and Very Long Baseline Interferometery (radio astronomy). In some cases these applications run over shared research networks such as Internet2 [VLBI]. 4. Problem Statement The previous examples show the problems that occur when resources allocations for both application and network layers are not synchronized in their action. This section elaborates the problem statements for a number of essential processes associated with cross layer optimization. 4.1. Synchronized Reception of Multiple Real-Time Topology and Traffic Engineering Related databases As seen in the previous discussion of the applications, the processes of server selection and content placement can have dramatically better outcomes if network topology and application topology are known at the same time. It is critical to know where the application clients and servers are, and how they are connected at network layers. The ability to capture the data at the same instant allows planning during rapidly changing events or short bursty flows. For example, location selection for servers and clients requires that the Lee Expires July 3, 2011 [Page 13] Internet-Draft Cross-Layer Optimization (CLO) January 2011 performance estimates about the network and application layer align for applications that require stringent QoS level with bandwidth guarantee. It is necessary that querying information about the routing information (routes and packets) align with application layer information. As 90% of traffic [CAIDA] is short flows rather than long flows, the databases queried without time-based synchronization will provide an inaccurate representation of the network traffic flow. This will cause the algorithms trying to select viable multi- layer network topologies to select the wrong paths. This "topology" information does not need to be exact, but it needs to be synchronized across the layers. To aid in calculation, the reporting nodes at network and application may provide an abstracted set of data. However, they key point is the data needs to be synchronized across the layers. Even time based statics (such as network delay over a time period), must be synchronized to the other layers load conditions. Probing techniques, resource proximity or SNMP MIB monitoring techniques do not provide mechanisms to guarantee synchronization of the data collection. This higher level of synchronization is necessary to service: a) application with stringent QoS and Bandwidth, or to b) better schedule massive quantities of small data flows. IETF ALTO WG has been focusing on overlay optimization among peers by utilizing information about topological proximity and appropriate geographical locations of the underlay networks. With this method, an application may optimize selecting peer by location. This location information may help reduce IP traffic or restrict traffic to going through a single IP service provider. The current scope of the Alto work does not address the multi-layer synchronization problems this document has been discussing. ALTO servers collect and distribute the information regarding servers based on resource availability and usage of the underlying networks. The ALTO work does not provide the mechanisms to synchronize writes or read/writes within the network. 4.2. Cross-Layer Cooperative Load and Traffic Monitoring Process Load and traffic monitoring processes can be facilitated using an interface between Cross layer Optimization (CLO) entity and the Lee Expires July 3, 2011 [Page 14] Internet-Draft Cross-Layer Optimization (CLO) January 2011 management entities in the application, transport, and network layer stacks. The CLO entity can monitor at each layer QoS and loading. As the above examples have shown, it is important to have a synchronized read of QoS and loading at each layer. As loads shift or problems occur, it may be important to adjust the granularity of these measurements. Some processes that may need adjustment in granularity are: bandwidth use, bandwidth allocation/reservation, network delay statistics, existing client-server relationships, and statistics regarding allocating clients to servers. 4.3. Cross-Layer Synchronization of Configuration Changes Re-optimization of cross-layers by network management process requires synchronized configuration across multiple layers. Without it, one layer's flows may stray outside the planned network traffic patterns at other layers. 4.4. Cross-layer Provisioning Process The cross-layer connections need to be able to provision certain layers with additional connectivity. For example in MPLS-TE and/or GMPLS networks, the network CLO entity needs to be able to initiate connection setup on behalf of the various application entities (such as clients and servers). The UNI interface defined for GMPLS networks are currently defined for network equipment rather than interacting with application layer services. These UNI interfaces would need to be used to create new provisioned circuits. 5. Existing Solutions The problems stated in the previous section cannot be solved with existing mechanisms in IETF network management using: SNMP, netconf/yang, MPLS OAM, or ITU Y.2011 or Y.2012. Solutions to these problems need a fundamental addition to the concepts found in the SNMP context. Lee Expires July 3, 2011 [Page 15] Internet-Draft Cross-Layer Optimization (CLO) January 2011 5.1. SNMPv3 Access models The SNMPv3 [RFC2265] provides the idea of a SNMP context. This SNMP context is defined as: "An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts." This indicates that the SNMPv3 access models may allow multiple viewpoints on the same data. RFC 2261 states: "four pieces of information are [necessary to provide access to a piece of information]: [*] the snmpEngineID of the SNMP entity which provides access to the management information at device-X, [*] the contextName (device-X), [*] the managed object type ([such as] ifDescr), [*] and the instance ('1')." The missing piece is a Context with a management information view that allows synchronization of actions across multiple layers for read-view, write-view, notify-view and actions. While the SNMP context provides the fundamental building blocks, it is does not provide the necessary context to view multiple layers. This cross-layer optimization work requires standardization of these multi-layer, multi-device, multi-as contexts. 5.2. Netconf/yang Netconf provides an XML based access to SNMP MIB data. These data uses YANG to define the data model. The netconf/yang data model still uses the concepts found in the SNMP Access models of context for viewing data. The same lack of functionality for synchronization of multi-layer still exists in netconf/yang data models. These protocol lack synchronization of layers within a device, across multiple devices within a single Autonomous System (AS), and across multiple devices across multiple ASes. Lee Expires July 3, 2011 [Page 16] Internet-Draft Cross-Layer Optimization (CLO) January 2011 Note: Since some operations are switching to the netconf with yang data models, the Cross-Layer access model problem will need to be solved in the netconf/yang models as well as SNMP. 5.3. MPLS OAM MPLS OAM is limited to MPLS device. MPLS is regarded as one of the underlying network transport technologies that could enable cross- layer optimization with application layer; however, current scope of MPLS OAM does not support any non-MPLS device for its configuration and provisioning functions. 5.4. ITU ITU-T Y.2011 NGN and Y.2111 Resource and Admission Control Functions (RACF) discuss NGN service stratum separation from NGN transport stratum. ITU-T Y.2012 defines application network interface (ANI) which provides a channel for interactions and exchanges between applications and NGN elements. This interface is similar to the CLO interface. Y.2012 however does not address any details on the cross-layer synchronization. 6. Security Considerations TBD 7. References [RFC2261] D. Harrington, et al., "An Architecture for Describing SNMP Management Frameworks," January, 1998. [RFC2265] B. Wijnen, et al., "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)," January, 1998. [Y.2011] General principles and general reference model for Next Generation Networks, October, 2004. [Y.2012] Functional Requirements and architecture of the NGN, April, 2010. [Cache] P. Krishnan, D. Raz, and Y. Shavitt, "The cache location problem," Networking, IEEE/ACM Transactions on, vol. 8, 2000, pp. 568-582. Lee Expires July 3, 2011 [Page 17] Internet-Draft Cross-Layer Optimization (CLO) January 2011 [GameMirror] S.D. Webb, S. Soh, and W. Lau, "Enhanced mirrored servers for network games," Proceedings of the 6th ACM SIGCOMM workshop on Network and system support for games, Melbourne, Australia: ACM, 2007, pp. 117-122. [GameServ]P. Quax, J. Dierckx, B. Cornelissen, G. Vansichem, and W. Lamotte, "Dynamic server allocation in a real-life deployable communications architecture for networked games," Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games, Worcester, Massachusetts: ACM, 2008, pp. 66-71. [GameTrf] J. Farber, "Network game traffic modeling," Proceedings of the 1st workshop on Network and system support for games, Braunschweig, Germany: ACM, 2002, pp. 53-57. [GroupGame] K. Vik, C. Griwodz, and P. Halvorsen, "Applicability of group communication for increased scalability in MMOGs," Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games, Singapore: ACM, 2006, p. 2. [IPTV] A.A. Mahimkar, Z. Ge, A. Shaikh, J. Wang, J. Yates, Y. Zhang, and Q. Zhao, "Towards automated performance diagnosis in a large IPTV network," Proceedings of the ACM SIGCOMM 2009 conference on Data communication, Barcelona, Spain: ACM, 2009, pp. 231-242. [Mirror] E. Cronin, S. Jamin, Cheng Jin, A. Kurc, D. Raz, and Y. Shavitt, "Constrained mirror placement on the Internet," Selected Areas in Communications, IEEE Journal on, vol. 20, 2002, pp. 1369-1382. [MPSel] S. Gargolinski, C.S. Pierre, and M. Claypool, "Game server selection for multiple players," Proceedings of 4th ACM SIGCOMM workshop on Network and system support for games, Hawthorne, NY: ACM, 2005, pp. 1-6. [PartState] P.B. Beskow, K. Vik, P. Halvorsen, and C. Griwodz, "Latency reduction by dynamic core selection and partial migration of game state," Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games, Worcester, Massachusetts: ACM, 2008, pp. 79-84. [Replica] Lili Qiu, V. Padmanabhan, and G. Voelker, "On the placement of Web server replicas," INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, 2001, pp. 1587-1596 vol.3. Lee Expires July 3, 2011 [Page 18] Internet-Draft Cross-Layer Optimization (CLO) January 2011 [ServVoD] N. Carlsson and D.L. Eager, "Server selection in large- scale video-on-demand systems," ACM Trans. Multimedia Comput. Commun. Appl., vol. 6, 2010, pp. 1-26. [ServStream]M. Guo, M.H. Ammar, and E.F. Zegura, "Selecting among replicated batching video-on-demand servers," Proceedings of the 12th international workshop on Network and operating systems support for digital audio and video, Miami, Florida, USA: ACM, 2002, pp. 155-163. [ServMulti] Zongming Fei, M. Ammar, and E. Zegura, "Multicast server selection: problems, complexity, and solutions," Selected Areas in Communications, IEEE Journal on, vol. 20, 2002, pp. 1399-1413. [SKA] P.E. Dewdney, P.J. Hall, R.T. Schilizzi, and T.J.L.W. Lazio, "The Square Kilometre Array," Proceedings of the IEEE, vol. 97, 2009, pp. 1482-1496. [Stream] D. Eager, M. Vernon, and J. Zahorjan, "Minimizing bandwidth requirements for on-demand data delivery," Knowledge and Data Engineering, IEEE Transactions on, vol. 13, 2001, pp. 742-757. [Topo] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, "Topologically-aware overlay construction and server selection," INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, 2002, pp. 1190-1199 vol.3. [VENT] http://www.ventrilo.com/ [VLBI] http://www.internet2.edu/science/vlbi.html [WoWHrs] P. Tarng, K. Chen, and P. Huang, "An analysis of WoW players' game hours," Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games, Worcester, Massachusetts: ACM, 2008, pp. 47-52. [WoWAct] M. Suznjevic, M. Matijasevic, and O. Dobrijevic, "Action specific Massive Multiplayer Online Role Playing Games traffic analysis: case study of World of Warcraft," Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games, Worcester, Massachusetts: ACM, 2008, pp. 106-107. Lee Expires July 3, 2011 [Page 19] Internet-Draft Cross-Layer Optimization (CLO) January 2011 [GFD-122] Tiziana Ferrari (editor), "Grid Network services Use Cases from the e-Science Community", GFD-I-122, Open Grid Forum, December 12, 2007. [CDN2001] B. Krishnamurthy, C. Wills, and Y. Zhang, "On the use and performance of content distribution networks," Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, San Francisco, California, USA: ACM, 2001, pp. 169-182. Lee Expires July 3, 2011 [Page 20] Internet-Draft Cross-Layer Optimization (CLO) January 2011 Author's Addresses Young Lee Huawei Technologies 1700 Alma Drive, Suite 500 Plano, TX 75075 USA Phone: (972) 509-5599 Email: ylee@huawei.com Greg M. Bernstein Grotto Networking Fremont California, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Susan Hares Huawei Technologies Email : shares@huawei.com Frank Xia Huawei Technologies 1700 Alma Drive, Suite 500 Plano, TX 75075 USA Phone: (972) 509-5599 Email: xiayangsong@huawei.com Kohei Shiomoto NTT Email : shiomoto.kohei@lab.ntt.co.jp Oscar Gonzalez de Dios Telefonica Email : ogondio@tid.es Ning So Verizon Business Email: ning.so@verizonbusiness.com Intellectual Property Statement Lee Expires July 3, 2011 [Page 21] Internet-Draft Cross-Layer Optimization (CLO) January 2011 The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee Expires July 3, 2011 [Page 22]