idnits 2.17.1 draft-zhang-ppsp-protocol-comparison-measurement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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.) ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 420, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 423, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 434, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Y.Zhang 2 Internet Draft China Mobile 3 Intended status: Informational C.Li 4 Expires: January 2010 Beijing Jiaotong University 5 July 9, 2009 7 Protocol Analysis and Comparison of PPlive and PPstream by Internet 8 Measurement 9 draft-zhang-ppsp-protocol-comparison-measurement-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on January 9,2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your 42 rights and restrictions with respect to this document. 44 Internet-Draft Protocol Analysis and Comparison of PPlive and 46 Abstract 48 In this draft we introduce an Internet measurement work for both 49 pplive and ppstream. First, we give a brief introduction about our 50 motivation and target of this measurement. We then introduce the 51 methodology, platform, data and modeling of our measurement. Finally 52 we outline the p2p media streaming protocols by the measurement. 54 Internet-Draft Protocol Analysis and Comparison of PPlive and 56 Table of Contents 58 1. Introduction.................................................4 59 2. Motivation and Target of the Measurement.....................5 60 3. Methodology of Our Measurement...............................6 61 4. Measurement Platforms........................................8 62 5. Data Analysis and Modeling..................................10 63 6. Study of P2P Media Streaming Protocols by the Measurement...10 64 6.1. PPLive Live Streaming:.................................10 65 6.2. PPLive VoD.............................................11 66 6.3. PPStream Live (early version, TCP).....................12 67 6.4. UUSee Live.............................................12 68 6.5. Conclusion.............................................12 69 7. Security Considerations.....................................14 70 8. References..................................................15 71 8.1. Normative References...................................15 72 8.2. Informative References.................................15 74 Internet-Draft Protocol Analysis and Comparison of PPlive and 76 1. Introduction 78 P2P media streaming is one of the most popular p2p system and is a 79 new developing trend for modern video system. More and more users, 80 vendors as well as researchers have been attracted to it. Currently, 81 there are many such systems on Internet, such as PPLive, PPStream, 82 UUSee, etc. Usually all of them can provide Live and VoD programs to 83 users. They have a similar system structures according to our 84 measurement. In good network conditions, all of them can bring good 85 experiences to users; once the stable condition is broken, the p2p 86 applications will present different performance. 88 Internet-Draft Protocol Analysis and Comparison of PPlive and 90 2. Motivation and Target of the Measurement 92 Naturally, we care about how to evaluate system performance, what the 93 performance limitations are under current system models, how to 94 decrease the pressure on the network. In order to answer these 95 questions, we study the following aspects of p2p streaming systems: 97 1. To extract the general p2p media streaming system structure; 99 2. To analyze and evaluate the signaling (protocol) messages (types, 100 format, function, exchange sequence); 102 3. To study and model the core mechanism such as initial buffer lag 103 policy, buffer cache schedule policy, data fetching policy, etc; 105 4. To optimize the system performance and improve network robustness; 107 5. To study its effect on physical layer network, transport lay 108 protocol (TCP and UDP ); 110 6. To study new p2p suitable transport protocol instead of 111 application lay p2p transportation; 113 7. To study the availability of current p2p streaming systems on 114 mobile ip; 116 8. To present related standard suggests. 118 Internet-Draft Protocol Analysis and Comparison of PPlive and 120 3. Methodology of Our Measurement 122 Real network based measurement is important in studying p2p media 123 streaming systems. However all current commercial p2p media streaming 124 systems are propriety protocol systems without any public document 125 about system' working mechanism available. Although some researchers 126 report some useful finds, most of our concerns are not resolved yet. 127 We have to firstly deeply understand how the system works. Usually we 128 use certain reverse-engineering method to analyze its working 129 principle. In the protocol cracking, we mainly focus on the top 2 of 130 very popular p2p streaming systems - PPLive and PPStream. Beside 131 their popular degree, several other reasons make them as the starting: 132 Both of them use plain text in their protocol exchanging; both udp 133 and tcp are adopted; both of them are the new generation data driven 134 p2p streaming systems. 136 Our reverse engineering are conducted in following 3 stages: 138 Firstly, by tracing a standard client, we capture interactive packets 139 between the local peer and others with ethereal/windump tool. Based 140 on our experience on the p2p streaming system, some basic protocol 141 types must be included such as buffer map, chunk request/response, 142 shake hand packet, etc. For each udp packet, it is reasonable to 143 assume that each packet is a completed protocol message, while for 144 tcp packets we must extract messages from all application data stream. 145 Usually we can get the rough protocol format by matching traced 146 packets to the known basic protocol types. But there are still many 147 unknown details left. 149 Secondly, the traced data is fed into our dumping tool, which can 150 filter data into a text file with composed conditions, such as source 151 ip/port, destination ip/port, VoD/Live protocol type. Through 152 inspecting the text file of different channels, we find many regular 153 changes that help us in parsing the protocol format in details. Of 154 course, there is still one-third irregular data. In this case, we 155 guess and try it based on our experiences in next step. At last, we 156 parse about nearly 90% of PPLive and PPStream while 50% UUSee 157 protocols(mostly because its signaling is encrypted). In PPLive 158 system, there are about 15 message types, all of that haven't any 159 clearly protocol marks in order to escape from restrictions ISPs may 160 imposed on as we guess. Among these types, buffermap and peerlist 161 messages are the most useful messages for us to measure and analyze 162 the system. 164 At the third stage, we analyze the time sequences of the protocol 165 messages. Some communication time sequence is obvious, such as chunk 167 Internet-Draft Protocol Analysis and Comparison of PPlive and 168 request/response, while others are not. In later case, we guess and 169 try differently composed events until a sequence makes right sound. 170 Ultimately, all time sequences in communications are resulted 171 successfully. 173 Internet-Draft Protocol Analysis and Comparison of PPlive and 175 4. Measurement Platforms 177 For different analysis, we take different measurement methods. In 178 general, our environment consists of 4 dell pc servers in a private 179 ip space (LAN) behind a 6mbps ADSL NAT router. each of which has 180 2.8Hz Pentium CPU, 1MB memory, 80GB hard disk, 10/100Mbps Ethernet, 181 windows OS, mysql database. 183 +------------------------------------------------+ 184 | crawler tracker server peer | 185 | | | | | 186 | | Shake hand | | | 187 | |------------------>| | | 188 | | Peerlist request | | | 189 | |------------------>| | | 190 | | Peerlist response| | | 191 | |<------------------| | | 192 | | | | | 193 | |Notification for connecting a peer X | | 194 | |------------------>| | | 195 | | Shake hand to peer x | | 196 | |-------------------|---------------->| | 197 | | Buffermap of peer x | | 198 | |<------------------|-----------------| | 199 | | | | | 200 | |Notification for connecting a peer y | | 201 | |------------------>| | | 202 | | Shake hand to peer y | | 203 | |-------------------|---------------->| | 204 | | Buffermap of peer x | | 205 | |<------------------|-----------------| | 206 | | | | | 207 +------------------------------------------------+ 209 Figure 1 Protocol sequence for crawling 211 1. Official client trace: use tcpdump/windump/wireshark to capture 212 exchanging packets between local peer and other peers. 214 2. System topology crawler: based on p2p streaming protocol, design 215 legal measurement tool to detect the whole network in short time. We 216 usually take some measures improve the probing efficiency such as 217 multi threads, fast data searching in memory, multi-tables in 219 Internet-Draft Protocol Analysis and Comparison of PPlive and 220 databases, master-slave distribution deployment, concurrent tcp 221 session limitation enlargement. 223 3. Long term multi online peers probe: different from topology 224 crawler, it will probe a certain online peers in a long term in order 225 to collect the detail information of these peers. Usually more 226 complete protocol set should be realized in it. 228 4. P2P streaming client measurement in mobile ip: A fix position PC 229 is used as the mobile device, where three types of software have been 230 installed: p2p streaming client software; packet capture software; 231 our mobile ip simulation software. 233 5. Special client accessing to official network in order to evaluate 234 the system robusticity and optimize the protocol: based on 235 protocols,we build the legal p2p client to join in the official p2p 236 network. By this client, we can test and evaluate new protocol design 237 and new core system models. 239 Internet-Draft Protocol Analysis and Comparison of PPlive and 241 5. Data Analysis and Modeling 243 As for data analysis and modeling, we have made some progress and 244 published some papers [1]~[6]. Interested readers can refer to them 245 for more details. 247 6. Study of P2P Media Streaming Protocols by the Measurement 249 We have measurement PPLive and PPstream and guessed the protocols 250 both for live streaming and VoD streaming respectively. However due 251 to some encryption(It's said to be Scrambling), VoD streaming data 252 from PPStream hasn't been analyzed yet. We list the signaling 253 transaction of pplive live streaming and VoD and ppstream live 254 streaming as follows: 256 6.1. PPLive Live Streaming: 258 Messages with Tracker 260 0101 (peer registration) 262 0100 (tracker response) 264 0201 (peerlist request) 266 0200 (peerlist response) 268 0301 (tracker offset request) 270 0300 (tracker offset response) 272 Messages with Peer 274 0x4101 (peerlist request) 276 0x 4201 (peerlist response) 278 0x 5400 (peerlist response) 280 0x 4400 (Buffermap response) 282 0x 5200 (chunk request) 284 0x 5300 (chunk response) 286 Internet-Draft Protocol Analysis and Comparison of PPlive and 287 0x 4601 (chunk response) 289 0x 6101 (chunk request) 291 0x6201 (chunk response) 293 0x 4000 (disconnect) 295 0x4500 (chunk request) 297 0x4901 (udp handshake) 299 0x4400: update/5s 301 6.2. PPLive VoD 303 0x04 (peers_data_request) 305 0x05 (peers_data_response_1) 307 0x06 (peers_data_response_2) 309 0x11 (peers_peerlist_request) 311 0x12 (peers_peerlist_response) 313 0x13 (peers_shakehand) 315 0x14 (peers_bitfield) 317 0x16 (trk shakehand) 319 0x17 (trk notification of a peer) 321 0x18 (peers_keepalive) 323 0x43 (host_ip) 325 0x44 (public_ip) 327 0x51 (host_ip_format2) 329 0x52 (public_ip_format2) 331 Internet-Draft Protocol Analysis and Comparison of PPlive and 333 6.3. PPStream Live (early version, TCP) 335 0x02 (buffermap) 337 0x22 (buffermap) 339 0x03 (chunk request) 341 0x04 (chunk response) 343 0x05 (nochunk response) 345 0x08 (peerlist request) 347 0x09 (peerlist response) 349 0x40 (media information) 351 0x1d (client version) 353 0x10 (protocol error information) 355 0x1b (remote live time) 357 0x1 (peer id) 359 0x19 (remote refuse) 361 0xA0 (vod bitmap) 363 6.4. UUSee Live 365 0x01080909 (UUSEE_MSG_HANDSHAKE_REQ) 367 0x014203e9 (UUSEE_MSG_HANDSHAKE_PEERLIST) 369 0x014403e9 (UUSEE_MSG_HANDSHAKE_BUFFERMAP) 371 0x014503e9 (UUSEE_MSG_HANDSHAKE_CHUNKREQ) 373 0x18070514 (UUSEE_MSG_HANDSHAKE_ACK) 375 6.5. Conclusion 377 PPLive, PPStream and UUSee all support Live and VoD programs, and 378 have similar system structures. As for the signaling protocol, both 380 Internet-Draft Protocol Analysis and Comparison of PPlive and 381 systems have similar process. We have depicted the interactions 382 between peers and peers as well as trackers in the problem statement 383 draft. Interested readers can refer to draft-zhang-ppsp-problem- 384 statement for details. 386 However, there are still some difference between pplive,UUsee and 387 ppstream which belongs to their high secrets. For example, in the 388 buffer aspect, pplive and UUSee have a large buffer, which can smooth 389 time delay jitters but contributes to relative large startup delay. 390 The chunk fetch policy is seqential fetcing and rarest first at same 391 time. The schema of the buffer is a variable length in chunks but 392 fixed length in playback time. The buffer map schedule is simple 393 based on chunksid. On the other hand, PPStream is a small buffer 394 system (early version), which has small startup delay but leads to 395 video freeze with large jitters. The chunk fetch is randomly in each 396 buffer window. The schema of the buffer is of multi playable media 397 blocks with fixed playback time (mulit buffers) for each of them. 398 Hence its buffer schedule is based on multi buffer windows, where 399 each chunk is uniquely marks indicated by the buffer window offset 400 and the internal chunk id. According to our understanding, the 401 mechanism of PPStream is a litter complex. 403 Internet-Draft Protocol Analysis and Comparison of PPlive and 405 7. Security Considerations 407 We don't involve security measurement till now. 409 Internet-Draft Protocol Analysis and Comparison of PPlive and 411 8. References 413 8.1. Normative References 415 [1] Y. Chen, C. Chen and C. Li, "A Measurement Study of Cache 416 Rejection in P2P Live Streaming System", Workshop on Multimedia 417 Network Systems and Applications in conjunction with ICDCS-2008, 418 June, 2008, Beijing, China 420 [2] Y. Chen, C. Chen and C. Li, "Measure and Model P2P Streaming 421 System by Buffer Bitmap", HPCC '08, Sept. 2008, Dalian, China 423 [3] Cx.Li,Cj.Chen "Fetching Strategy in the Startup Stage of p2p 424 Live Streaming", http://arxiv.org/abs/0810.2134 426 [4] Cx.Li,Cj.Chen "Initial Offset Placement in p2p Live Streaming 427 Systems" http://arxiv.org/abs/0810.2063 429 [5] Cx.Li,Cj.Chen "Inferring Playback Rate and Rate Resets of p2p 430 Video Streaming Transmissions by Piecewise Line Envelope 431 Approximation" The Journal of China Universities of Posts and 432 Telecommunications March.2009 434 [6] Cx.Li,Cj.Chen "Real P2P System Measurement under Mobile IP 435 Environment" accepted by icnds2009 437 8.2. Informative References 439 Author's Addresses 441 Yunfei Zhang 442 China Mobile 444 Phone: 86 13601032119 445 Email: zhangyunfei@chinamobile.com 447 Chunxi Li 448 Beijing Jiaotong University 450 Phone: 86 10 51684757 451 Email: chunxili@yahoo.cn