[HCS]HASCS Town Hall

Scott A. Golder golder at fas.harvard.edu
Tue Feb 20 11:54:42 EST 2001

Dear HCS Members and Friends,

I would like to inform/remind all of you that, this evening at 5 PM
in Science Center D, there will be a Town Hall meeting with HASCS
(notably, with Bill Ouchark, head of the unix group) concerning the
recent changes to HASCS' methods of traffic control.

As the leading student computer group on campus, it is our responsibility
to promote sane computing and a healthy computing environment here at
Harvard.  In view of this, I believe it is our obligation to have a strong
voice (or collection of strong voices) in what philosophies HASCS adopts
with regard to student computing.

The original posting is on harvard.hascs.  I have reprinted it at
the very bottom of this email, in case you do not have access to

The gist of it is this:
HASCS intends to control bandwidth utilization by refusing all
connections to machines on student subnets that are initiated from
outside of harvard.edu.  No connections initiated from within harvard.edu
should be affected.

There will be a policy exempting students from such restriction.
Such policy is not yet written.  Or, at least, HASCS has not made it
public.  My intuition is that it is in fact not written.

(A) It is my view, and the view of many others (as posted on h.hascs) that
this policy must be clear, and that obtaining such an exemption be
instantaneous and trivial.  That is:
(1) Any student should be able to receive an exemption, for whatever
    reason, be it experimenting with socket programming for CSxxx or
    even serving MP3s (legal issues aside)
(2) The toggling of {blocked,unblocked} should be instantaneous, preferably
    done by way of a web or shell interface.  That is, without human
(3) Firewalling should be a matter of "Please remove the computer on
    jack #foo from behind the firewall," not a matter of "Please open
    port 80 so I can serve my web page."
(3) Any such policy should be fully in place _before_ any firewalling goes
    into effect.

(B) Further, hcs% (the machine, not the organization) should be exempt
from any such impediments such as firewalling.  HCS's server has
a vital role in supporting the student community, and, as such, deserves
special exemption.  I will not back down on this point, and I assume the
HCS Manager Team will not either.

The views I've expressed above are mine, and I do not purport to represent
anyone other than myself in stating them.  However, I encourage HCS members
to support (A) and strongly request public support of (B).

I want to remind everyone that HASCS is _not_ our adversary.  Some of you
might have negative feelings about HASCS.  Let us remember that HASCS has
been helpful and friendly to the HCS in the past.  I want to maintain this
relationship.  Both the HCS and HASCS can benefit from the organizations
working together.  At least, nothing can be accomplished if we do not.

HASCS is putting together a group of students to beta-test the firewalling.
The students who volunteer will be VLAN'ed together and will be the first
to test the new restrictions.  There will be an immediate way to opt out if
you join the test group and decide you no longer want to be part of it.
There will likely be some carrot held out to make it palatable and
rewarding to the test group.  Email Kevin Davis <ksdavis at fas> the head of
residential computing, if you would like to participate.

Note that I have set Reply-To: to hcs-discuss at hcs.  Let there not
be a separate flamewar about mucking with Reply-To.  :)

I hope to see many HCS members at the meeting this evening.


Scott A. Golder
HCS President

Scott A. Golder '03                                   Kirkland L-11
golder at fas.harvard.edu                     166 Kirkland Mail Center
(617) 877-9230                             Cambridge, MA 02138-7525

-- Bill Ouchark's original posting --

>From ouchark at fas.harvard.edu Tue Feb 20 11:26:54 2001
Path: news.fas.harvard.edu!not-for-mail
From: ouchark at fas.harvard.edu
Newsgroups: harvard.hascs
Subject: FAS Student Network Update (02/16/01)
Date: 16 Feb 2001 21:27:03 GMT
Organization: Harvard University, Cambridge, Massachusetts
Lines: 193
Message-ID: <96k5v7$8l8$1 at news.fas.harvard.edu>
NNTP-Posting-Host: is06.fas.harvard.edu
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (OSF1/V4.0 (alpha))
Xref: news.fas.harvard.edu harvard.hascs:13647

        Lately, many of you may have noticed decreased performance and
        overall  sluggish  response in  connectivity  between the  FAS
        Network and  external sites.  We have received  reports from a
        number  of you; others  may have  simply suffered  in silence.
        There has been a lot of concern, especially with recent events
        in the  news pertaining to  Napster, over the impact  of these
        services and  what can be done.   We hope this  note will help
        bring you all up to date.

        Background Information

        To provide a bit  of background information, network bandwidth
        between  the  FAS Network  and  both  the  Internet and  other
        schools  at Harvard  currently traverses  a 100Mb  link.  This
        link,  when  one considers  both  current average  utilization
        trends  and  link   capacities  further  upstream,  should  be
        sufficient to meet current demand.

        Unfortunately, and for some time  now, a portion of the demand
        curve  has been  growing  out  of line  with  the rest.   This
        component  is  best  generally  classified as  high  bandwidth
        services provided  by systems on  the FAS Network  to external
        sites and  users.  While the most  notable application meeting
        this criterion  is Napster, a  search and download  engine for
        MP3  music  files, there  are  many  others  that are  similar
        (Gnutella, CuteMX, and more being introduced all the time).  A
        user  installing one  of  these applications  on their  system
        generally has the intent of using it to obtain/download images
        for their  own use.  Unfortunately, many  have the transparent
        side-effect of in turn  offering the obtained image for others
        to  access  via  the  student's  system.   Effectively,  users
        unknowingly  or unwittingly turn  their systems  into servers.
        The combined impact of  this, when you consider the popularity
        of  the applications and  the number  of systems  involved, is
        enormous  and  can   become  a  highly  detrimental  bandwidth
        consumer.   In  addition  to   the  effects  of  user  systems
        participating  as  servers,  the  reason the  application  was
        installed  on  the  user's  system  to  begin  with,  that  of
        obtaining files, should not be overlooked as a load source.

        You have likely picked up on the implication that this in some
        way  has   affected  the  FAS  Network.   This   would  be  an
        understatement,  particularly  over   the  past  few  days  --
        presumably in  reaction to court rulings in  the Napster case.
        The primary,  but not necessarily the  only, source generating
        the  issues are  the student  systems we  support.  Widespread
        reports of  similar problems exist at  other universities, but
        there is little solace in the fact that we are not alone.

        Fix The Problem!

        So what can we do  to address the problem?  Previously, we had
        installed  a  filter  on  the network  to  specifically  limit
        outgoing bandwidth directly linked to Napster.  Unfortunately,
        a decreasing number of these applications actually have easily
        identifiable signatures.  As such, with new applications being
        introduced  all  the  time,  surgical strikes  have  become  a
        never-ending  game of cat  and mouse  tying up  valuable staff

        Our best chance of success in combating the problem is to take
        a multipronged approach.  The general areas of focus are:

        o Education

        o Infrastructure Improvement

        o Traffic Control


        A very important aspect of the plan is that of education.  The
        majority of the user community are unaware of the implications
        of  many  of  their  actions  on  systems.   The  results,  as
        demonstrated here, are potentially disastrous for all.

        One step in this  direction is an upcoming anti-virus campaign
        designed  to  increase  the   use  of  updated  and  effective
        anti-virus  software  on campus.   We  also  need  to get  the
        message out  on how to  help keep the network  healthy through
        being  a  "Good  Network   Citizen."   :)  Although  there  is
        significant concern  about the unintentional  server bandwidth
        effects of  applications like  Napster, there is  also concern
        over  potential  abuses  in   obtaining  music.   If  you  are
        routinely using applications  like this to download everything
        you  can  get  your  hands  on,  chances  are  your  bandwidth
        consumption is quite high.  Consider the implications of a few
        dozen  others doing  it at  the same  time.  This  has  been a
        problem throughout this week, as  we have also seen quite high
        incoming bandwidth going to the student networks, particularly
        in the evening  hours.  One guess what the  majority of it is.
        Our  preference is to  address issues  of this  nature through
        education and  unintrusive methods, however,  traffic limiting
        and/or filtering may need to be considered as options.

        Equally  important is  that those  supporting the  systems and
        network keep  up to date  on the technology,  methodology, and
        experiences of other environments  similar to our own.  We are
        continually sharing information  with other universities about
        their experiences and are always open to new ideas.

        Infrastructure Improvements

        There are several areas that  we are working on to improve and
        enhance our  ability to  manage network resources.   Many have
        asked why we don't simply increase the link speeds and be done
        with  it.  In  response, we  must point  out again  that there
        currently  exists rapid  growth in  the area  of unintentional
        outbound bandwidth.  There are also improvements to be made in
        user community  network awareness.  We most  certainly need to
        be planning for  link improvements in the future,  and we are.
        However,  at  the  present  time  we  feel  that  focusing  on
        controlling traffic while working  in parallel on other fronts
        is the best course of action.

        We are  also exploring other quality of  service solutions and
        routing/switching technologies as  components of the plan.  In
        addition to  bandwidth limiting  and filtering we  are looking
        into traffic  classification and prioritization methodologies,
        adaptive application management, and other analysis tools.  We
        do not feel any of  these offer a "magic bullet" solution, but
        they  are  all  potential  contributing pieces  of  the  total

        Traffic Control

        We are unlikely  to implement bandwidth improvements requiring
        considerable investment of  tangible resources without further
        study, so short term benefits attributed to this are unlikely.
        Certainly education  will help, but that alone  will provide a
        complete  solution.  As  such, we  are looking  at  methods of
        controlling  and/or  eliminating  the  unintentional  outbound
        traffic  mentioned  earlier,   as  well  as  discouraging  the
        operation of individual high-bandwidth services.

        As a temporary  measure, we implemented bandwidth restrictions
        on  all  outgoing   non-Harvard-destined  bandwidth  from  the
        student networks on Tuesday evening of this week.  The effects
        of this change for non-student service has been very positive,
        and  all  indicators  point  to  significant  improvements  in
        response  time.  Unfortunately,  the same  cannot be  said for
        student  connectivity.  While response  times have  in general
        improved over levels before  the change, a number of protocols
        are   negatively  impacted.    In   addition,  the   bandwidth
        limitations are  imposed across the  board and are  not easily
        focused on unintentional or abusive traffic.

        The next step in traffic control is that of traffic filtering.
        Our goal  is to establish a  set of traffic rules  to place on
        the student  networks which would allow  all activity sourcing
        from the  user of  the system, yet  at the same  time disallow
        connection  attempts  from  external  systems  and  discourage
        high-bandwidth serving.  It is  hoped that this would not only
        resolve the  unintentional traffic issue,  but also go  a long
        way  towards improving  the  overall security  for systems  on
        these networks.

        Obviously,  there  are   concerns  about  this  approach,  and
        policies  regarding exceptions  would need  to  be established
        prior to  approving this approach and  developing a deployment
        timeline.  In addition, we  feel evaluating it in a production
        setting is  the best  way to identify  and resolve  issues and
        ensure  that nothing  is released  prematurely.   This testing
        phase  will commence  immediately, and  we will  be  holding a
        meeting this coming Tuesday,  February 20th, at 5PM in Science
        Center Lecture Hall D.  We encourage those students interested
        to  attend  and  assist   us  in  developing  a  solution  and
        facilitating its transparent implementation.

        In Closing

        We regret any inconvenience that you may have experienced, and
        would like to assure you all that we are working as rapidly as
        possible on solutions.  It is priority one.

                                           Bill Ouchark

                                           Senior Manager,
                                           Networking and Unix Systems
                                           FAS Computer Services

More information about the HCS-Announce mailing list