Internet DRAFT - draft-aleksandrov-rttp-prop


INTERNET-DRAFT                                            D. Aleksandrov
Expires June 2002                                          December 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

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

      Copyright (C) The Internet Society (2001). All Rights Reserved.


      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   December 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 
   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 
      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

      "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 . 

      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   December 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 

      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 

      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   December 2001

      usually there is enough data received for a human to understand 
      what is broadcasted. This is a huge advantage of broadcastings on 

      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 

        - 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 

      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   December 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   December 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   December 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 

      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   December 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 

Aleksandrov                                                     [Page 8]
INTERNET-DRAFT  RTTP: Properties of a real-time protocol   December 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   December 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 

      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 

      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   December 2001

            routed like any other but real-time ones are manipulated 
            according to the principles of a single line in the outgoing 

      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   December 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   December 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   December 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   December 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   December 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   December 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   December 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 

      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   December 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 

      - 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   December 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   December 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 

      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   December 2001

      matrix' line. 

      The received matrix can be multiplied by the one representing the 
      completeness of transfer:


      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 

         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 

      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   December 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 

      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   December 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   December 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   December 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 

      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   December 2001

      automatically stops or decreases the transfer when the network is 

      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   December 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 

      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   December 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   December 2001

      outgoing queues according to same mechanism with non-real-time 

      - 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 - 

      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   December 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]).

      The commercial aspect of the Internet must be treated as a very 
      important one. Currently, World Wide Web users receive transfer by 
      TCP/IP which has no touch with the principle for importance of 
      time. Yet, most of the users always obtain transfer equal or very 
      close to the maximum transfer their network equipment provides. It 
      means that user requirements force the market called Internet to 
      provide features that used protocols do not really guarantee. 
      Implementing RTTP in Internet will lead to the same effect. No 
      matter the protocol will not stick to the principle for importance 
      of reliability it will be in most of the cases reliable, as users 
      will add RTTP reliability as one of their requirements.

      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:

Aleksandrov                                                    [Page 31]
INTERNET-DRAFT  RTTP: Properties of a real-time protocol   December 2001

      - 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 

      - reaching a better resolution for the picture

      - 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 a primary RTTP is created they must be tested
      in a small network but with many variations of 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 

      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

Aleksandrov                                                    [Page 32]
INTERNET-DRAFT  RTTP: Properties of a real-time protocol   December 2001

      [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",, 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 98 425788

15.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Aleksandrov                                                    [Page 33]
INTERNET-DRAFT  RTTP: Properties of a real-time protocol   December 2001

   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
   followed, or as required to translate it into languages other than

   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

This document expires June 19, 2002.

Aleksandrov                                                    [Page 34]