INTERNET-DRAFT D. Aleksandrov Expires March 2002 September 2001 RTTP: Properties of a real-time protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The purpose of this document is to provide ideas for real-time communications in Internet. This document doesn't expand any pre- defined standards or practices, it also doesn't conform ones. This document contains a separate idea for real-time data delivery. Aleksandrov [Page 1] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 Table of Contents 1. Introduction....................................................2 2. Definition of basic principles..................................3 3. "Streams" definition. Model of the Single Physical Line.........5 4. Structure of real-time data.....................................8 5. Fishbone model..................................................9 6. Real-time requests.............................................12 7. Local Broadcasters Model.......................................13 8. Mathematical evaluation of the created models..................17 9. Requirements for a real-time protocol based on the Local Broadcasters Model.............................................25 9a. Properties of an imaginary protocol..........................26 9b. General principles of the chosen model for real-time data transmission.................................................28 10. Comparison between the imaginary RTTP and other researches concerning real-time data transmissions.......................30 11. Plan for researches based on this document....................31 12. Security Considerations.......................................32 13. References....................................................32 14. Author's Address..............................................33 15. Full Copyright Statement......................................33 1. Introduction The purpose of this memo is to focus discussion on real-time data transmission in the Internet and give a possible method of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. "Real-time data transmission" means audio and visual information. The closest by analogy with radio broadcasting. The offered idea expects this imformation to be interpreted by a human. It is not suitable for real-time transmissions between machines only. This document doesn't only propose ideas but also descibes the way some of them have been reached. The memo's origin is the "Protocol for real-time transmission in a packet-switched computer network" work first published and still available in HTML at http://rttp.over-ground.net . The core idea of the document is described in sections 7 and 8. Aleksandrov [Page 2] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 Section 2 defines principles valid for analogue audio and video broadcasting. The conclusion is that they are much different than the principles Internet is constructed on. Sections 3, 4, 5 and 6 of this document develop ideas how to apply the principles of an ordinary tv and radio to a computer network. Section 9 compares the basic idea of the document with some existing ideas for real- time transmission. 2. Definition of basic principles Two principles concerning data transmission are defined here. They are used for comparison between TCP/IP transmission and radio broadcasting. The following definition of "broadcasting" is made here: transmission of data independently from the recipients. A broadcaster operates in the same way no matter the receivers. This definition is valid for the whole memo. Principle for importance of reliability û transmitted data must be received as full as possible, no matter the time it will be taken for. The reliability is more important than the time the transfer will take. Principle for importance of time û transmitted data must be received as synchronously as possible. The perfect way is to receive the data with the speed ot its transmission. If the whole data cannot be received synchronously some part of it may be eliminated but there must be no obstruction to receive the following actual data. According to these definitions IP follows neither one nor the other of the principles. The time to live each packet has can be assigned to the second principle but its purpose is to preserve the network from overloading. Basicly TCP/IP is constructed according to the first principle. The packed switching gives some level of reliability and the acknoledges TCP uses cause nearly every packet to reach its destination. If a radio or tv program must be transmittes we must refer to the second principle. It is more important to receive data synchronously than to receive it full. Broadcastings on air are constructed this way. The receiver is surely in touch with the transmitter, the transmitter is also a broadcaster, according to the definition. If the program is not received properly, for example if the antenna is too small, Aleksandrov [Page 3] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 usually there is enough data received for a human to understand what is broadcasted. This is a huge advantage of broadcastings on air. This advantage is due to the fact that the most importaint peices of data are in the surest zone of the information stream. The surest zone is the one in the center of the freqiency band width. Examples from FM radio and tv broadcastings will follow. In the center of the frequency bandwidth there are the lowest frequencies which are enogh for speech or melody understanding. If a human receives with its radio only these lowest frequencies he is not supposed to enjoy the program but he will understand what is it about. If the bandwidth that is received is expanded there will be a good quality of the music received. The stereo information is situated in the farest non-sure zone of the bandwidth. If the stereo information is received the quality gets better but there is a pretty good quality even without it. Color and B&W tv can be compared by analogy. The color information is a little piece of the whole one and is in the farest zone of the bandwidth. Because of its lower frequencies the sound of a tv program is most surely received. If some of the broadcasted data is lost the user will hear a distinguished sound and a picture with bad quality. If less data is lost there will be a brilliant picture but still B&W. In this case there is enough information a human can understand. Most of the information carriers are present, there is only an adition missing û the color. Three characteristics of real-time broadcastings on air have been defined: - guaranteed synchronous receiving; - preserving of information as much as possible even if not the whole data is received; - the broadcaster is independent from the count and state of the receivers. To transfer data with these characteristics in a computer network the real-time mechanism must include data multiplexing according to its levels of importance. Data must be devided into pieces with increasing and assigned Aleksandrov [Page 4] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 levels of importance. If the whole information cannot be transferred only the most important pieces should be. 3. "Streams" definition. Model of the Single Physical Line. A model of real-time communication between a client and a server will be constructed. They are parts of a packet-swithing network. In particular we may thing for the data as audio-visual one although this is not obligatory. In this model "client" is defined as a (process on) host requesting and receiving data. The "server" is a (process on) host which finally manipulates data before it is supplied to the client. This definition of "server" is not actually true in the common sense of the term but it will be used with its pre-defined meaning in the whole work. Model description. The client requests and receives data. The client is connected only with the server by a single line with defined maximal transfer rate. This kind of connection will be called "single physical line". The server is not a generator of the packets it sends to the client. It is just a host of an interconnected network. The real executor of client's request is another host among the network and will be called "broadcaster". At this point the mechanism for transmission of data between the broadcaster and the server is not a subject of interest. It is accepted to be true that the server is able to receive all of the data generated by the broadcaster in its primary sequence. The broadcaster generates every specified interval data with quantity k [B/s]. Let W [B/s] be the quantity of data which can be sent from the server to the client for the specified interval. Let W variates in the range [0; m], where m > k. It is accepted that the client requests only the data of the broadcaster. It doesn't mean there are no other packets transfered by the single physical line that connects it with the server. This can be one of the reasons for W variation. If W exceeds or equals k, evidently all of the data generated by the broadcaster will be received by the client. Aleksandrov [Page 5] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 If W < k the server must discharge some of the packets according to the principle for importance of time but according to the principle for importance of reliability the mustn't be chosen occasionally. The server must have a criteria which of the packets to be eliminated if they cannot all be transmitted. The broadcaster must structure its data according to some levels of importance. It is to do this as the server is not oblidged to interpret broadcaster's data. In this model the broadcaster generates n packets each unit of time. They are numbered from 1 to n independently for each unit and these numbers will be called "internal". Time intervals are numbered also form 1 to q and they form q so called ôstreamsö. Every packet holds its stream number - i and the sequent number inside the stream - j. On the whole, the broadcaster generates packets each having two indexes (i, j) in the following sequence: (1, 1), (1, 2)... (1, n), (2, 1), (2,2)...(2, n), (3, 1)... (q-1, n), (q, 1)...(q, n), (1, 1)..... In this model the information is first divided by time in units with equal length. For every time unit the data is structured according to its importance and the packets carrying the most important data are the packets with smallest internal numbers. The time to live for a packet (if there is one specified for the network) must not be greater than the time for turning through the whole stream numbers. This guarantees there will not be received two pakets with identical indexes (stream and internal number) without having idea which was first generated. The indexes implemented in all of the packets must be used by the server in case W < k. The purpose is to obtain real-time transmission so it is unacceptable just to queue the newcoming pieces of data. It is accepted for true that all of the packets that should be sent through the single physical line are stored in FIFO queue by the server. This is not enogh for real-time data transmissions so broadcester's packets should be treated differently. The sequence of streams is the sequence of their identifiers except for stream q followed by stream number 1. The server acts as following: Aleksandrov [Page 6] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 1) Every newcoming real-time packet with destination the client is added to the queue for the client if in it there is no untransmitted packet with the same or smaller internal number and smaller stream identifier. Every time a real-time packet is added all of the broadcaster's packets are sorted by ascending indexes. They are stored in so sorted order on places of the queue already reserved by broadcaster's packets. 2) When a new packet arrives to the server and in the queue for the client there is untransmitted one with the same or smaller internal number and smaller stream identifier all the packets belonging to previous steams are discharged. The packets remaining in the queue are stored on the nearest to the exit places of the queue already reserved by broadcaster's packets. These acts of the server asure: 1) The principle for importance of time. Discharging old packets guarantees that the client will always receive actual data. As a packet with same or bigger internal number from the next stream is received, the client's delay is bigger than one time unit of the broadcaster. 2) The principle for importance of reliability. The packets with smallest internal numbers are always stored on front positions into the queue. 3) Transmission equity. The real-time data doesn't bother the other. Each time real-time packets are sorted they are placed on already reserved by the real-time transfer places. These places are FIFO manipulated like non-real-time packets. Example: Let's have packets with numbers (2, 4); (2,5) and so on in an outgoing queue of a server. There is a delay in transfer to the client and they are not transmitted for a period of time. When (3, 1) packet arrives it will be stored at the end of the queue. After it (3, 2) and (3, 3) will be stored. If packet (2, 4) is still untransmitted and (3,4) arrives, evidently the client is behind time. In this case packet (3, 1) will be stored on the place (2, 4) used to take; (3, 2) will replace (2, 5) etc. The old data will be discharged and the new will take its place for the purpose of compensating as much as possible the delay. (end of the example) Aleksandrov [Page 7] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 The second term of transmission is according to the priciples for importance of time and reliability and also the queue operations are equitable. There is no danger to mix the arriving data. The basic problems are how information will be structured and transfered to the server. The model does not guarantee synchronous receiving of data. We are not sure all of the packets will be received in the sequence they are generated but when a client receives a packet with stream number different than the one of the previous it may be sure there will be no more data from the previuos stream. If a client stores the received packets in memory after the stream changes the data from the previous one may be interpreted. 4. Structure of real-time data An example of data multiplexing according to levels of importance is given here. No standard is specified in this point. The purpose is just to prove it is possible and combined with the real-time transfer mechanism sufficient result can be reached. An example of stereo sound multiplexing will be used, the frequency responce is 20~20000 Hz and the dynamic range is 96 dB. The example is based on the charactreristics of the sound recording on a compact disc (digital audio) which is recognized as a high quality standard. Generally, in this point a sample mechanism for structuring the data from a compact disc is needed. The first thing which can be done is to transform the stereo sound to mono. By making an average of each two corresponding samples from the two channels the mono channel is received. The received sound has enough information for sound understanding, it has lower quality than the original program but its data is half at size. If the mono channel is present together with one of the stereo channels, the other channel of the stereo sound can be reckoned. The whole size of the mono channel and one of the stereo ones is the same with the original size of the program. Even this elementary operation leads to two basic facts: 1) The data was divided, so a receiver able to receive only half of its size would interpret it correctly. 2) A recever of the complete information doesn't need to have bigger capacity than a receiver of the original program. The received mono signal can additionally be devided by frequency ranges. Aleksandrov [Page 8] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 Let a new channel called ôK1/5ö be created. K1/5 is made by calculating averages of each five sequent samples of the mono channel. The frequency responce of the new signal is 4 KHz, which is close to a phone call quality and enough for speech or melody understanding. The size of K1/5 is one fifth of the size of the primary mono sound. If any four of five samples from the mono channel are transmitted together with the respective K1/5 sample the all five samples of the mono signal can be received. Yet, a receiver having capacity 1/10 (it is 1/5 of the half) will be able to interpret some data. On the other hand the whole program, structured as K1/5 samples fist, followed by the complementary blocks of four samples from the mono channel, and then followed by one of the stereo channels has the size of the original program. A working example for data structured by levels of importance must lie on channels with cascading expanding of frequency responce and dynamic range. This memo doesn't take up with offering such mechanism. This example was just for a provement it is possible to multiplex data this way. In the example compression is not foreseen but it can greatly reduce the data size. Surely there can be numberless algorithms for data structuring and if there is a working real-time mechanism for data delivery they will be undoubtlessly invented. 5. Fishbone model At this point a model with many single physical lines will be considered. The Single Physical Line model was created with the purpose to find a mechanism for data structuring. Dividing the broadcaster from the server was not necessary. It was made because this model had to be easily extended. As first extension of the model more than one client is added. All of the clients are connected by their own singe lines to one and the same server. All of the clients request one and the same broadcaster's program. ("Broadacster's program" is the real-time data generated by the broadcaster. The analogy is a "tv program" or "radio program".) The server has different outgoing queues for all of the clients. In every queue the real-time packets are handled together with non-real-time packets, according to the principles for a single physical line defined in section 3 of the document. Evidently the server must operate with each queue individually. On the other hand there will be many coinciding packets in the outgoing queues. This is disadvantageous to send each client's request to the broadacster as all of the data is sent through the server. Aleksandrov [Page 9] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 The Single Physical Line model doesn't discuss the request operation. When there are more than one clients the request method is important. There are two cases: 1) Every client sends its own request to the broadacster and the broadacster receives it. The broadacster sends packets with destination the client-requester. The server manipulates the real- time packets transmitted through it according to the rules for a Single Physical Line. 2) The server sends a request to the broadcaster. After a real- time packet from the broadcaster is received it is multiplied and stored in the queue for each client that requested the data. Each queue is manipulated according to the rules for a single physical line. The second variant is more advantageous. The network traffic is diminished but it doesn't affect the quantity of data each client receives. The data for all of the clients is transmitted through the server so there is no need to do it as many times as the clients are. The behaviour of each host of the network must be defined. It is defined that the server is engaged with the transfer. The server holds the balance between the principles for importance of time and importance of reliability. The single request for more than a client is close to the principle for independence of the broadcaster from the receivers and close to transmissions on air. This scheme works for clients connected by single physical lines but the purpose is to build a working scheme for the whole network. It is possible a client to be connected than more than a line to more than a host of the network. If there is real-time data transmission there are three ways each host can act: 1) Lack of commitment: The server is the only host of the network dividing the real-time packets form the other. The other hosts route each real-time packet like any other. This scheme contradicts the principle for importance of time. The network can be engorged with data. These are enogh reasons to treat this variant as unacceptable. 2) Partial commitment: Every host recognizes the real-time packets. Every packet is Aleksandrov [Page 10] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 routed like any other but real-time ones are manipulated according to the principles of a single line in the outgoing queues. 3) Complete commitment (Fishbone model): Every host commits with the real-time requests it is to transfer. Every host modifies the requests and transfers them with its address as receiver. When the host receives real-time data it sends it to each of the hosts that requested it. Evidently the server from the previous model is completely commited with the transfer. If all hosts act this way any request's destination will be cascadingly modified. There will be constructed a transfer route through the network. When a request from another part of the network is sent it will either be performed by another route or will cause an existing transfer route to branch out into another direction. If the broadcaster is connected by d lines with d hosts of the network the maximum number of requests it will receive will always be d, and each will be executed by a different route through the network. The complete tree of routes through the network if there are many clients remains a fishbone which gives the model name. The Fishbone model is near the principles for broadcaster's independance from the receivers, it observes the importance of time but has disadvantages about reliability. It is based on a fixed route through the network and every host can become a weak point of the structure. Data losses between two hosts become current for all of the hosts relying on them. A big problem appears when a host taking part in the transfer route drops out. If every request is resend after a period of time the transmission will be recovered by another route but after a period of silence. On the other hand if a host is physically the only one able to serve multiple request ("server - client", according to the single line model) the Fishbone model seen to be the optimum one. A network with lack of commitment of the hosts was categorically rejected so a medial variant between partial and complete commitment is needed. The scheme for real-tme transfer must be applicable for a packet- switching network and what is the most important - all hosts of this network must follow same principles with others. In the Aleksandrov [Page 11] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 models yet described there were parts of the network (for example the server in the Single Physical Line model) acting differently than the others. If different hosts of a network are able to act differently it must be only as a result of apllying same principles in different situations. It is assumed that all hosts must observe the following basic rules for real-time transfer: 1) every host distinguishes real-time packets from the others; 2) in every outgoing queue the real-time packets of any broadcasted program are manipulated according to the principles for a Single Physical Line. 6. Real-time requests In the models already constructed requests are not discussed. These models accept there is a request and pay attention to data transfer as a result. A specified requesting mechanism is evidenly needed. The broadacster must receive at least one request for data to start transferring. The request can be sent by a real-time or non-real-time packet. The client won't need broadcaster's transfer ethernally so it better renew its request after a period of time. On the other hand the client mustn't be deprived of transfer if its renovating request is transferred too slow, therefore the broadcaster must generate data for a longer period than the one for request renovation. Let Tz be the time interval after which the client will resend its request. The client will send its request and the broadcaster will receive it (no matter with or without modified client's address) after time represented by Tp. Let the broadcaster stop the transfer if a request is not re-confirmed in Ts time. In this case it is necessary to be true that: Ts = Tz * k + Óp, as k is a coefficient and k > 1. (1) The reason for this is the assumption that the client will start counting out Tz imediately after the request is sent. The requesting packet will reach the broadcaster in time Tp, and if there's no a big change in network state the next (renewed) request will reach the broadcaster in time Tz + Tp. The coefficient k guarantees there will be no stop of transfer before the next request reaches the broadcaster. This coefficient should be big enough to cope with this task. If there is a mechanism for counting Tp, the broadcaster will be able to set different Ts for each request, even if k = const. It is necessary the time interval Aleksandrov [Page 12] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 for each client (Ts) to be reset by the broadcaster each time a request is renovated. The mechanism of mutual time intervals guarantees there will be no constant high intensive request traffic in the network, also the presence of transfer for a while even if there is no request reconfirmation saves the network from unnecessary traffic in cases a client refuses the program. Evidently the time interval and the coefficient k must be carefully selected. It is natural the time interval Ts to contain the time for turning out some series of data streams. If it elapses for the time of one data stream the requests will be too frequent. In equality (1) the most significant member should be Tz, i.e. Tz >> Tp, otherwise the variation of Tp will strongly affect the implementation of the term and a big enough value for k will be needed to prevent from transfer interrupting. According to the client the real-time data will stop Tp + k * Tz + TpÆ time after its last request, TpÆ is the time for the last broadcaster's packet with destination the client to reach it. If the network has respectively constant parameters it is probably true that Tp approximately equals TpÆ. As Tz >> Tp it is a good idea to provide a refusing request (refusal) which can be sent by the client if it no more needs broadcaster's transfer. It will preserve the network from a little unnecessary traffic. If a refusal is not sent, for example is the client just drops down, the traffic will be ceased too, but a little bit later. 7. Local Broadcasters Model Request renovation applyed to the Fishbone model is able to minimish its disadvantages. Fishbone model presumes each host is to modify the request. The request will be sent by the most optimum route through the network, so the transfer will be sent by the same optimum route. When the request is renewed if the developed route is no more the most optimum another transfer path will be created. This solves the problem with dropping out a host of the network but doesn't solve the problem with the weak point each host can be. The next development of the Fishbone model appears after a detailed study of a host signified as "server" in the Single Aleksandrov [Page 13] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 Physical Line model. This host is always completely committed with the transfer. Real- time packets are always treated the same way no matter if it is the requester (according to the broadcaster) or a single client is. Committment of this host must be examined in details. The first client's request reaches it and according to the Fishbone model this host should replace requester's address with its own. On the other hand there is no need to do this. The transfer between the server and the client will always follow one and the same scheme no matter which of them is the requester. According to the principle for network sameness (all hosts must follow same principles) if this host modifies the request all others must do this - it is the Fishbone model itself. To change the model it is accepted the host doesn't modify requester's address but just transmits the request-packet with its original contents. As there is network sameness all other hosts have to do this so the broadcaster receives a request for data with destination the client. After a time the server receives another client's request for the program which data is already transmitted through it. If the server just transmits this request again it will bother the principle for mimimum transfer through the network. Evidently in this moment (or a little bit later) the server is to commit with the transfer, send its own request and then resend the real-time data to both his clients. The conclusion is that the server must remember all real-time requests transmitted through it and still active (with unelapsed time) and if another request for already ordered program appears, the server must send it as its own. The basic criterion is the number of still active requests passed through each host. Let's have a detailed look at server's behaviour. By the time of the second request the first one is still active, so if the server immediately sends its request there will be a period of time with double identical data transfer. It bothers the principles for mimimum traffic and for broadcaster's independance. The second request is sent later than the first, so according to the subjection Tz >> Tp the second one will expire later. On the other hand the server can immediately comply with the real-time transfer just by copying and sending the packets with destination the first requester to the second one too. If the server is in charge of the minimum transfer there are two variants: 1) the server waits for the first request to expire and modifies its renovation with its own address; Aleksandrov [Page 14] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 2) the server sends its own request immediately and a refusal on behalf of the first client together with it. Both variants are acceptable. If the first client doesn't renew its request the first variant seems to be better. Without renovation the server will pass second client's request without any modification but after the first client's request is elapsed. If the second variant is chosen in the above situation there will be for a short period of time: server's REQUEST -> first client's REFUSAL -> second client's REQUEST -> server's REFUSAL, and as the second client's request was delayed there will soon be its next one. The basic principle of this model is the following: The server passes each request for a real-time program if there is no active request that passes through it for the same program. The server stops every request for a real-time program if there is at least one active request that passes through it for the same program. When the server stops client's request it send one for the same program with its own address as destination and takes up with multiplying the real-time data to all clients having active requests for this program. As the server acts this way any other host of the network should act this way too. A disadvantage - if a client's request is stopped it will start receiving the data which the server multiplies for the client. Anyway, it is possible that not the whole traffic for the previous client passes through the server, so the next one will not receive complete data but a partial one. It will be true until the previous client's request expires. After that the server will send the request and becoming a receiver of the whole data will act equally towards both clients. The idea of the model is in constructing local broadcasters in network areas with enhanced interest in one and the same program. The model will be called "Local Broadcasters model" or just LBC model in future. There are no additional rules for packet routing except these for a Single Physical Line in the outgoing queues. As requests are renovated the local broadcasters will dynamically appear and die out. Each host can become a local broadcaster of a program for a time. Each host must also recognize not only the Aleksandrov [Page 15] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 packets containing real-time data but also the ones containing requests for such data. Another aspect of LBC is that a refusal can reach not the local broadcaster but the real broadcaster which doesn't have idea about this client at all. Therefore a notification is necessary so each client should know whether it is served by the real or a local broadcaster. If a client was notified it should send a refusal to the local broadcaster. Behaviours of the different components of a network, according to the LBC model must be explained: 1) Client. According to the client all Single physical line model, Fishbone model and LBC model are equal. Local broadcaster's notifications are a small and unessential difference between LBC and the other two models. 2) Host (which is not a client). Compared with the case in which each host is partially committed with the transfer there is an additional work-load as each host must listen for real-time requests. When a host becomes a local broadcaster it is completely committed with the transfer and still has to listen for other real-time requests. 3) Broadcaster. The maximum number of requests a broadcaster can receive equals the number of physical lines it is coonected to the network by. Each line is a beginning of a branch of lines and if more than a request is generated in any branch a local broadcaster will be created. The broadcaster is free to choose a route for each real-time packet. It is loaded like a completely commited with the transfer host. 4) Entire network. Network behavior can't be indicated without mathematical appliance. LBC seems to be better than the Fishbone model for there is no compulsory data route which can save the transfer from some losses of data. The whole data can be divided and transfered by lots of low-capacity lines which is not possible according to the Fishbone model. On the other hand there is a possibility of double traffic by one and the same line between two hosts. If host Á is a local broadcaster for host à all real-time data will have host A as distination. It is possible some of this data to pass through host B, reach A, and then be sent again to host B by host A. There will be equal transfer in both directions, one more outgoing queue with a possibility of data loss. Yet, this transfer will bother neither the broadcaster, nor the other hosts of the network. Local Broadcaters Model is the core of this memo. The other ones Aleksandrov [Page 16] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 are constructed just for the purpose of reaching the idea of LBC easier. The author believes that a protocol based on LBC model can be sufficient for real-time data transmisions in Internet. 8. Mathematical evaluation of the created models The created models for real-time data transmission need some mathematical evaluation. It is given at this point. The first interesting index is the loading of network. The network load should be measured as the quantity of traffic transfered for a period of time, in particular B/s. The network load is a combination of all hosts' loads. There are three types of hosts while real-time data transmission. These are broadcaster, server and client. These designations are not really precise in their common meanings but they will be still used in the future in their redefined meanings. At first broadcaster's load is to be discussed. Each time unit the broadcaster generates a real-time program which data's amount is t [B/s]. For our convenience it is accepted that the data has an even distribution in time, i.e. t=const for any time unit. Let T [B/s] is the complete amount of data that the broadcaster sends to the network for a defined unit of time. 1) If hosts are partially commited with the transfer: T = l1 * t + l2 * t + ... + lk * t = t * sum(l1; lk), where li is the completeness of the transfer allocated for i-th receiver (0 =< li =< 1), according to the broadcaster; k - number of clients for the examined unit of time. According to this model the broadcaster sends data concretely for each client, so there are k addends, it is possible some data to be lost in broadcaster's outgoing queues so coefficient for completeness are added. Fictionally every li = 1. 2) Fishbone model: T = n1 * t + n2 * t + ... + nm * t = t * sum(n1; nm), where m is the number of broadcaster's physical lines used for real-time traffic; ni is the completeness of the transfer by the Aleksandrov [Page 17] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 i-th line (0 =< ni =< 1), according to the broadacster. The Fishbone model permits only one real-time request by line, so the maximum value for m is the value of the physical lines that connect the broadcaster to the network. It is possible some data to be lost in the outgoing queues for the differenet lines, so coefficients ni for completeness are added. Fictionally every ni = 1. 3) Local Broadcasters Model: T = p1 * t + p2 * t + ... + pq * t = t * sum(p1; pq), where q is the number of received requests; pi is the completeness of the transfer allocated for i-th request, according to the broadcaster. Only one request can reach the broadcaster by line, as any multiple requests will be stopped by local broadcasters, so the maximum value for q is the value of the physical lines that connect the broadcaster to the network. It is possible some data to be lost in the outgoing queues, so coefficients pi for completeness are added. Fictionally every pi = 1. The three formulas look rather alike, evidently with main inportance are the sums they contain. On the other hand it mustn't be expected the index T to rise unlimited. The broadcaster has limited number of connections to the network and each connection has its maximum capacity. Let c be the number of broadcaster's connections, and let the i-th has ri [B/s] as a capacity for real-time transfer, 1 =< i =< c. Broadcaster's physical lines are numbered fictitiously but their numbers, once assigned, should be unchanged for the formulas. Let R [B/s] be the maximum data that the network can accept from the broadcaster. In this case R = r1 + r2 + ... + rc = sum(r1; rc). Evidently T =< R, so there are the following inequalities for the three models: 1) sum(l1; lk) =< R/t for partial transfer commitment; Aleksandrov [Page 18] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 2) sum(n1; nm) =< R/t for Fishbone; 3) sum(p1; pq) =< R/t for LBC. Both R = const, and t = const, so two facts are subjects of interest: - Conditions making each inequality to an equation; - The average value for the indexes of each sum whenever the expression it takes part in is an equation. According to the principle for smallest traffic, the optimum inequality is the one which's left side is the smallest, compared with the other two, when the number of clients is one and the same for the three expressions, because the whole data transferred by the broadcaster is the product of each left part and t. According to the principle for reliability, the optimum inequality is the one in which the average value of all indexes the left side consists of is the biggest, compared with the other two inequalities, when the number of clients is one and the same for the three expressions, because the left parts are all sums of coefficients giving completenesses of transfer. As bigger the average completeness is, as better the program will be received. In both cases the least sum of bigger members is needed, so evidently the most optimum sum is the one with fewest members. The first formula is the only containing the number of clients. There is a need of mechanism for counting the number of clients in the formulas for Fishbone and LBC models. For ease, the following addmission is made: The broadcaster takes a central zone of the network, which means there are approximately equal numbers of hosts most shortly addressed by each line. This is not a precised addmission but if it is true there are equal possibilities a request to reach the broadcster by any line. It will most load the broadcaster. If the network is not balanced in relation to the broadcaster, most of the requests will be served by some of the lines, which will be far of the borderline case (maximum load) that we are looking for. That's the reason the addmission mustn't be treated as a negative one. If there is at least one client a transfer route will be created, so T = n1 * t. If the second request reaches the broadcaster by another line the Aleksandrov [Page 19] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 whole transfer will be T = t(n1 + n2). The value of T will grow until it reaches T = t * sum(n1; nm), realized for every i =< m, and then will stay constant for every i > m. Fictionally every ri >= t, i.e. R >= mt, so the biggest possible transfer is T = mt. This was the sutuation according to the Fishbone model. The LBC model is largely the same. The value of T will grow until it reaches T = t * sum(p1; pq), realized for every q =< m, and then will stay constant for every q > m. Fictionally T = mt. For the model of hosts with partial commitment the fictional value of T is T = tk, and there is no limitation for the increase of k. This is a linear function which is practically impossible as the value of R can't be unlimited. That's the reason this model will no more be evaluated. It is to be rejected as unefficient. The more clients are, the average data each receives is less. At the other two models the growth of transfered data stops no matter how many the clients are, and if R >= mt it is possible that no data is lost in broadcaster's outgoing queues. The Fishbone model foresees each request is served by its own physical line, so the potential loss of data for the request depends entirely on this line. The completeness of transfer by the i-th line is describes with the following function ni = F(ri): ni = ri/t, realized for ri =< t; ni = 1, realized for ri > t, t = const. This dependence not only describes the completeness of transfer for the i-th request according to the Fishbone model, but generally the completeness of real-time transfer by the i-th line. If there are two or more requests served by a line the completeness of the data for each request will be ri/s * t, as s is the number of requests served by the line. The completeness of transfer is the ratio of the possible transfer and the desired by the host one, generally ri/Ri, as Ri [B/s] is the desired transfer (the one which if fully transmitted will lead to no loss). At the Fishbone model Ri = t realized for every i. The LBC model doesn't keep within this condition. At LBC Ri is different than a constant, and wholly depends on network's condition. Aleksandrov [Page 20] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 Basicly, the data predestinated for the j-the request is to be divided in c parts, because c are the physical lines of the broadcaster. Each line will take gji part of the transfer which will be gji * t [B/s]. The following conditions are realized: 0 < j =< c; 0 < i =< c; 0 =< gji =< 1, realized for every i, j; gj1 + gj2 + gj3 + .... + gjc = 1, realized for every j. Each unit of time the desired transfer destinated to a host is: Ri = t(g1i + g2i + ... + gci), and Ri is the quantity of data which if sent through the i-th host will be sent with no loss. Fictionally Ri =< ri. The completeness of transfer through the i-th host - G, by analogy is the ratio of these two quantities: Gi = Ri / ri = t(g1i + g2i + ... + gci) / ri, realized for Ri =< ri; Gi = 1, realized for Ri > ri. In difference to F, G can't be defined as a function of one single index. The coefficients showing the division of data among the hosts can be structured in a square matrix: g11 g12 g13 ...... g1c g21 g22 g23 ...... g2c .......................................... gc1 gc2 gc3 ...... gcc It is true that each line's sum equals 1. By multiplying the matrix by t it looks like: g11t g12t g13t ...... g1ct g21t g22t g23t ...... g2ct .............................................. gc1t gc2t gc3t ...... gcct It is true that each line's sum equals 1 t. This is not totally true, as is the statement for 1 lines' sums. Some of the lines can equal 0 as there can be no request by every line. In the borderline case of maximum load the statement is true for each Aleksandrov [Page 21] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 matrix' line. The received matrix can be multiplied by the one representing the completeness of transfer: G1 G2 G3 . . . Gc The result looks as following: g11G1 + g12G2 +......+ g1nGn g21G1 + g22G2 +......+ g2nGn . . . . gn1G1 + gn2G2 +......+ gnnGn By analogy the Fishbone model can be presented by the following matrixes: 1 0 0 0 ... 0 0 F1 F1 0 1 0 0 ... 0 0 F2 F2 0 0 1 0 ... 0 0 F3 F3 0 0 0 1 ... 0 0 * F4 = F4 ............... . . 0 0 0 0 ... 1 0 Fn-1 Fn-1 0 0 0 0 ... 0 1 Fn Fn In both cases the completeness of transfer for each request is expressed in one and the same way. But both formulas are still unrelated so the models can't be compared according to them. These formulas are convenient for simulating programs and statistical evaluation. Another limitation must be introduced here, after the one for centered broadcaster. In LBC model it is assumed that the broadcaster acts intelligently in some measure. The intelligent aspect of broadcaster's behaviour includes distribution of data according to the network load. Generally must be true the following: Aleksandrov [Page 22] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 Ri / Rj = ri / rj, realized for 0 < j =< c; 0 < i =< c. We are not interested in the concrete traffic distribution for each request but we know it is according to lines load. If the broadcaster doesn't behave this way the whole model is unefficient. Evidently the last equality can't be entirely true in all cases but it must be approximately true. Anyway, if R >= ct, the loss for each request's data must lean towards 0 for the nearest to the broadcaster zone of the network. This must be true no matter which the physical lines are - the great advantage of the LBC model compared with the Fishbone. As the maxumum possible transfer for both models is one and the same this advantage makes the LBC model the preferable one. After a broadcaster's behaviour was examined the one of the hosts and the clients must be examined too. Any client is a host of the network but for ease "host" will be used only for ones that transfer real-time data but are no clients. The transfer route through the network is always unknown and there are numberless possibilities so it is impossible all variants of host behaviour to be embraced. Only conclusions based on statistics and probability can be made. Yet, there are two possible cases for a client's role in the network: - final host, connected by a single physical line to another host of the network; - intermadiate host, connected by multiple lines to the network. Other than the requested real-time data can be transmitted through this kind of client. On the other hand if the client is an intermediate host a virtual final one can be added, so the host of the client will be examined just like any other. The capacity of the line between the real and the virtual hosts can be treated as unlimited and with no time delay. Evidently the quantity and quality of the data received by the virtual host depends entirely on the network. Virtual hosts can be added in any situation so client examination is not needed at all. Enough information can be obtained just by threshing out the hosts which transfer the data. Aleksandrov [Page 23] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 This is the reason client's examination to be abandoned. Only formulas describing the data transfer as a result of its transmission through the network are needed. According to the Fishbone model the transfer is realized by k constant hosts (k > 0). The transfer route repeats the route of the request through the network. Relying on hosts' inteligence it can be expected the request to be sent by the freeest lines, so the created transfer route will be the one with lowest loss compared with the other variants for possible transfer paths. Anyway, the request is small enough to be directed on a route with capacity smaller than the real-time data needs. As there are k hosts forming the route the data is sent by k+1 physical lines, and each has its own completeness of real-time transfer F - the same as broadcaster's lines have. This function will be called ôtransmissionö for ease. Let F(1) be the transmission of the first line of the data route - the one connected to the broadcaster, F(2) be the transmission of the next line data will flow through and so on, up to F(k+1). The transmission of the whole system is presented by the mimimum value found among these functions. Let P(x) be the probability a physical line to be able to transfer at least x [B/s]. (x >= 0) The probability to be no loss at the first line is P(1)(t). (We stick to the denotion that t [B/s] is the whole quantity of data generated by the broadcster for a unit of time.) The probability to be no loss at the second line is P(2)(t), etc. The complete probability to be no loss after the data was sent by k+1 lines is P = P(1)(t) * P(2)(t)....P(k+1)(t). If the network is a regular one, i.e. there is same probability for each line, then P equals P (t) multiplied k+1 times by itself. In both cases the far form the broadcster the client is, the lowest probability for comlete transfer is, too. Figuratively, the signal "dies away" in the network. The presentation for LBC model is more complex. The data is transfered by s physical lines, but the transfer by each line can be ti, realized for every ti =< t. Aleksandrov [Page 24] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 There must be no loss by any line, so the complete probaility to be no loss is P = P(1)(t1) * P(2)(t2) * P(3)(t3).........P(s)(ts). If the network is a regular one it is P = P(t1) * P(t2)....P(ts). For better descriptions of the received formulas the variation of P(x) must be examined. P(0) = 1 for sure, as data with zero size can be sent even by unexisting line. As the material world has its limitations there exists j with a limited value, and every P(x) = 0, realized for x >= j. On the other hand surely P(x) >= P(x + dx), realized for dx > 0. P(x) beginning point is (0,1) and never growing the function reaches the point (j, 0). As closer to the upward end of the shown zone P(x) is, better the real-time transfer is. Generally, the formula describing the LBC model will consists of more but smaller members, than the formula describing the Fishbone model. Both models must be compared according to P(x). The signal "dies away" according to the LBC model, too. The question is, is it more expressed at the LBC model than at the Fishbone? Author's opinion is that the answer is "No". The reason for this is that P(x) will probably keep its value of 1 for values of x close to the zero point. As P(x) variation may only be proved in practice and it will be much different for the different lines of a network, a final conclusion is not given here. 9. Requirements for a real-time protocol based on the Local Broadcasters Model Overview of probable real-time data transmission in the Internet is made in this point. No standard is specified here. Properties of an imaginary protocol realizing data broadcasting are discussed. This non-existing imaginary protocol is called Real- time transfer protocol (RTTP) and doesn't conform to the specified in RFC 1889 Real-time transport protocol abbreviated as "RTP" [1]. The "RTTP" abbreviation and protocol's name are used just for ease, for example ôRTTP packetö means ôa packet containing real- Aleksandrov [Page 25] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 time data. 9a. Properties of an imaginary protocol RTTP is based on LBC model. Some RTTP principles may be defined: 1) every host of the network can become a local broadcaster of any program; 2) every host of the network must recognize and check out any RTTP packet which passes through it. The first conclusion based on these principles is that the whole network must support RTTP. The easiest way for introducing a new protocol is basing it on TCP/IP [2], [3], [4]. If RTTP is based on TCP/IP it is executable in Internet. On the other hand it is impossible to apply a new protocol to the whole Internet shortly, so mechanisms for compatibility between RTTP and non-RTTP hosts must be foreseen. It must be marked off there's an essential difference between TCP and RTTP (based on LBC) conceptions. The whole network is engaged with the broadcasting in the meaning of ôit changes according to itö, so RTTP encroaches upon IP. TCP envolves the communicating hosts and they exchange data but the other hosts take part only as IP routers. Yet, there are two assumptions that seem to be valid: 1) the broadcaster supports RTTP; 2) the requester (client) supports RTTP, otherwise it will not be able to interpret the received data. The real-time transfer doesn't need some TCP functions like the acknoledge and the window size. If there exists RTTP, it will be based on, or even parallel to IP, not based on TCP, i.e. there will exist the independent subjections: IP -> TCP, which can be IP/RTTP -> TCP; IP -> RTTP, and the subjection IP -> TCP -> RTTP will be no valid. ô->ö marks the protocol layering. RTTP abandones some of the ideas of TCP because of some real-time priorities - importance of time and broadcaster's independence. In this case the acknoledge is not desired. The temporary cease of transfer that happens in TCP when zero window size is reported is also unnecessary. Applying the principle of a sigle physical line for the outgoing queues Aleksandrov [Page 26] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 automatically stops or decreases the transfer when the network is loaded. The conclusion is that RTTP can hardly be based on the existing TCP protocol. If the future proves that an RTTP will work satisfactory the only variant for its network implantation is complete compatibility between IP and IP/RTTP hosts. The things RTTP needs and IP doesn't include are pointed here: The first is a port (identifier) of the broadcasted program. The broadcaster has an IP address but probably it generates more than one program. On the other hand there can be multiple clients on one IP, so client's port is needed, too. Every packet must contain stream identifier and internal number. It is assumed packets are small enough and their fragmentation is not needed. This data can easily be stored in the data field of an IP packet, so there are no problems about it. But a mechanism for recognition of RTTP packets is needed. On the other hands there are three types of packets, if RTTP exists: 1) non real-time (ordinary) IP packet; 2) a real-time packet. There are two kinds of RTTP packets: - containig broadcasted data; - containig request, refusals or other official information. In every IP header there is a reserved for future use bit, there is an option class which is reserved, too, yet there are 152 unassigned values for the "protocol" field, so there are enough possibilities for marking an IP packet as an RTTP one. RTTP packets must only be marked and all other necessary information can be stored in their data fields. As real-time transfer can be carried out by IP packets the problem with host compatibility is solved. There appears the problem with the network behaviour. IP hosts (host will be marked as IP and RTTP) will not manipulate their outgoing queues according to real-time requirements. RTTP packets will not be rejected earlier than their TTL is elapsed. It Aleksandrov [Page 27] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 will not reject the belated traffic and as there is some belated traffic the broadcaster generates more data than the network can handle. Also, the program will not be received satisfactory by the client. It was stated above that the broadcaster is an RTTP host. As the network loads its outgoing capacity will fall down. The broadcaster will destroy more and more packets in its outgoing queues so the traffic it generates will also fall down. A balance will be reached, some IP zones will be much loaded, the clients divided by IP zones from the broadcaster will receive its program poorly, but the network will not be blocked up. These problems will be rarer if there are more RTTP hosts. In a mixed network (IP & RTTP hosts) more difficulties the popular programs will experience. IP hosts will not engage as local broadcasters, so the broadcaster or the local ones will receive more requests than their physical lines are and there will be great losses even at their outgoing queues. The statement that a mixed network will load but not block up sounds true but must be checked out statistically or by a simulating model. Neither statistics, nor a simulating model is offered here. If a private program (produced for just a single client) in an RTTP network must be realized the easiest way is to modify its request method. In case the client sends its request to the broadacaster by non-real-time packet, another request sent to the same broadcaster will not be recognized by the hosts on its road, there will be no local broadcasters and no possibility for data confusion. The RTTP packets of the private program will be manipulated as RTTP ones on their road but only the host of the client is going to receive them. 9b. General principles of the chosen model for real-time data transmission 1) Data format: - the real-time data is transfered through a packet-switching network. Each packet is routed separately; - every host of the network recognizes the real-time packets; - the broadcasted data is devided in time units with equal durations. The data for each unit of time is structured as a numbered stream, the packets inside each stream obtain sequent internal numbers. The packets carrying the most important information are the ones with smallest internal numbers; Aleksandrov [Page 28] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 - every real-time packet carrying data contains stream and internal numbers, and the address of the broadcaster. 2) Requests: - a request for a public broadcasted program is made by a real- time packet sent to the broadcaster; - every request is repeated after a specified time interval if the requester still wants to receive the program; - every host includes all requests routed by it in its table of active requests; - a request for a program not present in host's table of active requests is transmitted further through the network; - every program is erased from host's table of active requests if it is not renovated, according to the host, after the specified time interval; - a request for a program present in host's table of active requests is stopped by the host. It starts to multiply the packets of the program and send them to the new requester, too. After the time interval of the old requester elapses and if its request is renovated the host stops the renewed request and sends its own to the broadcster with its address as destination for the real-time data. The host notifies all clients for the program that it is their local broadcaster. It means that every host must count time intervals for all request in its table of active ones separately. As multiple requests are cascadingly stopped by hosts becoming local broadcasters, the maximum records for a program in a table of active requests equals the number of physical lines of the host that holds up the table; - a refusal exists. A refusal is made by a real-time packet sent to the local broadcaster or the primary broadcaster if there is no a local one; - a receive of refusal leads to erasing the client from all the tables of actice requests on the road of the refusal; - a request for private program is send by non-real-time packet to the broadcster. 3) Real-time data transmission: - every real-time packet is stored by a routing host in one of its Aleksandrov [Page 29] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 outgoing queues according to same mechanism with non-real-time packets; - every newcoming real-time packet with destination the client is added to the queue for the client if in it there is no untransmitted packet with the same or smaller internal number and smaller stream identifier. Every time a real-time packet is added all of the broadcaster's packets are sorted by ascending indexes. They are stored in so sorted order on places of the queue already reserved by broadcaster's packets; - when a new packet arrives to the server and in the queue for the client there is untransmitted one with the same or smaller internal number and smaller stream identifier all the packets belonging to previous steams are discharged. The packets remaining in the queue are stored on the nearest to the exit places of the queue already reserved by broadcaster's packets. 10. Comparison between the imaginary RTTP and other researches concerning real-time data transmissions There are lots of works dedicated to real-time transfer. There are standartized protocols and practices. By the time researches concerning this item are too advanced this memo describes just basic ideas. That's because RTTP ideas are in a little different direction than the developed ones. This section compares RTTP with existing protocols and practices for real-time data transmission. This section doesn't pretend to be comprehensive, its main point is to focus discussion on the need of resource reservation. This section's references are [6 - 10]. As most of the works dedicated to real-time transfer concern video and audio conferences, RTTP points mainly on broadcasting. "Broadcasting" according to its definition in section 2 of this document. Pointing on broadcasting RTTP doesn't provide any reliability which is a basic efford in other real-time researches. A common way for obtaining reliability is the resource reservation process ([5], [6], [7], [8]). Resource reservation is denied by the RTTP concept for some reasons: - it doesn't seem to be democratic; - it foresees the possibility of a "busi signal" when there is not enough bandwidth for the transfer; - if the transmitted data is structured by levels of importance Aleksandrov [Page 30] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 (idea not present only in this memo, [9]) the bandwidth adjusts itself and it is always the optimum one. Resource reservation lies on conception that a user has the right to order and receive a specified Quality of Service (QoS). Yet, resource reservation doesn't guarantee connection, it only guarantees it will be good enough if established. Let's look at the commercial aspect of the problem. If a user is often not able to establish connection because his lines don't have enough capacities he will just change his ISP, or pay for a better connection. All users will be satisfied only if they will always obtain the services (at fixed QoS) they will have ordered. It is possible only if all network's lines have enough capacities. If the whole network consists of lines with big enough capacities, there is no need to reserve resources, is there? So, there is no need to develop complex protocols to take care of the transfer. The imaginary RTTP is very simple and it has another great advantage - it is self-adjusting. It adjusts the transfer without lots of data exchange, in fact without any data exchange. It can be disigned as fully compatible with IP ([2], [4]). If RTTP exists it will not be able always to asure quality real- time delivery but it will be able to asure all over delivery of real-time data. Any user, connected via modem to the Internet will be able to generate a low quality radio program, and if all other users among the network will want to listen to it, they will probably be able to do this. RTTP's best effords are simplicity and democracity. 11. Plan for researches based on this document A primary mechanism for data division by levels of importance must be created. An exemplary list of these levels is defined by the following sequence: - low quality sound - low quality picture with few frames per second - increasing the number of frames per second - reaching the necessary number of frames per second at low quality - reaching a better resolution for the picture Aleksandrov [Page 31] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 - reaching a better quality of sound - reaching the maximum sound quality - reaching a better resolution for the picture - stereo sound - reaching a better resolution for the picture and so on. Then a model specification of RTTP must be creatred together with the software that will support it. After a simple mechanism for data division and s simple RTTP is created they must be testes in a small network but with many variations it its structure and different capacities of its lines. The primary mechanism for data division by levels of importance doesn't need to be complex, so the testing network will probably have lines with capacities higher than ordinary Internet users obtain. Not until the network behaviour is examined RTTP must be specified. After a variant of a specified protocol is chosen it must be tested in a bigger than the previous network and if it proves its efficiency it may be proposed for implantation in the Internet. Then the effords must be directed at mechanisms for real-time data structuring, requiring less traffic than the primary one. 12. Security Considerations Security issues are not discussed in this memo. 13. References [1] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [2] Information Sciences Institute, "Internet Protocol", RFC 791, September 1981. [3] Information Sciences Institute, "Transmission Control Protocol", RFC 793, September 1981. [4] Baccala, B., "Connected: An Internet Encyclopedia", Aleksandrov [Page 32] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 http://freesoft.org/CIE/index.htm, April 1997. [5] Borden, M., Crawley, E., Davie, B., Batsell, S., "Integration of Real-time Services in an IP-ATM Network Architecture", RFC 1821, August 1995. [6] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [7] Braden, R., Clark, D., Shenker, S., "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [8] ST2 Working Group, Delgrossi, L. & Berger, L. - Editors, "Internet Stream Protocol Version 2 (ST2) / Protocol Specification - Version ST2+", RFC 1819, August 1995. [9] Gentric et al., "RTP Payload Format for MPEG-4 Streams", work in progress, draft-gentric-avt-mpeg4-multisl-04.txt, May 2001. [10] Speakman, T., Farinacci, D., Lin, S., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., Vicisano, L., "PGM Reliable Transport Protocol Specification", work in progress, draft-speakman-pgm-spec-07.txt, September 2001. 14. Author's Address Dimitar Aleksandrov Vladislavovo, 7-12-93 9023 Varna BULGARIA Phone: +359 52 470481 EMail: rttp@over-ground.net 15. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be Aleksandrov [Page 33] INTERNET-DRAFT RTTP: Properties of a real-time protocol September 2001 followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." This document expires March 27, 2002. Aleksandrov [Page 34]