idnits 2.17.1 draft-banerjee-rtp-vod-00.txt: -(148): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(610): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(655): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(699): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 22 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 26 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 203 has weird spacing: '...maximum when ...' == Line 656 has weird spacing: '...te load value...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 22, 2002) is 7819 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 735 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Rahul Banerjee 2 BITS, Pilani 3 Venkatesan V 4 BITS, Pilani 5 Bharani M 6 BITS, Pilani 7 Swaminathan P 8 BITS, Pilani 9 Rajesh Kumar Reddy 10 BITS, Pilani 11 November 22, 2002 13 An extension of RTP and RTCP protocols 14 For Video-on-Demand systems 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract: 39 This memorandum specifies an extension to RTP and RTCP as 40 specified in RFC 1889 [1] specifically designed to extend support to 41 Video-on-Demand systems in particular and unicast systems in general. 42 It is presented through an experimental Video-on-Demand Architecture 43 that supports dynamic changes in the distribution pattern and load 44 balancing to optimize the service quality provided to the user. 46 Contents: 48 1 Introduction ................................................2 49 2 Overview of the architecture ................................3 50 2.1 Components of the VoD architecture ..........................3 51 2.2 Working of the VoD system ...................................3 52 3 Overview of dynamic scheduling concept ......................5 53 4 The protocol ................................................6 54 5 Packet formats ..............................................9 55 5.1 The RTP-Ext header format....................................9 56 5.2 The fixed part of the RTCP-Ext header........................10 57 5.3 The RTCP-Ext packet format...................................11 58 6 Appendix ....................................................13 59 6.1 Parameters...................................................13 60 6.2 Load Calculations............................................14 61 6.3 Algorithm for evaluating the distribution pattern............14 62 6.4 Full address of authors .....................................15 63 7 Security Considerations......................................15 64 8 Copyright statement..........................................15 65 9 References ..................................................16 67 1. Introduction: 69 RTP and RTCP as specified in RFC 1889 [1], although having support 70 for both multicast and unicast applications, when used for a unicast 71 application, need to be tailored specifically to needs of the unicast 72 application. Applications such as Video-on-Demand which are specifically 73 unicast applications would not need to use some of the features provided 74 by the existing specification of RTP and RTCP. In addition, the set of 75 protocols need to be tailored in specific implementations in order to 76 meet the needs of specific applications. 78 The protocol extensions suggested in this draft are best explained 79 using an experimental architecture for Video-on-Demand systems. Video- 80 on-Demand is a typical example of a unicast application. The rest of the 81 draft is explained on the basis 83 This article presents the existing architecture for VoD system 84 and introduces changes in the existing architecture for achieving 85 better quality in the video at the client end. The article is organized 86 as follows: introduction of the existing architecture, overview of the 87 new architecture, protocol for communication in the new architecture, 88 existing protocols tailored for the new architecture and mathematical 89 models for estimation of optimum parameters. 91 2. Overview of the architecture: 93 2.1 Components of the VoD architecture: 95 The existing architecture of VoD system has the following 96 components: 98 1. Client: The client is the machine, which sends a request for a video 99 file. The client has the player software, which runs the received video 100 file. The client also has a buffer which buffers the data received from 101 the video server. 103 2. Control Server: The control server(s) takes care of the control 104 operations involved in the transfers of the data. When a request is 105 received from a client machine for a video file, the control server 106 that runs the Load Balancing Tool (LBT) estimates the least loaded 107 video server and assigns that video server to serve the client. The 108 control server is the central point from which all the video servers 109 can be accessed. 111 3. Video Server: The video server contains the video files. The video 112 server also maintains a database of the video files present in it. When 113 a client connects to the system, the video server sends the list of 114 video files present in it. The client then sends a request for a video 115 file. When video server is selected to serve the client, it transfers 116 data in chunks to the client. 118 2.2 Working of the VoD system: 120 The process starts with the client sending a request for a video 121 file. The Load Balancing Tool (LBT) evaluates the least loaded video 122 server among the video servers having the requested video file. When 123 the admission control succeeds, the selected video server starts 124 serving the client. It sends the video file in chunks to the client. 125 The transmission follows the RTP and RTCP [1]. 126 Once a video server is assigned to serve a client, it continues 127 to serve the client until the end of transmission or until the point 128 the transmission stops under some error condition. 130 +----------------------+ 131 | Client sends request | 132 | for video file | 133 +----------------------+ 134 | 135 | 136 | 137 | 138 | +--------------+ +---------------+ +-------------+ 139 +--->| LBT estimates| |Least loaded | |VS servers | 140 |least loaded |---->|server assigned|-->|client until | 141 |server | |to client | |EOT | 142 +--------------+ +---------------+ +-------------+ 144 fig. 1 146 The sequence is shown in fig.1. The encircled region shown the part 148 which is static. In this context, the word �static� means that once the 149 LBT estimates the least loaded server and a video server is assigned to 150 serve the client, the same video server keeps serving the client until 151 the EOT. 153 The various processes that run to accomplish the VoD function are the 154 following: 156 * client: This process runs in the client machine. This process 157 communicates with the video server sending request for video files and 158 getting the response back. 159 * player: This process runs in the client machine. This is the software 160 which plays the data received from the video server and stored in the 161 buffer. 163 * video server: this is the process that communicates with the control 164 server for regulating the transmission and with the client for the 165 actual data transfer. 166 * Meta data manager (MDM): this process runs in the video server which 167 is involved with the database of video files present in the video 168 server. 169 * Control server: this process is responsible for all control functions 170 such as accessing data and files in the video server. 171 * Load Balancing Tool: this process runs on the control server. This 172 process evaluates the load on the video servers when a client sends a 173 request for a video file. 175 3. Overview of dynamic scheduling concept: 177 According to the existing architecture and implementation, once a 178 video server is assigned to serve a client, it keeps serving the client 179 until the end of the transmission or until the point the transmission 180 stops due to some error. This model though simple, does not take into 181 account the dynamically changing load on the video servers. The model 182 just evaluates the load on the video server at the point of admission 183 and hence forth ignores the change in load with time on the video 184 server. Though the admission control policy takes care that the number 185 of clients served does not exceed a number where the QoS demands cannot 186 be met, a better response time can be achieved at the client end if the 187 number of clients server by a video server decreases. This goes by the 188 equation : 190 Response time = k * 1/no of clients 192 where 'k' is proportionality constant. 194 The new system is based on this principle, to minimize the response 195 time whenever possible. The new schema, deals with the dynamically 196 changing load on a video server, and proposes an alternative method so 197 that load gets distributed over time and all the video servers have 198 minimum possible clients to serve. 200 We see that the response time is inversely proportional to the number 201 of clients connected to it. When the number of clients served by a 202 video server decreases, better response time is achieved for those 203 clients. Though the processor efficiency is maximum when the maximum 204 number of clients it can serve are allowed, the best response time is 205 not achieved. In applications like Video-on-Demand, where there are 206 more than one servers (video server), response time is one of the most 207 important parameter. By distributing the load among the video servers, 208 the efficiency for the group of video servers remains the same and the 209 response time at the individual clients either becomes better or 210 remains the same. 212 The control server evaluates the load on the video servers 213 periodically. Hence, there must be periodic exchange of information 214 between the video servers and the control server. The video server 215 sends information about the load present on it at regular intervals of 216 time. The control server gets the load information from different video 217 servers, evaluates the load on these video servers, finds a 218 distribution pattern and sends a response back to the video servers. 219 During the time the control server calculates the distribution 220 pattern, there is a delay involved. This gives a pause at the client 221 end which is undesirable. In order to avoid this delay, the video 222 servers keep streaming the video to the client during the time the 223 control server evaluates the distribution pattern. When the control 224 server sends back the response to the video server and if there is a 225 shift in the video server for a particular client, the client starts 226 receiving data from the newly assigned video server. The entire load 227 shifting process is discussed in sec.4 228 Better response time is achieved at the cost of the overload in 229 distributing the load and a few additional functions to be performed by 230 the client. 232 4. Protocol: 234 (1)For the dynamic scheduling to happen the video servers must send 235 information about their load to the control server every fixed interval 236 of time. This information is sent as an RTCP packet with server 237 statistics (SERVSTAT) report in it. The estimation of time interval is 238 discussed in the appendix. This SERVSTAT report carries information 239 about the load on the video server. The control server receives the 240 SERVSTAT report from all the video servers in the system. These reports 241 give a picture of the load distribution in the system. The video server 242 after sending the SERVSTAT packet keeps streaming video to the clients. 244 +-------+ 245 +------->| CS |<------+ 246 SERVSTAT | +-------+ | SERVSTAT 247 | | 248 | | 249 +-------+ +-------+ 250 | VS-A | | VS-B | 251 +-------+ +-------+ 253 +-------+ 254 |client | 255 +-------+ 257 (2)The control server on receiving the SERVSTAT report from all the 258 video servers evaluates the distribution pattern. For this evaluation, 259 it uses the load information sent by the video servers. The estimation 260 of the distribution pattern is discussed in appendix 262 (3)If for a particular client, a different video server (video server 263 A) is scheduled, then the control server sends a DEL report to the 264 video server (video server A) which is serving the client. 266 +-------+ 267 | CS | 268 +-------+ 269 | 270 | DEL 271 +-------+ | +-------+ 272 | VS-A |<-------+ | VS-B | 273 +-------+ +-------+ 275 +-------+ 276 |client | 277 +-------+ 279 (4)The video server A on receiving the DEL packet from the control server, 280 responds by sending a SWITCH packet to the client. This SWITCH 281 report carries information about the new video server (video server B) 282 the client has to receive video from. The video server informs the 283 client about the change in the server through a SWITCH packet. 285 +-------+ 286 | CS | 287 +-------+ 289 +-------+ +-------+ 290 | VS-A | | VS-B | 291 +-------+ +-------+ 292 | 293 | 294 | SWITCH 295 | 296 | +-------+ 297 +------->|client | 298 +-------+ 300 (5)The client receives information about the new video server it has to 301 get data from the SWITCH packet. Now the client sends a REQ packet to 302 the new video server it has to receive data from. The client now has to 303 send an offset from where the server B starts streaming. For this 304 value, the client decides the size of the data it has to buffer before 305 it can start playing data from the new video server. The client adds 306 the size of the data it has to buffer to the current offset of the file 307 it has received and sends the resulting value in the REQ packet. The 308 buffer size varies from one client to another. So different client add 309 different value to the current offset. 311 +-------+ 312 | CS | 313 +-------+ 315 +-------+ +-------+ 316 | VS-A | +---->| VS-B | 317 +-------+ | +-------+ 318 | 319 | REQ 320 | 321 +-------+ 322 |client | 323 +-------+ 325 (6)The video server B on receiving the REQ packet starts streaming the 326 video file from the requested offset onwards. The client buffers the 327 data received from the video server B. It also simultaneously receives 328 data from the video server A. It plays data which is buffered from 329 video server A. When the client receives the first data chunk which 330 overlaps with the data from video server B it sends a BYE packet to 331 video server A. Then it starts playing data buffered from the video 332 server B. When video server A receives the BYE packet from the client 333 it stops its transmission. The server A keeps transmitting data until 334 it receives the BYE packet. Hence there will a overlap in data received 335 from server A and server B. The client ignores the data packets from 336 server A. Since the client starts playing data from server B only after 337 buffering sufficient amount (during which it receives and plays data 338 from server A) the delay due to slow transmission from B is avoided. 340 +-------+ 341 | CS | 342 +-------+ 344 +-------+ +-------+ 345 | VS-A |<------+ | VS-B | 346 +-------+ | +-------+ 347 | 348 BYE | 349 | 350 +-------+ 351 |client | 352 +-------+ 354 (7)Once the client sends a BYE packet to the server A, it buffers and 355 plays data only from server B. The client has now switched from video 356 server A to video server B. After the next time interval, the video 357 servers send their SERVSTAT packet and the cycle continues. 359 5. Packet Formats: 361 The format of the different packets involved in the communication 362 between different components is given below 364 5.1 The RTP-Ext header format 366 The RTP-Ext header is of fixed length and contains the following 367 fields. However, it has the option to be extended by using a header 368 extension bit. The format of this is the same as the RTP header 369 extension as described in RFC-1889 [1]. 371 The RTP-Ext header is of the following fixed format. 373 0 1 2 3 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | V=2 |P|X| --- | PT | sequence number | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Timestamp | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Server Identifier | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Stream Identifier | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Stream Offset | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 The header is of length 20 octets. The header may be extended using the 388 extension bit but it is recommended not to use this field. However 389 implementations should be prepared to parse and ignore header 390 extensions that are not supported by them. The details of header 391 extensions are the same as described in RFC-1889. 393 The fixed part of the header has the following fields 395 Version (V): 3 bits 396 This field identifies the version of RTP-Ext. The value defined by this 397 draft version is 1. 399 Padding (P): 1 bit 400 This bit indicates that there are one or more padding octets at the end 401 of the payload which are not part of payload. The last octet of the 402 padding indicates how many octets should be ignored. 404 Extension bit (X): 1 bit 405 This bit indicates that an extension header as suggested in section 406 5.3.1 of RFC-1889 follows the fixed length header. 408 Reserved Field: 4 bit 409 There is a three bit reserved field left unspecified for experimental 410 purposes. Although implementations can ignore this field, it is 411 strongly recommended that this field be set to zero on the sender side. 412 Similarly the receiver makes sure this value if zero. This is to make 413 sure malicious parties do not misuse this field. 415 Payload type (PT): 7 bits 416 This field identifies the payload format and is application specific. 417 The mapping of these codes to the corresponding codes could be a static 418 binding or could be a dynamic one which is appropriately communicated 419 to the receiver before start of the streaming. 421 Sequence number: 16 bits 422 The sequence number is a 16-bit value that is used to detect packet 423 loss and packets that arrive out of order. The initial value is 424 unpredictable for security reasons and to minimize clash with older 425 packets left over from a previous stream. The value wraps around on 426 reaching the maximum value. 428 Time stamp: 32 bits 429 The time stamp is needed for jitter calculations. It is not necessary 430 that this timestamp reflect the actual time at which the packet is send 431 nor is it required that the sender and receiver should be synchronized. 432 ( Refer to RFC-1889 sec 5.1 ) 434 Source Identifier: 32 bits 435 This is a 32 bit address that is chosen randomly to identify the source 436 of the packet. This is described in RFC-1889. The other details of the 437 server can be known from the SDES packet 439 5.2 The fixed part of the RTCP-Ext header 441 There is a fixed length portion of the RTCP-Ext header that is common 442 among all the packet types and spans 3 octets. This is similar to the 443 RTP-Ext header. The fixed part of the RTCP-Ext header will therefore 444 look like this. 446 0 1 2 3 447 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | V=2 |P|N| ----- | PT | sequence number | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | timestamp | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Source Identifier | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 The field unique to this header in contrast to the RTP-Ext header are 458 Next header (N): 1 bit 459 RTCP-Ext could make a compound packet formed out of many RTCP-Ext 460 packets. In such a scenario, the N bit indicates whether this header is 461 followed by another RTCP-Ext header. The flag is set to indicate anther 462 header following this one and cleared to indicate that this one is the 463 final one. 465 Packet Type (PT): 7 bit 466 This field identifies the type of current RTCP-Ext header. This could 467 be one of the types like SR, RR, SDES, SERVSTAT, BYE, DEL, etc. 469 5.3 The RTCP-Ext packet format 471 As discussed earlier the RTCP-Ext packet has a fixed length header 472 prefix followed by type specific data. The type of the packet as 473 indicated by the packet type could be any of SR, RR, SDES, BYE or APP 474 as defined in RFC 1889. In addition three packet types are additionally 475 defined to take care of the dynamic scheduling aspect of the 476 architecture. The control server evaluates the loads on these video 477 servers based on reports obtained from them and makes required 478 modifications to the distribution pattern. These three packet types 479 facilitate this communication. 481 These packet types are 483 SERVSTAT: 484 This packet is sent at periodic intervals by the video servers to 485 the control server to allow it to calculate the load on the video 486 servers and the required changes to the distribution pattern. This 487 calculation could use the number of clients being served and total 488 capacity of the servers. In addition to the 3 octets common among all 489 RTCP-Ext headers the remaining structure of the SERVSTAT packet is 491 0 1 2 3 492 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | N Clients | Server Load | Server Capacity | 495 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 496 | Client Identifier | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Stream Identifier | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | File Size | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | File Offset | 503 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 504 ��.. 506 The fields in the packet are described below. 508 N Clients: 8 bits 509 The number of clients currently being served by the video server. 511 Server Load: 8 bits 512 This is a metric which indicates the extent to which the server is 513 loaded. 515 Server Capacity: 16 bits 516 This is a metric which indicates the capacity of the server. Refer the 517 Appendix 6.2 for the description of this metric 519 Client Identifier: 32 bits 520 A 32 bit identifier of the client. This is a randomly chosen value and 521 is in fact, the value used as the source identifier in any packet 522 originating from the client. 524 Stream Identifier: 32 bits 525 A 32 bit identifier that uniquely identifies any of the files that 526 are available with the video server. 528 File Size: 32 bits 529 This is the size of the video file in bytes. This is used in a 530 calculation by the control server. 532 File offset: 32 bits 533 A 32 bit value indicating the current offset of the file which is 534 being served by the server. 536 DEL packet: 537 This packet is sent by the control server to a video server when 538 it is intended that the distribution pattern has to change. Assuming 539 that the client is currently receiving steaming data from a video 540 server A and it is intended that the client instead get the data from 541 video server B, the control server sends a DEL packet to the video 542 server A instructing it to put these changes to effect. The packet has 543 the following format 545 0 1 2 3 546 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Client Identifier | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Stream Identifier | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | New Server Identifier | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Client Identifier: 32 bits 556 This identifies the client, which is involved in the switching 557 process. 559 Stream Identifier: 32 bits 561 The identifier of the stream that is being served by the video 562 server to the indicated client. 564 New Server Identifier: 32 bits 565 The identifier (IP Address) of the new video server to which the 566 client is expected to switch. 568 SWITCH: 569 This packet is sent by a video server to its client instructing 570 it to initiate a switch from this server to another. In the case 571 described above, video server A sends a SWITCH packet to its client 572 instructing it to switch to video server B. The packet has the 573 following format 575 0 1 2 3 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Stream Identifier | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | New Server Identifier | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Stream Identifier: 32 bits 584 The identifier of the stream being accessed by the client 586 New Server Identifier: 587 The identifier (IP Address) of the new server to which the client 588 is expected to switch. 590 6. Appendix: 592 6.1 Parameters: 594 These are parameters whose value cannot be estimated using 595 formulae. These parameters depend on the VoD system nature and the 596 human response to video. 597 The following parameters fall into the category: 599 1.the time interval between the exchange of the information and 600 response packet. This parameter depends on the nature of the VoD 601 system. For systems where there are large number of clients and shorter 602 video files, the time interval should be small, so that the video 603 server loads are checked and distributed more frequently. For VoD 604 systems where there are larger video files and smaller number of 605 clients the interval can be made larger so that the distribution 606 pattern can be revised less frequently. 608 2.The load difference between the video servers for a shift has to be 609 performed. This is a very critical parameter. Let the load of server 610 A be �LA� and that of server B be �LB�. Let �x� be shift in load from 611 server A to server B. This shift is permitted only if, 612 (LB + x) <= (LA � x) 613 The above equation says that the shift is permitted only if the total 614 load on server B after the shift is less that or equal to the load on 615 the server A. But the equation if strictly followed does not always 616 provide a significant improvement in the response time. 618 6.2 Load Calculations: 620 Number of bytes transferred = �BT� 621 Number of bytes left = �BL� 622 Offset = �OF� 623 File size = �FS� 624 Video Server capacity = �CP� 626 Video Server Capacity is one or more (e.g. processor speed) of the 627 measure used to evaluate the capacity of a machine. 629 BT = OF 631 BL = FS � BT 633 load due to a client/video pair = BL / CP 635 load on a video server = (BL1/CP) + (BL2/CP) + ��. + (BLn/CP) 637 6.3 Algorithm for evaluating the distribution pattern: 639 for all client/video �x� server by a VS �a� 640 { 641 for all VS �y� 642 { 643 if VS �y� has video file �x� 644 { 645 /* calculate load on video server �a� after the shift */ 646 v1 = load of �a� � load due to file �x� 648 /* calculate load on video server �y� after the shift */ 649 v2 = load of �y� � load due to file �x� 651 /* if the load on the new server is still less than that 652 of the old server permit shift*/ 653 if(v2 < v1) 654 { 655 send DEL packet to VS �a� with server identifier of VS �y� 656 /* update load value in both the servers */ 657 load of �a� = v1 658 load of �y� = v2 659 } 661 } 662 } 663 } 665 6.4 Address of the Authors: 667 Rahul Banerjee 669 Professor, 670 CS/IS Department, 671 BITS,Pilani-333031 672 rahul@bits-pilani.ac.in 674 Venkatesan V 675 BITS, Pilani 676 venkatesan796@yahoo.com 678 Bharani M 679 BITS, Pilani 680 bharani.m@lycos.net 682 Swaminathan P 683 BITS, Pilani 684 swami_1406@yahoo.co.uk 686 Rajesh Kumar Reddy 687 BITS, Pilani 688 krk_rajesh@yahoo.com 690 7.Security Considerations: 692 RTP packets using the payload format defined in this specification are 693 subject to the security considerations discussed in the RTP 694 specification, and any appropriate RTP profile. 695 There is one more additional security factor that has to be taken care 696 of. Any machine can send a command to the video server to transfer the 697 control to a different one. There is no way in the method above to 698 verify that the message is from the control server. To avoid this one 699 possible solution is the �call back� mechanism where the video server 700 on receiving a DEL packet sends a confirmation packet to the control 701 server. If control server was the one which sent the DEL packet then 702 it sends an acknowledgement and the video server responds to the DEL 703 packet. Had the DEL packet been from some other machine, then the video 704 server does not receive any acknowledgement. 706 8. Full Copyright Statement 707 Copyright (C) The Internet Society (2002). All Rights Reserved. 709 This document and translations of it may be copied and furnished to 710 others, and derivative works that comment on or otherwise explain it or 711 assist in its implementation may be prepared, copied, published and 712 distributed, in whole or in part, without restriction of any kind, 713 provided that the above copyright notice and this paragraph are included 714 on all such copies and derivative works. 716 However, this document itself may not be modified in any way, such as by 717 removing the copyright notice or references to the Internet Society or 718 other Internet organizations, except as needed for the purpose of 719 developing Internet standards in which case the procedures for 720 copyrights defined in the Internet Standards process must be followed, 721 or as required to translate it into languages other than English. 723 The limited permissions granted above are perpetual and will not be 724 revoked by the Internet Society or its successors or assigns. 726 This document and the information contained herein is provided on an "AS 727 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 728 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 729 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 730 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 731 FITNESS FOR A PARTICULAR PURPOSE." 733 9.References: 735 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 736 A Transport Protocol for Real-Time Applications", RFC 1889.