{\def {\bulletList \items}
  {{\if \items
     {\ul
      {\foreach \item \items
       {\li \item}
       }}}}}

{\def {\descList \items}
  {{\if \items 
     {\dl
      {\foreach \item \items
       {\dt {\em{\car \item}}}{\dd {\cdr \item}}
       }}}}}

{\def {\row \approach \advantages \disadvantages \examples}
  {\stripedRow {{\approach} {\bulletList \advantages} {\bulletList
  \disadvantages} {\descList \examples}}}}

{\page 
 \name={Campus Bandwidth Management: Approaches and Tradeoffs}
 \author={Ben Teitelbaum}
 \keywords={}
 \description={}
 \stylesheet={cbm-style.css}
 
 {\h1 Campus Bandwidth Management: Approaches and Tradeoffs}
 {\i This is a work in progress. }
 {\table \border=1 \cellpadding=5 \cellspacing=0 \width=100%
  \nonstandard={summary {Table showing...}}
  {\tr \bgcolor=\tableTitleBg \valign=top
   {\foreach \cell {{Approach} {Advantages} {Disadvantages} {Examples}}
    {\th \align=left {\font \color=\tableTitleFg \cell}}}}
  {\row {Do Nothing} 
        {Simple} 
        {Unfair 
	 Expensive
         {Mis-match between usage and cost recovery, especially severe
          if university is charged
          per-bit, but performs cost recovery by charging flat fees}  
         {Mission of university may be impeded by inappropriate use}} 
        {{Many {}}}}
  {\row {Per-IP Quotas (Rate-Based)} 
        {{Arguably "fair"}
         {Can tune quotas so that conforming traffic rarely experiences congestion}
         {No need for application-level classification}
	 {End-system portability is supported (since all ResHall IP
 addresses are policed identically)}}
        {{IP addresses become an artificially rare commodity (consider impact on IPv6)}
         {Additional router complexity}
         {May impede deployment of meritorious high-bandwidth
 applications (especially if limits apply to Internet2 traffic)}
	 {Inability to burst once in a while}}
        {{{U. Penn}
         {An overall rate limit is applied to outbound ResHall traffic.
          Additionally, rate-limiters (one per IP address) are
          installed on the edge router and applied only to outbound traffic. {\br}
          [{\a
        \href=http://www.internet2.edu/qos/wg/calendar/200205-Arlington/200205-kassabian.pdf
        talk}] [{\a
        \href=http://www.internet2.edu/qos/wg/calendar/200210-LA/200210-kassabian.pdf
        updated talk}]}}}}
  {\row {Per-IP Quotas (Volume-Based)} 
        {{Top talkers can be isolated by placing them in a penalty box}
         {Negative feedback loop encourages users to modify their own behavior}
         {No need for application-level classification}
	 {Ability to burst once in a while}}
        {{IP addresses become an artificially rare commodity (consider
         impact on IPv6)}
         {May impede deployment of meritorious high-bandwidth
         applications (especially if limits apply to Internet2 traffic)}
         {Additional router complexity}
         {Additional accounting complexity}
	 {Usage and penalty status need to be communicated quickly to
 average users}}
        {{{{\a \name=nodak}North Dakota State University} 
          {Quotas apply only to ResHall users. Quota is 300 MB per day
          per user.  Users who exceed their quota are placed in a
          shared pool rate-limited to 256kbps.{\br}[{\a
          \href=http://www.internet2.edu/qos/wg/calendar/200205-Arlington/200205-ross.pdf
          talk}] [{\a \href=http://www.ndsu.nodak.edu/resnet/
          ResNet}]}}
         {{{\a \name=waterloo}University of Waterloo}
          {Residence hall users subjected to per-user quotas of the
          form "{\em x} MB in last {\em y} days".  In addition the
          residence hall traffic aggregate is given a guaranteed
          minimum share of external bandwidth through CB-WFQ. {\br}
          [{\a \href=http://ist.uwaterloo.ca/cn/Residence/history.html
          more info}]}}
        {{Iowa State}
          {Residence hall users who exceed a specific level
          (currently 200 MB), are transferred to a "slower Internet
          connection".  As abuse continues, offending users are shifted
          to ever more restricted traffic classes.  User quotas are reset at the
          end of each day, except for those in the rate-limited
          classes, for whom a 24-hour moving average is applied to
          determine when they are returned to a less restrictive
          traffic class. {\br}
          [{\a \href=http://www.ait.iastate.edu/policy/residence.html more info}]}}
         {{Virginia Tech} {{\a \href=#vt see below}}}}}
  {\row {Per-Class Quotas (Rate-Based)}
        {{Can balance use among different user communities}
         {Can tune so that conforming or exempt classes rarely
        experience congestion}
         {Easy to implement (if not discriminating between commodity
        and Internet2 traffic)}
         {No need for application-level classification}}
        {{No fairness within classes}
         {May impede deployment of meritorious high-bandwidth
         applications (especially if limits apply to Internet2 traffic)}}
        {{{{\a \name=ucb}UC Berkeley} 
          {Packeteers in front of a campus edge router separately rate-limit
          commodity traffic to/from residence halls and to/from
          the rest of campus (ROC) traffic.  Two PacketShapers are
          required because the total bandwidth exceeds the 100 Mbps.
          Routing has been engineered to keep ResHall and ROC traffic
          separate. {\br}
          [{\a \href=http://www.internet2.edu/qos/wg/calendar/200201-Tempe/lindahl.pdf talk}]{\footnote Talk addenda (10/25/2002): ResHall rate limit is 60 Mbps in each direction and ROC rate limit is 100 Mbps in each direction; SETI@Home has purchased its own ISP service and is no longer in Berkeley's IP address space}}}
         {{{\a \name=vt}Virginia Tech}
          {Complex hybrid approach that primarily employs class-based
          policing, but also makes use of application-based policing
          and a penalty box scheme.  Off-campus traffic from residence hall subnets is  
          policed to 60 Mbps aggregate and off-campus traffic from the campus news server is
          policed to 5 Mbps.  "Nuisance applications" are policed to
          10 Mbps in aggregate (profiles are generated manually).  Finally, individual users are
          placed in one of three classes: Class 0 (unpoliced), Class 1
          (policed to 1.5 Mbps), and Class 3 (policed to 250 Kbps).
          When users exceed a certain threshold (currently 650 MB) in a
          24hr period, their class is incremented; if they stay under
          threshold, their class is decremented.  (The CB-WFQ scheme
          described in the talk below is not currently in use.) {\br} 
        [{\a
        \href=http://www.internet2.edu/qos/wg/calendar/200205-Arlington/200205-gaylord.pdf
        talk}]}}
         {{{\a \name=uw}University of Washington} 
          {Total network bandwidth from the residence halls to
           off-campus commodity destinations is limited to 100 Mbps.  Off-campus
           access to common server ports (Web, FTP, IRC, etc) in the
           residence halls is blocked.  Inbound peer-to-peer traffic is
           rate-limited to 20 Mbps; outbound peer-to-peer traffic is limited
           to 2 Mbps. {\br}
           [{\a \href=http://www.washington.edu/computing/rules/residencehall.html residence hall computing policy}]}}
         {{UC Santa Cruz} {\a \href=#ucsc see below}}}}
  {\row {Per-Class Proportional Sharing}
        {{Restricted traffic classes can use unused capacity}} 
        {{No fairness within classes}
         {May impede deployment of meritorious high-bandwidth
         applications (especially if limits apply to Internet2 traffic)}}
        {{{University of Waterloo} {Residence hall traffic is given a guaranteed
          minimum share of external bandwidth through CB-WFQ. ({\a
 \href=#waterloo see above})}}
	 {{Texas A&M} 
	  {Planning to support four application classes.  Per-session
	   admission to classes.  Diff-serv edge marking, policing, and
	   stateless core queueing.  (Currently using per-application
	   rate-limits.) {\br}
	   [{\a \href=http://www.internet2.edu/qos/wg/calendar/200210-LA/200210-marti.pdf talk}]}}}}
  {\row {Per-IP Proportional Sharing} 
        {{Arguably "fair"}
         {No surprises (users get the service they pay for)}
         {[{\a \href=http://www.internet2.edu/qos/wg/calendar/200205-Arlington/200205-stsauver.pdf additional praise}]}
         } 
        {{IP addresses become an artificially rare commodity (consider
         impact on IPv6)}
         {May impede deployment of meritorious high-bandwidth
         applications (especially if limits apply to Internet2 traffic)}
         {Additional router complexity}
         {Many queues required}
         {Care must be taken not to restrict Internet2 performance}}
        {{{No known deployment examples}{}}}}
  {\row {Usage-based Charges After Threshold} 
        {{Economically rational (users who get the most value from a
        scarce resource pay the most for it)} 
         Fair
         {Negative feedback loop for heavy users}
         {Can be tuned so that most users pay flat monthly rate;
          similar to pricing of department printers for students, of
          cell phones, etc.} 
         {[{\a \href=http://www.internet2.edu/qos/wg/calendar/200205-Arlington/200205-shalunov.pdf additional praise}]}}
        {{Additional accounting and billing complexity}
         {Need system to collect usage stats ({\i e.g.} NetFlow)}}
        {{{Cornell} 
          {Planning to charge each department a monthly fee that
        includes a WAN usage component.  Rate structure to include a mix
        of port fees, infrastructure tax, and usage fees.  Per-megabit
        usage fees will only kick in for use above a certain
        threshold (adjusted so that 80% of IP addresses will avoid
        usage fees).  Monthly
        bills to the departments will include enough detail to support
        recursive usage-based charges to individual users or research
        groups.  NetFlow-based billing system
        using Apogee software and home-brewed scripts. {\br}
        [{\a \href=http://www.cit.cornell.edu/oit/Arch-Init/netbilling/ white paper}] 
        [{\a \href=http://www.cit.cornell.edu/services/newnetrates/
 web site}]}}
	 {{University of Kansas}
	  {Applying artificially low usage based charge to ResHall
 users.  Only heavy users will feel the usage based fees; ordinary
 users will be charged a flat rate.}}}}
  {\row {Per-Application Quotas (Rate-Based)} 
        {{Majority of problems often caused by small number of
        applications}
         {Tool to reduce illegal use of network ({\i e.g.} illegal
        distribution of copyrighted materials)}
         {"Magic bullet" middlebox}
         {Automatic maintenance through "bad apps du jour"
        subscriptions}
         {[{\a \href=http://www.internet2.edu/qos/wg/calendar/200205-Arlington/200205-stsauver.pdf additional praise}]}
         } 
        {{Must pass judgment on which applications are "good" and
        which are "bad"}
         {Performance impact (QoS appliances are designed to handle a
          scare resource and therefore generally lag routers in their
          ability to handle high speeds or maintain very low loss
          rates for "good" traffic)}
         {Loss of transparency (e.g. rewriting of TCP window size)}
         {Complex and dynamic configurations complicate performance
        debugging}
         {Application profiling creates a cat and mouse game that the
        mouse will win ({\i e.g.} http, https, proxies, random port
        numbers, ssh, etc.)}
         {[{\a \href=http://www.internet2.edu/qos/wg/calendar/200205-Arlington/200205-shalunov.pdf additional criticism}]}} 
        {{{{\a \name=ucsc}UC Santa Cruz} 
          {Allot NetEnforcer deployed between ResNet and
           commodity/Internet2 access link.  Traffic is classified
           into four priority levels: High (web, ssh), Medium
           (everything except peer-to-peer), Low (peer-to-peer),
           Blocked (worms). {\br}
           {[{\a \href=http://www.internet2.edu/qos/wg/calendar/200201-Tempe/warner.pdf talk}]{\footnote Talk addendum (10/25/2002): UCSC has acquired a faster Allot box with more memory; they are still experiencing some problems with interactive performance.}}}}
         {{Virginia Tech} {{\a \href=#vt see above}}}
         {{University of Washington} {\a \href=#uw see above}}}}
  {\row {Outsource Residential Networking}
	{}
	{}
	{{{University of New Mexico} {}}}}
  {\row {Block Servers (with NAT or firewall)}
        {{Can apply only in "bad neighborhoods" ({\i e.g.} residence halls)}} 
        {{Destroying end-to-end transparency can restrict deployment of
        numerous advanced applications ({\i e.g.} VoIP,
        research-oriented peer-to-peer)}
         {Potentially sever performance impacts}
         {Motivated users will learn to punch through}}
        {{{We know you are out there!}{}}}}
\;  {\row {CBQ to Protect Real Time Flows} 
\;      {} 
\;      {} 
\;      {}}
  }
 {\hr}
 {\h2 Footnotes}
 {\footnotes}
 {\hr}
 {\colophon}
 }