["Anders Broman" <a.broman@xxxxxxxxx>]

Checked in.

Following warnings received:

mcast_stream.c
mcast_stream.c(256) : warning C4244: '=' : conversion from 'float ' to
'unsigned
 int ', possible loss of data
mcast_stream.c(389) : warning C4244: '-=' : conversion from 'double ' to
'int ',
 possible loss of data
mcast_stream_dlg.c

Brg
Anders


-----Ursprungligt meddelande-----
Från: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] För Miha Jemec
Skickat: den 24 april 2006 16:18
Till: ethereal-dev@xxxxxxxxxxxx
Kopia: Miha Jemec
Ämne: [Ethereal-dev] New feature: analysing Multicast streams

Hi!

In my daily work I have a lot to do with the video solutions. One of the
major problems we encounter are the traffic bursts which may
significantly degrade the video quality. Analysing this kind of problems
with the ethereal I/O graph can be difficult and thus we developed
another mechanism.

Background:
If you imagine a real solution there are points in the network where
speed reduction occurs (ethernet links, DSL lines, etc). One example can
be: 

>---100 Mbit/s link-----|ethernet switch|----10 Mbit/s link -------->

If this is video network for carrying one MPEG2 stream with average
bandwidth of 5 Mbit/s, the crucial information is how big are the bursts
inside this stream. Because of limited memory of the output queue inside
the ethernet switch we can get packet drops if the bursts get to high. 

With the new feature we can: 
1. Measure how big the bursts are for a video streams (it uses sliding
window algorithm)
2. Measure how big the output buffer should be that no packet drop will
occur (it uses Leaky bucket algorithm) 
3. Detect if we have loses inside the MPEG2 video stream (if there are
already MPEG2 packets missing) - this part of code is not added yet, see
Limitations

The addition is called Multicast streams and works as follows:

- it uses the TAP system
- the main "stream" logic is taken from rtp_strems.* files
- the TAP system checks for UDP packets where the destination MAC
address starts with "01:00:5E" (ethernet multicast address)
- it creates an entry for every new multicast stream
- based on sliding window and leaky bucket algorithm it calculates for
every stream average BW, max BW, burst size, max buffer needed, some
alarms if the limits are exceeded,...
- the same calculation is done for all streams together
- inside the window dialog you can specify the burst interval, the alarm
limits and output speeds

To do & limitations:

- Currently the analysis can be done only for multicast streams, it
means that VoD (Video on demand) or PayTV streams, which are normally
unicast can not be analysed. 

- since the MPEG2 is patended I don't know if decoding of MPEG2 packets
is allowed? Can we look inside this packets and calculate packets drops
based on some counter information inside the payload? Can someone please
answer this question? If we can do this, I will post this part of code
too.

-  some more flexibility will be added

Attached is picture of the two windows, the source code and make files
(all go inside gtk directory) for Linux. Tested on FC3, FC4, FC5. 
I don't know what has to be added for Windows compatibility, maybe
changes inside the Makefile.nmake are enough?

Here is also a link with one Multicast stream capture file, you can play
with

http://www2.arnes.si/~ljmik6/pub/video_streams.cap (13MB)

Below is also a detailed explanation of the columns inside the window.

The major credit goes to my co-worker Jakob Bratkovic, who wrote the
whole calculation and analysing part of the code.

Regards, 

Miha Jemec
Iskratel
Slovenia

Column explanation:
Max burst - the highest number of packets inside a sliding window time
interval. The time interval can be specified inside the Set parameters
window
Max Bw - same as the above one, only in Mbps instead of pps
Burst Alarms -  how many times the bursts exceeded the limit set inside
the Parameters dialog
Max buffer - how big the output queue should be that no packet will be
dropped at specified output speed
Buff alarms - how many times this was not the case (the required buffer
was higher than available one)

Inside the Set parameters dialog, beside the Burst Interval and Alarm
Limits, you can also specify the output speed for single stream and
output speed for all streams.