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

Mailman List Mirror (Read Only)
1

Hi Benson,

Okay -- forget about banks, forget about other comparative
analogies -- let's talk about the Internet.

I think Bill Manning hit on it a couple of days ago; Bill said
something about the Internet being about best effort and QoS
should be (various) levels of 'better-than-best effort' -- and
anything less that best effort is _not_ the Internet.

I completely agree with this, and I would also add that anything
less than best effort is not a QoS frob, it is penalization, no
matter what you want to call, and is a Bad Thing (tm).

I really don't want to get into a debate on service-level
semantics (e.g. WRED, etc.) but I think most reasonable people
can understand what I'm trying to illustrate. This thread has
gone one far enough as it stands. :slight_smile:

I think that the knobs are already 'out there' for service
providers, etc. to create real 'services', but to create arbitrary
services just to protect one's walled garden, and/or to generate
revenue (while also penalizing some customers) is something that
the market will have to sort out. It always does.

Vote with your dollar$.

Cheers,

- ferg

ps. Having looked at QoS issues from the inside-out, outside-in,
and various other persepctives, I do know a thing or two about it. :slight_smile:

2

I think Bill Manning hit on it a couple of days ago; Bill said
something about the Internet being about best effort and QoS
should be (various) levels of 'better-than-best effort' -- and
anything less that best effort is _not_ the Internet.

AT&T, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold
QOS services for years. Level3 says 20% of the traffic over its
backbone is "better than Best-Effort." Ok, maybe they aren't
"the Internet." Internet2 gave up on premium QOS and deployed
"less-than Best Effort" scavenger class. Ok, may they aren't
"the Internet" either.

I think that the knobs are already 'out there' for service
providers, etc. to create real 'services', but to create arbitrary
services just to protect one's walled garden, and/or to generate
revenue (while also penalizing some customers) is something that
the market will have to sort out. It always does.

Vote with your dollar$.

Ah, good to see that you agree with Bill Smith from BellSouth.

   William Smith, chief technology officer at BellSouth, argues that
   competitive forces, rather than regulation, are all that's needed to
   prevent the totalitarian online environment that the web camp fears.

   "We have no intention whatsoever of saying 'You can't go here, you
   can't go there, you can't go somewhere else'," Smith said. "We have a
   very competitive situation with cable. If we start trying to restrict
   where our customers can go on the internet, we would see our DSL
   customers defect to cable in droves."

   But, he added, "If I go to the airport, I can buy a coach standby
   ticket or I can buy a first class ticket from Delta. I've made a
   choice as to which experience I want."

But also realize all companies are acting in their own self-interest,
even the companies that have hire lobbyists claiming to be "saving
the Internet." The enemy of your enemy isn't always your friend.

I agree QOS as defined by marketeers isn't very useful. But that is a
strawman argument. Of course, I understand you think its just politics.

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.

I have no idea how all this will turn out or if there are some dark
smoke-filled rooms somewhere I don't know about where the henchmen are
plotting. But I would really hate to see the network engineer's hands
tied by a law preventing them from managing the network because of some
people spreading a lot of FUD. The news articles are filled with lots
of speculation about what "could" happen, but very few facts.

3

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
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
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.

backbone is "better than Best-Effort." Ok, maybe they aren't
"the Internet." Internet2 gave up on premium QOS and deployed
"less-than Best Effort" scavenger class. Ok, may they aren't
"the Internet" either.

Scavenger is not currently enabled on Abielene. In fact, no QoS
mechanisms are.

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.

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.

John

4

> 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 :slight_smile: )

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 :slight_smile:
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? :frowning: I could be wrong though.

5

My point is that it's not QoS, it's DoS mitigation. Whatever that
means to you, that is the solution I think most people may ultimately
be looking for when they say they want QoS.

John

6

ah-ha! and here I thought they wanted buzzword compliance :slight_smile: From what
sales/customers say it seems like they have a perception that 'qos will
let me use MORE of my too-small pipe' (or not spend as fast on more pipe)
more than anything else.

7

You might check slides 35-38 in

   http://www.1-4-5.net/~dmm/sprintlink_and_mpls.ppt

  Dave

8

Hello Dave;

This won't open for me.

Do you have a pdf of these slides ?

Regards;
Marshall

9

ah-ha! and here I thought they wanted buzzword compliance :slight_smile: From what
sales/customers say it seems like they have a perception that 'qos will
let me use MORE of my too-small pipe' (or not spend as fast on more pipe)
more than anything else.

and i wonder who is selling that need?

randy

10

those would be them.. and dave can grab just the 3 slides in pdf from:

http://www.secsup.org/files/dmm-queuing.pdf

(or of course anyone else can grab them, but it's dave presentation so :slight_smile:
)

-Chris

11

the wierd thing is you'd think the telco would just say: "Well gosh, sorry
we can't help you squeeze 10lbs of poo into your 5lb bag, wanna by a
shiney new 10lb bag?" or maybe you meant equipment vendors? :slight_smile:

12

Thanks Chris.

Dave

13

ah-ha! and here I thought they wanted buzzword compliance :slight_smile: From what
sales/customers say it seems like they have a perception that 'qos will
let me use MORE of my too-small pipe' (or not spend as fast on more pipe)
more than anything else.

and i wonder who is selling that need?

the wierd thing is you'd think the telco would just say: "Well gosh, sorry
we can't help you squeeze 10lbs of poo into your 5lb bag, wanna by a
shiney new 10lb bag?" or maybe you meant equipment vendors? :slight_smile:

bingo! buy more, and more complex, hardware and you can charge
more. what they forget to mention is that income will get blown
in opex and capex (with the vendors getting the latter).

randy

14

charge more you say?? I need to talk to our marketting dept!!! :slight_smile:

The world of marketting and sales is so incestuously intertwined among
consumers and consumee's ... it's an amazing thing.

15

oh firstgrad spelling where ahve you gone?

also at: http://www.secsup.org/files/dmm-queueing.pdf

incase you type not paste.

16

When you're running voip over a T1/E1, you really want to LLQ the VOIP packets because VOIP doesn't like delay (not so much a problem) nor jitter (big problem), nor packetloss (not so much a problem if it's less than a 0.1 percent or so).

So combining voip and data traffic on a link that sometimes (more often now when windows machine have a decent TCP window) go full, even just in a fraction of a second, means you either go QoS or do what Skype does, crank up the jitter buffer when there is high-jitter, which means latency for the call goes up.

So prioritizing packets in the access and core is good, for access because it's usually low-bandwidth and going to higher bw to remove congestion might mean factor 10 higher bw and a serious cost, in the core it's good to handle multiple faults, if the things that never should happen, you're not dropping your customers VOIP packets when the pipe is full that 0.1% of the time.

But, if you take the above model and start to always run your pipes full and use core packet prioritization as an everyday thing to support your lack of core bw, then you're in much bigger doo-doo.

17

>
> http://www.secsup.org/files/dmm-queuing.pdf
>

oh firstgrad spelling where ahve you gone?

also at: http://www.secsup.org/files/dmm-queueing.pdf

incase you type not paste.

Another interesting one is

"Provisioning IP Backbone Networks to Support Latency Sensitive Traffic"

From the abstract,

"To support latency sensitive traffic such as voice, network
providers can either use service differentiation to prioritize such traffic
or provision their network with enough bandwidth so that all traffic
meets the most stringent delay requirements. In the context of widearea
Internet backbones, two factors make overprovisioning an attractive
approach. First, the high link speeds and large volumes of traffic make
service differentiation complex and potentially costly to deploy. Second,
given the degree of aggregation and resulting traffic characteristics, the
amount of overprovisioning necessary may not be very large

...

We then develop a procedure which uses this model to find the amount of
bandwidth needed on each link in the network so that an end-to-end delay
requirement is satisfied. Applying this procedure to the Sprint network,
we find that satisfying end-to-end delay requirements as low as 3 ms
requires only 15% extra bandwidth above the average data rate of the
traffic."

18

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?

Here in London, we have noticed that the double-length
bendy buses have a harder time moving through city streets
than motor scooters do. I suspect that the studies you are
referring to show that the key factor is the ratio between
the size of pipe and the size of the flows moving through
that pipe.

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 :slight_smile:

A single VoIP call is a rather slim volume of packets compared
to many other uses of the Internet. If a network doesn't have
systemic jitter caused by layer 2 congestion, then one would
expect VoIP to work fine on a modern network. Indeed, that is
what Bill Woodcock reported a year or so ago in regard to
INOC-DBA.

--Michael Dillon

19

* Sean Donelan:

AT&T, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold
QOS services for years. Level3 says 20% of the traffic over its
backbone is "better than Best-Effort."

Well, are you sure these traffic classes are actually enforced at the
router level? Maybe it's just a difference in the SLA, and the
packets are still treated the same across the network.

Internet2 gave up on premium QOS and deployed "less-than Best
Effort" scavenger class.

I doubt that utilization on Abilene is high enough for QoS to make any
difference. :sunglasses:

20

Thus spake "Mikael Abrahamsson" <swmike@swm.pp.se>

ah-ha! and here I thought they wanted buzzword compliance :slight_smile: From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else.

When you're running voip over a T1/E1, you really want to LLQ the
VOIP packets because VOIP doesn't like delay (not so much a
problem) nor jitter (big problem), nor packetloss (not so much a
problem if it's less than a 0.1 percent or so).

There's two problems, actually. The first is serialization delay, and afflicts any link under about 3Mb/s regardless of utilization. Access speeds are finally climbing past this, but for links where they haven't you need something like MLPPP for fragmentation and interleaving.

The second is queueing delay, and that tends to only matter when average utilization passes 58% (someone with a stat background explained why, but my math isn't good enough to explain it). LLQ and WRED solve this well enough for end systems to cope with the result.

So combining voip and data traffic on a link that sometimes (more often now when windows machine have a decent TCP window) go full, even
just in a fraction of a second, means you either go QoS or do what
Skype does, crank up the jitter buffer when there is high-jitter, which
means latency for the call goes up.

Adaptive jitter buffers are old technology; Skype is hardly the first company to use them. Most phones and softphones have them; it's the gateways at the other end that are usually stuck with static ones.

S

Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking