PPSP Xin.Wang Internet Draft Fudan University Intended status:Informational Jin.Zhao Expires: April 2011 Fudan University Zhicong.He Fudan University Guangzhao.Gu Fudan University Shihui.Duan China CATR October 25, 2010 A Router Caching Scheme for Streaming Media draft-wang-ppsp-router-caching-01.txt 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), 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 April 25, 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 Wang, et al Expires April 25, 2011 [Page 1] Internet-Draft router caching October 25, 2010 (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 Generally, streaming media content delivery on the Internet requires very high bandwidth and the streaming server usually endures a heavy burden to serve a large number of users. This document introduces a practical work for accelerating the delivery of streaming media based on router caching. In this document, it introduces some key problems in router caching scheme for video streaming. Then it gives a brief introduction on this scheme and especially discusses the streaming protocol and cooperative router caching protocol in detail. Wang, et al Expires April 25, 2011 [Page 2] Internet-Draft router caching October 25, 2010 Table of Contents 1. Introduction ................................................ 4 2. Document Conventions......................................... 4 2.1. Notational Conventions .................................. 4 2.2. Terminology ............................................ 4 3. Overview of Router Caching for Video Streaming ............... 5 3.1. Router Caching based Architecture ....................... 5 3.2. Scheme Implementation ................................... 6 3.3. Scheme Key Technologies ................................. 6 4. Protocol Design ............................................. 7 4.1. Streaming Protocol ...................................... 7 4.2. Cooperative Router Caching Protocol .................... 10 5. Validation of Cooperative Router Caching Scheme ............. 12 5.1. Overview .............................................. 12 5.2. Experimental Evaluation ................................ 12 6. PPSP Compatibility Considerations ........................... 14 7. Security Considerations ..................................... 15 8. IANA Considerations ........................................ 15 9. Conclusions ................................................ 15 10. References ................................................ 15 10.1. Normative References .................................. 15 10.2. Informative References ................................ 15 Wang, et al Expires April 25, 2011 [Page 3] Internet-Draft router caching October 25, 2010 1. Introduction Streaming media content delivery has become increasingly important because of the media content proliferation in many application areas such as education, medical treatment and entertainment. Generally these video streaming applications on the Internet have very high bandwidth requirements and the server endures a heavy burden. Proxy caching techniques prove to be a good approach to deliver text- based objects, but it faces many difficulties in delivering streaming media data due to much larger size of multimedia content and rigorous continuous delivery demand from clients. Currently, CDN (Content delivery network) and P2P (peer-to-peer) technology are two major methods to overcome the hurdles of high bandwidth requirements and heavy burden on the server. However, CDN servers are expensive to deploy and maintain, so the system has poor scalability. Generally speaking, although routers as basic network facilities are deployed everywhere on the Internet, they are not well applied in the streaming media scheme. Hence, we propose a distributed router caching method for video streaming. In our scheme, routers cache multimedia content with high popularity and respond clients' requests directly when cache hits. In this way, clients can get extremely small initial startup latency. Moreover, we propose CRCP (cooperative router caching protocol) to support more routers to participate in the streaming media scheme. With the cooperation of multiple routers, server loads can be greatly reduced and the total traffic over the backbone network can also be cut down. 2. Document Conventions 2.1. Notational Conventions 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 [RFC2119]. 2.2. Terminology Cache router: In our scheme, a router with cached multimedia data is called the cache router. Initial cache router: When a user request is intercepted by a cache router for the first time, this cache router is called the initial cache router. Wang, et al Expires April 25, 2011 [Page 4] Internet-Draft router caching October 25, 2010 Cooperative cache routers: As mentioned before, the initial cache router intercepts a user request and if the initial cache router cannot find the block which user requested in its caching, the initial cache router will send the user request to the other cache routers. These cache routers are called cooperative cache routers. Source server: In our scheme, the source server is an original streaming server. It can deliver all of the multimedia data to the users. Buffer map: Buffer map is a data structure that indicates if multimedia data exist in a cache router. 3. Overview of Router Caching for Video Streaming 3.1. Router Caching based Architecture As mentioned before, routers with the capability of caching multimedia data are called cache routers. Generally, in our scheme, the cache routers which are one kind of peers in the P2P streaming systems are deployed in the edge of the Internet. These cache routers are directly connected to the clients, so they are the nearest ones to the users. Thus, the client perceived startup latency almost can be ignored and the user experience is greatly enhanced. | +--------+ | +-----| client | | | +--------+ | | | +----------+ +--------------+ +--------+ | | |---| cache router |---| client | | +--------+ | | +--------------+ +--------+ | | Server |---| Internet | | +--------+ | | +--------------+ +--------+ | | |---| cache router |---| client | | +----------+ +--------------+ +--------+ | | | | +--------+ | +-----| client | | +--------+ | | Figure 1 The architecture of streaming systems with caching routers The architecture of streaming scheme based on cache routers is shown in Figure 1. As can be seen from the architecture, these cache Wang, et al Expires April 25, 2011 [Page 5] Internet-Draft router caching October 25, 2010 routers are directly connected to the clients. Consequently, the video data cached in these cache routers can be provided for the clients as soon as possible. Generally, the prefixes of popular videos are cached in these cache routers. As a result, initial startup latency can be greatly reduced. Furthermore, since all the cache routers can collaborate with each other to serve the clients, the server loads can also be cut down significantly. 3.2. Scheme Implementation Overall, there are four steps in our scheme and the details are described as follows. Step 1: In initial phase, a client sends connection request to a source server, and then the source server sends the playlist to the client. When the client receives the playlist from the source server, the user can choose his/her favorite video to play. Step 2: In data request phase, the client requests for the segments one by one. In our scheme, every video file is divided into some segments logically. Meanwhile every segment is divided into many blocks. Step 3: In cache searching phase, the cache router intercepts the user requests by the previous defined rules, and then the cache router will search blocks in its caching. Step 4: In cache cooperation phase, the initial cache router searches blocks in its cooperative cache routers by CRCP. Step 5: In server response phase, the source server sends those blocks that are not cached in all the cache routers to the client. 3.3. Scheme Key Technologies In this section, it presents with some key issues which should be settled in sec 3.2. 1. Cache routers need to know which blocks are required by the client, so we should design a structure that can indicate the requirement of the client, namely buffer map. 2. The router, as is well known, works in the network layer; now cache routers need to handle the services in the application layer. Therefore, we should design a new streaming protocol to support the cache routers to complete the above function. Wang, et al Expires April 25, 2011 [Page 6] Internet-Draft router caching October 25, 2010 3. Usually, the routers cannot swap extra messages except routing table information; so we should devise a new protocol to support all the cache routers exchanging control messages among these cache routers with each other. 4. Protocol Design 4.1. Streaming Protocol There are two aspects in streaming protocol. One of them is a scheme of the control messages exchanged among the peers in the streaming system, and the other scheme is that how multimedia data are transmitted over the Internet. The streaming control protocol is a set of rules of exchanging control messages among the clients, the cache routers and the source server. In the protocol, we establish a mapping of the router caching, namely buffer map. Every segment has one buffer map in which every bit shows whether the relevant block exists or not in the cache router. The detail of the streaming protocol is shown as following. The workflow of the streaming protocol is shown in Figure 2 and the detail procedure is illustrated as follows. 1. Build a connection between the client and the source server; 2. A unique peer ID is assigned for the client by the source server; 3. The client sends a request which includes a buffer map of a segment to the source server and the format of control message is explained later; 4. The initial cache router captures the request by the method of DPI and gets the buffer map, and then the cache router can obtain the information about cache hit or cache miss; 5. The initial cache router sends cached blocks in its caches to the client; 6. The cache router updates the buffer map and sends the new buffer map to the source server; 7. When the streaming server receives the new buffer map, it will send all the required blocks which are indicated in the new buffer map; 8. After the client sends its request, it will receive blocks from the cache routers or the source server, but actually the client Wang, et al Expires April 25, 2011 [Page 7] Internet-Draft router caching October 25, 2010 doesn't know where the blocks come from. In other words, the cache routers are transparent to the client. 9. The client checks its buffer map periodically. If all the blocks in this segment have been received, the client will request for the next segment. Otherwise, the client sends the latest buffer map again. +--------------------------------------------------------+ | +---------------------+ | | | Source server | | | +---------------------+ | | | ^ | | ----...--- | | | | | | | | | Internet | | Request | | | | | | | ---------- | | | / \ | | | +-------------+ +-------------+ | | | Router1 | | Router 2 | | | +-------------+ +-------------+ | | ^ | content ^ content | | | | available | unavailable | | Request | v Request| | | +------------+ +------------+ | | | Client1 | | Client2 | | | +------------+ +------------+ | +--------------------------------------------------------+ Figure 2 Streaming scheme based on cache routers Wang, et al Expires April 25, 2011 [Page 8] Internet-Draft router caching October 25, 2010 In the streaming control protocol, the control message is encapsulated into an IP packet as follows. +------------------------------------------------------------+ | +--------------------------------------------------------+ | | |Application layer | | | | +----+ +-------+ +--------+ +----------+ +-----------+ | | | | |Type| | PeerID| | VideoID| | SegmentID| | Buffer Map| | | | | +----+ +-------+ +--------+ +----------+ +-----------+ | | | +--------------------------------------------------------+ | | +--------------------------------------------------------+ | | | |---------------------------------------------------| | | | | | UDP | | | | | +---------------------------------------------------| | | | | IP Network | | | | | | | +--------------------------------------------------------+ | +------------------------------------------------------------+ Type: The type field represents the type of this packet, indicating this message is from a client or a cooperative router. Peer ID: In the initial phase, the source server assigns a unique identifier for every client to manage all the clients. Video ID: Obviously, Video ID clearly shows that which video is being watched by the user. Buffer Map: This field is very important in the streaming protocol. This identifier is to indicate which blocks are required by client. Every segment has a buffer map, and the size of the buffer map is about 32 bytes. Every bit of the buffer map indicates whether this block is required or not. As aforementioned, the block is a basic unit cached in a cache router. The multimedia data are encapsulated into an IP packet as follows: Wang, et al Expires April 25, 2011 [Page 9] Internet-Draft router caching October 25, 2010 +------------------------------------------------------------+ | +--------------------------------------------------------+ | | |Application layer | | | | +----++------++-------++---------++-------++-------+ | | | | |Type||PeerID||VideoID||SegmentID||BlockID||Payload| | | | | +----++------++-------++---------++-------++-------+ | | | +--------------------------------------------------------+ | | +--------------------------------------------------------+ | | | |---------------------------------------------------| | | | | | UDP | | | | | +---------------------------------------------------| | | | | IP Network | | | | | | | +--------------------------------------------------------+ | +------------------------------------------------------------+ BlockID: This field indicates that the payload belongs to which block. Payload: The real data of multimedia. 4.2. Cooperative Router Caching Protocol The cooperative router caching protocol is a supplement for the streaming protocol. The strategy in a cache router is different from the one in the streaming protocol. When a cache router updates the client's buffer map, it doesn't forward the new buffer map directly to the source server; instead the initial cache router firstly forwards the new buffer map to its cooperative cache routers. These cooperative cache routers will send feedbacks to the initial cache router. The initial cache router collects all the feedbacks from these cooperative cache routers and obtains the latest buffer map. At last, the initial cache router sends the latest buffer map to the source server. In this way, all the cooperative cache routers can serve the client together. The workflow of CRCP is shown in Figure 3 and the detail of CRCP is as follows. 1. The initial cache router intercepts the user request by the rules previous defined; 2. The initial cache router gets the buffer map in the user request; 3. The buffer map is updated according to the caching scheme in the initial cache router; Wang, et al Expires April 25, 2011 [Page 10] Internet-Draft router caching October 25, 2010 4. The hit blocks in the initial cache router are sent to the client. Meanwhile, the new buffer map is forwarded to the cooperative cache routers; 5. When the cooperative cache routers receive the new buffer map, they do the same operations as the initial cache router does. In other words, the cooperative cache routers send hit blocks to the client and send feedbacks that indicate which blocks are cached in their caches to the initial cache router; 6. After the initial cache router collects the feedbacks in a certain period time, it forms a latest buffer map and sends the latest buffer map to the source server; +-------------------------------------------------------------+ | +-------------+ Request +------------+ | | | Router1 | <------------ | Router 2 | | | +-------------+ ---- +------------+ | | ^ | content | provide ^ content | | | | available | content | unavailable | | Request | v | Request| | | +------------+ | +------------+ | | | Client1 | -------> | Client2 | | | +------------+ +------------+ | +-------------------------------------------------------------+ Figure 3 Workflow of CRCP The format of messages in CRCP is as follows. +--------------------------------------------------------------+ | +----------------------------------------------------------+ | | |Application layer | | | | +----++--++----++------++-------++---------++----------+ | | | | |Type||IP||Port||PeerID||VideoID||SegmentID||Buffer Map| | | | | +----++--++----++------++-------++---------++----------+ | | | +----------------------------------------------------------+ | | +----------------------------------------------------------+ | | | +---------------------------------------------------+ | | | | | UDP | | | | | +---------------------------------------------------+ | | | | IP Network | | | | | | | +----------------------------------------------------------+ | +--------------------------------------------------------------+ IP: Client IP address Wang, et al Expires April 25, 2011 [Page 11] Internet-Draft router caching October 25, 2010 Port: Client port 5. Validation of Cooperative Router Caching Scheme 5.1. Overview We do some measurement and experiments in the prototype system to validate the cooperative router caching scheme. Hereby we present the numerical experiments that we have conducted to evaluate the performance of the scheme. 5.2. Experimental Evaluation We set up a streaming system based on cache routers. In the system, there are some cache routers, a number of clients and a single source server. All the cache routers are in the same autonomous domain, and they can cooperate with each other. In the prototype system, all the cache routers have the same hardware and software configuration: Intel Pentium D 2.80GHz, 1G memory; OS is Linux operating system, and the server is simulated by PC (Intel Core Dual-Core CPU, T5670 1.80GHz, 2G RAM). The links between routers and clients are connected by the Ethernet. Below we show the experimental results as follows. 1. average startup delay Parameters configurations: Server bandwidth B=4000KBps, cache ratio = 0.10 User number 100 200 300 400 500 600 Average startup delay (s) With CRCP: 13 14 15 18 18 22 Without CRCP: 43 74 121 154 307 340 Parameters configurations: User number N = 120, cache ratio R = 0.10 Server bandwidth (KBps) 32 64 256 512 1024 2048 Average startup delay (s) With router caching: 14 14 15 16 15 15 Without router caching: 60 56 53 51 46 44 Wang, et al Expires April 25, 2011 [Page 12] Internet-Draft router caching October 25, 2010 When we introduce the router caching scheme in the streaming system, the average startup delay is always low in different scenarios; while if there is no caching scheme in the cache routers, the average startup delay increases sharply with the increase of user number. 2. server bandwidth cost Parameters configurations: cache ratio R = 0.10 User number 100 200 300 400 500 600 Server bandwidth cost (KBps) With router caching: 1024 1109 1331 1536 1689 1850 Without router caching: 1231 1515 1588 1817 2053 2107 Parameters configurations: user number N = 200 Cache ratio of media file (%) 0.10 0.12 0.14 0.16 0.18 0.20 Server bandwidth cost (KBps) With CRCP: 1105 1017 927 849 703 452 Without CRCP: 1697 418 1387 1374 1258 1152 In the first scenario, the bandwidth consumption of server is rising with the increase of concurrent users. Nevertheless, compared to the case of without router caching, the bandwidth consumption of server in the case of with router caching can be reduced by 10%. In the second scenario, if there is no CRCP in the scheme, the bandwidth cost of server is reduced from 1697KBps to 1152KBps (reduced by 32%); while in the case of with cooperative caching, the bandwidth cost of server is reduced from 1105KBps to 452KBps (reduced by 59%). It shows that the cache size has an important impact on the performance of the server. 3. reduction of network traffic Parameters configurations: User number N = 200, server bandwidth B = 4000KBps Cache ratio of media file (%) 0.10 0.12 0.14 0.16 0.18 0.20 Traffic reduction (%) Wang, et al Expires April 25, 2011 [Page 13] Internet-Draft router caching October 25, 2010 With CRCP: 5 25 39 53 65 71 Without CRCP: 3 18 25 28 35 42 4. Overhead of cache routers' CPU Parameters configurations: User number N = 200, server bandwidth B = 4000KBps Cache ratio of media file (%) 0.10 0.12 0.14 0.16 0.18 0.20 Overhead of CPU (%) With CRCP: 1.3 1.3 1.3 1.3 1.3 1.3 Without CRCP: 1.3 1.3 1.25 1.2 1.2 1.2 This part shows the extra usage of CPU due to running CRCP in cache routers. Anyway, only additional 1.3% of CPU has been occupied by running CRCP. In other words, the introduction of CRCP doesn't make the cache routers endure much more burden. Through the above measurement, the conclusion is: 1. The scheme of cooperative router caching for streaming systems can reduce the initial startup delay greatly even with the increase of user number. 2. The scheme proves to be an appropriate method in the streaming systems. When the cache ratio reaches to 0.20, more than half of the server bandwidth cost and the traffic over backbone network can also be prominently cut down. 6. PPSP Compatibility Considerations As we known, the objective of the PPSP work is to standardize the key signaling protocols among various P2P streaming system components including the tracker and the peers. Regarding to the components it involves, PPSP allows effective integration between the peer index servers named tracker and different kinds of peers including edge infrastructure nodes such as cache, gateway and CDN nodes who can act as super peers and ordinary peers. In our scheme, the cache routers can be one kind of super peers in the P2P streaming system. In P2P streaming system, a P2P cache refers to a network entity that caches P2P traffic in the network, and either transparently or Wang, et al Expires April 25, 2011 [Page 14] Internet-Draft router caching October 25, 2010 explicitly as a peer distributes content to other peers. While in our scheme, edge routers cache popular video data in their caches and transparently provide contents for the clients. These edge routers can be considered as P2P caches in P2P streaming systems. Moreover, the proposed streaming protocol and CRCP work at the application layer. Therefore, the proposed scheme is fully compatible with PPSP. 7. Security Considerations This draft does not introduce any new security issues. 8. IANA Considerations This memo includes no request to IANA. 9. Conclusions The router caching scheme is proposed for video streaming systems. By caching popular video contents on the cache routers in the edge of the Internet, the server load and the traffic transmission over the backbone network are greatly reduced and the user experience is improved significantly. Moreover, CRCP is proposed to enable the cache routers cooperation to further improve the performance of the streaming systems. Besides, the most important thing is that the cooperative router caching scheme can be well applied to the P2P streaming systems. Finally, if we pay more attention to the distributed cache storage and replacement policy, that would allow the system to gain more benefits from cooperative router caching scheme. 10. References 10.1. Normative References [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] [RFC5861] Mark Nottingham, "HTTP Cache-Control Extensions for Stale Content", RFC 5861, May 2010. 10.2. Informative References [3] [draft-zhang-ppsp-problem-statement-06] http://datatracker.ietf.org/doc/draft-zhang-ppsp-problem- statement-06 Wang, et al Expires April 25, 2011 [Page 15] Internet-Draft router caching October 25, 2010 [4] [draft-zong-ppsp-reqs-04] http://datatracker.ietf.org/doc/draft-zong-ppsp-reqs [5] [draft-gu-ppsp-peer-protocol-00] http://datatracker.ietf.org/doc/draft-gu-ppsp-peer-protocol/ [6] [draft-lei-sppsp-00] http://datatracker.ietf.org/doc/draft-lei- sppsp/ [7] Zhicong He, Zhongjie Huang, Jiawu Zhong, Guangzhao Gu Xin Wang, and Jin Zhao, A Cooperative Router Caching Scheme for Video Streaming Systems, in IEEE IPDPS, 2010, submitted [8] Jiawu Zhong, Zhicong He, Jun Li, Xin Wang, and Jin Zhao, Router Caching for Video Streaming Systems In Proc.USENIX Conference on File and Storage Technologies, Feb.2010: Poster Session Wang, et al Expires April 25, 2011 [Page 16] Internet-Draft router caching October 25, 2010 Authors' Addresses Xin Wang Fudan University Shanghai 201203, China Phone: 86-21-51355526 Email: xinw@fudan.edu.cn Jin Zhao Fudan University Shanghai 201203, China Phone: 86-21-51355526 Email: jzhao@fudan.edu.cn Zhicong He Fudan University Shanghai 201203, China Phone: 86-21-51355526 Email: hzcashy@gmail.com Guangzhao Gu Fudan University Shanghai 201203, China Phone: 86-21-51355526 Email: guangzhao.gu@gmail.com Shihui Duan China CATR Beijing 100191, China Phone: 86-10-62300068 Email: duanshihui@mail.ritt.com.cn Wang, et al Expires April 25, 2011 [Page 17]