INTERNET-DRAFT D. Aleksandrov
Expires June 2002 December 2001
RTTP: Properties of a real-time protocol
<draft-aleksandrov-rttp-prop-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use Internet
Drafts as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The purpose of this document is to provide ideas for real-time
communications in Internet. This document doesn't expand any pre-
defined standards or practices, it also doesn't conform ones. This
document contains a separate idea for real-time data delivery.
Aleksandrov [Page 1]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
transmission.................................................28
10. Comparison between the imaginary RTTP and other researches
concerning real-time data transmissions.......................30
11. Plan for researches based on this document....................31
12. Security Considerations.......................................32
13. References....................................................32
14. Author's Address..............................................33
15. Full Copyright Statement......................................33
1. Introduction
The purpose of this memo is to focus discussion on real-time data
transmission in the Internet and give a possible method of
solution.
No proposed solutions in this document are intended as
standards for the Internet. Rather, it is hoped that a
general consensus will emerge as to the appropriate solution
to such problems, leading eventually to the adoption of
standards.
"Real-time data transmission" means audio and visual information.
The closest by analogy with radio broadcasting.
The offered idea expects this imformation to be interpreted by a
human. It is not suitable for real-time transmissions between
machines only.
This document doesn't only propose ideas but also descibes the way
some of them have been reached. The memo's origin is the "Protocol
for real-time transmission in a packet-switched computer network"
work first published and still available in HTML at
http://rttp.over-ground.net .
The core idea of the document is described in sections 7 and 8.
Aleksandrov [Page 2]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
broadcasting.
The following definition of "broadcasting" is made here:
transmission of data independently from the recipients. A
broadcaster operates in the same way no matter the receivers. This
definition is valid for the whole memo.
Principle for importance of reliability û transmitted data must be
received as full as possible, no matter the time it will be taken
for. The reliability is more important than the time the transfer
will take.
Principle for importance of time û transmitted data must be
received as synchronously as possible. The perfect way is to
receive the data with the speed ot its transmission. If the whole
data cannot be received synchronously some part of it may be
eliminated but there must be no obstruction to receive the
following actual data.
According to these definitions IP follows neither one nor the
other of the principles. The time to live each packet has can be
assigned to the second principle but its purpose is to preserve
the network from overloading.
Basicly TCP/IP is constructed according to the first principle.
The packed switching gives some level of reliability and the
acknoledges TCP uses cause nearly every packet to reach its
destination.
If a radio or tv program must be transmittes we must refer to the
second principle. It is more important to receive data
synchronously than to receive it full.
Broadcastings on air are constructed this way. The receiver is
surely in touch with the transmitter, the transmitter is also a
broadcaster, according to the definition. If the program is not
received properly, for example if the antenna is too small,
Aleksandrov [Page 3]
INTERNET-DRAFT RTTP: Properties of a real-time protocol December 2001
usually there is enough data received for a human to understand
what is broadcasted. This is a huge advantage of broadcastings on
air.
This advantage is due to the fact that the most importaint peices
of data are in the surest zone of the information stream.
The surest zone is the one in the center of the freqiency band
width. Examples from FM radio and tv broadcastings will follow.
In the center of the frequency bandwidth there are the lowest
frequencies which are enogh for speech or melody understanding. If
a human receives with its radio only these lowest frequencies he
is not supposed to enjoy the program but he will understand what
is it about. If the bandwidth that is received is expanded there
will be a good quality of the music received.
The stereo information is situated in the farest non-sure zone of
the bandwidth. If the stereo information is received the quality
gets better but there is a pretty good quality even without it.
Color and B&W tv can be compared by analogy. The color information
is a little piece of the whole one and is in the farest zone of
the bandwidth. Because of its lower frequencies the sound of a tv
program is most surely received.
If some of the broadcasted data is lost the user will hear a
distinguished sound and a picture with bad quality. If less data
is lost there will be a brilliant picture but still B&W. In this
case there is enough information a human can understand. Most of
the information carriers are present, there is only an adition
missing û the color.
Three characteristics of real-time broadcastings on air have been
defined:
- guaranteed synchronous receiving;
- preserving of information as much as possible even if not the
whole data is received;
- the broadcaster is independent from the count and state of the
receivers.
To transfer data with these characteristics in a computer network
the real-time mechanism must include data multiplexing according
to its levels of importance.
Data must be devided into pieces with increasing and assigned
Aleksandrov [Page 4]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
broadcaster.
2) The principle for importance of reliability. The packets with
smallest internal numbers are always stored on front positions
into the queue.
3) Transmission equity. The real-time data doesn't bother the
other. Each time real-time packets are sorted they are placed on
already reserved by the real-time transfer places. These places
are FIFO manipulated like non-real-time packets.
Example: Let's have packets with numbers (2, 4); (2,5) and so on
in an outgoing queue of a server. There is a delay in
transfer to the client and they are not transmitted for a
period of time.
When (3, 1) packet arrives it will be stored at the end
of the queue. After it (3, 2) and (3, 3) will be stored.
If packet (2, 4) is still untransmitted and (3,4)
arrives, evidently the client is behind time.
In this case packet (3, 1) will be stored on the place
(2, 4) used to take; (3, 2) will replace (2, 5) etc. The
old data will be discharged and the new will take its
place for the purpose of compensating as much as possible
the delay.
(end of the example)
Aleksandrov [Page 7]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
ranges.
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
line.
The second variant is more advantageous. The network traffic is
diminished but it doesn't affect the quantity of data each client
receives. The data for all of the clients is transmitted through
the server so there is no need to do it as many times as the
clients are.
The behaviour of each host of the network must be defined. It is
defined that the server is engaged with the transfer. The server
holds the balance between the principles for importance of time
and importance of reliability. The single request for more than a
client is close to the principle for independence of the
broadcaster from the receivers and close to transmissions on air.
This scheme works for clients connected by single physical lines
but the purpose is to build a working scheme for the whole
network.
It is possible a client to be connected than more than a line to
more than a host of the network. If there is real-time data
transmission there are three ways each host can act:
1) Lack of commitment:
The server is the only host of the network dividing the
real-time packets form the other. The other hosts route each
real-time packet like any other. This scheme contradicts the
principle for importance of time. The network can be
engorged with data. These are enogh reasons to treat this
variant as unacceptable.
2) Partial commitment:
Every host recognizes the real-time packets. Every packet is
Aleksandrov [Page 10]
INTERNET-DRAFT RTTP: Properties of a real-time protocol December 2001
routed like any other but real-time ones are manipulated
according to the principles of a single line in the outgoing
queues.
3) Complete commitment (Fishbone model):
Every host commits with the real-time requests it is to
transfer. Every host modifies the requests and transfers
them with its address as receiver. When the host receives
real-time data it sends it to each of the hosts that
requested it.
Evidently the server from the previous model is completely
commited with the transfer. If all hosts act this way any
request's destination will be cascadingly modified. There will be
constructed a transfer route through the network. When a request
from another part of the network is sent it will either be
performed by another route or will cause an existing transfer
route to branch out into another direction. If the broadcaster is
connected by d lines with d hosts of the network the maximum
number of requests it will receive will always be d, and each will
be executed by a different route through the network. The complete
tree of routes through the network if there are many clients
remains a fishbone which gives the model name.
The Fishbone model is near the principles for broadcaster's
independance from the receivers, it observes the importance of
time but has disadvantages about reliability.
It is based on a fixed route through the network and every host
can become a weak point of the structure. Data losses between two
hosts become current for all of the hosts relying on them.
A big problem appears when a host taking part in the transfer
route drops out. If every request is resend after a period of time
the transmission will be recovered by another route but after a
period of silence.
On the other hand if a host is physically the only one able to
serve multiple request ("server - client", according to the single
line model) the Fishbone model seen to be the optimum one.
A network with lack of commitment of the hosts was categorically
rejected so a medial variant between partial and complete
commitment is needed.
The scheme for real-tme transfer must be applicable for a packet-
switching network and what is the most important - all hosts of
this network must follow same principles with others. In the
Aleksandrov [Page 11]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
broadcaster.
Only one request can reach the broadcaster by line, as any
multiple requests will be stopped by local broadcasters, so the
maximum value for q is the value of the physical lines that
connect the broadcaster to the network.
It is possible some data to be lost in the outgoing queues, so
coefficients pi for completeness are added. Fictionally every
pi = 1.
The three formulas look rather alike, evidently with main
inportance are the sums they contain.
On the other hand it mustn't be expected the index T to rise
unlimited. The broadcaster has limited number of connections to
the network and each connection has its maximum capacity.
Let c be the number of broadcaster's connections, and let the i-th
has ri [B/s] as a capacity for real-time transfer, 1 =< i =< c.
Broadcaster's physical lines are numbered fictitiously but their
numbers, once assigned, should be unchanged for the formulas.
Let R [B/s] be the maximum data that the network can accept from
the broadcaster. In this case
R = r1 + r2 + ... + rc = sum(r1; rc).
Evidently T =< R, so there are the following inequalities for the
three models:
1) sum(l1; lk) =< R/t for partial transfer commitment;
Aleksandrov [Page 18]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
interest:
- Conditions making each inequality to an equation;
- The average value for the indexes of each sum whenever the
expression it takes part in is an equation.
According to the principle for smallest traffic, the optimum
inequality is the one which's left side is the smallest, compared
with the other two, when the number of clients is one and the same
for the three expressions, because the whole data transferred by
the broadcaster is the product of each left part and t.
According to the principle for reliability, the optimum inequality
is the one in which the average value of all indexes the left side
consists of is the biggest, compared with the other two
inequalities, when the number of clients is one and the same for
the three expressions, because the left parts are all sums of
coefficients giving completenesses of transfer. As bigger the
average completeness is, as better the program will be received.
In both cases the least sum of bigger members is needed, so
evidently the most optimum sum is the one with fewest members.
The first formula is the only containing the number of clients.
There is a need of mechanism for counting the number of clients in
the formulas for Fishbone and LBC models. For ease, the following
addmission is made: The broadcaster takes a central zone of the
network, which means there are approximately equal numbers of
hosts most shortly addressed by each line.
This is not a precised addmission but if it is true there are
equal possibilities a request to reach the broadcster by any line.
It will most load the broadcaster. If the network is not balanced
in relation to the broadcaster, most of the requests will be
served by some of the lines, which will be far of the borderline
case (maximum load) that we are looking for. That's the reason the
addmission mustn't be treated as a negative one.
If there is at least one client a transfer route will be created,
so T = n1 * t.
If the second request reaches the broadcaster by another line the
Aleksandrov [Page 19]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
index.
The coefficients showing the division of data among the hosts can
be structured in a square matrix:
g11 g12 g13 ...... g1c
g21 g22 g23 ...... g2c
..........................................
gc1 gc2 gc3 ...... gcc
It is true that each line's sum equals 1. By multiplying the
matrix by t it looks like:
g11t g12t g13t ...... g1ct
g21t g22t g23t ...... g2ct
..............................................
gc1t gc2t gc3t ...... gcct
It is true that each line's sum equals 1 t. This is not totally
true, as is the statement for 1 lines' sums. Some of the lines can
equal 0 as there can be no request by every line. In the
borderline case of maximum load the statement is true for each
Aleksandrov [Page 21]
INTERNET-DRAFT RTTP: Properties of a real-time protocol December 2001
matrix' line.
The received matrix can be multiplied by the one representing the
completeness of transfer:
G1
G2
G3
.
.
.
Gc
The result looks as following:
g11G1 + g12G2 +......+ g1nGn
g21G1 + g22G2 +......+ g2nGn
.
.
.
.
gn1G1 + gn2G2 +......+ gnnGn
By analogy the Fishbone model can be presented by the following
matrixes:
1 0 0 0 ... 0 0 F1 F1
0 1 0 0 ... 0 0 F2 F2
0 0 1 0 ... 0 0 F3 F3
0 0 0 1 ... 0 0 * F4 = F4
............... . .
0 0 0 0 ... 1 0 Fn-1 Fn-1
0 0 0 0 ... 0 1 Fn Fn
In both cases the completeness of transfer for each request is
expressed in one and the same way. But both formulas are still
unrelated so the models can't be compared according to them. These
formulas are convenient for simulating programs and statistical
evaluation.
Another limitation must be introduced here, after the one for
centered broadcaster. In LBC model it is assumed that the
broadcaster acts intelligently in some measure.
The intelligent aspect of broadcaster's behaviour includes
distribution of data according to the network load. Generally must
be true the following:
Aleksandrov [Page 22]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
unefficient.
Evidently the last equality can't be entirely true in all cases
but it must be approximately true. Anyway, if R >= ct, the loss
for each request's data must lean towards 0 for the nearest to the
broadcaster zone of the network. This must be true no matter which
the physical lines are - the great advantage of the LBC model
compared with the Fishbone.
As the maxumum possible transfer for both models is one and the
same this advantage makes the LBC model the preferable one.
After a broadcaster's behaviour was examined the one of the hosts
and the clients must be examined too. Any client is a host of the
network but for ease "host" will be used only for ones that
transfer real-time data but are no clients. The transfer route
through the network is always unknown and there are numberless
possibilities so it is impossible all variants of host behaviour
to be embraced. Only conclusions based on statistics and
probability can be made. Yet, there are two possible cases for a
client's role in the network:
- final host, connected by a single physical line to another host
of the network;
- intermadiate host, connected by multiple lines to the network.
Other than the requested real-time data can be transmitted through
this kind of client.
On the other hand if the client is an intermediate host a virtual
final one can be added, so the host of the client will be examined
just like any other. The capacity of the line between the real and
the virtual hosts can be treated as unlimited and with no time
delay. Evidently the quantity and quality of the data received by
the virtual host depends entirely on the network. Virtual hosts
can be added in any situation so client examination is not needed
at all. Enough information can be obtained just by threshing out
the hosts which transfer the data.
Aleksandrov [Page 23]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
program;
2) every host of the network must recognize and check out any RTTP
packet which passes through it.
The first conclusion based on these principles is that the whole
network must support RTTP. The easiest way for introducing a new
protocol is basing it on TCP/IP [2], [3], [4]. If RTTP is based on
TCP/IP it is executable in Internet. On the other hand it is
impossible to apply a new protocol to the whole Internet shortly,
so mechanisms for compatibility between RTTP and non-RTTP hosts
must be foreseen.
It must be marked off there's an essential difference between TCP
and RTTP (based on LBC) conceptions. The whole network is engaged
with the broadcasting in the meaning of ôit changes according to
itö, so RTTP encroaches upon IP. TCP envolves the communicating
hosts and they exchange data but the other hosts take part only as
IP routers.
Yet, there are two assumptions that seem to be valid:
1) the broadcaster supports RTTP;
2) the requester (client) supports RTTP, otherwise it will not be
able to interpret the received data.
The real-time transfer doesn't need some TCP functions like the
acknoledge and the window size. If there exists RTTP, it will be
based on, or even parallel to IP, not based on TCP, i.e. there
will exist the independent subjections:
IP -> TCP, which can be IP/RTTP -> TCP;
IP -> RTTP,
and the subjection IP -> TCP -> RTTP will be no valid. ô->ö marks
the protocol layering. RTTP abandones some of the ideas of TCP
because of some real-time priorities - importance of time and
broadcaster's independence. In this case the acknoledge is not
desired. The temporary cease of transfer that happens in TCP when
zero window size is reported is also unnecessary. Applying the
principle of a sigle physical line for the outgoing queues
Aleksandrov [Page 26]
INTERNET-DRAFT RTTP: Properties of a real-time protocol December 2001
automatically stops or decreases the transfer when the network is
loaded.
The conclusion is that RTTP can hardly be based on the existing
TCP protocol.
If the future proves that an RTTP will work satisfactory the only
variant for its network implantation is complete compatibility
between IP and IP/RTTP hosts.
The things RTTP needs and IP doesn't include are pointed here:
The first is a port (identifier) of the broadcasted program. The
broadcaster has an IP address but probably it generates more than
one program. On the other hand there can be multiple clients on
one IP, so client's port is needed, too.
Every packet must contain stream identifier and internal number.
It is assumed packets are small enough and their fragmentation is
not needed.
This data can easily be stored in the data field of an IP packet,
so there are no problems about it. But a mechanism for recognition
of RTTP packets is needed. On the other hands there are three
types of packets, if RTTP exists:
1) non real-time (ordinary) IP packet;
2) a real-time packet. There are two kinds of RTTP packets:
- containig broadcasted data;
- containig request, refusals or other official information.
In every IP header there is a reserved for future use bit, there
is an option class which is reserved, too, yet there are 152
unassigned values for the "protocol" field, so there are enough
possibilities for marking an IP packet as an RTTP one.
RTTP packets must only be marked and all other necessary
information can be stored in their data fields.
As real-time transfer can be carried out by IP packets the problem
with host compatibility is solved. There appears the problem with
the network behaviour.
IP hosts (host will be marked as IP and RTTP) will not manipulate
their outgoing queues according to real-time requirements. RTTP
packets will not be rejected earlier than their TTL is elapsed. It
Aleksandrov [Page 27]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
client.
It was stated above that the broadcaster is an RTTP host. As the
network loads its outgoing capacity will fall down. The
broadcaster will destroy more and more packets in its outgoing
queues so the traffic it generates will also fall down. A balance
will be reached, some IP zones will be much loaded, the clients
divided by IP zones from the broadcaster will receive its program
poorly, but the network will not be blocked up. These problems
will be rarer if there are more RTTP hosts.
In a mixed network (IP & RTTP hosts) more difficulties the popular
programs will experience. IP hosts will not engage as local
broadcasters, so the broadcaster or the local ones will receive
more requests than their physical lines are and there will be
great losses even at their outgoing queues.
The statement that a mixed network will load but not block up
sounds true but must be checked out statistically or by a
simulating model. Neither statistics, nor a simulating model is
offered here.
If a private program (produced for just a single client) in an
RTTP network must be realized the easiest way is to modify its
request method. In case the client sends its request to the
broadacaster by non-real-time packet, another request sent to the
same broadcaster will not be recognized by the hosts on its road,
there will be no local broadcasters and no possibility for data
confusion. The RTTP packets of the private program will be
manipulated as RTTP ones on their road but only the host of the
client is going to receive them.
9b. General principles of the chosen model for real-time data transmission
1) Data format:
- the real-time data is transfered through a packet-switching
network. Each packet is routed separately;
- every host of the network recognizes the real-time packets;
- the broadcasted data is devided in time units with equal
durations. The data for each unit of time is structured as a
numbered stream, the packets inside each stream obtain sequent
internal numbers. The packets carrying the most important
information are the ones with smallest internal numbers;
Aleksandrov [Page 28]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
packets;
- every newcoming real-time packet with destination the client is
added to the queue for the client if in it there is no
untransmitted packet with the same or smaller internal number and
smaller stream identifier. Every time a real-time packet is added
all of the broadcaster's packets are sorted by ascending indexes.
They are stored in so sorted order on places of the queue already
reserved by broadcaster's packets;
- when a new packet arrives to the server and in the queue for the
client there is untransmitted one with the same or smaller
internal number and smaller stream identifier all the packets
belonging to previous steams are discharged. The packets remaining
in the queue are stored on the nearest to the exit places of the
queue already reserved by broadcaster's packets.
10. Comparison between the imaginary RTTP and other researches
concerning real-time data transmissions
There are lots of works dedicated to real-time transfer. There are
standartized protocols and practices. By the time researches
concerning this item are too advanced this memo describes just
basic ideas. That's because RTTP ideas are in a little different
direction than the developed ones.
This section compares RTTP with existing protocols and practices
for real-time data transmission. This section doesn't pretend to
be comprehensive, its main point is to focus discussion on the
need of resource reservation. This section's references are [6 -
10].
As most of the works dedicated to real-time transfer concern video
and audio conferences, RTTP points mainly on broadcasting.
"Broadcasting" according to its definition in section 2 of this
document. Pointing on broadcasting RTTP doesn't provide any
reliability which is a basic efford in other real-time researches.
A common way for obtaining reliability is the resource reservation
process ([5], [6], [7], [8]). Resource reservation is denied by
the RTTP concept for some reasons:
- it doesn't seem to be democratic;
- it foresees the possibility of a "busi signal" when there is not
enough bandwidth for the transfer;
- if the transmitted data is structured by levels of importance
Aleksandrov [Page 30]
INTERNET-DRAFT RTTP: Properties of a real-time protocol 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
quality
- 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
Internet.
Then the effords must be directed at mechanisms for real-time data
structuring, requiring less traffic than the primary one.
12. Security Considerations
Security issues are not discussed in this memo.
13. References
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",
http://freesoft.org/CIE/index.htm, April 1997.
[5] Borden, M., Crawley, E., Davie, B., Batsell, S., "Integration
of Real-time Services in an IP-ATM Network Architecture",
RFC 1821, August 1995.
[6] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[7] Braden, R., Clark, D., Shenker, S., "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[8] ST2 Working Group, Delgrossi, L. & Berger, L. - Editors,
"Internet Stream Protocol Version 2 (ST2) / Protocol Specification
- Version ST2+", RFC 1819, August 1995.
[9] Gentric et al., "RTP Payload Format for MPEG-4 Streams", work
in progress, draft-gentric-avt-mpeg4-multisl-04.txt, May 2001.
[10] Speakman, T., Farinacci, D., Lin, S., Tweedly, A., Bhaskar,
N., Edmonstone, R., Sumanasekera, R., Vicisano, L., "PGM Reliable
Transport Protocol Specification", work in progress,
draft-speakman-pgm-spec-07.txt, September 2001.
14. Author's Address
Dimitar Aleksandrov
Vladislavovo, 7-12-93
9023 Varna BULGARIA
Phone: +359 98 425788
EMail: rttp@over-ground.net
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
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
This document expires June 19, 2002.
Aleksandrov [Page 34]