Firewall Wizards mailing list archives
RE: Killing Napster and beyond...
From: "Barry Dykes" <barry () onesec net>
Date: Mon, 23 Oct 2000 11:39:37 -0500
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 ofbandwidth,but there are a lot of creative solutions that don't involve blockingports.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,whereyou can assign percentages of bandwidth to specific protocols and ports.Forexample, you could restrict RealAudio to 20% of the total bandwidth. Inthepresence 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.Youcan define multiple layers of prioirity, with your business application protocols at the highest priority, and RealAudio and Napster at thebottom.Your business applications will effectively preempt any RealAudiotraffic.This can lead to certain protocols being "starved" in the presence ofhighutilization, 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 itbeHTTP? Bingo!) From the router's perspective, all you see is traffic onTCPport 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 notbeconsidered 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) isthatsome companies have relatively small pipes (I have a T1) for a largenumberof 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
Current thread:
- RE: Killing Napster and beyond..., (continued)
- RE: Killing Napster and beyond... David O'Shea (Oct 20)
- RE: Killing Napster and beyond... Henry Sieff (Oct 19)
- RE: Killing Napster and beyond... Dave Costello (Oct 20)
- RE: Killing Napster and beyond... Harris, Tim (Oct 20)
- RE: Reducing Napster and beyond... Jonn Martell (Oct 23)
- RE: Killing Napster and beyond... Delmer Harris (Oct 20)
- Re: Killing Napster and beyond... Vern Paxson (Oct 20)
- Re: Killing Napster and beyond... Brad Van Orden (Oct 20)
- RE: Killing Napster and beyond... jcintron (Oct 23)
- RE: Killing Napster and beyond... agoldney (Oct 24)
- RE: Killing Napster and beyond... Barry Dykes (Oct 24)
- RE: Killing Napster and beyond... agoldney (Oct 24)
- RE: Killing Napster and beyond... Graham, Randy (RAW) (Oct 24)