idnits 2.17.1 draft-zhang-ppsp-usage-08.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 9) being 103 lines 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 2018 Mi Zhang 5 Tianming Zhao 6 Beijing Jiaotong University 7 March 2 2018 9 Usage of the Peer-to-Peer Streaming Protocol (PPSP) 10 draft-zhang-ppsp-usage-08.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute 19 working documents as Internet-Drafts. The list of current Internet- 20 Drafts is at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on September 4, 2018. 29 Copyright Notice 31 Copyright (c) 2016 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with 39 respect to this document. Code Components extracted from this 40 document must include Simplified BSD License text as described in 41 Section 4.e of the Trust Legal Provisions and are provided without 42 warranty as described in the Simplified BSD License. 44 Abstract 46 This document concerns several significant operation issues of Peer- 47 to-Peer Streaming Protocol (PPSP) usage, focusing on two basic modes: 48 Leech mode and Seed mode. The related parameters setting for default 49 PPSP scenario reference to tracker protocol and peer protocol 50 respectively. Besides, the limitations and gaps of current PPSP 51 system are identified at with the standpoint of satisfying PPSP 52 requirements. 54 Table of Contents 56 1. Introduction ................................................ 2 57 2. Tetminology ................................................. 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 ............ 8 62 4.1. Parameters Setting in Tracker protocol .................. 9 63 4.2. Parameters Setting in Peer protocol ..................... 9 64 5. Limitations and Gaps Analysis ................................ 9 65 6. Security Consideration ...................................... 10 66 7. IANA Considerations ........................................ 10 67 8. References ................................................. 10 68 8.1. Normative References ................................... 10 69 8.2. Informative References ................................. 10 70 9. Acknowledgements ........................................... 10 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, it's unnecessary for end user 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 is proposed in a request/response model 86 handles the initial and periodic exchange of meta-information 87 between trackers and peers. The peer protocol is supposed to run as 88 a gossip like protocol controls the advertising and exchange of 89 media data directly among the peers. It currently runs on the top of 90 UDP using 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 related parameters setting for default PPSP scenario 95 are given by the tracker protocol and peer protocol respectively. 96 The limitations and gaps of current PPSP system are identified by 97 the standpoint of satisfying PPSP requirements. 99 2. Tetminology 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 The operation process of PPSP system in this document focuses on how 113 to associate multiple entities working together, such as peers, 114 trackers, portals, etc., and achieve corresponding functions, which 115 is different with previous protocol-related drafts. The following 116 section will provide both macroscopic overview and detailed steps. 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 is defined as a directory service that maintains a list 125 of active peers participating in a specific audio/video channel or 126 in the distribution of a streaming file. It is a logical entity, 127 which 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. There are two different modes (Leech mode and Seed 133 mode) in PPSP based on the properties of peers. It will be detailed 134 in Section 3.2. 136 The basic communication unit of PPSP is message. In peer 137 protocol, multiple messages are typically multiplexed into a 138 single datagram in transmission process. And in the PPSP system, 139 there are several rules MUST be obeyed. 140 1. In the same swarm, the same chunk addressing method MUST be 141 used to ensure that peers can communicate with each other 142 smoothly. 143 2. The portal needs to pick an appropriate tracker supporting 144 the same encoding type as the peer. Additionally, the VoD 145 streaming and live should be distinguished by the portal and 146 then the portal should select the appropriate tracker for peers. 148 3.2. Operation Illustration 150 Figure 1 illustrates the normal operation process of the PPSP system. 151 The related entities and elements are described as follows: 153 Tracker: A logical entity that provides the peer list to peers. 155 Portal: A logical entity that provides the Media Presentation 156 Description (MPD) files to peers. 158 Peer A: A peer that has content resource and wants to share it with 159 others. (PeerMode is of Seed) 161 Peer B: A peer that wants to join swarm x to obtain the content 162 provided by Peer A. (PeerMode is of Leech) 164 Peer C (Peer D): A peer that obtain the content provided by Peer A 165 through joining swarm x. And it has finished part of the content 166 transmission. (PeerMode is of Leech) 168 Assume that Peer A (Seeder) attends to share a static/dynamic video 169 content with other peers. Firstly, Peer A MUST send a CONNECT 170 message to a tracker to start/join swarm x. 172 After a correct CONNECT message is received, the tracker responses 173 to Peer A with an OK message. 175 In order to keep in swarm x, Peer A should send the STAT_REPORT 176 message to the tracker periodically. Normally, it is recommended 3 177 minutes for setting the value of Track_timeout (More details 178 described in section 4). An OK message should be generated and sent 179 back to Peer A whenever STAT_REPORT message reaches the tracker. 181 Assume that Peer B (Leecher) attends to watch this video content 182 provided by Peer A. Hence, Peer B need connect and login in a 183 service Portal with its peer ID to get the MPD file, includes the IP 184 address(es) of tracker(s) and swarm x's ID of the selected swarm x. 186 Then Peer B starts to communicate with the tracker and try to join 187 the swarm x by sending a CONNECT message to the tracker. If the 188 previous check was correct, the tracker is triggered to send 189 response back to Peer B with an OK+PeerList message. Peer B is 190 offered a proper list including peers' name and IP addresses (only 191 Peer A and its address here) by the mentioned message. 193 Till now, Peer B realizes which peer (Peer A here) has already been 194 in the swarm x. And then it sends a datagram with HANDSHAKE message 195 to Peer A (Due to there is only a seeder in the swarm x). A channel 196 ID and a sequence of protocol options are the payload of HANDSHAKE 197 message. 199 Then Peer A determines whether to communicate with Peer B based on 200 considering the status and current network capacities. Once Peer A 201 decides to make response, it returns a datagram wit HANDSHAKE+HAVE 202 message to Peer B. (HS is the abbreviation of HANDSHAKE in Figure 1) 204 Peer B updates PeerList as OPTIONAL through another way after 205 REQ message to Peer A). The message will help Peer B to discover 206 other new peers, which could not be provided by the tracker. 208 Peer A returns a datagram with PEX_RES message. Assume it including 209 the information of Peer C and Peer D. 211 As mentioned before, if Peer B attends to initial a new conversation 212 with Peer C or D, it MUST send a datagram including HANDSHAKE 213 message. 215 Similar with Peer A, Peer C or D needs to decide whether it will 216 reply Peer B or not. If Peer C is willing to contact with Peer B, it 217 responds a datagram containing HANDSHAKE+HAVE message. If Peer D 218 attends to deny Peer B, it MUST reply a datagram including the 219 HANDSHAKE+HAVE+CHOKE message. 221 Peer B checks the messages and obtains which is available for 222 communication once receiving previous datagram. Then datagrams 223 containing the REQUEST message to Peer A and C asking for chunks is 224 send by Peer B. 226 After Peer A or C receives the Peer B's request, they SHOULD 227 send the datagrams to Peer B. The content of datagram depends 228 on the video type: INTEGRITY+DATA message for static video and 229 SIGNED_INTEGRITY+DATA message for dynamic video. 230 +-------+ +------+ +------+ +------+ +------+ +------+ 231 |Tracker| |Portal| |Peer A| |Peer B| |Peer C| |Peer D| 232 +-------+ +------+ +------+ +------+ +------+ +------+ 233 | | | | | | 234 |<-CONNECT(Join Swarm x)| | | | 235 |--------OK------------>| | | | 236 |<----STAT_REPORT-------| | | | 237 |---------OK----------->| | | | 238 : : | | | 239 | |<------Select Swarm x-----| | | 240 | |---------OK+MPD(x)------->| | | 241 |<-------CONNECT(Join Swarm x)-------| | | 242 |------------OK+PeerList------------>| | | 243 : : | | 244 | |<-HANDSHAKE-| | | 245 | |--HS+HAVE-->| | | 246 | |<-PEX_REQ---| | | 247 | |--PEX_RES-->| | | 248 | | |-HANDSHAKE->| | 249 | | |-------HANDSHAKE------>| 250 |<-----STAT_REPORT------| | | | 251 |----------OK---------->| |<-HS+HAVE---| | 252 : : |<----HS+HAVE+CHOKE-----| 253 | |<--REQUEST--|--REQUEST-->| | 254 | |---DATA---->|<----DATA---| | 255 | |<--ACK,HAVE-|-ACK,HAVE-->| | 256 | : : : | 257 |<---------STAT_REPORT---------------| | 258 |-------------OK-------------------->|<--------UNCHOKE-------| 259 | | |---------REQUEST------>| 260 : | :<---------DATA---------| 261 | | |---------ACK,HAVE----->| 262 : |<---HAVE----|----HAVE--->| | 263 | | |<--REQUEST--| | 264 | | |<--------REQUEST-------| 265 | | |----DATA--->| | 266 | | |----------DATA-------->| 267 | : : : : 268 | |<-KEEPALIVE-|-KEEPALIVE->| | 269 | | |--------KEEPALIVE----->| 270 |<-------------------STAT_REPORT------------------| | 271 |------------------------OK---------------------->| | 272 | |<-HANDSHAKE-|-HANDSHAKE->| | 273 | | |----------HANDSHAK---->| 274 |<---CONNECT/FIND(Leave Swarm x)-----| | 275 |<---CONNECT/FIND(Join Swarm y,z)----| | 276 Procedures of PPSP System 278 According to the corresponding data received, Peer B replies a 279 datagram Containing an ACK message to Peer A and C. Peer B 280 SHOULD also send a datagram containing HAVE message to all 281 other peers in the swarm x for announcement purpose. The timing 282 of sending HAVE message depends on Peer B. 283 In order to demonstrate all the functionalities, Peer D is 284 supposed to release previous rejection for Peer B by sending an 285 UNCHOKE message. 286 Then, Peer B can send a new REQUEST message to Peer D. 287 Peer D replies with the actually data message. Peer B MAY send 288 HAVE message to other peers in swarm x after the content 289 integrality is verified. 290 Peer C and D can also require the Peer B chunks by sending 291 REQUEST message. Whether the corresponding chunks could be sent 292 or not depends on Peer B. 294 If the above peers attend to keep in the swarm, they need to 295 send the STAT_REPORT message to the tracker while send the 296 KEEP_ALIVE message to other peers periodically. 297 After all the necessary content is received successfully, Peer 298 B can close the connection by sending a HANDSHAKE message to 299 all peers in swarm x. An all 0-zeros channel ID MUST be 300 embedded in HANDSHAKE message. Meanwhile, Peer B SHOULD send 301 STAT_REPORT or CONNECT message to log out and eliminate its 302 state in tracker. 304 Peer B MAY employ CONNECT message to join a new swarm, such as 305 swarm y or z in Figure 1. Similar instruction mentioned before 306 can be capitalized on data exchanging. 307 Useful Message List: 308 CONNECT message 309 This message is used to register/leave a PPSP system and 310 request swarm actions with tracker. 311 FIND message 312 This message is used to request a new peer list to tracker 313 whenever needed. It is also used when a peer attends to leave 314 the PPSP system with tracker. 315 STAT_REPORT message 316 This message is used to send status and statistic data to 317 tracker, in order to facilitate the tracker service. This 318 message MUST be periodically sent while the peer is active. 319 OK message 320 This message is used for tracker to convey that has 321 successfully received the last message. 322 OK+PeerList message 323 This message is used for tracker to respond proper PeerList to 324 peer. 325 HANDSHAKE message 326 This message MUST be sent as the first message in the first 327 datagram between peers, in order to start communication between 328 peers. 329 HAVE message 330 This message is used to convey which chunks a peer has 331 available for download. 332 DATA message 333 This message is used to transfer chunks of content. 334 ACK message 335 This message is used to acknowledge received chunks after 336 receiving a DATA message. 337 REQUEST message 338 This message is used to request one or more chunks from another 339 peer. 340 INTEGRITY message 341 This message carries information required by the receiver to 342 verify the integrity of a chunk. It is usually used in static 343 content. 344 SIGNED_INTEGRITY message 345 This message is used to verify chunks in live streaming. 346 CHOKE message 347 The message is used to inform another peer that it will no 348 longer respond to any REQUEST massages from that peer. 349 UNCHOKE message 350 This message is used to inform another peer that it will 351 respond to new REQUEST messages from that peer again. 352 PEX_REQ & PEX_RES messages 353 These message allows peers to exchange the transport addresses 354 of the peers they are currently interacting with, thereby 355 reducing the need to contact a central tracker. 356 KEEPALIVE message 357 This message SHOULD be sent periodically to each peer it wants 358 to interact with in the future. 360 4. Suggestions for parameters Setting in PPSP System 362 In the procedure of constructing the PPSP system, parameters setting 363 is absolutely crucial. This section will discuss related issues in 364 tracker protocol and peer protocol. The default values are provided 365 as references. The practical setting can be adjusted according to 366 different scenarios. 368 4.1. Parameters Setting in Tracker protocol 370 Parameters, their default values and description in the PPSP tracker 371 protocol is shown in Table 1. 372 +--------------------+------------+------------------------------+ 373 | Name | Default | Description | 374 +--------------------+------------+------------------------------+ 375 | Init_timeout | 30 seconds | Maximum value of the "init | 376 | | | timer" used in the "per peer | 377 | | | transaction state machine" | 378 | Track_timeout | 3 minutes | Maximum value of the "track | 379 | | | timer" used in the "per peer | 380 | | | transaction state machine" | 381 | STAT_REPORT Period | 3 minutes | Maximum period of STAT_REPORT| 382 | | | message | 383 | Retry_timeout | 3 minutes | Maximum waiting time until a | 384 | | |peer initiates a retry process| 385 | ConcurrentLinks | NORMAL |Concurrent connectivity level | 386 | | |of peers, HIGH, LOW or NORMAL | 387 | OnlineTime | NORMAL | Availability or online | 388 | | | duration of peers, HIGH or | 389 | | | NORMAL | 390 | UploadBWlevel | NORMAL | Upload bandwidth capability | 391 | | | of peers, HIGH OR NORMAL | 392 +--------------------+------------+------------------------------+ 393 Table 1 PPSP Tracker Protocol Defaults 395 4.2. Parameters Setting in Peer protocol 397 For the PPSP peer protocol having a detailed description about 398 parameters, this section only assume it as a reference to summarize 399 Table 2, which reveals some of the parameters default values and 400 descriptions. Some parameters should be recommended as a fixed value 401 while others should alter according to users' demands or network 402 conditions. 403 +---------------------+-------------+-----------------------------+ 404 | Name | Default | Description | 405 +---------------------+-------------+-----------------------------+ 406 | Chunk Size | var | (Maximum) Size of a chunk | 407 | | 1024 bytes | | 408 | | recommended | | 409 | Static Content | 1 (Merkle | Methods for protecting the | 410 | Integrity Protection| Hash Tree) | integrity of static content | 411 | Method | | | 412 | Live Content | 3 (Unified | Methods for protecting the | 413 | Integrity Protection| Merkle Tree | integrity of static content | 414 | Method | | including "sign all" and | 415 | | | "Unified Merkle Tree" | 416 | Merkle Hash Tree | 0 (SHA1) | Hash function used for the | 417 | Function | | Merkle Hash Tree | 418 | Live Signature | 13 (ECDSAP2 | Must be defined for live | 419 | Algorithm | 56SHA256 | streaming | 420 | Chunk Addressing | 2 (32-bit | Methods of chunk addressing | 421 | Method | chunk | | 422 | | ranges) | | 423 | Live Discard Window | var | Must be defined for live | 424 | | | streaming | 425 | NCHUNKS_PER_SIG | var | Must be defined in the | 426 | | | Signed Munro Hash | 427 | Dead peer detection | No reply in | Guideline for declaring a | 428 | | 3 minutes + | peer is dead | 429 | | 3 datagrams | | 430 | KEEPALIVE Period | 2 minutes | Maximum period for a peer | 431 | | | to send KEEPALIVE datagram | 432 | | | to other peers | 433 +---------------------+-------------+-----------------------------+ 434 Table 2 PPSP Peer Protocol Defaults 436 5. Limitations and Gaps Analysis 438 This section aims to identify the limitations and gaps of the 439 current PPSP system from the standpoint of satisfying PPSP 440 requirements. 442 1. One of the PPSP target is extending current Peer-to-Peer (P2P) 443 system in mobile and wireless environments [RFC6972]. However, 444 the related information such as the packet loss rate and battery 445 status is not included in the message used in PPSP system, which 446 is essential for wireless and mobile environments. 448 2. The PPSP system provides two ways to acquire the PeerList. Peer 449 can obtain the PeerList from the tracker or they can get it 450 through the PEX_REQ and PEX_RES messages. It is not definite to 451 update the local PeerList efficiently, when both methods are 452 available 454 3. It not supported by the STAT REPORT message of tracker protocol 455 to exchange the content data information between an active peer 456 and a tracker. Thus, the relevant tracker could only employ 457 PeerMode to choose the PeerList and return the new peer, whenever 458 a new peer wants to join a swarm. In the cases which there is 459 only one seeding peer while other peers that already finished 460 part of the content transmission and are willing to share with 461 others. Therefore, the tracker could not provide the high quality 462 PeerList but just a seeder. Thus, the peer could only update 463 PeerList relying on the PEX-REQ message. 465 4. In some cases, the user may want to adjust the video definition 466 based on the bandwidth (or user demand) automatically (or 467 manually). Or the user may watch videos and play online games at 468 the same time, and he/she doesn't want the videos occupy too much 469 of the bandwidths. This will need adaptive multi-rate control for 470 both users and ISPs. It is better to add some controllable limits 471 in the protocol, rather than limiting the download links through 472 ISPs or government 474 5. PT (private tracker) has become popular in recent years for 475 safety and manageability reasons. It is uncertain whether this 476 should be taken into consideration in PPSP. If the answer is 477 positive, the tracker protocol should make some changes in 478 finding & connecting private tracker and add data traffic 479 statistics part. 481 6. Security Consideration 483 This document does not contain any security considerations. 485 7. IANA Considerations 487 There are presently no IANA considerations with this document. 489 8. References 491 8.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 8.2. Informative References 498 [RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- 499 Peer Streaming Peer protocol (PPSPP)", RFC 7574, October 2015. 501 [I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y., 502 Xia, J., and J. Taveira, "PPSP Tracker Protocol-Base Protocol (PPSP- 503 TP/1.0)", draft-ietf-ppsp-base-tracker-protocol-12 (work in 504 progress), January 2016. 506 [RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements 507 of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972, July 2013. 509 9. Acknowledgements 511 This document was prepared using 2-Word-v2.0.template.dot. 513 Authors' Addresses 515 Hongke Zhang 516 Beijing Jiaotong University (BJTU) 517 Beijing, 100044, P.R.China 519 Email: hkzhang@bjtu.edu.cn 521 Fei Song 522 Beijing Jiaotong University (BJTU) 523 Beijing, 100044, P.R.China 525 Email: fsong@bjtu.edu.cn 527 Di Wu 528 Beijing Jiaotong University (BJTU) 529 Beijing, 100044, P.R.China 531 Email: diwu2@seas.upenn.edu 533 Mi Zhang 534 Beijing Jiaotong University (BJTU) 535 Beijing, 100044, P.R.China 537 Email: 13120174@bjtu.edu.cn 539 Tianming Zhao 540 Beijing Jiaotong University (BJTU) 541 Beijing, 100044, P.R.China 543 Email: 14125070@bjtu.edu.cn