This discussion thread on "Network Performance or Bandwidth Issues"
seems to have pretty much died out, but I've got a few questions.
--Where in your network do you place the packet shaping box? Close to
your attachment to the greater Internet so that all traffic goes
through the packet shaper, close to the residence halls or other
major sources of lower priority traffic, or somewhere else?
--Has anyone run into performance problems due the use of a packet
shaper? This might be general performance problems due to simply too
much traffic going through the packet shaper or it might be
performance problems specific to a particular application such as
--At one time you could identify most peer to peer traffic using the
TCP or UDP port numbers in the IP packet header. More recently this
has gotten harder since the peer to peer applications are using
random port numbers or using the same well known port numbers used by
other applications (port 80 is common). Here at Merit we see about
2/3s of the peer to peer traffic is using random or other well known
port numbers today. Has this shift caused problems for the packet
--I am not sure I have this next part right, but from people's
responses to this discussion thread it seems as if many of the
solutions involve limiting peer to peer or other low priority
applications to some fixed amount of bandwidth, possibly adjusted at
different times of the day or days of the week. Is anyone trying to
control bandwidth use in a more dynamic fashion based on total demand
at the time (when there is less high priority traffic you allow more
lower priority traffic and vice versa)? If so, how do you do this?
What rules do you use?
--Is anyone using or considered using a Quality of Service or Class
of Service approach to these issues? With this approach the priority
of a packet is marked (possibly using a packet shaper, but it would
also be done by a router or an application) in the Type of Service
(TOS) field in the IP header and decisions about what to do with the
packet are made by routers based on how the packets are marked. This
splits the traffic shaping work up so that different parts can be
done at different spots or even at multiple spots in the network. The
advantage to this approach is that each location can have more local
context upon which to make its decisions. The QBone Scavenger
Service (QBSS) that is available over Internet2 (but which could be
implemented on pretty much any network) is one example of this
approach. See http://qbone.internet2.edu/qbss/ for details.
At 3:07 PM -0400 9/10/02, James R. Dalton wrote:
>As we discuss commercial systems with lots of bells and whistles, I think
>there may be interest in some discussion of lower cost solutions which get
>the job done. I would like to see further development of open systems in
>At Roanoke College we have been running a Linux based system for 10 months
>which very effectively meets our needs. Our DS3 was maxed with outgoing
>traffic in December of 2001 so we began limiting large packet out going
>traffic from the residence halls to 5 mb over non http, ftp, etc. ports.
>This solution allows both firewall and packet limiting for a cost of an
>industrial strength PC and a ROM card to minimize moving parts. Our traffic
>immediately dropped to 15% utilization and equal incoming to outgoing
>traffic. We have noticed this year a 100% increase in traffic but still
>well below max.
>James R. Dalton
>Director of Information Services
>----- Original Message -----
>From: "John L. Beck" <[log in to unmask]>
>To: <[log in to unmask]>
>Sent: Tuesday, September 10, 2002 12:19 PM
>Subject: Re: [CIO] Network Performance or Bandwidth Issues
>> Like Berry College, we also chose Allot's NetEnforcer after evaluating
>> Packeteer and a bandwidth shaping plug-in (FloodGate) to our CheckPoint
> > firewall.
>> We capped our total bandwidth and prioritized and partitioned it out by
>> type of traffic and where the traffic is going. One of the things we did
>> was to have a catch-all traffic type ("other") for all undefined traffic
>> with a bandwidth limit. This catches new services as they pop up (or
>> things we hadn't thought of). Our students were very supportive and my
>> Kevlar underwear was unnecessary. We have heard from students who do
>> Internet gaming and are being limited. I tell them that while we don't
>> consider that to be as much of a concern as P2P stuff (because of the
>> and ethical implications), it's not our primary mission.
>> Via the Computer Services Advisory Committee, we developed a formal policy
>> for bandwidth management:
>> As to where we are now... we are staying under our cap and are running at
>> about the same utilization we had last spring.
>> Hope this helps. John
>> >Would any of you like to share the priority and/or bandwidth rules that
>> >set up with Packetshaper? We implemented Packetshaper last year and saw
>> >immediate results. We, however, put in place a very simple priority
>> >and no bandwidth reservation. This fall we are seeing major problems
>> >We, obviously, need to further develop our prioritization scheme and/or
>> >dedicate bandwidth to certain applications and/or restrict P2P to certain
>> >times. It would be helpful to see exactly what others are doing.
>> John L. Beck
>> Director, Computer Services
>> St. Norbert College
>> 100 Grant Street
>> De Pere, WI 54115-2099
>> E-Mail: [log in to unmask]
>> Phone: (920) 403-3866
>> Fax: (920) 403-4084
>> Participation and subscription information for this EDUCAUSE Constituent
>Group discussion list can be found at http://www.educause.edu/memdir/cg/.
>Participation and subscription information for this EDUCAUSE
>Constituent Group discussion list can be found at
Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/memdir/cg/.