RE: Killing Napster and beyond...

[<agoldney () qantas com au>]

Yes,
           but if you use something like Class based queueing (CBQ) or any
one of the Hierarchical queing algorithms (HPFQ etc) then you can specify
limits on classes, and prioritise them.  It is then just up to your
classification system.  So, you could give guaranteed flow rates to certain
traffic, and give whats left (Best effort) to Real audio say.

Naturally, it's the classification that causes the problem, how do you
classify what is 'good' when it is all munged into port 80.  That's the
same problem you have if you actually want to just dump all that stuff at
the firewall, rather than give any of the corporate bandwidth away to
things that probably aren't corporate in nature :-).  The big problem with
classification is that the more complex it becomes (e.g. digging into http
to try and find out if the data is real audio/napster/evil hackers tunnel)
the more CPU you suck, and the more latency you add.

RED only lets someone who is not TCP-friendly eat up the released
bandwidth.  If everyone is TCP friendly, then a saturated link should end
up giving around about the same bandwidth to all parties.  Again, if people
don't use flow controlled traffic, then eventually the flow controlled
stuff is forced to nothing and the unfriendly stuff soaks up the entire
pipe.  Of course, RED is not designed to magically give you bandwidth, if
you have a permanently saturated link then you either need to upgrade the
link, or drop/shape the traffic that you don't want, which comes back to
classification again....

Oh well, we wouldn't be in IT if we didn't enjoy challenges :-)

Alex.





From: "Barry Dykes" <barry () onesec net> on 23/10/2000 11:39 EST

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


Yes, but flow control at the TCP layer will not limit the traffic on the T1
to
only "good" traffic nor can it ensure that the "good" traffic is preferred.
It's kind of like RED (random early detection) in that you slow down the
flows,
but someone else just eats up the released bandwidth - you end up with more
smaller flows and still with a full T1 usage.
     QoS on the link itself will make a more acceptable decision (on the
link) than
trying to manage each of the flows.  Only the T1 queues themselves can have
the
full picture of the current bandwidth!  But you are correct in what you say
about shrinking the window size.  And thanks for the comment.

Barry

> -----Original Message-----
> From: agoldney () qantas com au [mailto:agoldney () qantas com au]
> Sent: Sunday, October 22, 2000 7:51 PM
> To: Barry Dykes
> Cc: Zarcone, Christopher; firewall-wizards () nfr net
> Subject: RE: [fw-wiz] Killing Napster and beyond...
>
>
>
> 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