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 -- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008
On Mon, 8 Jul 2002, Stephen J. Wilcox wrote:
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
Cheers
Steve
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 On Mon, 8 Jul 2002, Stephen J. Wilcox wrote:
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
On Sun, 14 Jul 2002 00:46:31 +0100 (BST) "Stephen J. Wilcox" <steve@opaltelecom.co.uk> wrote:
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
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
On Mon, 8 Jul 2002, Stephen J. Wilcox wrote:
Hi all, I've been looking through the various qos/cos options available, my
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
particular 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
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. On Sun, 14 Jul 2002, Stephen J. Wilcox wrote:
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
On Mon, 8 Jul 2002, Stephen J. Wilcox wrote:
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
On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) Art Houle <houle@zeppo.acns.fsu.edu> wrote:
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
On Sun, 14 Jul 2002, Stephen J. Wilcox wrote:
Well, end of the week and the responses dried up pretty quickly, I think
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
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
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
On Mon, 8 Jul 2002, Stephen J. Wilcox wrote:
Hi all, I've been looking through the various qos/cos options available, my
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
dont just mean that they want the latest QoS because its the 'latest
thats a they are the particular this I 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
On Sun, 14 Jul 2002, Marshall Eubanks wrote:
On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) Art Houle <houle@zeppo.acns.fsu.edu> wrote:
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
On Sun, 14 Jul 2002, Stephen J. Wilcox wrote:
Well, end of the week and the responses dried up pretty quickly, I think
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
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
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
On Mon, 8 Jul 2002, Stephen J. Wilcox wrote:
Hi all, I've been looking through the various qos/cos options available, my
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
dont just mean that they want the latest QoS because its the 'latest
thats a they are the particular this I 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
--On Sunday, July 14, 2002 9:26 PM -0400 Art Houle <houle@zeppo.acns.fsu.edu> wrote:
On Sun, 14 Jul 2002, Marshall Eubanks wrote:
On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) Art Houle <houle@zeppo.acns.fsu.edu> wrote: 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.
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?
At 11:13 AM 7/15/2002 -0400, Art Houle wrote:
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.
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. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov
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. :)
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
participants (8)
-
Art Houle -
Bill Nickless -
Kurt Erik Lindqvist -
Marshall Eubanks -
Nathan Stratton -
Peter John Hill -
Randy Bush -
Stephen J. Wilcox