idnits 2.17.1 draft-zhang-ppsp-usage-07.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 37 characters 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 (September 3, 2017) is 2426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: March 4 2018 Mi Zhang 5 Tianming Zhao 6 Beijing Jiaotong University 7 September 3, 2017 9 Usage of the Peer-to-Peer Streaming Protocol (PPSP) 10 draft-zhang-ppsp-usage-07.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 March 4, 2018. 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 [RFC7574] 77 and the PPSP tracker protocol [I-D.ietf-ppsp-base-tracker-protocol]. 78 Both of them are proposed from individual perspective based on PPSP 79 structure. However, the end users are unnecessary to understand the 80 whole procedure works and the parameters setting when combining 81 above two mentioned protocol together in application. What's more, 82 the potential limitations of current protocol should also be learnt 83 and known to the community. 85 The tracker protocol which in a request/response model handles the 86 initial and periodic exchange of meta-information between trackers 87 and peers. The peer protocol is supposed to run as a gossip like 88 protocol controls the advertising and exchange of media data 89 directly among the peers. It currently runs on the top of UDP using 90 LEDBAT for congestion control. 92 This document includes several important operation issues in PPSP 93 usage, considering two basic modes: Leech mode and Seed mode. In 94 addition, the tracker protocol and peer protocol respectively give 95 the related parameters setting for default PPSP scenario. The 96 standpoint of satisfying PPSP requirements identifies the limitations 97 and gaps of current PPSP system. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC-2119 [RFC2119]. 105 The document makes extensive use of the terminology and definitions 106 inherited from Concepts and Terminology for PPSP peer protocol 107 [RFC7574] and PPSP-TP/1.0 [I-D.ietf-ppsp-base-tracker-protocol] in 108 this document. 110 3. Operation of PPSP System 112 Different with previous protocol-related drafts, the operation 113 process of PPSP system in this document focuses on how to associate 114 multiple entities working together, such as peers, trackers, portals, 115 etc., and achieve corresponding functions. Both macroscopic overview 116 and detailed steps are provided in the following sections. 118 3.1. Operation Overview 120 The PPSP supports two kinds of modes including real-time and VoD 121 streaming modes which involve two protocols: the PPSP tracker 122 protocol and the PPSP peer protocol. 124 The tracker refers to a directory service that maintains a list of 125 active peers participating in a specific audio/video channel or in 126 the distribution of a streaming file. It is a logical entity, which 127 can be centralized or distributed, and in this document, it is 128 treated as a single logical entity. 130 The peer refers to a participant in a P2P streaming system that both 131 receives streaming content and caches streaming content to other 132 participants. Based on the properties of peers, there are two 133 different modes (Leech mode and Seed mode) in PPSP. It will be 134 detailed in Section 3.2. 136 The basic communication unit of PPSP is message. In peer protocol, 137 multiple messages are typically multiplexed into a single datagram in 138 transmission process. And in the PPSP system, there are several rules 139 MUST be obeyed. 141 1. In the same swarm, the same chunk addressing method MUST be used 142 to ensure that peers can communicate with each other smoothly. 144 2. The portal needs to pick an appropriate tracker supporting the 145 same encoding type as the peer. Additionally, the portal needs to 146 distinguish the VoD streaming from live streaming and then selects 147 the app ropriate tracker for peers. 149 3.2. Operation Illustration 151 The normal operation process of the PPSP system is illustrated in 152 Figure 1. The related entities and elements are described as follows: 154 Tracker: A logical entity that provides the peer list to peers. 156 Portal: A logical entity that provides the Media Presentation 157 Description (MPD) files to peers. 159 Peer A: A peer that has content resource and wants to share it with 160 others. (PeerMode is of Seed) 162 Peer B: A peer that wants to join swarm x to obtain the content 163 provided by Peer A. (PeerMode is of Leech) 165 Peer C (Peer D): A peer that obtain the content provided by Peer A 166 through joining swarm x. And it has finished part of the content 167 transmission. (PeerMode is of Leech) 169 Assume that Peer A (Seeder) attends to share a static/dynamic video 170 content with other peers. Firstly, Peer A MUST send a CONNECT message 171 to a tracker to start/join swarm x. 173 After a correct CONNECT message is received, the tracker responses to 174 Peer A with an OK message. 176 In order to keep in swarm x, Peer A should send the STAT_REPORT 177 message to the tracker periodically. Normally, it is recommended 3 178 minutes for setting the value of Track_timeout (More details 179 described in section 4). An OK message should be generated and sent 180 back to Peer A whenever STAT_REPORT message reaches the tracker. 182 Assume that Peer B (Leecher) attends to watch this video content 183 provided by Peer A. Hence, Peer B need connect and login in a service 184 Portal with its peer ID to get the MPD file, includes the IP 185 address(es) of tracker(s) and swarm x's ID of the selected swarm x. 187 Then Peer B starts to communicate with the tracker and try to join 188 the swarm x by sending a CONNECT message to the tracker. This will 189 trigger the tracker to send response back to Peer B with an 190 OK+PeerList message if previous check was correct. The message 191 provides Peer B a proper list including peers' name and IP addresses 192 (only Peer A and its address here). 194 Till now, Peer B realizes which peer (Peer A here) has already been 195 in the swarm x. It sends a datagram with HANDSHAKE message to Peer A 196 (Due to there is only a seeder in the swarm x). The payload of the 197 HANDSHAKE message is a channel ID and a sequence of protocol options. 199 Then Peer A determines whether to communicate with Peer B base on 200 considering the status and current network capacities. Once Peer A 201 decides to make respondence, it returns a datagram wit HANDSHAKE+HAVE 202 message to Peer B.(HS is the abbreviation of HANDSHAKE in Figure 1) 204 Then Peer A determines whether to communicate with Peer B base on 205 considering the status and current network capacities. Once Peer A 206 decides to make respondence, it returns a datagram wit HANDSHAKE+HAVE 207 message to Peer B.(HS is the abbreviation of HANDSHAKE in Figure 1) 209 After acquiring the acknowledgement of Peer A, Peer B updates 210 PeerList as OPTIONAL through another way (sending PEX_REQ message to 211 Peer A). The message will help Peer B to discover other new peers, 212 which could not be provided by the tracker. 214 Peer A returns a datagram with PEX_RES message. Assume it including 215 the information of Peer C and Peer D. 217 As mentioned before, if Peer B attends to initial a new conversation 218 with Peer C or D, it MUST send a datagram including HANDSHAKE message. 220 Similar with Peer A, Peer C or D needs to decide whether it will 221 reply Peer B or not. If Peer C is willing to contact with Peer B. It 222 responds a datagram containing HANDSHAKE+HAVE message. If Peer D 223 attends to deny Peer B, it MUST reply a datagram including the 224 HANDSHAKE+HAVE+CHOKE message. 226 Once receiving previous datagram, Peer B checks the messages and 227 obtains which is available for communidation. Then it sends datagrams 228 containing the REQUEST message to Peer A and C asking for chunks. 230 After Peer A or C receives the Peer B's request, it SHOULD send the 231 datagram to Peer B. The content of datagram depends on the video type: 232 INTEGRITY+DATA message for static video and SIGNED_INTEGRITY+DATA 233 message for dynamic video. 235 +-------+ +------+ +------+ +------+ +------+ +------+ 236 |Tracker| |Portal| |Peer A| |Peer B| |Peer C| |Peer D| 237 +-------+ +------+ +------+ +------+ +------+ +------+ 238 | | | | | | 239 |<-CONNECT(Join Swarm x)| | | | 240 |--------OK------------>| | | | 241 |<----STAT_REPORT-------| | | | 242 |---------OK----------->| | | | 243 : : | | | 244 | |<-----Select Swarm x----| | | 245 | |--------OK+MPD(x)------>| | | 246 |<-------CONNECT(Join Swarm x)-------| | | 247 |------------OK+PeerList------------>| | | 248 : : | | 249 | |<-HANDSHAKE-| | | 250 | |--HS+HAVE-->| | | 251 | |<-PEX_REQ---| | | 252 | |--PEX_RES-->| | | 253 | | |-HANDSHAKE->| | 254 | | |-------HANDSHAKE------>| 255 |<-----STAT_REPORT------| | | | 256 |----------OK---------->| |<-HS+HAVE---| | 257 : : |<----HS+HAVE+CHOKE-----| 258 | |<--REQUEST--|--REQUEST-->| | 259 | |---DATA---->|<----DATA---| | 260 | |<--ACK,HAVE-|-ACK,HAVE-->| | 261 | : : : | 262 |<---------STAT_REPORT---------------| | 263 |-------------OK-------------------->|<--------UNCHOKE-------| 264 | | |---------REQUEST------>| 265 : | :<---------DATA---------| 266 | | |---------ACK,HAVE----->| 267 : |<---HAVE----|----HAVE--->| | 268 | | |<--REQUEST--| | 269 | | |<--------REQUEST-------| 270 | | |----DATA--->| | 271 | | |----------DATA-------->| 272 | : : : : 273 | |<-KEEPALIVE-|-KEEPALIVE->| | 274 | | |--------KEEPALIVE----->| 275 |<-------------------STAT_REPORT------------------| | 276 |------------------------OK---------------------->| | 277 | |<-HANDSHAKE-|-HANDSHAKE->| | 278 | | |----------HANDSHAK---->| 279 |<---CONNECT/FIND(Leave Swarm x)-----| | 280 |<---CONNECT/FIND(Join Swarm y,z)----| | 281 Procedures of PPSP System 283 According to the corresponding data received, Peer B replies 284 adatagram Containing an ACK message to Peer A and C. Peer B SHOULD 285 also send a datagram containing HAVE message to all other peers in 286 the swarm x for announcement purpose. The timing of sending HAVE 287 message depends on Peer B. 289 In order to demonstrating all the functionalities, Peer D is supposed 290 to release previous rejection for Peer B by sending an UNCHOKE 291 message. 293 Then, Peer B can send a new REQUEST message to Peer D. 295 Peer D replies with the actually data message. After the content 296 integrality is verified, Peer B MAY send HAVE message to other peers 297 in swarm x. 299 Peer C and D can also require the Peer B chunks by sending REQUEST 300 message. Whether the corresponding chunks could be sent or not 301 depends on Peer B. 303 If the above peers attend to keep in the swarm, they need to send the 304 STAT_REPORT message to the tracker while send the KEEP_ALIVE message 305 to other peers periodically. 307 After all the necessary content is received successfully, Peer B can 308 close the connection by sending a HANDSHAKE message to all peers in 309 swarm x. An all 0-zeros channel ID MUST be embedded in HANDSHAKE 310 message. Meanwhile, Peer B SHOULD send STAT_REPORT or CONNECT message 311 to log out and eliminate its state in tracker. 313 Peer B MAY employ CONNECT message to join a new swarm, such as swarm 314 y or z in Figure 1. Similar instruction mentioned before can 315 becapitalized on data exchanging. 317 Useful Message List: 319 o CONNECT message 321 This message is used to register/leave a PPSP system and request 322 swarm actions with tracker. 324 o FIND message 326 This message is used to request a new peer list to tracker whenever 327 needed. It is also used when a peer attends to leave the PPSP system 328 with tracker. 330 o STAT_REPORT message 332 This message is used to send status and statistic data to tracker, in 333 order to facilitate the tracker service. This message MUST be 334 periodically sent while the peer is active. 336 o OK message 338 This message is used for tracker to convey that has successfully 339 received the last message. 341 o OK+PeerList message 343 This message is used for tracker to respond proper PeerList to peer. 345 o HANDSHAKE message 347 This message MUST be sent as the first message in the first datagram 348 between peers, in order to start communication between peers. 350 o HAVE message 352 This message is used to convey which chunks a peer has available for 353 download. 355 o DATA message 357 This message is used to transfer chunks of content. 359 o ACK message 361 This message is used to acknowledge received chunks after receiving a 362 DATA message. 364 o REQUEST message 366 This message is used to request one or more chunks from another peer. 368 o INTEGRITY message 370 This message carries information required by the receiver to verify 371 the integrity of a chunk. It is usually used in static content. 373 o SIGNED_INTEGRITY message 375 This message is used to verify chunks in live streaming. 377 o CHOKE message 379 The message is used to inform another peer that it will no longer 380 respond to any REQUEST massages from that peer. 382 o UNCHOKE message 384 This message is used to inform another peer that it will respond to 385 new REQUEST messages from that peer again. 387 o PEX_REQ & PEX_RES messages 389 These message allows peers to exchange the transport addresses of the 390 peers they are currently interacting with, thereby reducing the need 391 to contact a central tracker. 393 o KEEPALIVE message 395 This message SHOULD be sent periodically to each peer it wants to 396 interact with in the future. 398 4. Suggestions for Parameters Setting in PPSP System 400 In the procedure of constructing the PPSP system, parameters setting 401 is absolutely crucial. This section will discuss related issues in 402 tracker protocol and peer protocol. The default values are provided 403 as references. The practical setting can be adjusted according to 404 different scenarios 406 4.1. Parameters Setting in Tracker Protocol 408 Table 1 shows parameters, their default values and description in the 409 PPSP tracker protocol. 411 +--------------------+------------+------------------------------+ 412 | Name | Default | Description | 413 +--------------------+------------+------------------------------+ 414 | Init_timeout | 30 seconds | Maximum value of the "init | 415 | | | timer" used in the "per peer | 416 | | | transaction state machine" | 417 | Track_timeout | 3 minutes | Maximum value of the "track | 418 | | | timer" used in the "per peer | 419 | | | transaction state machine" | 420 | STAT_REPORT Period| 3 minutes | Maximum period of STAT_REPORT | 421 | | | message | 422 | Retry_timeout | 3 minutes | Maximum waiting time until a | 423 | | | peer initiates a retry process| 424 | ConcurrentLinks | NORMAL | Concurrent connectivity level | 425 | | | of peers, HIGH, LOW or NORMAL | 426 | OnlineTime | NORMAL | Availability or online | 427 | | | duration of peers, HIGH or | 428 | | | NORMAL | 429 | UploadBWlevel | NORMAL | Upload bandwidth capability | 430 | | | of peers, HIGH OR NORMAL | 431 +--------------------+------------+------------------------------+ 432 Table 1 PPSP Tracker Protocol Defaults 434 4.2. Parameters Setting in Peer Protocol 436 For the PPSP peer protocol has a detailed description about 437 parameters, this section only assume it as a reference to summarize 438 Table 2, which reveals some of the parameters default values and 439 descriptions. Some parameters should be recommended as a fixed value 440 while others should alter according to users' demands or network 441 conditions. 443 +---------------------+-------------+-----------------------------+ 444 | Name | Default | Description | 445 +---------------------+-------------+-----------------------------+ 446 | Chunk Size | var | (Maximum) Size of a chunk | 447 | | 1024 bytes | | 448 | | recommended | | 449 | Static Content | 1 (Merkle | Methods for protecting the | 450 | Integrity Protection| Hash Tree) | integrity of static content | 451 | Method | | | 452 | Live Content | 3 (Unified | Methods for protecting the | 453 | Integrity Protection| Merkle Tree | integrity of static content | 454 | Method | | including "sign all" and | 455 | | | "Unified Merkle Tree" | 456 | Merkle Hash Tree | 0 (SHA1) | Hash function used for the | 457 | Function | | Merkle Hash Tree | 458 | Live Signature | 13 (ECDSAP2 | Must be defined for live | 459 | Algorithm | 56SHA256 | streaming | 460 | Chunk Addressing | 2 (32-bit | Methods of chunk addressing | 461 | Method | chunk | | 462 | | ranges) | | 463 | Live Discard Window | var | Must be defined for live | 464 | | | streaming | 465 | NCHUNKS_PER_SIG | var | Must be defined in the | 466 | | | Signed Munro Hash | 467 | Dead peer detection | No reply in | Guideline for declaring a | 468 | | 3 minutes + | peer is dead | 469 | | 3 datagrams | | 470 | KEEPALIVE Period | 2 minutes | Maximum period for a peer | 471 | | | to send KEEPALIVE datagram | 472 | | | to other peers | 473 +---------------------+-------------+-----------------------------+ 474 Table 2 PPSP Peer Protocol Defaults 476 5. Limitations and Gaps Analysis 478 This section aims to identify the limitations and gaps of the current 479 PPSP system from the standpoint of satisfying PPSP requirements. 481 1. One of the PPSP target is extending current Peer-to-Peer (P2P) 482 system in mobile and wireless environments [RFC6972]. However, the 483 message used in PPSP system does not include related information 484 such as the packet loss rate and battery status, which is 485 essential for wireless and mobile environments. 487 2. The PPSP system provides two ways to acquire the PeerList. Peer 488 can obtain the PeerList from the tracker or they can get it 489 through the PEX_REQ and PEX_RES messages. When both methods are 490 available, it is not definite to update the local PeerList 491 efficiently. 493 3. The STAT_REPORT message of tracker protocol does not support 494 exchange the content data information between an active peer and a 495 tracker. Thus, whenever a new peer wants to join a swarm, the 496 relevant tracker could only employ PeerMode to choose the PeerList 497 and return the new peer. In the cases which there is only one 498 seeding peer while other peers that already finished part of the 499 content transmission and are willing to share with others. 500 Therefore, the tracker could not provide the high quality PeerList 501 but just a seeder. Thus, the peer could only update PeerList 502 relying on the PEX-REQ message. 504 4. In some cases, the user may want to adjust the video definition 505 based on the bandwidth (or user demand) automatically (or 506 manually). Or the user may watch videos and play online games at 507 the same time, and he/she doesn't want the videos occupy too much 508 of the bandwidths. This will need adaptive multi-rate control for 509 both users and ISPs. Rather than limiting the download links 510 throuth ISPs or government, it is better to add some controllable 511 limits in the protocol. 513 5. For safety and manageability reasons, PT (private tracker) has 514 become popular in recent years. It is uncertain whether this 515 should be taken into consideration in PPSP. If the answer is 516 positive, the tracker protocol should make some changes in finding 517 & connecting private tracker and add data traffic statistics part. 519 6. Security Consideration 521 This document does not contain any security considerations. 523 7. IANA Considerations 525 There are presently no IANA considerations with this document. 527 8. References 529 8.1. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 8.2. Informative References 536 [RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- 537 Peer Streaming Peer protocol (PPSPP)", RFC 7574, October 2015. 539 [I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y., 540 Xia, J., and J. Taveira, "PPSP Tracker Protocol-Base Protocol (PPSP- 541 TP/1.0)", draft-ietf-ppsp-base-tracker-protocol-12 (work in progress), 542 January 2016. 544 [RFC6972] Zhang, Y. and N. Zong, "Problem Statement and 545 Requirements of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972, 546 July 2013. 548 9. Acknowledgments 550 This document was prepared using 2-Word-v2.0.template.dot. 552 Authors' Addresses 554 Hongke Zhang 555 Beijing Jiaotong University (BJTU) 556 Beijing, 100044, P.R.China 558 Email: hkzhang@bjtu.edu.cn 560 Fei Song 561 Beijing Jiaotong University (BJTU) 562 Beijing, 100044, P.R.China 564 Email: fsong@bjtu.edu.cn 566 Di Wu 567 Beijing Jiaotong University (BJTU) 568 Beijing, 100044, P.R.China 570 Email: diwu2@seas.upenn.edu 572 Mi Zhang 573 Beijing Jiaotong University (BJTU) 574 Beijing, 100044, P.R.China 576 Email: 13120174@bjtu.edu.cn 577 Tianming Zhao 578 Beijing Jiaotong University (BJTU) 579 Beijing, 100044, P.R.China 581 Email: 14125070@bjtu.edu.cn