DECADE Xiao.Zhu Internet Draft BUPT Intended status: Informational Yunfei.Zhang Expires: June 26, 2011 Jin.Peng China Mobile December 27, 2010 Additional protocol requirements on DECADE draft-zhu-decade-additional-requirements-00 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 27, 2011. Copyright Notice 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The DECoupled Application Data Enroute(DECADE)working group is specifying standardized interfaces for accessing in-network storage zhu Expires June 26, 2011 [Page 1] Internet-Draft Additional protocol requirements on DECADE December 2010 from applications to store, retrieve and manage data. The main object is to provide a framework that is useful to the applications, including P2P applications and other data-oriented applications, possibly related applications that can benefit from accessing in- network storage. This memo focuses on some requirements such as request redirecting and so on which are on the central of mobility, wireless network environment and CDN application. We present these in this memo as additional requirements that should be considered for the DECADE architecture and protocol specifications. Table of Contents 1. Introduction ................................................ 2 2. Terminology ................................................. 3 3. Protocol requirements........................................ 3 3.1. Request redirect requirement............................ 3 3.1.1. Discussion......................................... 4 3.2. Multi-connection requirement............................ 5 3.3. Data distribution requirement........................... 6 3.3.1. Discussion......................................... 6 3.4. Service assurance related feedback requirements......... 7 3.4.1. Discussion......................................... 7 4. Storage requirements......................................... 7 4.1. Data classification storage requirement ................ 7 4.2. Small objects storage requirement ...................... 8 5. Open issues ................................................. 8 5.1. Removal of Expired Records.............................. 8 6. Security Considerations...................................... 9 7. IANA Considerations ......................................... 9 8. References .................................................. 9 8.1. Normative References.................................... 9 9. Acknowledgments ............................................. 9 1. Introduction DECADE (DECoupled Application Data Enroute) is an architecture that provides applications with access to in-network storage. The target of DECADE is to provide an open and standard in-network storage system for application, primarily P2P applications, to store, retrieve and manage their data [draft-ietf-decade-reqs-00]. And the [draft-ietf-decade-reqs-00] presents that the DECADE support majority of existing application, including P2P application and none P2P application. As considering CDN application and the mobility scenarios, we present a set of requirements that should be met by the DECADE architecture design in order to guarantee its applicability to zhu Expires June 26, 2011 [Page 2] Internet-Draft Additional protocol requirements on DECADE December 2010 such applications. We propose that these requirements be added to the DECADE requirements specification. In this memo, we align the requirement description to the layout and requirements classification used in [draft-ietf-decade-reqs-00]. rd th Section 3 and 4 describes the additional protocol requirements and th storage requirements separately, and section 5 presents and discuses the corresponding open issues that are mentioned in [draft- ietf-decade-reqs-00] or some issues should be considered to ensure a broad enough applicability of the DECADE framework 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. This memo uses terminology and definitions defined in DECADE [I- D.ietf-decade-problem-statement]. Terms defined in this memo: o Serving-in-network storage: the in-network storage which actually send data to user. o Proxy-in-network storage: the selected in-network storage in which the resource is ingested initially. 3. Protocol requirements 3.1. Request redirect requirement Request redirecting is responsible for routing client request to the appropriate in-network storage for the delivery of data. That suits the following situations: o Adaptive in-network storage selection Due to the different copies deployment over the network, the serving-in-network storage status and the dynamic change of network environments, the serving-in-network storage may not be suitable any more. So, DECADE must support redirecting the client request to the best suitable in-network storage. It may use a set zhu Expires June 26, 2011 [Page 3] Internet-Draft Additional protocol requirements on DECADE December 2010 of metrics, such as network proximity, available bandwidth, and client perceived latency, distance, and in-network storage load and other factors, in an attempt to find the appropriate in- network storage that can best serve the request. The selected in- network storage delivers requested data to the end-users. Thus, transparency for users is achieved. However, how to select the best in-network storage is out of scope of the DECADE. This approach helps to reduce network impact on the response time of user requests and performs load balancing across a number of in-network storages and increase the system capacity under load. A centralized in-network storage can act at the front end of an in- network storage farm and redirects the data request to a nearby application-specific in-network storage. Hence, the centralized in-network storage gathers necessary information in order to make load balancing decisions. o Mobility With the rapid development of the types and users of data service in the mobile terminal and the traffic generated by data service, DECADE must support the application in wireless network environment and have the ability to support roaming for terminals/users/applications by allowing the use of in-network storage in the visited network [draft-ohlman-decade-add-use-cases- reqs-01]. Actually the mobility situation can also be understood as part of the dynamic change of network environments mentioned in the first point, but the in-network storage before may remain suitable after the terminal roaming. However, in order to reduce the cross network traffic, the request redirection may be needed. 3.1.1. Discussion 3.1.1.1. The existing protocol requirements The following point mentioned in [draft-ietf-decade-reqs-00]: o Some applications may have requirements on delivery time (e.g., live streaming). The DECADE MUST provide "low-latency" access for application clients. DECADE MUST allow clients to specify at least two classes of services for service: lowest possible latency and latency non-critical. the requirement here needs the request redirect to implement. zhu Expires June 26, 2011 [Page 4] Internet-Draft Additional protocol requirements on DECADE December 2010 3.1.1.2. The existing protocols The following existing protocols are put forward to give some idea for this kind of scenario: o NECP [draft-cerpa-necp-01]: the Network Element Control Protocol is a lightweight protocol for signaling between servers and the network elements that forward traffic to them. The network elements consist of a range of devices, including content-aware switches and load-balancing routers. NECP allows network elements to perform load balancing across a farm of servers and redirection to interception proxies. o WCCP [draft-wilson-wrec-wccp-v2-01]: The Web Cache Coordination Protocol specifies interaction between one or more routers and one or more Web-caches. It runs between a router functioning as a redirecting network element and interception proxies. The selected traffic is redirected to a group of Web-caches in order to increase resource utilization and to minimize response time. 3.2. Multi-connection requirement User accesses data stored in multiple storages simultaneously when: o Having multiple serving-in-network storages Users may have the serving-in-network storages at the same time. In that case, the multi-connection may be established between client and other serving-in-network storages, which may need information interaction between different connections to avoid the operation unsynchronized. For example, client deletes the data uploaded to multiple in-network storages at the same time. And the operation of deletion to different storage may decide deleting different parts (chunk-level or piece- level) of the data, which needs to be coordinated. Or considering the requirement descried in [draft-ietf-decade-reqs-00] as data reuse, the operation launched in different connection may work with the same data. o Supporting "soft handover" in wireless network and the in-network storage change The request-routing requirement mentioned before may lead the change of serving-in-network storage. The handover of the serving-in-network storages needs to the "soft" to ensure the service continuity. That zhu Expires June 26, 2011 [Page 5] Internet-Draft Additional protocol requirements on DECADE December 2010 requires the connection between the client and the current serving- in-network storage will not be disconnected until the new establish of connection between client and the new serving-in-network storage. That means user needs to communicate with multiple in-network storage about the data transmission proceeding simultaneously. Meanwhile, in the mobility scenario, the access network may change, e.g., change from the 3G to wLan, when user moves. The different access network has the different authorization and authentication mechanism and message flow, which means the DECADE IAP support the smooth transition between the different authorization and authentication mechanisms. 3.3. Data distribution requirement Data distribution is strategically vital in DECADE for efficient data delivery and for overall performance. Each of in-network storages wants to delivery their data to users over the network in a reliable and timely manner. The data is moved from the proxy-in-network storage (which has stored the data initially) to the other in-network storage which can be selected according to some principals. The distribution is transparent to the users as they interact with the in-network storage as a single logical system. In the P2P file sharing or P2P file downloading or similar applications, data distribution will help applications complete the data publication. Client will upload its data in the in-network storage and hope other clients may get the data in time, especially when the client is content provider. The serving-in-network storage will be act as a proxy-in-network storage to complete the data distribution in the DECADE. The process and result of data distribution may be decided by the range (number of domain) and granularity of distribution (piece-level or content-level way), and the access control, authentication and authorization information of distributed data and other relative complementary parameters configured manually or automatically. 3.3.1. Discussion o The requirement is a kind of typical CDN scenario. o The targeted in-network storage in the process of data distribution can be selected based on kinds of factors, including the technical factors, e.g. the data type (static, dynamic and streaming content), or some business factors, e.g. distribution range. zhu Expires June 26, 2011 [Page 6] Internet-Draft Additional protocol requirements on DECADE December 2010 3.4. Service assurance related requirements Actually, service assurance related requirements refer to control mechanisms in the DECADE service to ensure a certain level of performance to a data flow. That means service quality should be achieved in the DECADE service. Quality of service is the ability to provide different priority to different applications, users, or data flows to guarantee a certain level of performance, which is important to the application and user experience, especially for real-time streaming application. 3.4.1. Discussion Service assurance mechanisms can be classified by whether or not the receiver feedback to the sender. o Resource reservation The resource reservation mechanism is characterized by having no feedback between the receiver and the transmitter. This means resource allocation is made at connection setup using connection admission control and this allocation is made using information that is already "old news" during the lifetime of the connection. And the resource needed cannot change on demand. o Dynamical feedback The Dynamical feedback control mechanism is characterized by the ability of the network to report service parameters, e.g., service response time, back to the transmitter. This information is then used by the transmitter in various ways to adapt its activity to existing network conditions. But the feedback data will cause the load increasing, which will be a bad way in the congestion network. The mechanism may be taken either or both in DECADE or other mechanism if needed. 4. Storage requirements 4.1. Data classification storage requirement Different kinds of application data are stored in categories. For example, the data for streaming and the data for downloading are stored and process separately. That can be benefit in: o Speeding the data access and retrieve because of reducing the time looking up the content in category ; zhu Expires June 26, 2011 [Page 7] Internet-Draft Additional protocol requirements on DECADE December 2010 o Different kind of data has its own use pattern and its life cycle and also different process mechanism. The classification storage of data may improve the data use efficiency. 4.2. Small objects storage requirement The in-network storage should support the small objects (chunk-level or piece-level) storage, because: o In the existing DECADE requirement[draft-ietf-decade-reqs-00], the data object size in DECADE allow for efficient data transfer of small objects (e.g., 16KB) between DECADE client and in-network storage with minimal additional latency required by the protocol. What's more, mainstream P2P applications adopt the chunk or piece transition and chunk or piece storage mechanism. The storage should satisfy the existed requirement. o And the in-network storage has the limited storage capacity, with the arrival of user requests and data distribution requirements, the data stored in the in-network storage will be replaced if the storage reaches the limit and data arrivals continually. To ensure and complete the user`s data delivery, the data replaced will be in the size of small object. And that results in the small objects storage. 5. Open issues 5.1. Removal of Expired Records The [draft-ietf-decade-reqs-00] mentions the requirement that the DECADE should not provide ability to update existing objects. If a user needs to update a resource, it can store a new resource and then distribute the new resource instead of the old one. And the [draft- ietf-decade-reqs-00] also mentions that there are actually two possible scenarios here. The first is the case of removing duplicates within one particular DECADE server (or logical server). The second scenario is removing duplicates across a distributed set of DECADE servers. However, the two scenarios did not mention how to handle the old resource if the user distributes the new resource which is an updated copy of the old resource. Here, the older resource is flagged as expired record instantly as soon as the new version is uploaded. The deletion of the expired record will be adopted because of the content consistency, naming simplicity and content requested certainty. zhu Expires June 26, 2011 [Page 8] Internet-Draft Additional protocol requirements on DECADE December 2010 6. Security Considerations This document does not currently consider the security considerations of this approach. TODO. 7. IANA Considerations There are no IANA considerations with this document. 8. References 8.1. Normative References [1] [draft-ietf-decade-problem-statement-00] H. Song, N. Zong, Y. Yang, R. Alimi," DECoupled Application Data Enroute (DECADE) Problem Statement", draft-ietf-decade-problem-statement-00 (work in progress), Sep 25, 2010. [2] [draft-ietf-decade-reqs-00] Y. Gu, D. Bryan, Y. Yang, R. Alimi," DECADE Requirements", draft-ietf-decade-reqs-00 (work in progress), Sep 21, 2010. 9. Acknowledgments Thanks to the many people who contributed include Jin Peng, Yunfei Zhang, and Xiao Zhu. zhu Expires June 26, 2011 [Page 9] Internet-Draft Additional protocol requirements on DECADE December 2010 Authors' Addresses Xiao Zhu Beijing University of Posts & Telecommunications (BUPT) Phone: Email: zhu.xiao@139.com Yunfei Zhang China Mobile Phone: +8610-6600-6688 ext. 3214 Email: zhangyunfei@chinamobile.com Jin Peng China Mobile Phone: +8610-6600-6688 ext. 3252 Email: pengjin@chinamobile.com zhu Expires June 26, 2011 [Page 10]