Re: Reflector Packet Storm

Tim Dorcey (td11@cornell.edu)
Wed, 10 Aug 1994 12:01:51 -0400


>>> Subject: URGENT: Packet storm
>>> Cc: noc@EU.net, noc@uunet.uu.net
>>>
>>> skyhawk.gte.com is sending large amounts of traffic to 192.126.1.15;
>>> this is for 15 minutes:
>>>
>>> From To Packets
>>>Kbytes
>>> ---------------------------------------------------------------------------
>>> skyhawk.gte.com 192.126.1.15 62941 53336 K
>>>
>>> I've blocked traffic both ways, but skyhawk keeps sending; our
>>> US line is completely saturated, dropping 50 packets per second.

By my calculation, 53336 KBytes in 15 minutes comes out to 474
kbits/sec, which could be a "normal" CU-SeeMe stream. E.g., if all video
senders were capped at the default 80 kbpsec, a receiver viewing 6 active
windows could receive that much data. Alternatively, a single transmitter
on a reasonably fast machine could pump out that much data if their cap was
cranked up high enough.
I think what makes this a "packet storm" is not the absolute volume of
data, but the fact that so much was being dropped without any scaling back
on the transmission rate (e.g., you would never see this kind of behavior
with TCP streams). In the current versions of CU-SeeMe, the only direct
control that a receiver has on the amount of data that they receive is by
the number of windows that they have open. If lots of data sent their way
is being lost, they will inform the senders, but these loss reports will
not always slow down the transmission rate for the following reasons:

1) packet loss reports are averaged over all video recipients, so that one
receiver losing lots of packets wouldn't have much effect on the
transmission rates if others are getting good results.

2) Senders can set a minimum rate cap, below which the rate cap will not
be adjusted, regardless of packet loss reports.

We eventually intend to implement a layered video encoding scheme that will
allow reflectors to send different amounts of data to different receivers,
with varying temporal and spatial resolutions. Then, receivers will be
able to set a reception rate cap, and allocate bandwidth as they see fit
(e.g., to lots of windows at low resolution, or a few windows at high
resolution, etc.). If this reception rate cap is adjusted automatically
according to packet loss, then packet storms should no longer be a problem
(unless we provide a user control to over-ride the automatic adjustment).
Until that time, individual users will need to make their own judgment
about what is appropriate for their situation.

>>> I've blocked traffic both ways, but skyhawk keeps sending;

This, however, is very strange. If the reflector receives no packets from
a recipient for a 10 second interval, it should cease all transmission.

> The processes on the reflector were killed however it still sent packets.

This is also very bizarre. Clearly, the reflector program cannot be
sending packets if it has been killed. Is there any possibility that the
traffic is being generated by something besides CU-SeeMe? All CU-SeeMe
packets should be identifiable as destined for one of the UDP ports
7648-7652.

-Tim

__________________________________________________________________
Tim Dorcey T.Dorcey@cornell.edu
Sr. Programmer/Analyst (607) 255-5715
Advanced Technologies & Planning
CIT Network Resources
Cornell University
Ithaca, NY 14850
__________________________________________________________________