RTVP Open Research                                        D. Aleksandrov
Internet Draft: Radio and Television Protocol              December 2003
Document: draft-aleksandrov-radio-and-television-protocol-00.txt  


                      Radio and Television Protocol                      


STATUS OF THIS MEMO

This document is an Internet-Draft and is NOT offered in accordance  
with Section 10 of RFC2026, and the author does not provide the IETF
with any rights other than to publish as an Internet-Draft

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

This document expires 1 June 2004

ABSTRACT

The purpose of the assignment is to emphasise on the necessity of 
available transport protocol for public broadcast of audio-video data in 
a packet switching network, in particular in Internet. A theoretic 
scheme of such protocol is suggested, conventionally called RTVP - Radio 
and Television Protocol. The spreading of information, that the teoretic 
protocol is trying to achieve, is general, i.e. independence in loading 
the supplying radio and television program server from the number of 
viewers has been sought. The purpose also is to achieve receiving 
quality which is independant from the number of viewers. The theoretical 
RTVP achieves these goals by implementing the radio transmitting idea in 
a packet switching network.











D. Aleksandrov                                                  [Page 1]

Internet-Draft        Radio and Television Protocol        December 2003

TABLE OF CONTENTS

1. AUDIO AND VIDEO PROGRAMS TRANSMISSION BY RADIO DISPERSION ........  2
2. DATA PACKING. RULES BY TRANSMISSION OF PACKETS ...................  2
3. PRIMARY AND LOGICAL RADIO AND TELEVISION PROGRAM TRANSMITTERS ....  5
4. POSSIBLE RTVP IMPLEMENTING IN IP .................................  7
5. HYPOTHETICAL RTVP ACCORDING TO THE OSI MODEL .....................  7
6. MAKING THIS DEVELOPMENT CONCRETE .................................  9
7. CONCLUSION .......................................................  9
8. PUBLICITY OF THE DEVELOPMENT. COPYRIGHT STATEMENT ................ 10 
9.  SECURITY CONSIDERATIONS ......................................... 10
10. AUTHOR'S ADDRESS ................................................ 11
11. REFERENCES ...................................................... 11


1. AUDIO AND VIDEO PROGRAMS TRANSMISSION BY RADIO DISPERSION

Real time information transmission, containing sound or/and  picture, is 
common practice. The purpose of the section is to define the main 
characteristics, then to look for a mechanism to achieve these 
particular characteristics in a computer network.

A radio dispersion characteristic that draws attention is the presence 
of full synchrony between the sender and the receivers from the human 
perceptional point of view and according to the size of the Earth. The 
receiver immediately gets the information sent without any danger of 
delay or split in intervals, in which case the pauses in-between could 
lead to delay. 

Another very valuable radio dispersion quality is the senderÆs 
independence from the number of receivers, located in the covered area. 
Consequently, the price of the program (the effort to accomplish it) is 
constant and it could be easily planned. It is necessary for the 
receivers, on the other hand, just to be in the senderÆs covered area, 
to receive the program with constant quality, and not be affected from 
the other consumers. 

A radio and television main quality is also the one-way flow of 
information. The lack of feed-back could be a disadvantage but in cases 
of mass-media it is natural.

The radio and television transmission has one more special feature. 
There is no need for the listener (viewer) his receiver to obtain the 
full flow of information containing the program, to interpret it 
correctly. Even a radio station that is badly received could be used for 
listening of news or music, although the pleasure from this is not 
complete.

2. DATA PACKING. RULES BY TRANSMISSION OF PACKETS

We will make an experiment with a common television transmitter and a 
mobile receiver. In the beginning of the experiment let the receiver be 
very near the transmitter. We begin moving it in a straight line, away 
from the transmitting point. As we move further, the receiving quality 

D. Aleksandrov                                                  [Page 2]

Internet-Draft        Radio and Television Protocol        December 2003

will start to change - there will be interference in picture; the sound 
if it is stereo, will become mono; the quality of the picture will 
gradually become worse and worse and there will be also sound 
interference. In a certain moment, at a certain point away from the 
transmitter, the program can not be received anymore.

In this kind of experiments it is interesting to trace the ability of 
interpreting the program properly while the receiver is moving. The 
information, fed by a certain sender, is available to the 
listener/viewer until almost reaching the point of not receiving the 
program. This is due to the adaptation of human perception. Naturally, 
the details and the pleasure in watching/listening the program are 
different, but the possibility to follow the information sent is 
preserved. 

Our aim is to accomplish such cascade with packet audio-video data. When 
mass-media is considered, using computer network as an area for 
distribution, the one that sends information could not know how many 
listeners (viewers) there would be. Hardware and network (as connection 
speed) clientsÆ abilities are unknown. Consequently, data has to be sent 
with such structure that the receivers could choose what they can or 
want to receive from it adaptively. Besides, the principle of synchrony 
has to be observed.

The information sent is packed. Let (s) packets be generated with total 
maximum size k[b] for a certain time period (t). If for every (t) the 
client receives the corresponding (s) packets, the program will be fully 
viewed. The methods for reserving network resources [1 - 2] assume a 
choice of s(t)-value that satisfies both sides and they seek a mechanism 
to fulfill it. 

This mechanism could hardly guarantee access to the transferred 
information for unlimited number of users.

For a client, unable to receive all (s) packets there has to be a 
mechanism to remove those that come too much. For this purpose, 
information could be structured according to its importance. The 
criteria of importance has to be the possibility for correct 
interpreting. 

Let the server, that feeds with information, numbers the packets from 1 
to (n) for every time interval (t). Besides, let time intervals be 
numbered in cycles from 1 to (q). If these indices are written in the 
packets which have been sent, there would be information flow, indexed 
as follows:

(1,1), (1,2)... (1,n), (2,1), (2,2), ... (2, n), (3,1) à (q-1, n), 
(q, 1), ... (q, n), (1, 1)...

The purpose by this numbering is that the n-value shows the packetÆs 
importance for information interpreting. It has to be modulated on 
several levels, complement to one another. The possible modulation 
mechanisms are not subject of this assignment. For every time interval 
the packets with the smallest n-value bring information from the first 

D. Aleksandrov                                                  [Page 3]

Internet-Draft        Radio and Television Protocol        December 2003

level, after them follow these from the complement second level and s.o.

The q-values have to go through a full cycle for time longer than the 
life time/ number of hops determined as maximum for the respective 
network. (In IP [3] case and if TTL is set to its biggest value, it is 
for 256 sec at least.) Its purpose is that no pair of packets should be 
received with the same indices (q, n) without a clear chronology. The 
introduced indices are directly connected to the Application network 
layer, but in the model developed here, they are implementing in the 
Network layer. It exercises the functions of data limiting, when the 
client can not fully receive it. We assume that the network layer 
distinguishes the packets carrying radio or television data. We will 
call them RTVP packets for convenience. 

Let the receiverÆs traffic be routed through the only gateway. Let the 
gateway manipulate the passing packets according to these rules:

1) The routing host maintains different queues for RTVP packets of every 
pair program of server - client. Each queue of this kind is always 
sorted, according to the subsequence of indices (q, n). In the queue 
outgoing to client FIFO, instead of RTVP packets, pointers to the 
corresponding queues that contain them are maintained. When a pointer 
reaches the exit, the packet that stands at the exit of the 
corresponding RTVP queue is transmitted. 

2) Every RTVP packet newly arrived is added to its relevant queue, if 
there is no packet in it, that has the same or smaller index (n) and 
index (q) of a previous time interval. In this case in the queue 
outgoing to client FIFO a pointer according to Rule No1 is added.

3) When a RTVP packet arrives, in case there is one with the same or 
smaller index (n) and index (q) of a previous time interval in the 
queue, all previous time interval packets are removed. In the queue 
outgoing to client FIFO, as many pointers are removed, as the number of 
the packets lessens in the corresponding RTVP queue. The removal of the 
pointers begins from the youngest one in time.

These actions of the gateway ensure:

- Synchrony of the client with server. Removal of old packets guarantees 
that any non-current information will not be received. After a packet is 
received with the same or bigger number from next time interval, the 
client has already fallen behind the transmittion at least with (t) and 
this has to be compensated.

- Keeping the maximum information principle. The packets with most 
information are always put in the first place - with the smallest 
numbers for the corresponding time interval. 

- Democracy in transmission.  RTVP packets do in no way hinder or 
outdistance the remaining transfer. They take place for transmission 
along with the rest of the packets. Transmission of "places" from the 
queue to the client is by keeping strictly to the FIFO model.


D. Aleksandrov                                                  [Page 4]

Internet-Draft        Radio and Television Protocol        December 2003

Example: Let packets (2, 4); (2, 5) etc. correspond to the pointers in 
the outgoing queue to the client till the end of the complete set of 
information. Due to a delay they are not transmitted, and during the 
same time the data begins to arrive from the program for the next time 
unit. Packet (3,1) will be added to the queue, according to the 
formulation above. After that packets (3, 2) and (3, 3) will be stored. 
If the packet (2, 4) standing in queue is still undelivered and a packet 
with numbers (3, 4) or bigger numbers arrives, it is obvious that the 
client falls behind from sending with at least one time interval. 

In this case  all packets (2, *) will be removed. Packet (3, 1) would 
now be correspondent to the exit-closest pointer in the queue to the 
client.

The application of the rules defined leads to unreliable data delivery 
in real time between two directly connected hosts. The scheme was made 
with assumption that all RTVP packets reach the gateway in time or it 
generates them itself. The transmission of the requested data type in a 
complicated network with a multitude of gateways, routers, clients and 
servers is viewed in the next section. 

3. PRIMARY AND LOGICAL RADIO AND TELEVISION PROGRAM TRANSMITTERS

Let the presented RTVP packets processing scheme is valid for the 
Network layer [4] of all hosts (incl. gateways and routers) in the 
network. The problem with the synchrony of data is solved with the 
described Transport layer behavior, but not the problem with the server 
independence, generating the program from the clients. With the radio 
dispersion this independence is complete. In this case relative 
independence is viewed.

The single clients, who want to receive the program on the same server 
do not need individual data sessions. If there are any, same information 
will be transmitted repeatedly. The better option is data to be sent to 
one or several different hosts and to be multiplied by them, so it can 
be transmitted to the clients. Transmission through radio dispersion is 
made according to this principle. The program is generated in a studio, 
after that it is sent to transmitters, and every consumer makes settings 
to receive the signal of the one, which covers his area. 

We will call "primary transmitter" the program generating host where the 
server is working. We will call "local transmitters" hosts, whose data 
multiply, so it can reach several clients. The hosts and not the servers 
working on them are viewed, because once again the data manipulation is 
taking place in the Network layer basically. 

The suggested rules for RTVP data transportation are:

1) A client, who wants to receive RTVP program, gives a request to the 
server host and renews it every definite time interval (f). The first 
and repeated requests can not be discerned. 

2) Each host, routing a clientÆs RTVP request according to item 1) turns 
on a timer for the corresponding client, server and program. It is 

D. Aleksandrov                                                  [Page 5]

Internet-Draft        Radio and Television Protocol        December 2003

active for time (p), where f<p<2f. If there is no other clientÆs timer 
on for the same program, the router transmits the request without 
alteration. By renewing the request from a client, for whom there is an 
active timer, it would be reset.

3) By receiving a request for a program to transport, for which there is 
an active other clientÆs timer, the routing host stops it. After that 
the host sends a request on its behalf for the corresponding program and 
sends the client a message, that it becomes a Local transmitter.

4) Every Routing host, which has become a Local transmitter for a 
certain program, sends forward every program packet to the clients, that 
have active timers according to item 2).

5) Every host, which has become a Local transmitter, stops being that 
for the corresponding program, when the only active timer left has 
expired or been reset by a clientÆs request.

These rules do not exclude the formulated ones in section "Data packing. 
Rules by package transmission". Their application is presumed for all 
hosts in the network.
The main idea of the described transport algorithm is multiplying of 
RTVP program in places in the network, where the interest for it is 
increased. The rules described are applied in full measure to the host, 
where the server works, generating program, and also to the receiving 
host. Their purpose is to forbid the transmission between two end points 
of one and the same program more than once. When more than one client 
wants to receive identical RTVP data through one common router, itÆs 
only natural to reach it once and then to be multiplied. Besides, every 
router (incl. the server host) can receive as many requests, to as many 
hosts it is directly connected. Multiple requests given behind another 
routing host, attached to the viewed one, will be stopped, because a 
Local transmitter will also be made there. 

This is the meaning of the term "Local transmitter". A host gives a 
program request on its behalf, receives it and multiplies it. From the 
point of view of data transportation to the clients, it is as if the 
Local transmitter generates the program. The local sender message is 
used in case when a client wants to give a service refusal before his 
last request has timed out.

When only one client is interested in a certain program behind a 
particular gateway, the building of a Local transmitter is not 
necessary.

The formulated rules do in no way limit the individual route choice for 
every packet. A Local transmitter can be built in one from several 
routers, connected to clients in a general network section, because the 
program requests have passed through it. Thus it is assumed, that the 
way through it has been the best by the time of their transmission. We 
could expect the same about the route quality in a short interval after 
sending the requests, therefore the place of the Local transmitter is 
the best, because the most of the data carrying packets would go through 
it, even if it would not become a Local transmitter. By load change in 

D. Aleksandrov                                                  [Page 6]

Internet-Draft        Radio and Television Protocol        December 2003

alternative routes it is natural for the Local transmitter to move its 
location.

4. POSSIBLE RTVP IMPLEMENTING IN IP

The purpose of the suggested protocol is to be put gradually into 
operation in Internet. As it changes part of transport features of IP 
[3], RTVP could be named IPvN - N-version of IP. It could also be named 
IP4RTV - IP for Radio and Television. As the Internet protocols of every 
device connected to Internet are not possible to change all at the same 
time, compatibility between the IP version used and RTVP is necessary.

There are 3 participant types in the transportation process by the radio 
and television transmission viewed:

1) sending host, on which the generating program server works;

2) transporting host - gateway, that could begin to play the role of 
local transmitter;

3) receiving host, on which the client interested in the program works.

In the previous section the lack of difference was pointed out between 
the sending and transporting hosts from transport point of view. We 
could presume that the server, generating program, surely has been 
located on a host, keeping the RTVP rules. If this is not the case, its 
installation on the corresponding machine would be meaningless. The 
problem is reduced to interaction between transporting hosts with or 
without implemented RTVP.

When the requests of more than one client pass through a router that 
does not recognize the RTVP packets, it would not get into the role of 
Local transmitter. They would be delivered without alteration, and that 
would lead to individual data sent back to every client. By sufficient 
bandwidth of network this would not lead to problems. By insufficient 
bandwidth, RTVP packets would remain long in outgoing queues of the 
supporting protocol hosts. The quantity of the removed ones due to delay 
would increase. This would lead to natural quantity regulation of the 
data transferred through the routers, that do not support RTVP. That 
would also lead to a low quality or practical receiving inability for 
the hosts, located behind gateways not supporting RTVP.

Most important is, that the IP traffic left will not be influenced if a 
certain host supports RTVP or not. RTVP does not change the rules, 
applied to it. A resource reservation is not provided, that could limit 
the transfer possibilities of common IP packets. Making both type hosts 
in a common network compatible, could make worse only the RTVP data 
transfer, but not this already used by the consumers.

5. HYPOTHETICAL RTVP ACCORDING TO THE OSI MODEL

The offered protocol for general transmission of sound and picture is 
located in the OSI model [4] layers between the Network layer and the 
Application layer. As with most protocols, its different functions are 

D. Aleksandrov                                                  [Page 7]

Internet-Draft        Radio and Television Protocol        December 2003

difficult to be ranked with only one specific layer. The special RTVP 
feature is very strongly interwoven between layers. This makes necessary 
upper layer functions to have a relation to parameters that construct 
communication on low level and vice versa.

The purpose of this section is a general view over the RTVP projection 
towards the OSI model layers from top to bottom:

1) Application layer

It takes care for generating/receiving of radio or television program. 
The clientÆs Application layer takes care of handling the requests and 
receiving the service messages - from the primary or Local transmitter. 
It makes the data change from a mode that people understand to digital 
mode and vice versa.

2) Presentation layer

It takes care of data packing and numbering according to the Network 
layer requirements. The Network layer makes a different effort to 
deliver the packets, considering their importance, assigned by index in 
Presentation layer. It has to be clear about the Network layer capacity 
according to the size of the packets and has to structure the data 
according to the pointed limit.

By receiving it takes care for data chronology sent to the Application 
layer. As many cascade compression algorithms could exist, according to 
the data importance, the Presentation layer takes care to inform the 
receivers which exactly is in use. 

3) Session layer

RTVP does not use sessions. Sessions could be used in exchanging of 
requests. This could help the client to find out whether his request has 
ever reached itÆs final destination, if there is no back transfer. This 
question is not of great importance at this stage of RTVP idea 
development.

4) Transport layer

Identifies sound and visual programs and applications to be received by 
assigning the ports.

5) Network layer

It takes main care for delivery, multiplication in the network and data 
limit. If necessary, builds a Local transmitter, while watching the 
passing requests and communicating with Application layers of remote 
systems.

The full RTVP implementation requires a change in the Network layers of 
all systems using IP.



D. Aleksandrov                                                  [Page 8]

Internet-Draft        Radio and Television Protocol        December 2003

6. MAKING THIS DEVELOPMENT CONCRETE

RTVP is made concrete towards the existing IP. ItÆs aim is to point an 
exemplary possibilities to build RTVP in IP. Elaboration of a concrete 
standard and proper description of its parameters is entirely a question 
of a future development of this idea.

1) RTVP packets difference from the other IP traffic.

The RTVP transmission principle is based on a necessity of this 
difference. Important feature is also whether the packet is carrying 
request or data. The easiest way this to happen is by assigning 2 
values, written in the protocol field in the IP header [6]. The value 
has to mean one of both:

- transport of RTVP request;

- transport of RTVP data.

2) Indexing of packets

Indexing scheme requires the index couple to be present in every packet. 
As marked before, this presumes the packetÆs size to be complied with 
the Network layerÆs capacity for data structuring in the Presentation 
layer. Indices could be stored in the Options field in the IP header 
[5]. To avoid the limitation assigned in the size of this field, the 
indices could be stored also at a specified place in the data part of 
the package. After identifying RTVP number in Protocol field, the 
Network layer could find the index couple at the certain place in the 
data part of the package. By both storage methods the compatibility with 
the present IP version is ensured.

3) Program and client identifiers

The port storage question is analogous to the index storage. This could 
happen either in the Options field or in the data part of the IP packet.

7. CONCLUSION

The main purpose of RTVP is a protocol to be made that allows every host 
to transmit radio or television program that is accessible to unlimited 
number of receivers. The idea is based on democracy and solidarity. The 
whole network receives additional loading that is allocated between the 
hosts connected in it, so the possibility of that transmission can be 
ensured.

As many ideas for reliable sound and picture transfer in computer 
networks are developed, the unreliability of RTVP could provoke 
mistrust. The experience from another technology - TCP/IP [7] shows that 
a protocol unreliable for delivery time begins to show such 
characteristics. Due to consumersÆ desires, TCP/IP begins to acquire 
temporal characteristics. This is due to the market pressure, pushing 
the Internet service providers to expand their possibilities. This 
market mechanism could also lead to a guaranteed quality (high statistic 

D. Aleksandrov                                                  [Page 9]

Internet-Draft        Radio and Television Protocol        December 2003

liability) in RTVP transmission, so the consumers will set this as a 
requirement and by the presence of enough resources in the Internet 
service providers, it would become a fact.

In this article a few analysis, that are necessary to be made at the 
beginning of a concrete RTVP development, are absent

The possibility to transport the packets according to the described 
rules is not evaluated here. The assessment to what extent the 
additional functions load the routers and of what capacity computers are 
needed, is vague.

The relation between (n) and (q) indexesÆ maximum values is also not 
investigated, as it depends on the concrete algorithm by data 
presentation. For sure, it wonÆt be the same for different coding, which 
could reflect transfer efficiency in network environment. 

Reaching a real protocol would not be easy and it has to go through many 
steps. The suggested idea speculatively is completely applicable and 
this could bring confidence to the future developers. The final target 
is clear - accessible information in real time for everyone all over the 
world on one condition - Internet connection available.

8. PUBLICITY OF THE DEVELOPMENT. COPYRIGHT STATEMENT

This development is distributed by the terms of public license. It 
guarantees the right for everyone to use, copy, distribute and develop 
it. This should be made by quoting the primary source and giving use 
rights identical to these for the original.

The final task of the issue is to produce a network protocol for mass 
transmission of sound and picture. It has to be public.

The open source of the program code, that would assure maintaining of 
such protocol, is recommended but not obligatory according to this 
license.

Publicity about the way of transfer of data, which is cascade-structured 
by importance levels, is not to be applied to the algorithms and the 
program code, building that structuring.

The original version of that development will be maintained till it is 
possible for the author, without alterations on the address: 
http://rtvp.over-ground.net/original/.

9.  SECURITY CONSIDERATIONS

Security issues are not discussed in this memo.







D. Aleksandrov                                                 [Page 10]

Internet-Draft        Radio and Television Protocol        December 2003

10. AUTHOR'S ADDRESS

Dimitar Aleksnadrov
Vladislavovo 7-12-93
Varna 9023
Bulgaria

EMail: rtvp@over-ground.net

11. REFERENCES

[1] RFC 1633 "Integrated Services in the Internet Architecture: an 
Overview", Braden R., Clark D., Shenker S., June 1994

[2] RFC 2205 "Resource ReSerVation Protocol (RSVP)", Braden R., Zhang 
L., Berson S., Herzog S., Jamin S., September 1997

[3] RFC 791 "Internet Protocol", September 1981

[4] "TCP/IP Primer Plus", Osterloh H., Bulgarian language edition, Sofia 
2002, p. 25 - 33

[5] "TCP/IP Primer Plus", Osterloh H., Bulgarian language edition, Sofia 
2002, p. 105

[6] RFC 1700, "Assigned Numbers", Reynolds J., Postel J., ISI, October 
1994

[7] RFC 793 "Transmission Control Protocol", September 1981


This document expires 1 June 2004























D. Aleksandrov                                                 [Page 11]