Hi all,
I've been looking through the various qos/cos options available, my particular
area was in how IP (MPLS perhaps) compares and can be a substitute for ATM.
Well, theres lots of talk and hype out there, from simple IP queuing eg cisco
priority queuing, rsvp, diffserv, mpls traffic engineering etc
But two things are bugging me..
1. To what extent have providers implemented QoS for their customers
2. Hype aside, to what extent do customers actually want this (and by this I
dont just mean that they want the latest QoS because its the 'latest thing',
there has to be a genuine reason for them to want it). And this takes me back to
my ATM reference where there is a clear major market still out there of ATM
users and what would it take to migrate them to an IP solution?
Also, how are people implementing bandwidth on demand (dynamic allocation
controlled by the customer) solutions to customers
Cheers
Steve
Hi all,
I've been looking through the various qos/cos options available, my particular
area was in how IP (MPLS perhaps) compares and can be a substitute for ATM.
Well, theres lots of talk and hype out there, from simple IP queuing eg cisco
priority queuing, rsvp, diffserv, mpls traffic engineering etc
But two things are bugging me..
1. To what extent have providers implemented QoS for their customers
I was providing this as a service so my customers at Exario. We 2 G.726
VoIP channels and data over one PVC on a 192kbps DSL link. I developed
patent pending process to make that happen. Priority based queuing was
required for VoIP traffic, but because of starvation selected WFQ for the
3 data queues. The scheduler had to be smart enough to fill the space
between voice samples with fragmented data based on the MTU of the link so
as to keep jitter down.
2. Hype aside, to what extent do customers actually want this (and by this I
dont just mean that they want the latest QoS because its the 'latest thing',
there has to be a genuine reason for them to want it). And this takes me back to
my ATM reference where there is a clear major market still out there of ATM
users and what would it take to migrate them to an IP solution?
Well every customer that used voice had to have QoS if they also wanted
data, but we also were able to sell data QoS to customers. We could
prioritize credit card transactions, or bulk ftp transfers or any
application that wanted based on IP or port.
Also, how are people implementing bandwidth on demand (dynamic allocation
controlled by the customer) solutions to customers
Because my last mile aggregation was DSL or T1 everything was frame or ATM
based so I decided to stick with a ATM core. We setup PVCs on our ATM
switches based on what customers wanted and built back office systems to
change bandwidth based on customer requirements.
<>
Nathan Stratton
nathan at robotics.net
http://www.robotics.net
Well, end of the week and the responses dried up pretty quickly, I think thats a
response in itself to my question!
Okay, heres a summary which was requested by a few people:
Other people too are interested in my questions, they dont implement QoS in any
saleable manner and wonder how it can be done and whats actually required.
A number of people think QoS was interesting for a while but that its never
either found its true use or is dead.
There are unresolved questions from a customer point of view as to what they are
actually going to get, what difference it will make and how they can measure
their performance and the improvements from QoS.
There is a real demand for guaranteed bandwidth, however this tends to be in the
form of absolute guarantees rather than improvements above "normal" hence
ATM remaining a popular solution.
There is a requirement to differentiate voice traffic, however this is
necessarily done by the network anyway in order to offer the service, this being
the case the customer doesnt pay extra or gets to know much about how all the
fancy bits are done.
On the face of it this is all negative. Nobody has responded saying there are
genuine requirements for services to be offered to customers. Nor has anybody
responded with any descriptions of implementations.
I conclude either the people doing this are successful and keep their secret
safe or the world is yet to sell largescale QoS across IP.
Steve
Boy, this is what people are always telling me about multicast!
(Except I never hear about ATM being popular.)
And I've heard the same about IPv6.
Has the Internet really fallen into old age so rapidly ?
Regards
Marshall Eubanks
There's a world of difference between "sell" and "actually provide". IMHO, QoS is sold by many networks, but not actually provided (at the router). What IS provided is a system to give the QoS paying Customer credit if they A) notice they didn't get the quality of service their contract specified, and B) they request a credit.
jc
Sprint Labs has some data from the real world.
http://www.sprintlabs.com/Department/IP-Interworking/Monitor/
They are very careful researchers and don't make brash statements,
but my reading of their research is not much support for QOS in a
backbone. However, QOS may have a place on access links.
You are talking standard SLAs tho right? Guarantee 0.001% packet loss, RTT Xms
between points on your network.. etc.
I was interested in traffic engineering, ATM/Frame PVC style. RSVP, MPLS TE,
diffserv and all that good stuff, of which I had no responses of people using it
and selling them as services.
Steve
We are using QOS to preferentially drop packets that represent
file-sharing (kazaa, gnutella, etc). This saves us 40Mbps of traffic
across our multiple congested WAN links. The trick is to mark packets
meaningfully. Also, the WFQ introduces some additional latency at our
edge.
We are using QOS to preferentially drop packets that represent
file-sharing (kazaa, gnutella, etc). This saves us 40Mbps of traffic
across our multiple congested WAN links. The trick is to mark packets
meaningfully. Also, the WFQ introduces some additional latency at our
edge.
Is this different from port filtering as is commonly done with, e.g.,
gnutella ?
Or, to put it another way, how are the packets marked ? And why not just
drop them then and there, instead of later ?
Regards
Marshall Eubanks
>
>
> We are using QOS to preferentially drop packets that represent
> file-sharing (kazaa, gnutella, etc). This saves us 40Mbps of traffic
> across our multiple congested WAN links. The trick is to mark packets
> meaningfully. Also, the WFQ introduces some additional latency at our
> edge.
Is this different from port filtering as is commonly done with, e.g.,
gnutella ?
Or, to put it another way, how are the packets marked ? And why not just
drop them then and there, instead of later ?
If we are not using our WAN connections to capacity, then p2p traffic can
expand and fill the pipe, but if business packets are filling the pipes,
then the p2p stuff is throttled back. This makes 100% use of an expensive
resource.
Regards
Marshall Eubanks
>
>
> >
> > Well, end of the week and the responses dried up pretty quickly, I think
> thats a
> > response in itself to my question!
> >
> > Okay, heres a summary which was requested by a few people:
> >
> > Other people too are interested in my questions, they dont implement QoS in
> any
> > saleable manner and wonder how it can be done and whats actually required.
> >
> > A number of people think QoS was interesting for a while but that its never
> > either found its true use or is dead.
> >
> > There are unresolved questions from a customer point of view as to what
> they are
> > actually going to get, what difference it will make and how they can
> measure
> > their performance and the improvements from QoS.
> >
> > There is a real demand for guaranteed bandwidth, however this tends to be
> in the
> > form of absolute guarantees rather than improvements above "normal" hence
> > ATM remaining a popular solution.
> >
> > There is a requirement to differentiate voice traffic, however this is
> > necessarily done by the network anyway in order to offer the service, this
> being
> > the case the customer doesnt pay extra or gets to know much about how all
> the
> > fancy bits are done.
> >
> >
> > On the face of it this is all negative. Nobody has responded saying there
> are
> > genuine requirements for services to be offered to customers. Nor has
> anybody
> > responded with any descriptions of implementations.
> >
> > I conclude either the people doing this are successful and keep their
> secret
> > safe or the world is yet to sell largescale QoS across IP.
> >
> > Steve
> >
> >
> >
> > >
> > > Hi all,
> > > I've been looking through the various qos/cos options available, my
> particular
> > > area was in how IP (MPLS perhaps) compares and can be a substitute for
> ATM.
> > >
> > > Well, theres lots of talk and hype out there, from simple IP queuing eg
> cisco
> > > priority queuing, rsvp, diffserv, mpls traffic engineering etc
> > >
> > > But two things are bugging me..
> > >
> > > 1. To what extent have providers implemented QoS for their customers
> > >
> > > 2. Hype aside, to what extent do customers actually want this (and by
> this I
> > > dont just mean that they want the latest QoS because its the 'latest
> thing',
> > > there has to be a genuine reason for them to want it). And this takes me
> back to
> > > my ATM reference where there is a clear major market still out there of
> ATM
> > > users and what would it take to migrate them to an IP solution?
> > >
> > > Also, how are people implementing bandwidth on demand (dynamic allocation
> > > controlled by the customer) solutions to customers
> > >
> > > Cheers
> > >
> > > Steve
> > >
> > >
> >
> >
> >
> >
> >
> >
>
> Art Houle e-mail: houle@acns.fsu.edu.
> Academic Computing & Network Services Voice: 850-644-2591
> Florida State University FAX: 850-644-8722
>
Art Houle e-mail: houle@acns.fsu.edu.
Academic Computing & Network Services Voice: 850-644-2591
Florida State University FAX: 850-644-8722
A number of people think QoS was interesting for a while but that its
never either found its true use or is dead.
There are unresolved questions from a customer point of view as to what
they are actually going to get, what difference it will make and how they
can measure their performance and the improvements from QoS.
Having worked for a pretty large, now bankrupt, Netherlands based operator - where we where looking at QoS what we concluded was that
a) QoS mechanisms are for the local-tail. Backbones should have "enough" bandwidth (and bandwidth is cheap).
b) QoS was for customers with services like VoIP and VPN - and in most cases they where needed becuase the end users refused to buy the bandwidth they actually needed.
c) The QoS implementations in the vendor boxes at best leaves a lot to whish for and in most cases simply does not work (but to their credit they where really helpful in working with us on this).
- kurtis -
PS. Notice that I left out the M... word. 
So, you are doing straight tcp port filtering. Are there any clients that use dynamic ports? Things will get trickier for you. Other than Packetteer, are there any other products that can look into the data of a packet at any usable rate to do filtering/marking?
a) QoS mechanisms are for the local-tail. Backbones should have "enough"
bandwidth (and bandwidth is cheap).
b) QoS was for customers with services like VoIP and VPN - and in most
cases they where needed becuase the end users refused to buy the bandwidth
they actually needed.
c) The QoS implementations in the vendor boxes at best leaves a lot to
whish for and in most cases simply does not work (but to their credit they
where really helpful in working with us on this).
the ietf ieprep (emergency preparednes) wg is going to force you to put qos
in your backbone or not sell to the government(s) etc. it i svery hard to
push simplicity to those making money by inflating fear. you might be
concerned.
randy
That's exactly the right phrase: "We are using QOS to preferentially drop packets...."
When my research customers come to me wanting QoS, I can usually screen out the silly requests from the serious requests by asking "OK how can I tell which packets are less important and should be dropped?"
If they say "someone's packets other than mine" I nod and smile politely.
However, the Access Grid application runs both video and audio. The AG folks can very easily mark the packets for video and audio, and are quite happy to drop video packets in order to get the audio clear. AG users really truly want good audio at the expense of high quality video.
To this point we haven't actually implemented it, but it's a nice option to have in one's back pocket to pull out when it's really needed.