The Qos PipeDream [Was: RE: Two Tiered Internet]

Fri Dec 16 03:29:29 UTC 2005

On Thu, 15 Dec 2005, John Kristoff wrote:

>
> On Thu, 15 Dec 2005 19:15:49 -0500 (EST)
> Sean Donelan <sean at 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.