Re: Lost Packets

Tim Dorcey (
Fri, 31 May 1996 09:35:07 -0400

Just to clear up some confusion, the packet loss statistics displayed in
the pull down panels measure end-to-end loss. There are 4 places that loss
can occur:

1. on the link from source to reflector
2. at the reflector
3. on the link from reflector to destination, and
4. at the destination.

Ideally, most of the loss you see is at the reflector, as the reflector
loss is intentional. The reflector monitors the capacity of each link, and
will forward no more data than it judges can be successfully received. If
you are requesting more data (by opening windows) than your connection can
handle, the reflector will drop random video packets (audio has priority)
in order to stay under the rate cap it has currently estimated for your
link. This value is displayed in parentheses below the local video window,
along with the aggregate data rate currently being received.

The reflector also lets each video source know the maximum amount of their
data that it expects to forward, so that sources don't send more data than
can be forwarded. Sources also monitor loss on their link to the
reflector, and reduce their rate to the smaller of a) the estimated
capacity of their link to the reflector and b) the most that the reflector
will forward to any receiver. This value is the transmission rate "cap"
displayed in parentheses below the local video window.

The adjustment algorithms must deal with a very dynamic situation. As
different windows are opened and closed and individual source video data
rates vary, the mix going out to each recipient changes. Also, as other
network traffic ebbs and flows, the link capacity varies interactively,
e.g., if one stream slows down, other streams will speed up to take
advantage of the capacity, and vice versa.

Users can bound the variation in the transmission/reception rate caps with
the min and max controls. E.g., setting the min value to 10 kbps means to
keep pushing at 10 kbps regardless of how much loss is observed. It may be
tempting to increase the minimum transmission rate because you will see a
higher outgoing frame rate. However, it is likely that more of what you
are sending is being dropped, so, in addition to creating more loss for
other network users, the resulting received video will actually be worse.

This description applies to the Cornell version, circa early 1996. I don't
know to what extent it is accurate for the White Pine version.

To clear up one other point, someone said that CU-SeeMe uses MBONE. This
is not correct. The individualized rate control described above would not
be possible using IP Multicast, which requires that exactly the same data
be sent to everyone who is receiving a particular multicast group.

Tim Dorcey
BoxTop Interactive