On Thu, 15 Dec 2005, John Kristoff wrote:
On Thu, 15 Dec 2005 19:15:49 -0500 (EST) Sean Donelan <sean@donelan.com> wrote:
AT&T, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold QOS services for years. Level3 says 20% of the traffic over its
What do they mean by QoS? Is it IntServ, DiffServ, PVCs, the law of
I think also mostly this applies to private network things as well... which mostly ends up being: "backups get 20% of the pipe and oracle-forms gets 70%" (or some variation on that mix... what with 8 queues or whatever on the private network you can just go to town :) ) Speaking to MCI's offering on the public network it's (not sold much) just qos on the end link to the customer... It's supposed to help VOIP or other jitter prone things behave 'better'. I'm not sure that we do much in the way of qos towards the customer aside from respecting the bits on the packets that arrive (no remarking as I recall). So, what does this get you aside from 'feeling better' ?
averages or something else? I've had to deploy it on a campus network and in doing so it seems like I've tread into territory where few if any big networks are to be found. Nortel apparently removed DiffServ
most large networks (as was said a few times I think) don't really need it in their cores. I think I've seen a nice presentation regarding the queuing delay induced on 'large pipe' networks, basically showing that qos is pointless if your links are +ds3 and not 100% full. Someone might have a pointer handy for that?
capability for their "ISP customers" from one of their VoIP product offerings specifically because the customers didn't want it. My impression is that DiffServ is not used by those types of networks you mentioned, but I'd be interested to hear that I'm mistaken.
diffserv is the devil... and I think the voip product(s) in question aren't meant to be used in places where bandwidth is the constraint :) when you back that rack-sized (not kidding) PVG15000 up to your multi-oc-12 connection area you aren't really worried about bandwidth constraints. You may, however, want to heed the documentation provided which says to never, ever, ever connect the equipment to the public network... or not.
On the other hand, those same QOS tools are very useful to the network engineer for managing all sorts of network problems such as DOS attacks and disaster recovery as well as more efficiently using all the available network paths.
WRED comes to mind for this... sure. stop the sawtooth, make it smooth baby!
In my experience that is easier said than done. However, you remind me of what I think is what most who say they want QoS are really after. DoS protection. By focusing on DoS mitigation instead of trying to provide service differentiation, things begin to make more sense and actually become much more practical and deployable.
how does qos help with a dos attack? I've struggled with this several times internally, unless you remark everyone (in which case you'll be remarking good and bad and not getting any benefit) I'm not sure it does help... I'd be happy to be shown the error of my ways/thoughts though. Oh, and don't say: "Well we qos icmp down to stop the icmp flood damage, silly!" of course you do, and your attacker says: "Gee icmp isn't working, what about UDP? What about TCP? What about I make my bots make full tcp/80 connections?" Oh.. doh! no qos helps that eh? :( I could be wrong though.