🚀 go-pugleaf

 
Hello everybody: 

We are working on the project EuroBridge founded by European 
commission. The aim of EuroBridge is to find flexible 
communication structures for distributed Multimedia 
applications. The problem we have is, that at the moment we 
haven't enough experience on the communication requirements of 
Multimedia application. That means we are looking for exact 
values of various performance parameters. 

If you are involved in developing distributed multimedia 
applications or you have knowledge on this item, please take 
five minutes time fill the questionnaire below and mail it to 

Wilko Reinhardt, Lehrstuhl f. Informatik, RWTH Aachen, Ahornstr. 
55
FAX: +49-241-80-21429, phone: -37, 

email: wilko@informatik.rwth-aachen.de

At the end of the questionnaire you will find an explanation of 
all items. Many thanks in advance for your co-operation!

Wilko Reinhardt (RWTH Aachen, Germany) 


--------------------------------------------



Questionnaire

Multimedia Application:


...........................................................


(Please give us a short description of your multimedia system)




Performance QoS
Video
                      | range:(max. / av. / min) | not relevant
                      |                          |
jitter                |                          |
                      |                          |
delay - one way       |                          |
                      |                          |
throughput (steady)   |                          |
                      |                          |
throughput (bursty)   |                          |
                      |                          |
connection set up time|                          |
                      |                          |
response time         |                          |
                      |                          |
max. acceptable error rate|                      |
for the application   |                          |
(without error contr. |                          |
 mechanism)           |                          |
                      |                          |
                      |                          |
others?               |                          |
                      |                          |
                      |                          |
                      |                          |

Performance QoS
Audio                      | range:(max. / av. / min) | not 
relevant
                      |                          |
jitter                |                          |
                      |                          |
delay - one way       |                          |
                      |                          |
throughput (steady)   |                          |
                      |                          |
throughput (bursty)   |                          |
                      |                          |
connection set up time|                          |
                      |                          |
response time         |                          |
                      |                          |
max. acceptable error rate|                      |
for the application   |                          |
(without error contr. |                          |
 mechanism)           |                          |
                      |                          |
                      |                          |
others?               |                          |
                      |                          |
                      |                          |
                      |                          |



Performance QoS
Data
                      | range:(max. / av. / min) | not relevant
                      |                          |
jitter                |                          |
                      |                          |
delay - one way       |                          |
                      |                          |
throughput (steady)   |                          |
                      |                          |
throughput (bursty)   |                          |
                      |                          |
connection set up time|                          |
                      |                          |
response time         |                          |
                      |                          |
max. acceptable error rate|                      |
for the application   |                          |
(without error contr. |                          |
 mechanism)           |                          |
                      |                          |
                      |                          |
others?               |                          |
                      |                          |
                      |                          |
                      |                          |


Functional QoS

                           |  relevant    |  not relevant
                           |              |
QoS re-negotiation         |              |
                           |              |
security mechanisms        |              |
                           |              |
  - encryption             |              |
                           |              |
  - password/id            |              |
                           |              |
resource reservation       |              |
                           |              |
multipoint connections     |              |
                           |              |
data flow synchronisation  |              |
                           |              |
Error correction scheme    |              |
(ARQ / FEC / none)         |              |
Channel Prioritisation     |              |
                           |              |
others?                    |              |
                           |              |
                           |              |
                           |              |



Appendix: Explanation of terms

Jitter
However due to statistical queuing delays and network errors 
(lost or corrupted packets) there are delay variations that we 
call jitter.  An additional source of jitter could be the system 
clocks at the source and sink running at different rates, the 
variation in quartz oscillators is small but at the high speeds 
required for videoconferencing this may be a factor.
Jitter may also be caused by unnecessary multiplexing in a 
layered protocol stack.

Delay
The transmission delay should be measured as an end to end 
metric, i.e. measured from the point  where the sample is 
generated to the point at which it is presented to the user.  
The total delay consists of the packetisation delay, the network 
transmission delay and the presentation delay. The packetisation 
delay is the time taken to generate a sample and deliver it to 
the network, the network transmission delay is the time taken to 
transmit the sample over the network, and the presentation delay 
is the time spent buffering and processing the sample be-fore 
presenting it to the user.

Throughput
The throughput of a channel is the amount of data that can be 
transmitted through that chan-nel in a unit of time (bits per 
second usually).  Research has identified a need to extend the 
definition of throughput to contain some measure to account for 
burstiness.

Connection time or set-up time
The time taken to set up a channel or virtual circuit should be 
as short as possible and not re-quire a large amount of network 
resources since this will be a common event on networks 
supporting videoconferencing applications. During channel set-up 
the service requirements for that association will need to be 
met or negotiated.

Response Time
The response describes the time between submission of a message 
and receipt of the remote system's reaction. This time indicates 
how long a user has to wait for answers. The value may vary from 
some ms (e.g. interactive work with the remote system) to a few 
minutes (e.g. non urgent file retrieve).

Error Rate
The reliability of a channel depends on what type of information 
it contains.  Both video and audio can tolerate a certain amount 
of loss of information.  Audio can tolerate a 1% loss as long as 
each error burst is less than 4ms.  The acceptable error loss 
for video is dependant on the encoding and compression schemes 
used.  Data can not tolerate any loss.  Research has indicated 
that the residual error rate should be revised to distinguish 
between bit and packet errors as video and audio are affected 
differently depending on the type of error.

QoS Parameter Renegotiation
As the network resources may change during the lifetime of an 
association a higher level re-source manager may wish to change 
the associations characteristics in mid connection.  The 
application may also request that the characteristics change, 
e.g. in a video surveillance appli-cation the guard may have 
numerous slow scan windows until he sees something that he 
wishes to investigate.  He then may wish to increase the 
resolution and frame rate for a better view.

Security Mechanisms
Your application may asked for a secure transfer of confidential 
data (e.g. medical diagnos-tics, financial information, love 
letters, etc.). The communication system can provide several 
security mechanisms like encryption or user identification by 
passwords or user id's.

Resource Reservation
This communication feature provides the reservation of 
communication resources (e.g. bandwidth) in advance. The user is 
able to reserve a channel which meets his QoS demands. At the 
scheduled time the communication system will guarantee the 
required QoS.

Data Flow Synchronisation
Three types of synchronicity have been identified :
Asynchronous: has unspecified delay, which implies unspecified 
jitter
Synchronous: has an upper bound on delay, which implies a coarse 
bound on jitter.
Isochronous: has a specified delay and delay jitter.
For videoconferencing applications we require isochronous 
synchronisation, where this is the synchronisation of streams in 
real-time.

Error Correction
For the case of video and audio in a real time video conference 
retransmitting a lost packet is not generally considered 
applicable.  The desired quality of service is usually reached 
by ne-gotiating a guarantied reliability.  For the case of data 
there must be some mechanism to re-trieve lost or corrupted 
data.  
There are two possible methods that would be applicable, 
Automatic Repeat Request (ARQ) and Forward Error Correction 
(FEC).
In order for ARQ to work efficiently, the receiver must have 
enough buffer space to buffer all packets from the lost/damaged 
one until the retransmitted packet has reached the receiver.  
ARQ requires a duplex connection.
FEC includes redundant information in the transmission to enable 
retrieval of corrupted or lost data at the sink, if necessary.  
FEC is applied to all packets transmitted and the overhead is 
known beforehand.  FEC calculations are complex and may need to 
be implemented in hardware to meet delay and jitter limits.

Channel Priorities
Research has identified a need to be able to assign priorities 
to channels so the transport sys-tem can be aware of the 
relevant 
importance of the various channels.