[Miha Jemec <m.jemec@xxxxxxxxxxx>]

I created a short explanation at the Wiki sites and a sample capture is
now available.

http://wiki.ethereal.com/Multicast_streams

I still have one question, if someone can please answer it: 

This analysis can also calculate packet losses inside MPEG2 packets. But
since the MPEG2 is patented codec I don't know if decoding of MPEG2
packets is allowed? Can we look inside this packets and calculate packet
drops based on some counter information inside the payload? 

If for ethereal license this is a legal way, I will post this part of
code too.

Regards, Miha


On Mon, 2006-04-24 at 23:27 +0000, ronnie sahlberg wrote:
> Very nice.
> 
> Can you add some pages to the WIKI describing this features with some
> screenshots and example captures for people to test with and learn
> about this feature?
> 
> 
> 
> On 4/24/06, Miha Jemec <m.jemec@xxxxxxxxxxx> wrote:
> > 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.
> >
> >
> >
> >