RE: Killing Napster and beyond...

[<agoldney () qantas com au>]

If you impose control on a flow that is TCP-friendly (ie, it conforms to
the TCP flow control) then using QoS on inbound flows still works.  The
sender will adjust its sending rate to match the size of the pipe it is
transmitting into.  Both Napster and Real Audio are TCP apps, so they can
be successfully shaped.  UDP has not flow control, so if the application
itself doesn't have that built into it then it will just keep hammerring
away irrespective of dropped traffic.  Very unfriendly.

Alex.




From: "Barry Dykes" <barry () onesec net>@nfr.com on 20/10/2000 10:01 EST

Sent by:  firewall-wizards-admin () nfr com


To:   "Zarcone, Christopher" <Christopher.Zarcone () netigy com>,
      <firewall-wizards () nfr net>
cc:
Subject:  RE: [fw-wiz] Killing Napster and beyond...


I think that you are missing something here.  QoS is a great concept, but
it
takes two parties to pull it off.  For instance, if you are setting QoS
outbound
you can control what gets sent out and it's priority.  However, inbound
gives
you no real control at all.  If your employees are pulling real-audio
feeds,
their outbound traffic is not your problem - it's what the real-audio
server is
sending to you! You cannot control that with an inbound policy on your
router.
Even if you drop all of the traffic, it has already consumed your T1 (the
same
way a DOS attack would).  Unless your ISP will cooperate with your QoS
scheme
(by configuring what you want on their outbound queues), you're wasting
your
time.  Queue management is an outbound issue from a device perspective.
You
can't drop a bit once it is "on the wire" - (with queuing).  So you must
drop it
before it gets "on the wire."

Barry

> -----Original Message-----
> From: firewall-wizards-admin () nfr com
> [mailto:firewall-wizards-admin () nfr com]On Behalf Of Zarcone, Christopher
> Sent: Thursday, October 19, 2000 3:07 PM
> To: firewall-wizards () nfr net
> Subject: RE: [fw-wiz] Killing Napster and beyond...
>
>
> All,
>
> Indeed, Napster and RealAudio are greedy applications in terms of
bandwidth,
> but there are a lot of creative solutions that don't involve blocking
ports.
> The simplest solution I can think of would be to enforce a
> Quality-Of-Service policy on your network.
>
> Cisco routers, for example, have a QOS feature called Custom Queueing,
where
> you can assign percentages of bandwidth to specific protocols and ports.
For
> example, you could restrict RealAudio to 20% of the total bandwidth. In
the
> presence of competing traffic, RealAudio traffic above the 20% threshhold
> would get queued (and ultimately dropped).
>
> Cisco also has another QOS feature called Priority Queueing, where
"higher"
> priority traffic ALWAYS takes precedence over "lower" priority traffic.
You
> can define multiple layers of prioirity, with your business application
> protocols at the highest priority, and RealAudio and Napster at the
bottom.
> Your business applications will effectively preempt any RealAudio
traffic.
> This can lead to certain protocols being "starved" in the presence of
high
> utilization, but in the case of RealAudio, that's probably what you want
> anyway.
>
> There is, of course, the notorious problem of applications tunneling over
> other protocols. (Let's see, can we think of any protocols that get
> ruthlessly exploited as a generic tunnel? Wait, let me think... could it
be
> HTTP? Bingo!) From the router's perspective, all you see is traffic on
TCP
> port 80. From a standpoint of QOS, the router won't be able to help you
> here. You might be better served by shunting all of your HTTP traffic
> through a really good proxy for more fine-grained traffic control.
>
> It's times like this where it makes sense to step back, take off your
> Firewall Hat, and put on your Router Hat (or your Proxy Hat or General
> Purpose Infrastructure Hat). There are a lot of ways to skin a cat.
>
> Regards,
>
> Christopher Zarcone, CISSP
> Senior Consultant
> christopher.zarcone () netigy com
>
> Netigy Corporation
> www.netigy.com
>
> My opinions do not necessarily represent the opinions of my employer. In
> fact, my opinions have no intelligent content whatsoever and should not
be
> considered by anyone.
>
> Message: 10
> From: "Harris, Tim" <tharris () ocair com>
> To: "'Chris Cappuccio'" <chris () empnet com>,
> Todd Schroeder <todd () stipples com>
> Cc: firewall-wizards () nfr com
> Subject: RE: [fw-wiz] Killing Napster and beyond...
> Date: Wed, 18 Oct 2000 16:05:04 -0700
> charset="iso-8859-1"
>
> The problem with Napster and similar programs (such as Real Audio) is
that
> some companies have relatively small pipes (I have a T1) for a large
number
> of users.  I care less that they are going to sites than that they are
> clogging up my precious bandwidth.  It takes very few people listening to
> Real Audio feeds before performance dies.  We are buying the bandwidth to
> facilitate business operations.  If they want to listen to music, they
> should buy a radio or a CD player.
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: firewall-wizards-unsubscribe () onesec net
> For additional commands, e-mail: firewall-wizards-help () onesec net


_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards




_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards