idnits 2.17.1 draft-aleksandrov-rttp-prop-01.txt: -(109): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(760): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1203): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1246): 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 13 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 2001) is 8168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1573, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 793 (ref. '3') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1821 (ref. '5') ** Obsolete normative reference: RFC 2326 (ref. '6') (Obsoleted by RFC 7826) ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '7') ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '8') -- Possible downref: Normative reference to a draft: ref. '9' ** Downref: Normative reference to an Experimental draft: draft-speakman-pgm-spec (ref. '10') Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Aleksandrov 3 Expires June 2002 December 2001 5 RTTP: Properties of a real-time protocol 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is inappropriate to use Internet 20 Drafts as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Copyright Notice 31 Copyright (C) The Internet Society (2001). All Rights Reserved. 33 Abstract 35 The purpose of this document is to provide ideas for real-time 36 communications in Internet. This document doesn't expand any pre- 37 defined standards or practices, it also doesn't conform ones. This 38 document contains a separate idea for real-time data delivery. 40 Table of Contents 42 1. Introduction....................................................2 43 2. Definition of basic principles..................................3 44 3. "Streams" definition. Model of the Single Physical Line.........5 45 4. Structure of real-time data.....................................8 46 5. Fishbone model..................................................9 47 6. Real-time requests.............................................12 48 7. Local Broadcasters Model.......................................13 49 8. Mathematical evaluation of the created models..................17 50 9. Requirements for a real-time protocol based on the Local 51 Broadcasters Model.............................................25 52 9a. Properties of an imaginary protocol..........................26 53 9b. General principles of the chosen model for real-time data 54 transmission.................................................28 55 10. Comparison between the imaginary RTTP and other researches 56 concerning real-time data transmissions.......................30 57 11. Plan for researches based on this document....................31 58 12. Security Considerations.......................................32 59 13. References....................................................32 60 14. Author's Address..............................................33 61 15. Full Copyright Statement......................................33 63 1. Introduction 65 The purpose of this memo is to focus discussion on real-time data 66 transmission in the Internet and give a possible method of 67 solution. 69 No proposed solutions in this document are intended as 70 standards for the Internet. Rather, it is hoped that a 71 general consensus will emerge as to the appropriate solution 72 to such problems, leading eventually to the adoption of 73 standards. 75 "Real-time data transmission" means audio and visual information. 76 The closest by analogy with radio broadcasting. 78 The offered idea expects this imformation to be interpreted by a 79 human. It is not suitable for real-time transmissions between 80 machines only. 82 This document doesn't only propose ideas but also descibes the way 83 some of them have been reached. The memo's origin is the "Protocol 84 for real-time transmission in a packet-switched computer network" 85 work first published and still available in HTML at 86 http://rttp.over-ground.net . 88 The core idea of the document is described in sections 7 and 8. 90 Section 2 defines principles valid for analogue audio and video 91 broadcasting. The conclusion is that they are much different than 92 the principles Internet is constructed on. Sections 3, 4, 5 and 6 93 of this document develop ideas how to apply the principles of an 94 ordinary tv and radio to a computer network. Section 9 compares 95 the basic idea of the document with some existing ideas for real- 96 time transmission. 98 2. Definition of basic principles 100 Two principles concerning data transmission are defined here. They 101 are used for comparison between TCP/IP transmission and radio 102 broadcasting. 104 The following definition of "broadcasting" is made here: 105 transmission of data independently from the recipients. A 106 broadcaster operates in the same way no matter the receivers. This 107 definition is valid for the whole memo. 109 Principle for importance of reliability � transmitted data must be 110 received as full as possible, no matter the time it will be taken 111 for. The reliability is more important than the time the transfer 112 will take. 114 Principle for importance of time � transmitted data must be 115 received as synchronously as possible. The perfect way is to 116 receive the data with the speed ot its transmission. If the whole 117 data cannot be received synchronously some part of it may be 118 eliminated but there must be no obstruction to receive the 119 following actual data. 121 According to these definitions IP follows neither one nor the 122 other of the principles. The time to live each packet has can be 123 assigned to the second principle but its purpose is to preserve 124 the network from overloading. 126 Basicly TCP/IP is constructed according to the first principle. 127 The packed switching gives some level of reliability and the 128 acknoledges TCP uses cause nearly every packet to reach its 129 destination. 131 If a radio or tv program must be transmittes we must refer to the 132 second principle. It is more important to receive data 133 synchronously than to receive it full. 135 Broadcastings on air are constructed this way. The receiver is 136 surely in touch with the transmitter, the transmitter is also a 137 broadcaster, according to the definition. If the program is not 138 received properly, for example if the antenna is too small, 139 usually there is enough data received for a human to understand 140 what is broadcasted. This is a huge advantage of broadcastings on 141 air. 143 This advantage is due to the fact that the most importaint peices 144 of data are in the surest zone of the information stream. 146 The surest zone is the one in the center of the freqiency band 147 width. Examples from FM radio and tv broadcastings will follow. 149 In the center of the frequency bandwidth there are the lowest 150 frequencies which are enogh for speech or melody understanding. If 151 a human receives with its radio only these lowest frequencies he 152 is not supposed to enjoy the program but he will understand what 153 is it about. If the bandwidth that is received is expanded there 154 will be a good quality of the music received. 156 The stereo information is situated in the farest non-sure zone of 157 the bandwidth. If the stereo information is received the quality 158 gets better but there is a pretty good quality even without it. 160 Color and B&W tv can be compared by analogy. The color information 161 is a little piece of the whole one and is in the farest zone of 162 the bandwidth. Because of its lower frequencies the sound of a tv 163 program is most surely received. 165 If some of the broadcasted data is lost the user will hear a 166 distinguished sound and a picture with bad quality. If less data 167 is lost there will be a brilliant picture but still B&W. In this 168 case there is enough information a human can understand. Most of 169 the information carriers are present, there is only an adition 170 missing � the color. 172 Three characteristics of real-time broadcastings on air have been 173 defined: 175 - guaranteed synchronous receiving; 177 - preserving of information as much as possible even if not the 178 whole data is received; 180 - the broadcaster is independent from the count and state of the 181 receivers. 183 To transfer data with these characteristics in a computer network 184 the real-time mechanism must include data multiplexing according 185 to its levels of importance. 187 Data must be devided into pieces with increasing and assigned 188 levels of importance. If the whole information cannot be 189 transferred only the most important pieces should be. 191 3. "Streams" definition. Model of the Single Physical Line. 193 A model of real-time communication between a client and a server 194 will be constructed. They are parts of a packet-swithing network. 195 In particular we may thing for the data as audio-visual one 196 although this is not obligatory. 198 In this model "client" is defined as a (process on) host 199 requesting and receiving data. The "server" is a (process on) host 200 which finally manipulates data before it is supplied to the 201 client. This definition of "server" is not actually true in the 202 common sense of the term but it will be used with its pre-defined 203 meaning in the whole work. 205 Model description. 207 The client requests and receives data. The client is connected 208 only with the server by a single line with defined maximal 209 transfer rate. This kind of connection will be called "single 210 physical line". 212 The server is not a generator of the packets it sends to the 213 client. It is just a host of an interconnected network. The real 214 executor of client's request is another host among the network and 215 will be called "broadcaster". At this point the mechanism for 216 transmission of data between the broadcaster and the server is not 217 a subject of interest. It is accepted to be true that the server 218 is able to receive all of the data generated by the broadcaster in 219 its primary sequence. 221 The broadcaster generates every specified interval data with 222 quantity k [B/s]. 224 Let W [B/s] be the quantity of data which can be sent from the 225 server to the client for the specified interval. Let W variates in 226 the range [0; m], where m > k. 228 It is accepted that the client requests only the data of the 229 broadcaster. It doesn't mean there are no other packets 230 transfered by the single physical line that connects it with the 231 server. This can be one of the reasons for W variation. 233 If W exceeds or equals k, evidently all of the data generated by 234 the broadcaster will be received by the client. 236 If W < k the server must discharge some of the packets according 237 to the principle for importance of time but according to the 238 principle for importance of reliability the mustn't be chosen 239 occasionally. The server must have a criteria which of the packets 240 to be eliminated if they cannot all be transmitted. 242 The broadcaster must structure its data according to some levels 243 of importance. It is to do this as the server is not oblidged to 244 interpret broadcaster's data. 246 In this model the broadcaster generates n packets each unit of 247 time. They are numbered from 1 to n independently for each unit 248 and these numbers will be called "internal". Time intervals are 249 numbered also form 1 to q and they form q so called �streams�. 251 Every packet holds its stream number - i and the sequent number 252 inside the stream - j. On the whole, the broadcaster generates 253 packets each having two indexes (i, j) in the following sequence: 255 (1, 1), (1, 2)... (1, n), (2, 1), (2,2)...(2, n), (3, 1)... 256 (q-1, n), (q, 1)...(q, n), (1, 1)..... 258 In this model the information is first divided by time in units 259 with equal length. For every time unit the data is structured 260 according to its importance and the packets carrying the most 261 important data are the packets with smallest internal numbers. The 262 time to live for a packet (if there is one specified for the 263 network) must not be greater than the time for turning through the 264 whole stream numbers. This guarantees there will not be received 265 two pakets with identical indexes (stream and internal number) 266 without having idea which was first generated. 268 The indexes implemented in all of the packets must be used by the 269 server in case W < k. The purpose is to obtain real-time 270 transmission so it is unacceptable just to queue the newcoming 271 pieces of data. 273 It is accepted for true that all of the packets that should be 274 sent through the single physical line are stored in FIFO queue by 275 the server. 277 This is not enogh for real-time data transmissions so 278 broadcester's packets should be treated differently. 280 The sequence of streams is the sequence of their identifiers 281 except for stream q followed by stream number 1. 283 The server acts as following: 285 1) Every newcoming real-time packet with destination the client is 286 added to the queue for the client if in it there is no 287 untransmitted packet with the same or smaller internal number and 288 smaller stream identifier. Every time a real-time packet is added 289 all of the broadcaster's packets are sorted by ascending indexes. 290 They are stored in so sorted order on places of the queue already 291 reserved by broadcaster's packets. 293 2) When a new packet arrives to the server and in the queue for 294 the client there is untransmitted one with the same or smaller 295 internal number and smaller stream identifier all the packets 296 belonging to previous steams are discharged. The packets remaining 297 in the queue are stored on the nearest to the exit places of the 298 queue already reserved by broadcaster's packets. 300 These acts of the server asure: 302 1) The principle for importance of time. Discharging old packets 303 guarantees that the client will always receive actual data. As a 304 packet with same or bigger internal number from the next stream is 305 received, the client's delay is bigger than one time unit of the 306 broadcaster. 308 2) The principle for importance of reliability. The packets with 309 smallest internal numbers are always stored on front positions 310 into the queue. 312 3) Transmission equity. The real-time data doesn't bother the 313 other. Each time real-time packets are sorted they are placed on 314 already reserved by the real-time transfer places. These places 315 are FIFO manipulated like non-real-time packets. 317 Example: Let's have packets with numbers (2, 4); (2,5) and so on 318 in an outgoing queue of a server. There is a delay in 319 transfer to the client and they are not transmitted for a 320 period of time. 322 When (3, 1) packet arrives it will be stored at the end 323 of the queue. After it (3, 2) and (3, 3) will be stored. 324 If packet (2, 4) is still untransmitted and (3,4) 325 arrives, evidently the client is behind time. 327 In this case packet (3, 1) will be stored on the place 328 (2, 4) used to take; (3, 2) will replace (2, 5) etc. The 329 old data will be discharged and the new will take its 330 place for the purpose of compensating as much as possible 331 the delay. 333 (end of the example) 334 The second term of transmission is according to the priciples for 335 importance of time and reliability and also the queue operations 336 are equitable. There is no danger to mix the arriving data. The 337 basic problems are how information will be structured and 338 transfered to the server. 340 The model does not guarantee synchronous receiving of data. We are 341 not sure all of the packets will be received in the sequence they 342 are generated but when a client receives a packet with stream 343 number different than the one of the previous it may be sure there 344 will be no more data from the previuos stream. If a client stores 345 the received packets in memory after the stream changes the data 346 from the previous one may be interpreted. 348 4. Structure of real-time data 350 An example of data multiplexing according to levels of importance 351 is given here. No standard is specified in this point. The purpose 352 is just to prove it is possible and combined with the real-time 353 transfer mechanism sufficient result can be reached. 355 An example of stereo sound multiplexing will be used, the 356 frequency responce is 20~20000 Hz and the dynamic range is 96 dB. 357 The example is based on the charactreristics of the sound 358 recording on a compact disc (digital audio) which is recognized as 359 a high quality standard. Generally, in this point a sample 360 mechanism for structuring the data from a compact disc is needed. 362 The first thing which can be done is to transform the stereo sound 363 to mono. By making an average of each two corresponding samples 364 from the two channels the mono channel is received. The received 365 sound has enough information for sound understanding, it has lower 366 quality than the original program but its data is half at size. If 367 the mono channel is present together with one of the stereo 368 channels, the other channel of the stereo sound can be reckoned. 369 The whole size of the mono channel and one of the stereo ones is 370 the same with the original size of the program. Even this 371 elementary operation leads to two basic facts: 373 1) The data was divided, so a receiver able to receive only half 374 of its size would interpret it correctly. 376 2) A recever of the complete information doesn't need to have 377 bigger capacity than a receiver of the original program. 379 The received mono signal can additionally be devided by frequency 380 ranges. 382 Let a new channel called K1/5 be created. K1/5 is made by 383 calculating averages of each five sequent samples of the mono 384 channel. The frequency responce of the new signal is 4 KHz, which 385 is close to a phone call quality and enough for speech or melody 386 understanding. The size of K1/5 is one fifth of the size of the 387 primary mono sound. If any four of five samples from the mono 388 channel are transmitted together with the respective K1/5 sample 389 the all five samples of the mono signal can be received. Yet, a 390 receiver having capacity 1/10 (it is 1/5 of the half) will be able 391 to interpret some data. On the other hand the whole program, 392 structured as K1/5 samples fist, followed by the complementary 393 blocks of four samples from the mono channel, and then followed by 394 one of the stereo channels has the size of the original program. 396 A working example for data structured by levels of importance must 397 lie on channels with cascading expanding of frequency responce and 398 dynamic range. This memo doesn't take up with offering such 399 mechanism. This example was just for a provement it is possible to 400 multiplex data this way. In the example compression is not 401 foreseen but it can greatly reduce the data size. Surely there can 402 be numberless algorithms for data structuring and if there is a 403 working real-time mechanism for data delivery they will be 404 undoubtlessly invented. 406 5. Fishbone model 408 At this point a model with many single physical lines will be 409 considered. The Single Physical Line model was created with the 410 purpose to find a mechanism for data structuring. Dividing the 411 broadcaster from the server was not necessary. It was made because 412 this model had to be easily extended. 414 As first extension of the model more than one client is added. All 415 of the clients are connected by their own singe lines to one and 416 the same server. All of the clients request one and the same 417 broadcaster's program. ("Broadacster's program" is the real-time 418 data generated by the broadcaster. The analogy is a "tv program" 419 or "radio program".) 421 The server has different outgoing queues for all of the clients. 422 In every queue the real-time packets are handled together with 423 non-real-time packets, according to the principles for a single 424 physical line defined in section 3 of the document. Evidently the 425 server must operate with each queue individually. On the other 426 hand there will be many coinciding packets in the outgoing queues. 427 This is disadvantageous to send each client's request to the 428 broadacster as all of the data is sent through the server. 430 The Single Physical Line model doesn't discuss the request 431 operation. When there are more than one clients the request method 432 is important. There are two cases: 434 1) Every client sends its own request to the broadacster and the 435 broadacster receives it. The broadacster sends packets with 436 destination the client-requester. The server manipulates the real- 437 time packets transmitted through it according to the rules for a 438 Single Physical Line. 440 2) The server sends a request to the broadcaster. After a real- 441 time packet from the broadcaster is received it is multiplied and 442 stored in the queue for each client that requested the data. Each 443 queue is manipulated according to the rules for a single physical 444 line. 446 The second variant is more advantageous. The network traffic is 447 diminished but it doesn't affect the quantity of data each client 448 receives. The data for all of the clients is transmitted through 449 the server so there is no need to do it as many times as the 450 clients are. 452 The behaviour of each host of the network must be defined. It is 453 defined that the server is engaged with the transfer. The server 454 holds the balance between the principles for importance of time 455 and importance of reliability. The single request for more than a 456 client is close to the principle for independence of the 457 broadcaster from the receivers and close to transmissions on air. 458 This scheme works for clients connected by single physical lines 459 but the purpose is to build a working scheme for the whole 460 network. 462 It is possible a client to be connected than more than a line to 463 more than a host of the network. If there is real-time data 464 transmission there are three ways each host can act: 466 1) Lack of commitment: 468 The server is the only host of the network dividing the 469 real-time packets form the other. The other hosts route each 470 real-time packet like any other. This scheme contradicts the 471 principle for importance of time. The network can be 472 engorged with data. These are enogh reasons to treat this 473 variant as unacceptable. 475 2) Partial commitment: 477 Every host recognizes the real-time packets. Every packet is 478 routed like any other but real-time ones are manipulated 479 according to the principles of a single line in the outgoing 480 queues. 482 3) Complete commitment (Fishbone model): 484 Every host commits with the real-time requests it is to 485 transfer. Every host modifies the requests and transfers 486 them with its address as receiver. When the host receives 487 real-time data it sends it to each of the hosts that 488 requested it. 490 Evidently the server from the previous model is completely 491 commited with the transfer. If all hosts act this way any 492 request's destination will be cascadingly modified. There will be 493 constructed a transfer route through the network. When a request 494 from another part of the network is sent it will either be 495 performed by another route or will cause an existing transfer 496 route to branch out into another direction. If the broadcaster is 497 connected by d lines with d hosts of the network the maximum 498 number of requests it will receive will always be d, and each will 499 be executed by a different route through the network. The complete 500 tree of routes through the network if there are many clients 501 remains a fishbone which gives the model name. 503 The Fishbone model is near the principles for broadcaster's 504 independance from the receivers, it observes the importance of 505 time but has disadvantages about reliability. 507 It is based on a fixed route through the network and every host 508 can become a weak point of the structure. Data losses between two 509 hosts become current for all of the hosts relying on them. 511 A big problem appears when a host taking part in the transfer 512 route drops out. If every request is resend after a period of time 513 the transmission will be recovered by another route but after a 514 period of silence. 516 On the other hand if a host is physically the only one able to 517 serve multiple request ("server - client", according to the single 518 line model) the Fishbone model seen to be the optimum one. 520 A network with lack of commitment of the hosts was categorically 521 rejected so a medial variant between partial and complete 522 commitment is needed. 524 The scheme for real-tme transfer must be applicable for a packet- 525 switching network and what is the most important - all hosts of 526 this network must follow same principles with others. In the 527 models yet described there were parts of the network (for example 528 the server in the Single Physical Line model) acting differently 529 than the others. 531 If different hosts of a network are able to act differently it 532 must be only as a result of apllying same principles in different 533 situations. It is assumed that all hosts must observe the 534 following basic rules for real-time transfer: 536 1) every host distinguishes real-time packets from the others; 538 2) in every outgoing queue the real-time packets of any 539 broadcasted program are manipulated according to the principles 540 for a Single Physical Line. 542 6. Real-time requests 544 In the models already constructed requests are not discussed. 545 These models accept there is a request and pay attention to data 546 transfer as a result. A specified requesting mechanism is evidenly 547 needed. The broadacster must receive at least one request for data 548 to start transferring. The request can be sent by a real-time or 549 non-real-time packet. The client won't need broadcaster's transfer 550 ethernally so it better renew its request after a period of time. 551 On the other hand the client mustn't be deprived of transfer if 552 its renovating request is transferred too slow, therefore the 553 broadcaster must generate data for a longer period than the one 554 for request renovation. 556 Let Tz be the time interval after which the client will resend its 557 request. The client will send its request and the broadcaster will 558 receive it (no matter with or without modified client's address) 559 after time represented by Tp. Let the broadcaster stop the 560 transfer if a request is not re-confirmed in Ts time. In this case 561 it is necessary to be true that: 563 Ts = Tz * k + �p, as k is a coefficient and k > 1. (1) 565 The reason for this is the assumption that the client will start 566 counting out Tz imediately after the request is sent. The 567 requesting packet will reach the broadcaster in time Tp, and if 568 there's no a big change in network state the next (renewed) 569 request will reach the broadcaster in time Tz + Tp. The 570 coefficient k guarantees there will be no stop of transfer before 571 the next request reaches the broadcaster. This coefficient should 572 be big enough to cope with this task. If there is a mechanism for 573 counting Tp, the broadcaster will be able to set different Ts for 574 each request, even if k = const. It is necessary the time interval 575 for each client (Ts) to be reset by the broadcaster each time a 576 request is renovated. 578 The mechanism of mutual time intervals guarantees there will be no 579 constant high intensive request traffic in the network, also the 580 presence of transfer for a while even if there is no request 581 reconfirmation saves the network from unnecessary traffic in cases 582 a client refuses the program. Evidently the time interval and the 583 coefficient k must be carefully selected. 585 It is natural the time interval Ts to contain the time for turning 586 out some series of data streams. If it elapses for the time of one 587 data stream the requests will be too frequent. In equality (1) the 588 most significant member should be Tz, i.e. 590 Tz >> Tp, 592 otherwise the variation of Tp will strongly affect the 593 implementation of the term and a big enough value for k will be 594 needed to prevent from transfer interrupting. 596 According to the client the real-time data will stop Tp + k * Tz + 597 Tp� time after its last request, Tp� is the time for the last 598 broadcaster's packet with destination the client to reach it. If 599 the network has respectively constant parameters it is probably 600 true that Tp approximately equals Tp�. 602 As Tz >> Tp it is a good idea to provide a refusing request 603 (refusal) which can be sent by the client if it no more needs 604 broadcaster's transfer. It will preserve the network from a little 605 unnecessary traffic. If a refusal is not sent, for example is the 606 client just drops down, the traffic will be ceased too, but a 607 little bit later. 609 7. Local Broadcasters Model 611 Request renovation applyed to the Fishbone model is able to 612 minimish its disadvantages. Fishbone model presumes each host is 613 to modify the request. The request will be sent by the most 614 optimum route through the network, so the transfer will be sent by 615 the same optimum route. When the request is renewed if the 616 developed route is no more the most optimum another transfer path 617 will be created. This solves the problem with dropping out a host 618 of the network but doesn't solve the problem with the weak point 619 each host can be. 621 The next development of the Fishbone model appears after a 622 detailed study of a host signified as "server" in the Single 623 Physical Line model. 625 This host is always completely committed with the transfer. Real- 626 time packets are always treated the same way no matter if it is 627 the requester (according to the broadcaster) or a single client 628 is. Committment of this host must be examined in details. 630 The first client's request reaches it and according to the 631 Fishbone model this host should replace requester's address with 632 its own. On the other hand there is no need to do this. The 633 transfer between the server and the client will always follow one 634 and the same scheme no matter which of them is the requester. 635 According to the principle for network sameness (all hosts must 636 follow same principles) if this host modifies the request all 637 others must do this - it is the Fishbone model itself. To change 638 the model it is accepted the host doesn't modify requester's 639 address but just transmits the request-packet with its original 640 contents. As there is network sameness all other hosts have to do 641 this so the broadcaster receives a request for data with 642 destination the client. 644 After a time the server receives another client's request for the 645 program which data is already transmitted through it. If the 646 server just transmits this request again it will bother the 647 principle for mimimum transfer through the network. Evidently in 648 this moment (or a little bit later) the server is to commit with 649 the transfer, send its own request and then resend the real-time 650 data to both his clients. The conclusion is that the server must 651 remember all real-time requests transmitted through it and still 652 active (with unelapsed time) and if another request for already 653 ordered program appears, the server must send it as its own. The 654 basic criterion is the number of still active requests passed 655 through each host. 657 Let's have a detailed look at server's behaviour. By the time of 658 the second request the first one is still active, so if the server 659 immediately sends its request there will be a period of time with 660 double identical data transfer. It bothers the principles for 661 mimimum traffic and for broadcaster's independance. The second 662 request is sent later than the first, so according to the 663 subjection Tz >> Tp the second one will expire later. On the other 664 hand the server can immediately comply with the real-time transfer 665 just by copying and sending the packets with destination the first 666 requester to the second one too. If the server is in charge of the 667 minimum transfer there are two variants: 669 1) the server waits for the first request to expire and modifies 670 its renovation with its own address; 671 2) the server sends its own request immediately and a refusal on 672 behalf of the first client together with it. 674 Both variants are acceptable. If the first client doesn't renew 675 its request the first variant seems to be better. Without 676 renovation the server will pass second client's request without 677 any modification but after the first client's request is elapsed. 678 If the second variant is chosen in the above situation there will 679 be for a short period of time: 681 server's REQUEST -> 682 first client's REFUSAL -> 683 second client's REQUEST -> 684 server's REFUSAL, 686 and as the second client's request was delayed there will soon be 687 its next one. 689 The basic principle of this model is the following: 691 The server passes each request for a real-time program if there is 692 no active request that passes through it for the same program. The 693 server stops every request for a real-time program if there is at 694 least one active request that passes through it for the same 695 program. When the server stops client's request it send one for 696 the same program with its own address as destination and takes up 697 with multiplying the real-time data to all clients having active 698 requests for this program. 700 As the server acts this way any other host of the network should 701 act this way too. 703 A disadvantage - if a client's request is stopped it will start 704 receiving the data which the server multiplies for the client. 705 Anyway, it is possible that not the whole traffic for the previous 706 client passes through the server, so the next one will not receive 707 complete data but a partial one. It will be true until the 708 previous client's request expires. After that the server will send 709 the request and becoming a receiver of the whole data will act 710 equally towards both clients. 712 The idea of the model is in constructing local broadcasters in 713 network areas with enhanced interest in one and the same program. 714 The model will be called "Local Broadcasters model" or just LBC 715 model in future. There are no additional rules for packet routing 716 except these for a Single Physical Line in the outgoing queues. As 717 requests are renovated the local broadcasters will dynamically 718 appear and die out. Each host can become a local broadcaster of a 719 program for a time. Each host must also recognize not only the 720 packets containing real-time data but also the ones containing 721 requests for such data. 723 Another aspect of LBC is that a refusal can reach not the local 724 broadcaster but the real broadcaster which doesn't have idea about 725 this client at all. Therefore a notification is necessary so each 726 client should know whether it is served by the real or a local 727 broadcaster. If a client was notified it should send a refusal to 728 the local broadcaster. 730 Behaviours of the different components of a network, according to 731 the LBC model must be explained: 733 1) Client. According to the client all Single physical line model, 734 Fishbone model and LBC model are equal. Local broadcaster's 735 notifications are a small and unessential difference between LBC 736 and the other two models. 738 2) Host (which is not a client). Compared with the case in which 739 each host is partially committed with the transfer there is an 740 additional work-load as each host must listen for real-time 741 requests. When a host becomes a local broadcaster it is completely 742 committed with the transfer and still has to listen for other 743 real-time requests. 745 3) Broadcaster. The maximum number of requests a broadcaster can 746 receive equals the number of physical lines it is coonected to the 747 network by. Each line is a beginning of a branch of lines and if 748 more than a request is generated in any branch a local broadcaster 749 will be created. The broadcaster is free to choose a route for 750 each real-time packet. It is loaded like a completely commited 751 with the transfer host. 753 4) Entire network. Network behavior can't be indicated without 754 mathematical appliance. LBC seems to be better than the Fishbone 755 model for there is no compulsory data route which can save the 756 transfer from some losses of data. The whole data can be divided 757 and transfered by lots of low-capacity lines which is not possible 758 according to the Fishbone model. On the other hand there is a 759 possibility of double traffic by one and the same line between two 760 hosts. If host � is a local broadcaster for host � all real-time 761 data will have host A as distination. It is possible some of this 762 data to pass through host B, reach A, and then be sent again to 763 host B by host A. There will be equal transfer in both directions, 764 one more outgoing queue with a possibility of data loss. Yet, this 765 transfer will bother neither the broadcaster, nor the other hosts 766 of the network. 768 Local Broadcaters Model is the core of this memo. The other ones 769 are constructed just for the purpose of reaching the idea of LBC 770 easier. The author believes that a protocol based on LBC model can 771 be sufficient for real-time data transmisions in Internet. 773 8. Mathematical evaluation of the created models 775 The created models for real-time data transmission need some 776 mathematical evaluation. It is given at this point. 778 The first interesting index is the loading of network. The network 779 load should be measured as the quantity of traffic transfered for 780 a period of time, in particular B/s. The network load is a 781 combination of all hosts' loads. There are three types of hosts 782 while real-time data transmission. These are broadcaster, server 783 and client. These designations are not really precise in their 784 common meanings but they will be still used in the future in their 785 redefined meanings. 787 At first broadcaster's load is to be discussed. Each time unit the 788 broadcaster generates a real-time program which data's amount is t 789 [B/s]. For our convenience it is accepted that the data has an 790 even distribution in time, i.e. t=const for any time unit. 792 Let T [B/s] is the complete amount of data that the broadcaster 793 sends to the network for a defined unit of time. 795 1) If hosts are partially commited with the transfer: 797 T = l1 * t + l2 * t + ... + lk * t = t * sum(l1; lk), 799 where li is the completeness of the transfer allocated for i-th 800 receiver (0 =< li =< 1), according to the broadcaster; k - number 801 of clients for the examined unit of time. 803 According to this model the broadcaster sends data concretely for 804 each client, so there are k addends, it is possible some data to 805 be lost in broadcaster's outgoing queues so coefficient for 806 completeness are added. 808 Fictionally every li = 1. 810 2) Fishbone model: 812 T = n1 * t + n2 * t + ... + nm * t = t * sum(n1; nm), 814 where m is the number of broadcaster's physical lines used for 815 real-time traffic; ni is the completeness of the transfer by the 816 i-th line (0 =< ni =< 1), according to the broadacster. 818 The Fishbone model permits only one real-time request by line, so 819 the maximum value for m is the value of the physical lines that 820 connect the broadcaster to the network. It is possible some data 821 to be lost in the outgoing queues for the differenet lines, so 822 coefficients ni for completeness are added. Fictionally every 823 ni = 1. 825 3) Local Broadcasters Model: 827 T = p1 * t + p2 * t + ... + pq * t = t * sum(p1; pq), 829 where q is the number of received requests; pi is the completeness 830 of the transfer allocated for i-th request, according to the 831 broadcaster. 833 Only one request can reach the broadcaster by line, as any 834 multiple requests will be stopped by local broadcasters, so the 835 maximum value for q is the value of the physical lines that 836 connect the broadcaster to the network. 838 It is possible some data to be lost in the outgoing queues, so 839 coefficients pi for completeness are added. Fictionally every 840 pi = 1. 842 The three formulas look rather alike, evidently with main 843 inportance are the sums they contain. 845 On the other hand it mustn't be expected the index T to rise 846 unlimited. The broadcaster has limited number of connections to 847 the network and each connection has its maximum capacity. 849 Let c be the number of broadcaster's connections, and let the i-th 850 has ri [B/s] as a capacity for real-time transfer, 1 =< i =< c. 852 Broadcaster's physical lines are numbered fictitiously but their 853 numbers, once assigned, should be unchanged for the formulas. 855 Let R [B/s] be the maximum data that the network can accept from 856 the broadcaster. In this case 858 R = r1 + r2 + ... + rc = sum(r1; rc). 860 Evidently T =< R, so there are the following inequalities for the 861 three models: 863 1) sum(l1; lk) =< R/t for partial transfer commitment; 864 2) sum(n1; nm) =< R/t for Fishbone; 866 3) sum(p1; pq) =< R/t for LBC. 868 Both R = const, and t = const, so two facts are subjects of 869 interest: 871 - Conditions making each inequality to an equation; 873 - The average value for the indexes of each sum whenever the 874 expression it takes part in is an equation. 876 According to the principle for smallest traffic, the optimum 877 inequality is the one which's left side is the smallest, compared 878 with the other two, when the number of clients is one and the same 879 for the three expressions, because the whole data transferred by 880 the broadcaster is the product of each left part and t. 882 According to the principle for reliability, the optimum inequality 883 is the one in which the average value of all indexes the left side 884 consists of is the biggest, compared with the other two 885 inequalities, when the number of clients is one and the same for 886 the three expressions, because the left parts are all sums of 887 coefficients giving completenesses of transfer. As bigger the 888 average completeness is, as better the program will be received. 890 In both cases the least sum of bigger members is needed, so 891 evidently the most optimum sum is the one with fewest members. 893 The first formula is the only containing the number of clients. 895 There is a need of mechanism for counting the number of clients in 896 the formulas for Fishbone and LBC models. For ease, the following 897 addmission is made: The broadcaster takes a central zone of the 898 network, which means there are approximately equal numbers of 899 hosts most shortly addressed by each line. 901 This is not a precised addmission but if it is true there are 902 equal possibilities a request to reach the broadcster by any line. 903 It will most load the broadcaster. If the network is not balanced 904 in relation to the broadcaster, most of the requests will be 905 served by some of the lines, which will be far of the borderline 906 case (maximum load) that we are looking for. That's the reason the 907 addmission mustn't be treated as a negative one. 909 If there is at least one client a transfer route will be created, 910 so T = n1 * t. 912 If the second request reaches the broadcaster by another line the 913 whole transfer will be T = t(n1 + n2). 915 The value of T will grow until it reaches T = t * sum(n1; nm), 916 realized for every i =< m, and then will stay constant for every 917 i > m. Fictionally every ri >= t, i.e. R >= mt, so the biggest 918 possible transfer is T = mt. 920 This was the sutuation according to the Fishbone model. 922 The LBC model is largely the same. The value of T will grow until 923 it reaches T = t * sum(p1; pq), realized for every q =< m, and 924 then will stay constant for every q > m. Fictionally T = mt. 926 For the model of hosts with partial commitment the fictional value 927 of T is T = tk, and there is no limitation for the increase of k. 928 This is a linear function which is practically impossible as the 929 value of R can't be unlimited. That's the reason this model will 930 no more be evaluated. It is to be rejected as unefficient. The 931 more clients are, the average data each receives is less. 933 At the other two models the growth of transfered data stops no 934 matter how many the clients are, and if R >= mt it is possible 935 that no data is lost in broadcaster's outgoing queues. 937 The Fishbone model foresees each request is served by its own 938 physical line, so the potential loss of data for the request 939 depends entirely on this line. 941 The completeness of transfer by the i-th line is describes with 942 the following function ni = F(ri): 944 ni = ri/t, realized for ri =< t; 945 ni = 1, realized for ri > t, 946 t = const. 948 This dependence not only describes the completeness of transfer 949 for the i-th request according to the Fishbone model, but 950 generally the completeness of real-time transfer by the i-th line. 951 If there are two or more requests served by a line the 952 completeness of the data for each request will be ri/s * t, as s 953 is the number of requests served by the line. The completeness of 954 transfer is the ratio of the possible transfer and the desired by 955 the host one, generally ri/Ri, as Ri [B/s] is the desired transfer 956 (the one which if fully transmitted will lead to no loss). At the 957 Fishbone model Ri = t realized for every i. The LBC model doesn't 958 keep within this condition. 960 At LBC Ri is different than a constant, and wholly depends on 961 network's condition. 963 Basicly, the data predestinated for the j-the request is to be 964 divided in c parts, because c are the physical lines of the 965 broadcaster. Each line will take gji part of the transfer which 966 will be gji * t [B/s]. 968 The following conditions are realized: 970 0 < j =< c; 971 0 < i =< c; 972 0 =< gji =< 1, realized for every i, j; 973 gj1 + gj2 + gj3 + .... + gjc = 1, realized for every j. 975 Each unit of time the desired transfer destinated to a host is: 977 Ri = t(g1i + g2i + ... + gci), and Ri is the quantity of data 978 which if sent through the i-th host will be sent with no loss. 979 Fictionally Ri =< ri. 981 The completeness of transfer through the i-th host - G, by analogy 982 is the ratio of these two quantities: 984 Gi = Ri / ri = t(g1i + g2i + ... + gci) / ri, 985 realized for Ri =< ri; 986 Gi = 1, realized for Ri > ri. 988 In difference to F, G can't be defined as a function of one single 989 index. 991 The coefficients showing the division of data among the hosts can 992 be structured in a square matrix: 994 g11 g12 g13 ...... g1c 995 g21 g22 g23 ...... g2c 996 .......................................... 997 gc1 gc2 gc3 ...... gcc 999 It is true that each line's sum equals 1. By multiplying the 1000 matrix by t it looks like: 1002 g11t g12t g13t ...... g1ct 1003 g21t g22t g23t ...... g2ct 1004 .............................................. 1005 gc1t gc2t gc3t ...... gcct 1007 It is true that each line's sum equals 1 t. This is not totally 1008 true, as is the statement for 1 lines' sums. Some of the lines can 1009 equal 0 as there can be no request by every line. In the 1010 borderline case of maximum load the statement is true for each 1011 matrix' line. 1013 The received matrix can be multiplied by the one representing the 1014 completeness of transfer: 1016 G1 1017 G2 1018 G3 1019 . 1020 . 1021 . 1022 Gc 1024 The result looks as following: 1026 g11G1 + g12G2 +......+ g1nGn 1027 g21G1 + g22G2 +......+ g2nGn 1028 . 1029 . 1030 . 1031 . 1032 gn1G1 + gn2G2 +......+ gnnGn 1034 By analogy the Fishbone model can be presented by the following 1035 matrixes: 1037 1 0 0 0 ... 0 0 F1 F1 1038 0 1 0 0 ... 0 0 F2 F2 1039 0 0 1 0 ... 0 0 F3 F3 1040 0 0 0 1 ... 0 0 * F4 = F4 1041 ............... . . 1042 0 0 0 0 ... 1 0 Fn-1 Fn-1 1043 0 0 0 0 ... 0 1 Fn Fn 1045 In both cases the completeness of transfer for each request is 1046 expressed in one and the same way. But both formulas are still 1047 unrelated so the models can't be compared according to them. These 1048 formulas are convenient for simulating programs and statistical 1049 evaluation. 1051 Another limitation must be introduced here, after the one for 1052 centered broadcaster. In LBC model it is assumed that the 1053 broadcaster acts intelligently in some measure. 1055 The intelligent aspect of broadcaster's behaviour includes 1056 distribution of data according to the network load. Generally must 1057 be true the following: 1059 Ri / Rj = ri / rj, 1061 realized for 1063 0 < j =< c; 1064 0 < i =< c. 1066 We are not interested in the concrete traffic distribution for 1067 each request but we know it is according to lines load. If the 1068 broadcaster doesn't behave this way the whole model is 1069 unefficient. 1071 Evidently the last equality can't be entirely true in all cases 1072 but it must be approximately true. Anyway, if R >= ct, the loss 1073 for each request's data must lean towards 0 for the nearest to the 1074 broadcaster zone of the network. This must be true no matter which 1075 the physical lines are - the great advantage of the LBC model 1076 compared with the Fishbone. 1078 As the maxumum possible transfer for both models is one and the 1079 same this advantage makes the LBC model the preferable one. 1081 After a broadcaster's behaviour was examined the one of the hosts 1082 and the clients must be examined too. Any client is a host of the 1083 network but for ease "host" will be used only for ones that 1084 transfer real-time data but are no clients. The transfer route 1085 through the network is always unknown and there are numberless 1086 possibilities so it is impossible all variants of host behaviour 1087 to be embraced. Only conclusions based on statistics and 1088 probability can be made. Yet, there are two possible cases for a 1089 client's role in the network: 1091 - final host, connected by a single physical line to another host 1092 of the network; 1094 - intermadiate host, connected by multiple lines to the network. 1095 Other than the requested real-time data can be transmitted through 1096 this kind of client. 1098 On the other hand if the client is an intermediate host a virtual 1099 final one can be added, so the host of the client will be examined 1100 just like any other. The capacity of the line between the real and 1101 the virtual hosts can be treated as unlimited and with no time 1102 delay. Evidently the quantity and quality of the data received by 1103 the virtual host depends entirely on the network. Virtual hosts 1104 can be added in any situation so client examination is not needed 1105 at all. Enough information can be obtained just by threshing out 1106 the hosts which transfer the data. 1108 This is the reason client's examination to be abandoned. Only 1109 formulas describing the data transfer as a result of its 1110 transmission through the network are needed. 1112 According to the Fishbone model the transfer is realized by k 1113 constant hosts (k > 0). The transfer route repeats the route of 1114 the request through the network. Relying on hosts' inteligence it 1115 can be expected the request to be sent by the freeest lines, so 1116 the created transfer route will be the one with lowest loss 1117 compared with the other variants for possible transfer paths. 1118 Anyway, the request is small enough to be directed on a route with 1119 capacity smaller than the real-time data needs. 1121 As there are k hosts forming the route the data is sent by k+1 1122 physical lines, and each has its own completeness of real-time 1123 transfer F - the same as broadcaster's lines have. This function 1124 will be called �transmission� for ease. Let F(1) be the 1125 transmission of the first line of the data route - the one 1126 connected to the broadcaster, F(2) be the transmission of the next 1127 line data will flow through and so on, up to F(k+1). 1129 The transmission of the whole system is presented by the mimimum 1130 value found among these functions. 1132 Let P(x) be the probability a physical line to be able to transfer 1133 at least x [B/s]. (x >= 0) The probability to be no loss at the 1134 first line is P(1)(t). (We stick to the denotion that t [B/s] is 1135 the whole quantity of data generated by the broadcster for a unit 1136 of time.) The probability to be no loss at the second line is 1137 P(2)(t), etc. 1139 The complete probability to be no loss after the data was sent by 1140 k+1 lines is 1142 P = P(1)(t) * P(2)(t)....P(k+1)(t). 1144 If the network is a regular one, i.e. there is same probability 1145 for each line, then 1147 P equals P (t) multiplied k+1 times by itself. 1149 In both cases the far form the broadcster the client is, the 1150 lowest probability for comlete transfer is, too. Figuratively, the 1151 signal "dies away" in the network. 1153 The presentation for LBC model is more complex. The data is 1154 transfered by s physical lines, but the transfer by each line can 1155 be ti, realized for every ti =< t. 1157 There must be no loss by any line, so the complete probaility to 1158 be no loss is 1160 P = P(1)(t1) * P(2)(t2) * P(3)(t3).........P(s)(ts). 1162 If the network is a regular one it is P = P(t1) * P(t2)....P(ts). 1164 For better descriptions of the received formulas the variation of 1165 P(x) must be examined. P(0) = 1 for sure, as data with zero size 1166 can be sent even by unexisting line. As the material world has its 1167 limitations there exists j with a limited value, and every 1168 P(x) = 0, realized for x >= j. 1170 On the other hand surely P(x) >= P(x + dx), realized for dx > 0. 1172 P(x) beginning point is (0,1) and never growing the function 1173 reaches the point (j, 0). 1175 As closer to the upward end of the shown zone P(x) is, better the 1176 real-time transfer is. 1178 Generally, the formula describing the LBC model will consists of 1179 more but smaller members, than the formula describing the Fishbone 1180 model. Both models must be compared according to P(x). 1182 The signal "dies away" according to the LBC model, too. The 1183 question is, is it more expressed at the LBC model than at the 1184 Fishbone? Author's opinion is that the answer is "No". 1186 The reason for this is that P(x) will probably keep its value of 1 1187 for values of x close to the zero point. 1189 As P(x) variation may only be proved in practice and it will be 1190 much different for the different lines of a network, a final 1191 conclusion is not given here. 1193 9. Requirements for a real-time protocol based on the Local 1194 Broadcasters Model 1196 Overview of probable real-time data transmission in the Internet 1197 is made in this point. No standard is specified here. Properties 1198 of an imaginary protocol realizing data broadcasting are 1199 discussed. This non-existing imaginary protocol is called Real- 1200 time transfer protocol (RTTP) and doesn't conform to the specified 1201 in RFC 1889 Real-time transport protocol abbreviated as "RTP" [1]. 1202 The "RTTP" abbreviation and protocol's name are used just for 1203 ease, for example �RTTP packet� means �a packet containing real- 1204 time data. 1206 9a. Properties of an imaginary protocol 1208 RTTP is based on LBC model. Some RTTP principles may be defined: 1210 1) every host of the network can become a local broadcaster of any 1211 program; 1213 2) every host of the network must recognize and check out any RTTP 1214 packet which passes through it. 1216 The first conclusion based on these principles is that the whole 1217 network must support RTTP. The easiest way for introducing a new 1218 protocol is basing it on TCP/IP [2], [3], [4]. If RTTP is based on 1219 TCP/IP it is executable in Internet. On the other hand it is 1220 impossible to apply a new protocol to the whole Internet shortly, 1221 so mechanisms for compatibility between RTTP and non-RTTP hosts 1222 must be foreseen. 1224 It must be marked off there's an essential difference between TCP 1225 and RTTP (based on LBC) conceptions. The whole network is engaged 1226 with the broadcasting in the meaning of �it changes according to 1227 it�, so RTTP encroaches upon IP. TCP envolves the communicating 1228 hosts and they exchange data but the other hosts take part only as 1229 IP routers. 1231 Yet, there are two assumptions that seem to be valid: 1233 1) the broadcaster supports RTTP; 1235 2) the requester (client) supports RTTP, otherwise it will not be 1236 able to interpret the received data. 1238 The real-time transfer doesn't need some TCP functions like the 1239 acknoledge and the window size. If there exists RTTP, it will be 1240 based on, or even parallel to IP, not based on TCP, i.e. there 1241 will exist the independent subjections: 1243 IP -> TCP, which can be IP/RTTP -> TCP; 1244 IP -> RTTP, 1246 and the subjection IP -> TCP -> RTTP will be no valid. �->� marks 1247 the protocol layering. RTTP abandones some of the ideas of TCP 1248 because of some real-time priorities - importance of time and 1249 broadcaster's independence. In this case the acknoledge is not 1250 desired. The temporary cease of transfer that happens in TCP when 1251 zero window size is reported is also unnecessary. Applying the 1252 principle of a sigle physical line for the outgoing queues 1253 automatically stops or decreases the transfer when the network is 1254 loaded. 1256 The conclusion is that RTTP can hardly be based on the existing 1257 TCP protocol. 1259 If the future proves that an RTTP will work satisfactory the only 1260 variant for its network implantation is complete compatibility 1261 between IP and IP/RTTP hosts. 1263 The things RTTP needs and IP doesn't include are pointed here: 1265 The first is a port (identifier) of the broadcasted program. The 1266 broadcaster has an IP address but probably it generates more than 1267 one program. On the other hand there can be multiple clients on 1268 one IP, so client's port is needed, too. 1270 Every packet must contain stream identifier and internal number. 1271 It is assumed packets are small enough and their fragmentation is 1272 not needed. 1274 This data can easily be stored in the data field of an IP packet, 1275 so there are no problems about it. But a mechanism for recognition 1276 of RTTP packets is needed. On the other hands there are three 1277 types of packets, if RTTP exists: 1279 1) non real-time (ordinary) IP packet; 1281 2) a real-time packet. There are two kinds of RTTP packets: 1283 - containig broadcasted data; 1285 - containig request, refusals or other official information. 1287 In every IP header there is a reserved for future use bit, there 1288 is an option class which is reserved, too, yet there are 152 1289 unassigned values for the "protocol" field, so there are enough 1290 possibilities for marking an IP packet as an RTTP one. 1292 RTTP packets must only be marked and all other necessary 1293 information can be stored in their data fields. 1295 As real-time transfer can be carried out by IP packets the problem 1296 with host compatibility is solved. There appears the problem with 1297 the network behaviour. 1299 IP hosts (host will be marked as IP and RTTP) will not manipulate 1300 their outgoing queues according to real-time requirements. RTTP 1301 packets will not be rejected earlier than their TTL is elapsed. It 1302 will not reject the belated traffic and as there is some belated 1303 traffic the broadcaster generates more data than the network can 1304 handle. Also, the program will not be received satisfactory by the 1305 client. 1307 It was stated above that the broadcaster is an RTTP host. As the 1308 network loads its outgoing capacity will fall down. The 1309 broadcaster will destroy more and more packets in its outgoing 1310 queues so the traffic it generates will also fall down. A balance 1311 will be reached, some IP zones will be much loaded, the clients 1312 divided by IP zones from the broadcaster will receive its program 1313 poorly, but the network will not be blocked up. These problems 1314 will be rarer if there are more RTTP hosts. 1316 In a mixed network (IP & RTTP hosts) more difficulties the popular 1317 programs will experience. IP hosts will not engage as local 1318 broadcasters, so the broadcaster or the local ones will receive 1319 more requests than their physical lines are and there will be 1320 great losses even at their outgoing queues. 1322 The statement that a mixed network will load but not block up 1323 sounds true but must be checked out statistically or by a 1324 simulating model. Neither statistics, nor a simulating model is 1325 offered here. 1327 If a private program (produced for just a single client) in an 1328 RTTP network must be realized the easiest way is to modify its 1329 request method. In case the client sends its request to the 1330 broadacaster by non-real-time packet, another request sent to the 1331 same broadcaster will not be recognized by the hosts on its road, 1332 there will be no local broadcasters and no possibility for data 1333 confusion. The RTTP packets of the private program will be 1334 manipulated as RTTP ones on their road but only the host of the 1335 client is going to receive them. 1337 9b. General principles of the chosen model for real-time data transmission 1339 1) Data format: 1341 - the real-time data is transfered through a packet-switching 1342 network. Each packet is routed separately; 1344 - every host of the network recognizes the real-time packets; 1346 - the broadcasted data is devided in time units with equal 1347 durations. The data for each unit of time is structured as a 1348 numbered stream, the packets inside each stream obtain sequent 1349 internal numbers. The packets carrying the most important 1350 information are the ones with smallest internal numbers; 1351 - every real-time packet carrying data contains stream and 1352 internal numbers, and the address of the broadcaster. 1354 2) Requests: 1356 - a request for a public broadcasted program is made by a real- 1357 time packet sent to the broadcaster; 1359 - every request is repeated after a specified time interval if the 1360 requester still wants to receive the program; 1362 - every host includes all requests routed by it in its table of 1363 active requests; 1365 - a request for a program not present in host's table of active 1366 requests is transmitted further through the network; 1368 - every program is erased from host's table of active requests if 1369 it is not renovated, according to the host, after the specified 1370 time interval; 1372 - a request for a program present in host's table of active 1373 requests is stopped by the host. It starts to multiply the packets 1374 of the program and send them to the new requester, too. After the 1375 time interval of the old requester elapses and if its request is 1376 renovated the host stops the renewed request and sends its own to 1377 the broadcster with its address as destination for the real-time 1378 data. The host notifies all clients for the program that it is 1379 their local broadcaster. It means that every host must count time 1380 intervals for all request in its table of active ones separately. 1381 As multiple requests are cascadingly stopped by hosts becoming 1382 local broadcasters, the maximum records for a program in a table 1383 of active requests equals the number of physical lines of the host 1384 that holds up the table; 1386 - a refusal exists. A refusal is made by a real-time packet sent 1387 to the local broadcaster or the primary broadcaster if there is no 1388 a local one; 1390 - a receive of refusal leads to erasing the client from all the 1391 tables of actice requests on the road of the refusal; 1393 - a request for private program is send by non-real-time packet to 1394 the broadcster. 1396 3) Real-time data transmission: 1398 - every real-time packet is stored by a routing host in one of its 1399 outgoing queues according to same mechanism with non-real-time 1400 packets; 1402 - every newcoming real-time packet with destination the client is 1403 added to the queue for the client if in it there is no 1404 untransmitted packet with the same or smaller internal number and 1405 smaller stream identifier. Every time a real-time packet is added 1406 all of the broadcaster's packets are sorted by ascending indexes. 1407 They are stored in so sorted order on places of the queue already 1408 reserved by broadcaster's packets; 1410 - when a new packet arrives to the server and in the queue for the 1411 client there is untransmitted one with the same or smaller 1412 internal number and smaller stream identifier all the packets 1413 belonging to previous steams are discharged. The packets remaining 1414 in the queue are stored on the nearest to the exit places of the 1415 queue already reserved by broadcaster's packets. 1417 10. Comparison between the imaginary RTTP and other researches 1418 concerning real-time data transmissions 1420 There are lots of works dedicated to real-time transfer. There are 1421 standartized protocols and practices. By the time researches 1422 concerning this item are too advanced this memo describes just 1423 basic ideas. That's because RTTP ideas are in a little different 1424 direction than the developed ones. 1426 This section compares RTTP with existing protocols and practices 1427 for real-time data transmission. This section doesn't pretend to 1428 be comprehensive, its main point is to focus discussion on the 1429 need of resource reservation. This section's references are [6 - 1430 10]. 1432 As most of the works dedicated to real-time transfer concern video 1433 and audio conferences, RTTP points mainly on broadcasting. 1434 "Broadcasting" according to its definition in section 2 of this 1435 document. Pointing on broadcasting RTTP doesn't provide any 1436 reliability which is a basic efford in other real-time researches. 1437 A common way for obtaining reliability is the resource reservation 1438 process ([5], [6], [7], [8]). Resource reservation is denied by 1439 the RTTP concept for some reasons: 1441 - it doesn't seem to be democratic; 1443 - it foresees the possibility of a "busi signal" when there is not 1444 enough bandwidth for the transfer; 1446 - if the transmitted data is structured by levels of importance 1447 (idea not present only in this memo, [9]) the bandwidth adjusts 1448 itself and it is always the optimum one. 1450 Resource reservation lies on conception that a user has the right 1451 to order and receive a specified Quality of Service (QoS). Yet, 1452 resource reservation doesn't guarantee connection, it only 1453 guarantees it will be good enough if established. Let's look at 1454 the commercial aspect of the problem. If a user is often not able 1455 to establish connection because his lines don't have enough 1456 capacities he will just change his ISP, or pay for a better 1457 connection. All users will be satisfied only if they will always 1458 obtain the services (at fixed QoS) they will have ordered. It is 1459 possible only if all network's lines have enough capacities. 1461 If the whole network consists of lines with big enough capacities, 1462 there is no need to reserve resources, is there? So, there is no 1463 need to develop complex protocols to take care of the transfer. 1464 The imaginary RTTP is very simple and it has another great 1465 advantage - it is self-adjusting. It adjusts the transfer without 1466 lots of data exchange, in fact without any data exchange. It can 1467 be disigned as fully compatible with IP ([2], [4]). 1469 The commercial aspect of the Internet must be treated as a very 1470 important one. Currently, World Wide Web users receive transfer by 1471 TCP/IP which has no touch with the principle for importance of 1472 time. Yet, most of the users always obtain transfer equal or very 1473 close to the maximum transfer their network equipment provides. It 1474 means that user requirements force the market called Internet to 1475 provide features that used protocols do not really guarantee. 1476 Implementing RTTP in Internet will lead to the same effect. No 1477 matter the protocol will not stick to the principle for importance 1478 of reliability it will be in most of the cases reliable, as users 1479 will add RTTP reliability as one of their requirements. 1481 If RTTP exists it will not be able always to asure quality real- 1482 time delivery but it will be able to asure all over delivery of 1483 real-time data. Any user, connected via modem to the Internet will 1484 be able to generate a low quality radio program, and if all other 1485 users among the network will want to listen to it, they will 1486 probably be able to do this. 1488 RTTP's best effords are simplicity and democracity. 1490 11. Plan for researches based on this document 1492 A primary mechanism for data division by levels of importance must 1493 be created. An exemplary list of these levels is defined by the 1494 following sequence: 1496 - low quality sound 1498 - low quality picture with few frames per second 1500 - increasing the number of frames per second 1502 - reaching the necessary number of frames per second at low 1503 quality 1505 - reaching a better resolution for the picture 1507 - reaching a better quality of sound 1509 - reaching the maximum sound quality 1511 - reaching a better resolution for the picture 1513 - stereo sound 1515 - reaching a better resolution for the picture 1517 and so on. 1519 Then a model specification of RTTP must be creatred together with 1520 the software that will support it. After a simple mechanism for 1521 data division and a primary RTTP is created they must be tested 1522 in a small network but with many variations of its structure and 1523 different capacities of its lines. The primary mechanism for data 1524 division by levels of importance doesn't need to be complex, so 1525 the testing network will probably have lines with capacities 1526 higher than ordinary Internet users obtain. 1528 Not until the network behaviour is examined RTTP must be 1529 specified. After a variant of a specified protocol is chosen it 1530 must be tested in a bigger than the previous network and if it 1531 proves its efficiency it may be proposed for implantation in the 1532 Internet. 1534 Then the effords must be directed at mechanisms for real-time data 1535 structuring, requiring less traffic than the primary one. 1537 12. Security Considerations 1539 Security issues are not discussed in this memo. 1541 13. References 1543 [1] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1544 "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, 1545 January 1996. 1547 [2] Information Sciences Institute, "Internet Protocol", RFC 791, 1548 September 1981. 1550 [3] Information Sciences Institute, "Transmission Control 1551 Protocol", RFC 793, September 1981. 1553 [4] Baccala, B., "Connected: An Internet Encyclopedia", 1554 http://freesoft.org/CIE/index.htm, April 1997. 1556 [5] Borden, M., Crawley, E., Davie, B., Batsell, S., "Integration 1557 of Real-time Services in an IP-ATM Network Architecture", 1558 RFC 1821, August 1995. 1560 [6] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Streaming 1561 Protocol (RTSP)", RFC 2326, April 1998. 1563 [7] Braden, R., Clark, D., Shenker, S., "Integrated Services in 1564 the Internet Architecture: an Overview", RFC 1633, June 1994. 1566 [8] ST2 Working Group, Delgrossi, L. & Berger, L. - Editors, 1567 "Internet Stream Protocol Version 2 (ST2) / Protocol Specification 1568 - Version ST2+", RFC 1819, August 1995. 1570 [9] Gentric et al., "RTP Payload Format for MPEG-4 Streams", work 1571 in progress, draft-gentric-avt-mpeg4-multisl-04.txt, May 2001. 1573 [10] Speakman, T., Farinacci, D., Lin, S., Tweedly, A., Bhaskar, 1574 N., Edmonstone, R., Sumanasekera, R., Vicisano, L., "PGM Reliable 1575 Transport Protocol Specification", work in progress, 1576 draft-speakman-pgm-spec-07.txt, September 2001. 1578 14. Author's Address 1580 Dimitar Aleksandrov 1581 Vladislavovo, 7-12-93 1582 9023 Varna BULGARIA 1583 Phone: +359 98 425788 1584 EMail: rttp@over-ground.net 1586 15. Full Copyright Statement 1588 Copyright (C) The Internet Society (2001). All Rights Reserved. 1590 This document and translations of it may be copied and furnished to 1591 others, and derivative works that comment on or otherwise explain it 1592 or assist in its implmentation may be prepared, copied, published and 1593 distributed, in whole or in part, without restriction of any kind, 1594 provided that the above copyright notice and this paragraph are 1595 included on all such copies and derivative works. However, this 1596 document itself may not be modified in any way, such as by removing 1597 the copyright notice or references to the Internet Society or other 1598 Internet organizations, except as needed for the purpose of 1599 developing Internet standards in which case the procedures for 1600 copyrights defined in the Internet Standards process must be 1601 followed, or as required to translate it into languages other than 1602 English. 1604 The limited permissions granted above are perpetual and will not be 1605 revoked by the Internet Society or its successors or assigns. 1607 This document and the information contained herein is provided on an 1608 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1609 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1610 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1611 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1612 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1614 This document expires June 19, 2002.