North American Network Operators Group

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

Re: Napster and others...

  • From: Scott McGrath
  • Date: Tue Mar 07 12:58:53 2000

One of the big problems from my standpoint is that I know of no well known
data port that I can queue for for web traffic from other than authorized sites
I use a low priority queue which during busy times drops packets but when the usage
is low all web traffic flows smoothly.

Another way would be to tag the Napster frames with QoS information so that
Napster usage could be controlled with QoS policies. I really DO NOT WANT
to prohibit access to Napster but I do NEED to deliver the critical services first
and "fill up the corners" with entertainment services which make our end-users
happy.

Michael Ridley wrote:

> What would be your suggestions on making Napster a more network
> friendly app?  Certainly it would be easier to queue it if it only used
> one port for client->client transfer, but the problem is that there's no
> way to know if that port would be in use.  Also, for people behind firewalls
> you need to tunnel in sometimes (of course, that works only a small
> portion of the time).  I don't know what the numbers look like, but it
> may be the case that just queueing up the default data port would
> catch some large percentage of the Napster file transfering.
>
> Anyway, if there are constructive suggestions, we're all ears.
>
> -Michael
>
> On Tue, Mar 07, 2000 at 11:48:25AM -0500, Scott McGrath wrote:
> --snip--
> > for which it is purchased for. If Napster and it's ilk were well written
> > applications
> > 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.
> >
> > Apologetically - Scott
> --snip--
>
> --
> Michael Ridley <[email protected]>