idnits 2.17.1 draft-zhang-ppsp-usage-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Hongke Zhang 2 Internet Draft Fei Song 3 Intended status: Informational Di Wu 4 Expires: September 4 2017 Mi Zhang 5 Tianming Zhao 6 Beijing Jiaotong University 7 February 28, 201717 9 Usage of the Peer-to-Peer Streaming Protocol (PPSP) 10 draft-zhang-ppsp-usage-06.txt 12 Abstract 14 This document concerns several significant operation issues of Peer- 15 to-Peer Streaming Protocol (PPSP) usage, focusing on two basic modes 16 Leech mode and Seed mode. The related parameters setting for default 17 PPSP scenario reference to tracker protocol and peer protocol 18 respectively. Besides, the limitations and gaps of current PPSP 19 system are identified at with the standpoint of satisfying PPSP 20 requirements. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute working 29 documents as Internet-Drafts. The list of current Internet-Drafts is 30 at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 4, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction ................................................ 2 57 2. Terminology ................................................. 3 58 3. Operation of PPSP System .................................... 3 59 3.1. Operation Overview...................................... 3 60 3.2. Operation Illustration.................................. 4 61 4. Suggestions for Parameters Setting in PPSP System........... 10 62 4.1. Parameters Setting in Tracker Protocol................. 10 63 4.2. Parameters Setting in Peer Protocol.................... 11 64 5. Limitations and Gaps Analysis ............................... 12 65 6. Security Consideration...................................... 13 66 7. IANA Considerations ........................................ 13 67 8. References ................................................. 13 68 8.1. Normative References................................... 13 69 8.2. Informative References ................................. 14 70 9. Acknowledgments............................................ 14 72 1. Introduction 74 The Peer-to-Peer Streaming Protocol (PPSP) supports two kinds of 75 streaming which include live and Video on Demand (VoD). It is 76 constitutive of two basic protocols: the PPSP peer protocol 77 [RFC7574] and the PPSP tracker protocol 78 [I-D.ietf-ppsp-base-tracker-protocol].Both of them are proposed 79 from individual perspective based on PPSP 80 structure. However, the end users are unnecessary to understand the 81 whole procedure works and the parameters setting when combining 82 above two mentioned protocol together in application. What's more, 83 the potential limitations of current protocol should also be learnt 84 and known to the community. 86 The tracker protocol which in a request/response model handles the 87 initial and periodic exchange of meta-information between trackers 88 and peers. The peer protocol is supposed to run as a gossip like 89 protocol controls the advertising and exchange of media data 90 directly among the peers. It currently runs on the top of UDP using 91 LEDBAT for congestion control. 93 This document includes several important operation issues in PPSP 94 usage, considering two basic modes: Leech mode and Seed mode. In 95 addition, the tracker protocol and peer protocol respectively give 96 the related parameters setting for default PPSP scenario. The 97 standpoint of satisfying PPSP requirements identifies the 98 limitations and gaps of current PPSP system. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC-2119 [RFC2119]. 106 The document makes extensive use of the terminology and definitions 107 inherited from Concepts and Terminology for PPSP peer protocol 108 [RFC7574] and PPSP-TP/1.0 [I-D.ietf-ppsp-base-tracker-protocol] in 109 this document. 111 3. Operation of PPSP System 113 Different with previous protocol-related drafts, the operation 114 process of PPSP system in this document focuses on how to associate 115 multiple entities working together, such as peers, trackers, 116 portals, etc., and achieve corresponding functions. Both 117 macroscopic overview and detailed steps are provided in the 118 following sections. 120 3.1. Operation Overview 122 The PPSP supports two kinds of modes including real-time and VoD 123 streaming modes which involve two protocols: the PPSP tracker 124 protocol and the PPSP peer protocol. 126 The tracker refers to a directory service that maintains a list of 127 active peers participating in a specific audio/video channel or in 128 the distribution of a streaming file. It is a logical entity, which 129 can be centralized or distributed, and in this document, it is 130 treated as a single logical entity. 132 The peer refers to a participant in a P2P streaming system that 133 both receives streaming content and caches streaming content to 134 other participants. Based on the properties of peers, there are 135 two different modes (Leech mode and Seed mode) in PPSP. It will be 136 detailed in Section 3.2. 138 The basic communication unit of PPSP is message. In peer protocol, 139 multiple messages are typically multiplexed into a single datagram 140 in transmission process. And in the PPSP system, there are several 141 rules MUST be obeyed. 143 1. In the same swarm, the same chunk addressing method MUST be used 144 to ensure that peers can communicate with each other smoothly. 146 2. The portal needs to pick an appropriate tracker supporting the 147 same encoding type as the peer. Additionally, the portal needs to 148 distinguish the VoD streaming from live streaming and then selects 149 the app ropriate tracker for peers. 151 3.2. Operation Illustration 153 The normal operation process of the PPSP system is illustrated in 154 Figure 1. The related entities and elements are described as follows 156 Tracker: A logical entity that provides the peer list to peers. 158 Portal: A logical entity that provides the Media Presentation 159 Description (MPD) files to peers. 161 Peer A: A peer that has content resource and wants to share it with 162 others. (PeerMode is of Seed) 164 Peer B: A peer that wants to join swarm x to obtain the content 165 provided by Peer A. (PeerMode is of Leech) 167 Peer C (Peer D): A peer that obtain the content provided by Peer A 168 through joining swarm x. And it has finished part of the content 169 transmission. (PeerMode is of Leech) 171 Assume that Peer A (Seeder) attends to share a static/dynamic video 172 content with other peers. Firstly, Peer A MUST send a CONNECT message 173 to a tracker to start/join swarm x. 175 After a correct CONNECT message is received, the tracker responses to 176 Peer A with an OK message. 178 In order to keep in swarm x, Peer A should send the STAT_REPORT 179 message to the tracker periodically. Normally, it is recommended 3 180 minutes for setting the value of Track_timeout (More details 181 described in section 4). An OK message should be generated and sent 182 back to Peer A whenever STAT_REPORT message reaches the tracker. 184 Assume that Peer B (Leecher) attends to watch this video content 185 provided by Peer A. Hence, Peer B need connect and login in a service 186 Portal with its peer ID to get the MPD file, includes the IP 187 address(es) of tracker(s) and swarm x's ID of the selected swarm x. 189 Then Peer B starts to communicate with the tracker and try to join 190 the swarm x by sending a CONNECT message to the tracker. This will 191 trigger the tracker to send response back to Peer B with an 192 OK+PeerList message if previous check was correct. The message 193 provides Peer B a proper list including peers' name and IP addresses 194 (only Peer A and its address here). 196 Till now, Peer B realizes which peer (Peer A here) has already been 197 in the swarm x. It sends a datagram with HANDSHAKE message to Peer A 198 (Due to there is only a seeder in the swarm x). The payload of the 199 HANDSHAKE message is a channel ID and a sequence of protocol options. 201 Then Peer A determines whether to communicate with Peer B base on 202 considering the status and current network capacities. Once Peer A 203 decides to make respondence, it returns a datagram wit HANDSHAKE+HAVE 204 message to Peer B.(HS is the abbreviation of HANDSHAKE in Figure 1) 206 Then Peer A determines whether to communicate with Peer B base on 207 considering the status and current network capacities. Once Peer A 208 decides to make respondence, it returns a datagram wit HANDSHAKE+HAVE 209 message to Peer B.(HS is the abbreviation of HANDSHAKE in Figure 1) 211 After acquiring the acknowledgement of Peer A, Peer B updates 212 PeerList as OPTIONAL through another way (sending PEX_REQ message to 213 Peer A). The message will help Peer B to discover other new peers, 214 which could not be provided by the tracker. 216 Peer A returns a datagram with PEX_RES message. Assume it including 217 the information of Peer C and Peer D. 219 As mentioned before, if Peer B attends to initial a new conversation 220 with Peer C or D, it MUST send a datagram including HANDSHAKE 221 message. 223 Similar with Peer A, Peer C or D needs to decide whether it will 224 reply Peer B or not. If Peer C is willing to contact with Peer B. It 225 responds a datagram containing HANDSHAKE+HAVE message. If Peer D 226 attends to deny Peer B, it MUST reply a datagram including the 227 HANDSHAKE+HAVE+CHOKE message. 229 Once receiving previous datagram, Peer B checks the messages and 230 obtains which is available for communidation. Then it sends datagrams 231 containing the REQUEST message to Peer A and C asking for chunks. 233 After Peer A or C receives the Peer B's request, it SHOULD send the 234 datagram to Peer B. The content of datagram depends on the video 235 type: INTEGRITY+DATA message for static video and SIGNED_INTEGRITY+ 236 DATA message for dynamic video. 238 +-------+ +------+ +------+ +------+ +------+ +------+ 239 |Tracker| |Portal| |Peer A| |Peer B| |Peer C| |Peer D| 240 +-------+ +------+ +------+ +------+ +------+ +------+ 241 | | | | | | 242 |<-CONNECT(Join Swarm x)| | | | 243 |--------OK------------>| | | | 244 |<----STAT_REPORT-------| | | | 245 |---------OK----------->| | | | 246 : : | | | 247 | |<-----Select Swarm x----| | | 248 | |--------OK+MPD(x)------>| | | 249 |<-------CONNECT(Join Swarm x)-------| | | 250 |------------OK+PeerList------------>| | | 251 : : | | 252 | |<-HANDSHAKE-| | | 253 | |--HS+HAVE-->| | | 254 | |<-PEX_REQ---| | | 255 | |--PEX_RES-->| | | 256 | | |-HANDSHAKE->| | 257 | | |-------HANDSHAKE------>| 258 |<-----STAT_REPORT------| | | | 259 |----------OK---------->| |<-HS+HAVE---| | 260 : : |<----HS+HAVE+CHOKE-----| 261 | |<--REQUEST--|--REQUEST-->| | 262 | |---DATA---->|<----DATA---| | 263 | |<--ACK,HAVE-|-ACK,HAVE-->| | 264 | : : : | 265 |<---------STAT_REPORT---------------| | 266 |-------------OK-------------------->|<--------UNCHOKE-------| 267 | | |---------REQUEST------>| 268 : | :<---------DATA---------| 269 | | |---------ACK,HAVE----->| 270 : |<---HAVE----|----HAVE--->| | 271 | | |<--REQUEST--| | 272 | | |<--------REQUEST-------| 273 | | |----DATA--->| | 274 | | |----------DATA-------->| 275 | : : : : 276 | |<-KEEPALIVE-|-KEEPALIVE->| | 277 | | |--------KEEPALIVE----->| 278 |<-------------------STAT_REPORT------------------| | 279 |------------------------OK---------------------->| | 280 | |<-HANDSHAKE-|-HANDSHAKE->| | 281 | | |----------HANDSHAK---->| 282 |<---CONNECT/FIND(Leave Swarm x)-----| | 283 |<---CONNECT/FIND(Join Swarm y,z)----| | 284 Procedures of PPSP System 286 According to the corresponding data received, Peer B replies 287 adatagram Containing an ACK message to Peer A and C. Peer B SHOULD 288 also send a datagram containing HAVE message to all other peers in 289 the swarm x for announcement purpose. The timing of sending HAVE 290 message depends on Peer B. 292 In order to demonstrating all the functionalities, Peer D is supposed 293 to release previous rejection for Peer B by sending an UNCHOKE 294 message. 296 Then, Peer B can send a new REQUEST message to Peer D. 298 Peer D replies with the actually data message. After the content 299 integrality is verified, Peer B MAY send HAVE message to other peers 300 in swarm x. 302 Peer C and D can also require the Peer B chunks by sending REQUEST 303 message. Whether the corresponding chunks could be sent or not 304 depends on Peer B. 306 If the above peers attend to keep in the swarm, they need to send the 307 STAT_REPORT message to the tracker while send the KEEP_ALIVE message 308 to other peers periodically. 310 After all the necessary content is received successfully, Peer B can 311 close the connection by sending a HANDSHAKE message to all peers in 312 swarm x. An all 0-zeros channel ID MUST be embedded in HANDSHAKE 313 message. Meanwhile, Peer B SHOULD send STAT_REPORT or CONNECT message 314 to log out and eliminate its state in tracker. 316 Peer B MAY employ CONNECT message to join a new swarm, such as swarm 317 y or z in Figure 1. Similar instruction mentioned before can 318 becapitalized on data exchanging. 320 Useful Message List: 322 o CONNECT message 324 This message is used to register/leave a PPSP system and request 325 swarm actions with tracker. 327 o FIND message 329 This message is used to request a new peer list to tracker whenever 330 needed. It is also used when a peer attends to leave the PPSP system 331 with tracker. 333 o STAT_REPORT message 335 This message is used to send status and statistic data to tracker, in 336 order to facilitate the tracker service. This message MUST be 337 periodically sent while the peer is active. 339 o OK message 341 This message is used for tracker to convey that has successfully 342 received the last message. 344 o OK+PeerList message 346 This message is used for tracker to respond proper PeerList to peer. 348 o HANDSHAKE message 350 This message MUST be sent as the first message in the first datagram 351 between peers, in order to start communication between peers. 353 o HAVE message 355 This message is used to convey which chunks a peer has available for 356 download. 358 o DATA message 360 This message is used to transfer chunks of content. 362 o ACK message 364 This message is used to acknowledge received chunks after receiving a 365 DATA message. 367 o REQUEST message 369 This message is used to request one or more chunks from another peer. 371 o INTEGRITY message 373 This message carries information required by the receiver to verify 374 the integrity of a chunk. It is usually used in static content. 376 o SIGNED_INTEGRITY message 378 This message is used to verify chunks in live streaming. 380 o CHOKE message 382 The message is used to inform another peer that it will no longer 383 respond to any REQUEST massages from that peer. 385 o UNCHOKE message 387 This message is used to inform another peer that it will respond to 388 new REQUEST messages from that peer again. 390 o PEX_REQ & PEX_RES messages 392 These message allows peers to exchange the transport addresses of the 393 peers they are currently interacting with, thereby reducing the need 394 to contact a central tracker. 396 o KEEPALIVE message 398 This message SHOULD be sent periodically to each peer it wants to 399 interact with in the future. 401 4. Suggestions for Parameters Setting in PPSP System 403 In the procedure of constructing the PPSP system, parameters setting 404 is absolutely crucial. This section will discuss related issues in 405 tracker protocol and peer protocol. The default values are provided 406 as references. The practical setting can be adjusted according to 407 different scenarios 409 4.1. Parameters Setting in Tracker Protocol 411 Table 1 shows parameters, their default values and description in the 412 PPSP tracker protocol. 414 +--------------------+------------+------------------------------+ 415 | Name | Default | Description | 416 +--------------------+------------+------------------------------+ 417 | Init_timeout | 30 seconds | Maximum value of the "init | 418 | | | timer" used in the "per peer | 419 | | | transaction state machine" | 420 | Track_timeout | 3 minutes | Maximum value of the "track | 421 | | | timer" used in the "per peer | 422 | | | transaction state machine" | 423 | STAT_REPORT Period| 3 minutes | Maximum period of STAT_REPORT | 424 | | | message | 425 | Retry_timeout | 3 minutes | Maximum waiting time until a | 426 | | | peer initiates a retry process| 427 | ConcurrentLinks | NORMAL | Concurrent connectivity level | 428 | | | of peers, HIGH, LOW or NORMAL | 429 | OnlineTime | NORMAL | Availability or online | 430 | | | duration of peers, HIGH or | 431 | | | NORMAL | 432 | UploadBWlevel | NORMAL | Upload bandwidth capability | 433 | | | of peers, HIGH OR NORMAL | 434 +--------------------+------------+------------------------------+ 435 Table 1 PPSP Tracker Protocol Defaults 437 4.2. Parameters Setting in Peer Protocol 439 For the PPSP peer protocol has a detailed description about 440 parameters, this section only assume it as a reference to summarize 441 Table 2, which reveals some of the parameters default values and 442 descriptions. Some parameters should be recommended as a fixed value 443 while others should alter according to users' demands or network 444 conditions. 446 +---------------------+-------------+-----------------------------+ 447 | Name | Default | Description | 448 +---------------------+-------------+-----------------------------+ 449 | Chunk Size | var | (Maximum) Size of a chunk | 450 | | 1024 bytes | | 451 | | recommended | | 452 | Static Content | 1 (Merkle | Methods for protecting the | 453 | Integrity Protection| Hash Tree) | integrity of static content | 454 | Method | | | 455 | Live Content | 3 (Unified | Methods for protecting the | 456 | Integrity Protection| Merkle Tree | integrity of static content | 457 | Method | | including "sign all" and | 458 | | | "Unified Merkle Tree" | 459 | Merkle Hash Tree | 0 (SHA1) | Hash function used for the | 460 | Function | | Merkle Hash Tree | 461 | Live Signature | 13 (ECDSAP2 | Must be defined for live | 462 | Algorithm | 56SHA256 | streaming | 463 | Chunk Addressing | 2 (32-bit | Methods of chunk addressing | 464 | Method | chunk | | 465 | | ranges) | | 466 | Live Discard Window | var | Must be defined for live | 467 | | | streaming | 468 | NCHUNKS_PER_SIG | var | Must be defined in the | 469 | | | Signed Munro Hash | 470 | Dead peer detection | No reply in | Guideline for declaring a | 471 | | 3 minutes + | peer is dead | 472 | | 3 datagrams | | 473 | KEEPALIVE Period | 2 minutes | Maximum period for a peer | 474 | | | to send KEEPALIVE datagram | 475 | | | to other peers | 476 +---------------------+-------------+-----------------------------+ 477 Table 2 PPSP Peer Protocol Defaults 479 5. Limitations and Gaps Analysis 481 This section aims to identify the limitations and gaps of the current 482 PPSP system from the standpoint of satisfying PPSP requirements. 484 1. One of the PPSP target is extending current Peer-to-Peer (P2P) 485 system in mobile and wireless environments [RFC6972]. However, the 486 message used in PPSP system does not include related information 487 such as the packet loss rate and battery status, which is 488 essential for wireless and mobile environments. 490 2. The PPSP system provides two ways to acquire the PeerList. Peer 491 can obtain the PeerList from the tracker or they can get it 492 through the PEX_REQ and PEX_RES messages. When both methods are 493 available, it is not definite to update the local PeerList 494 efficiently. 496 3. The STAT_REPORT message of tracker protocol does not support 497 exchange the content data information between an active peer and a 498 tracker. Thus, whenever a new peer wants to join a swarm, the 499 relevant tracker could only employ PeerMode to choose the PeerList 500 and return the new peer. In the cases which there is only one 501 seeding peer while other peers that already finished part of the 502 content transmission and are willing to share with others. 503 Therefore, the tracker could not provide the high quality PeerList 504 but just a seeder. Thus, the peer could only update PeerList 505 relying on the PEX-REQ message. 507 4. In some cases, the user may want to adjust the video definition 508 based on the bandwidth (or user demand) automatically (or 509 manually). Or the user may watch videos and play online games at 510 the same time, and he/she doesn't want the videos occupy too much 511 of the bandwidths. This will need adaptive multi-rate control for 512 both users and ISPs. Rather than limiting the download links 513 throuth ISPs or government, it is better to add some controllable 514 limits in the protocol. 516 5. For safety and manageability reasons, PT (private tracker) has 517 become popular in recent years. It is uncertain whether this 518 should be taken into consideration in PPSP. If the answer is 519 positive, the tracker protocol should make some changes in finding 520 & connecting private tracker and add data traffic statistics part. 522 6. Security Consideration 524 This document does not contain any security considerations. 526 7. IANA Considerations 528 There are presently no IANA considerations with this document. 530 8. References 532 8.1. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 8.2. Informative References 539 [RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- 540 Peer Streaming Peer protocol (PPSPP)", RFC 7574, October 2015. 542 [I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., 543 Gu, Y.,Xia, J., and J. Taveira, "PPSP Tracker Protocol-Base Protocol 544 (PPSP-TP/1.0)", draft-ietf-ppsp-base-tracker-protocol-12 545 (work in progress),January 2016. 547 [RFC6972] Zhang, Y. and N. Zong, "Problem Statement and 548 Requirements of the Peer-to-Peer Streaming Protocol (PPSP)", 549 RFC 6972, July 2013. 551 9. Acknowledgments 553 This document was prepared using 2-Word-v2.0.template.dot. 555 Authors' Addresses 557 Hongke Zhang 558 Beijing Jiaotong University (BJTU) 559 Beijing, 100044, P.R.China 561 Email: hkzhang@bjtu.edu.cn 563 Fei Song 564 Beijing Jiaotong University (BJTU) 565 Beijing, 100044, P.R.China 567 Email: fsong@bjtu.edu.cn 569 Di Wu 570 Beijing Jiaotong University (BJTU) 571 Beijing, 100044, P.R.China 573 Email: diwu2@seas.upenn.edu 575 Mi Zhang 576 Beijing Jiaotong University (BJTU) 577 Beijing, 100044, P.R.China 579 Email: 13120174@bjtu.edu.cn 580 Tianming Zhao 581 Beijing Jiaotong University (BJTU) 582 Beijing, 100044, P.R.China 584 Email: 14125070@bjtu.edu.cn