[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Packeteer/Packetshaper and the IDD

Hi there,

Over the past two weeks we have had two sites (University of Arizona,
and City College of New York) whose data reception was significantly
throttled or completely blocked by the installation of Packeteer and
specifically (as I understand it) its Packetshaper package.  The
symptoms I saw were: extremely low throughput, latency problems, RPC
time outs, "can't contact portmapper" messages, and "no route to host"
messages.  For U of A occasional products got through although latencies
got bad, but for CCNY nothing ever got through.  ldmping consistently
failed at both sites.

Packeteer is not just software, but is a box that generally sits between
a router and switch.  It does not run on any other hardware.  Thus,
there's no way to tell from any of our sites if it's running.

It appears that Packetshaper can discriminate in a very fine manner,
limiting traffic based on port number, IP address,  application,
protocol, subnet, URL, and apparently some other criteria.  It could
actually be a very helpful tool (it can apparently run at 100Mbs),
although the possibility of misconfiguration may be high.  The
University of Arizona inadvertently placed the LDM in a "point to point"
class along with KaZaA, Gnutella, and Napster, and then severly limited
that class.  I presume now they're running well with just the removal of
the LDM from that class of services.

Packetshaper also allows services to be assigned priorities.  By default
all services are set at priority 3 in a range of 0 to 7.  And, you can
also specify a bandwidth partition for a service, giving it a minimum
bandwith plus an optional maximum bandwidth to handle bursts.  I don't
yet know if there are other tunable parameters beyond what I've
described here.

I'm in communication with someone from Packeteer with the goal of
getting some directions so we can tell sites how to configure it to
allow our traffic through as fast as possible.  Probably most of our
sites will be relying on their institutional network administrators to
configure the package properly.  Based on our experiences of the past
two weeks, those folks could also use some guidance.