Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Napster and others...

  • From: John Kristoff
  • Date: Tue Mar 07 13:59:01 2000

Scott McGrath wrote:
> I could create custom queues for it and discard  when necessary like I do for non
> business related web traffic rather than my current heavy handed ACL's If anyone
> on the list has a alternate method I would appreciate hearing about it and my
> users would love me for giving them back access to Napster and other music sites.

I've been thinking and talking about this a lot with some of my peers in
the University environment the last couple of weeks.  Like yourself, I
am trying to come up with a fairness policy and implementation based on
technical limitations of IP and our network equipment.

Some of the most important thoughts/conclusions I have had are as
follows:

Avoid mucking with TCP and end-to-end transparency as much as possible. 
Let IP and RFC 2581 do its job.

Managing by UDP/TCP port is unreliable.  All it takes is for someone to
change configuration, find the next killer app or even more fun,
implement some type of "port hopping" mechanism.  I'm just waiting for
this to happen.

Using ToS fields *seems* to be the right approach to provide *some* of
what we want.  Coupled with something like WRED in our Cisco routers at
the our Internet border.  More sophisticated QoS mechanisms than that
seems to be an effort in futility.  KISS.  I'm thinking a simple low
priority, high priority ToS setting for packets that are either within
or outside of the local definition of fair.  For example, I like the
idea where all packets exceeding an average rate of X bps get tagged low
priority and dropped by WRED as necessary.  Be prepared to find that by
using ToS bits, you break something (see
http://micro.uoregon.edu/macintosh/mactcp.html).

You might be able to influence what comes into your network from the
outside through these mechanisms, but you can't control them.  You also
can't count on any service guarantees past your administrative control. 
A few more good reasons to avoid anything overly complex.

It is often easier and cheaper to just add bandwidth than trying to
tweak utilization and apply QoS throughout your network.

I'm having a hard time applying this fairness concept down to the user
port level, if anyone has any thoughts or feedback, I'd appreciate it if
you contact me (and also see my post in the unisog list).

John





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.