RE: QoS/CoS in the real world?
Kurtis, My apologies on the low SNR. The original question(s) centered around the customer requirements/applications/experience and I thought the product guys could speak to it better than I ... and certainly and without giving away any of our "patent pending processes". :) I think "native" can be translated as to mean "non-ATM". All core links are PPP/POS. MPLS does not imply or require DSCP, or vice versa. DSCP/EXP promotion ensures priority packets to be forwarded ahead of best effort at each hop thru the network. Could this be done other ways? Sure. The original question was how was/is this being done for customer traffic - this is how we do it in the core...along with queueing gymnastics. As for MPLS features, I think fast re-route qualifies. MPLS also provides traffic eng capabilities, as well as in-order packet delivery, which we've found to be useful for customer voice 'n video traffic. J -Original Message- From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 5:54 AM To: [EMAIL PROTECTED] Subject: RE: QoS/CoS in the real world? Appart from that this to me looks like a marketing post > Sorry I didn't see this note earlier, but wanted to make you aware > that Masergy Communications is actually offering such a service on a > native MPLS based IP network. We provide differentiated IP services > via "native MPLS based IP network" ? Native to what? > MPLS based IP network. We provide differentiated IP services via > customer DSCP marking at the network edge. QoS is supported end to end > through the Masergy core via promotion to the MPLS EXP marking. Uhm, I never figured out why we need MPLS to honor the DSCP markings. After reading further in the text it doesn't seem to me as if you are using any of the MPLS "features" either... Sorry - I couldn't resist... - kurtis -
RE: QoS/CoS in the real world?
Appart from that this to me looks like a marketing post > Sorry I didn't see this note earlier, but wanted to make you aware that > Masergy Communications is actually offering such a service on a native > MPLS based IP network. We provide differentiated IP services via "native MPLS based IP network" ? Native to what? > MPLS based IP network. We provide differentiated IP services via > customer DSCP marking at the network edge. QoS is supported end to end > through the Masergy core via promotion to the MPLS EXP marking. Uhm, I never figured out why we need MPLS to honor the DSCP markings. After reading further in the text it doesn't seem to me as if you are using any of the MPLS "features" either... Sorry - I couldn't resist... - kurtis -
RE: QoS/CoS in the real world?
Steve, Hope this info helps answer your questions about QoS, implementations and customers. Forwarded from a product person person in our org... Sorry I didn't see this note earlier, but wanted to make you aware that Masergy Communications is actually offering such a service on a native MPLS based IP network. We provide differentiated IP services via customer DSCP marking at the network edge. QoS is supported end to end through the Masergy core via promotion to the MPLS EXP marking. Masergy closely manages its network by service class. This allows each marking to have its own end-to-end SLA, customized to the type of customer traffic sent with each marking. Customers see the need for QoS in two broad categories: 1) Prioritizing business applications for performance reasons 2) Providing guaranteed performance to real-time IP applications such as IP voice and IP videoconferencing Some real examples: A Masergy customer does file backups overnight. When the backups continued into the next morning performance of daily business activities suffered. By lowering priority of the backup traffic, acceptable performance for both the backups and day users can be provided at a lower cost to the customer. Most of our customers have similar stories (the p2p example mentioned previously is another good one). An interesting application is that customers can mark all outbound traffic as priority--this is a simple config and requires little smarts on the part of the edge router. Any traffic that originates and terminates on the Masergy network is prioritized. All traffic from outside, non-business sites (i.e. surfing, p2p, radio etc.) gets best-effort treatment. Note that many of the applications that need priority are not high bandwidth--MS Exchange for example is a low BW app, but notoriously sensitive to network quality issues. QoS in the manner described above can enhance performance even for lower BW applications. Another customer application is video conferencing - specifically replacing current ISDN video architectures with IP equivalents. IP QoS and MPLS allow Masergy to engineer a class of service for voice and video that provides low jitter and 100% guaranteed throughput across our core. MPLS fast fail-over improves application performance in the case of a core network link or hardware failure. Without differentiated QoS, we would not be able to guarantee this level of performance. One of the major issues with properly utilizing QoS is giving the customer the ability to view and manage performance. Masergy customers use the Service Control Center - a secure, web-based interface for managing their service. It provides per QoS level and application statistics on network utilization and performance. Customers can change their access bandwidth and enable additional QoS capabilities in real time. http://www.masergy.com -- --- Jeff HancockP: 703-846-0161 Senior Engineer F: 703-846-0149 Masergy Communications, Inc.C: 2901 Telstar, Ct. E: mailto:[EMAIL PROTECTED] Falls Church, VA, 22042 W: http://www.masergy.com --- -Original Message- From: Stephen J. Wilcox [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 18, 2002 5:26 PM To: John Evans Cc: [EMAIL PROTECTED] Subject: RE: QoS/CoS in the real world? On Thu, 18 Jul 2002, John Evans wrote: > > I realise this is a US-centric list, however, a significant number of > providers in Europe have deployed Diffserv as a means of supporting > (and > selling) differential SLAs. Of these, some have deployed Diffsev at the > edge and some both the edge and core. See Clarence Filsfils presentation at > NANOG 25 for a description of typical core deployments. > > > 2. Hype aside, to what extent do customers actually want this > > Surely end customers want a service with SLAs that will support their > applications, and at low cost? It then becomes a provider cost > consideration as to whether these SLA assurances can most > competitively satisfied with mechanisms such as Diffserv or without. I have to say that the majority of users barely understand how their outlook client works let alone the difference between applications. I'm starting to think theres no demand for these services other than that which the hype says is there. THis is in line with what people said about using qos behind the scenes but customers dont know.. kind of what I thought to begin with STeve > > I conclude either the people doing this are successful and keep > > their secret safe
RE: QoS/CoS in the real world?
On Thu, 18 Jul 2002, John Evans wrote: > > I realise this is a US-centric list, however, a significant number of > providers in Europe have deployed Diffserv as a means of supporting (and > selling) differential SLAs. Of these, some have deployed Diffsev at the > edge and some both the edge and core. See Clarence Filsfils presentation at > NANOG 25 for a description of typical core deployments. > > > 2. Hype aside, to what extent do customers actually want this > > Surely end customers want a service with SLAs that will support their > applications, and at low cost? It then becomes a provider cost > consideration as to whether these SLA assurances can most competitively > satisfied with mechanisms such as Diffserv or without. I have to say that the majority of users barely understand how their outlook client works let alone the difference between applications. I'm starting to think theres no demand for these services other than that which the hype says is there. THis is in line with what people said about using qos behind the scenes but customers dont know.. kind of what I thought to begin with STeve > > 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. > > or perhaps they are just not on this list. > > cheers > > John > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > > Stephen J. Wilcox > > Sent: 14 July 2002 00:47 > > To: [EMAIL PROTECTED] > > Subject: Re: QoS/CoS in the real world? > > > > > > > > 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 > > > > > > > > > > > > > > > > > >
Re: QoS/CoS in the real world?
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 Nicklesshttp://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 [EMAIL PROTECTED]
Re: QoS/CoS in the real world?
> 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
Re: QoS/CoS in the real world?
On Mon, 15 Jul 2002, Peter John Hill wrote: > --On Sunday, July 14, 2002 9:26 PM -0400 Art Houle > <[EMAIL PROTECTED]> wrote: > > On Sun, 14 Jul 2002, Marshall Eubanks wrote: > > >> On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) > >> Art Houle <[EMAIL PROTECTED]> 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? > We look at ports mostly to mark the packets, but we are also using cisco 'pdlm' to discover the p2p stuff. We are not doing port filtering to drop packets, WFQ is doing the drop function. policy-map cbwfq2ISPonPVC class class-default random-detect dscp-based random-detect dscp 0 5 10 8 random-detect dscp 8 15 22 16 random-detect dscp 16 20 30 32 random-detect dscp 24 30 45 64 random-detect dscp 48 40 60 128 random-detect dscp 56 50 75 256 fair-queue fair-queue queue-limit 24 queue-limit 72 vc-class atm Sprint-ISP ubr 45000 encapsulation aal5snap interface ATM0/0/0.1 point-to-point pvc 0/106 class-vc Sprint-ISP service-policy out cbwfq2ISPonPVC >sho policy-map interface Class Random Tail Minimum Maximum Mark Output drop drop threshold threshold probability packets 06960177 19227320 510 1/8 962935241 8245 161522 1/16 47165439 16 0 02030 1/32 2754705 24 0 03045 1/64 18453509 48 0 04060 1/128 62112 56 0 05075 1/256 119861 fair-queue: per-flow queue limit 24 queue-limit 72 Art Houle e-mail: [EMAIL PROTECTED] Academic Computing & Network ServicesVoice: 850-644-2591 Florida State University FAX: 850-644-8722
Re: QoS/CoS in the real world?
> 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. :)
Re: QoS/CoS in the real world?
--On Sunday, July 14, 2002 9:26 PM -0400 Art Houle <[EMAIL PROTECTED]> wrote: > > On Sun, 14 Jul 2002, Marshall Eubanks wrote: >> On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) >> Art Houle <[EMAIL PROTECTED]> 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?
Re: QoS/CoS in the real world?
On Sun, 14 Jul 2002, Marshall Eubanks wrote: > > On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) > Art Houle <[EMAIL PROTECTED]> 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 > > 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: [EMAIL PROTECTED] > > Academic Computing & Network ServicesVoice: 850-644-2591 > > Florida State University FAX: 850-644-8722 > > > Art Houle e-mail: [EMAIL PROTECTED] Academic Computing & Network ServicesVoice: 850-644-2591 Florida State University FAX: 850-644-8722
Re: QoS/CoS in the real world?
On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) Art Houle <[EMAIL PROTECTED]> 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 > 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: [EMAIL PROTECTED] > Academic Computing & Network Services Voice: 850-644-2591 > Florida State University FAX: 850-644-8722 >
Re: QoS/CoS in the real world?
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: [EMAIL PROTECTED] Academic Computing & Network ServicesVoice: 850-644-2591 Florida State University FAX: 850-644-8722
Re: QoS/CoS in the real world?
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 On Sat, 13 Jul 2002, JC Dill wrote: > > On 04:46 PM 7/13/02, Stephen J. Wilcox wrote: > > >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. > > 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 > >
Real World Data: Re: QoS/CoS in the real world?
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.
Re: QoS/CoS in the real world?
On 04:46 PM 7/13/02, Stephen J. Wilcox wrote: >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. 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
Re: QoS/CoS in the real world?
On Sun, 14 Jul 2002 00:46:31 +0100 (BST) "Stephen J. Wilcox" <[EMAIL PROTECTED]> 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 > 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 > > > > > > > > > >
Re: QoS/CoS in the real world?
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 > >
Re: QoS/CoS in the real world?
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
