CIT Wiki Home

From CIT Wiki

Bandwidth Management

The Internet connection for Oberlin College is provided by the Ohio Academic and Research Network, OARNet. We have two DS3s which we lease from Qwest, which provides us 80Mb/s usable combined intraOhio, Internet_2, and commodity Internet bandwidth. That sounds like a lot, until you divide by the number of users, which might be about half of us during busy times.

As applications have developed and demand grown, we've steadily increased our bandwidth purchased each year to try to keep pace. Our location in rural Lorain County has limited our options, as some types of circuits are simply not available and other carriers do not have a presence anywhere nearby. This situation keeps changing, and we're always looking for ways to increase our bandwidth within our budget. Until unlimited bandwidth becomes available cheaply, we will always need to manage what traffic we generate to keep things flowing smoothly.
If we were to let all traffic pass without management, there would be collisions and contention for passage through our connection to the rest of the world. Many applications would simply break, especially those sensitive to latency and jitter, like Skype and game play. But, as we've seen, even simple web browsing becomes painful or simply impossible in all the din. Once, our bandwidth manager was turned off for an afternoon. Note how outbound traffic rises to a maximum plateau and remains there. Traffic jam on the Information Superhighway!



Oberlin now uses a Procera Packetlogic to divide the bandwidth evenly and to prioritize different kinds of traffic as appropriate, so important work can get done without resorting to draconian measures. In times past, we used an application-by-application approach to manage each type of traffic passing our threshold. As peer-to-peer applications multiply and evolve, the limitations of this method became increasingly apparent. Herewith follows an explanation of our policies and strategy.

General Principles

There are three classes of traffic in general: Good, Bad, and Fragile. Our goal is to give the Fragile the helping hand they need to function, encourage the Good to share nicely on the network, and squelch and limit the Bad as much as we can to make the network experience as responsive as we can. We also prioritize traffic from academic resources located outside our network, whether services such as OhioLINK and Naxos Music Service, or Oberlin resources provided by contractors like Blackboard (Oberlin OnCampus).

We use the Packetlogic in part to track some of the unwanted traffic associated with viruses, so we can identify our infected systems and get them cleaned up. Some sites we block entirely, which we've identified as being involved in virus spreading and phishing emails. Others we don't block, but monitor for suspicious activity associated with infected machines on campus that might need some help and clean up.

While we do have a firewall to drop some of the bad traffic before it even gets onto our network, there are not a lot of ports being blocked arbitrarily. That's not the reason your game doesn't play properly, no matter what the game developers say! We've been able to make special provisions for several games in common use on campus, as well as some Ventrilo servers and the like, but for this we're limited by the information the game developers provide. Some have been quite helpful, others don't seem to want to provide us with their networking details, fearing perhaps we'll use the information to block game play altogether. We'll do what we can, but can make no promises your favorite games will work on our network. Caveat emptor--try before you buy, if at all possible. What do we need to make games on our network play well?

The Good, The Bad, and The Special

Bad traffic can be divided into two categories. We have a Gulag of applications that we don't want to enter our network at all, typically command and control traffic caused by trojan infections and zombie controllers. The less-bad traffic is that caused by peer-to-peer applications like KaZaA or BitTorrent serving files from on-campus users back out to the Internet. That's the traffic most likely to get one in trouble with the RIAA.

Then, we have the traffic that is generally good, but not usually able to make itself heard over the crowd of other voices on our network. This includes chat, AIM, Gaming, and video or telephony like Skype. These classes don't take much bandwidth, but need a protected portion of our bandwidth reserved for their use, and special rate or priority treatment to keep their connections from suffering latency or jitter.

• Inbound and Outbound, they're nearly symmetrical
  • Gulag -- These traffic classes need to be contained or kept out of circulation.
    • Code Red, Nimda, Spyware and Zombie controllers (Discard policies)
      • These are host lists, traffic types, and subnets we don't need to hear from.
  • La_La_LAN -- Violations of our acceptable use policy and severe bandwidth consumers when unchecked.
    • Peer-to-Peer applications, specifically servers on our campus sharing out to the world. This group shares a rather small bandwidth partition, some have other restrictive policies.
    • Copyright Violators. Those implicated in copyright violation by notice from the RIAA or other copyright holders are placed in a special class. Normal traffic is permitted to this class, but Peer-to-peer applications like Gnutella or BitTorrent are dropped.
  • LANada -- Official Oberlin College services hosted off-campus, such as Blackboard, the Common Ap, or Naxos. They're kind of just like us, only on the other side of the border ;-)
  • Munchkin_LAN -- Low-bandwidth applications easily lost in the noise of more-aggressive classes.
    • Chat
      • AIM, ICQ, MSN, Yahoo Messengers, SMS (File sharing is treated as P2P).
    • Gaming -- Each client gets up to 1Mb/s, managed for minimum latency. Appears to be sufficient.
      • All of the online games we or Packetlogic can identify easily, from Asheron's Call to XBox Live.
    • Telephony -- same shaping rules as gaming traffic.
      • CUSeeMe, Net2Phone, H.323 and T.120 applications, etc.
      • Skype, treated separately but also to minimize latency above all.
  • Play_LAN -- ResNet, wireless, and public lab computers, defined on IP ranges in use.
    • Filesharing has volume-based restrictions, so after the first 2GB downloaded today greedy clients will notice an appreciable drop in speed; BitTorrent and Gnutella are in there duking it out.
    • Default Resnet traffic uses dynamic partitioning; each IP address gets an equal share of up to 75% of our total bandwidth.
  • Promised_LAN -- These are the College's official servers and services. They have priority over everything.
  • Work_LAN -- Defined mostly by exclusion, this should be on-campus Faculty and Staff systems. A relatively small portion of bandwidth is reserved for these systems at all times, larger during the day and less after hours.