North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Is anyone actually USING IP QoS?
Howdy, > I'm particularly interested to know if the famed replacement > of ATM QoS features (basic stuff, like prioritization, > traffic policing and traffic shaping, sustained and peak > rates) has happened in a native IP network (ie POS or IP > over PtP circuits), particularly one that runs multiple > services (like some real-time stuff like voice, video, > streaming, and some non-real-time stuff). Yes. Most all IP networks run 'multiple services'. We run IP networks, we don't pay alot of attention to what's in the packets. In my network, I use NetMeeting for video and real-time collaboration, and several customers use our IP backbone for VOIP transit. Additionally, we do VOIP testing within engineering and with our telco brethren. The question is what levels of service, what different levels of service does the IP network offer. Today, so far as I know, no IP network offers different levels of service based on the customers choice. Soon, many will. See, it's not about setting different QOS on different traffic types. It's about setting relative or objective QOS on different services or products, in exchange for offering value or collecting revenue from the customer. > There have been a lot of announcements and rumors about this > kind of stuff (like Enron Communications PureIP network, > Convergent's fully-Cisco [possibly L3] network, Level3's > IP-only network, etc), Enron may be building a pure IP network, but Level3 is not running one at this time. Add to that list DIGEX, QWEST, WILLIAMS, FGC, and others... > The presentations I've seen about QoS implementations have > all seemed to contain major sections about how the networks > had to work around problems or scale back the implementation > because of resource limitations (CPU, memory, etc). Primarily CPU and Queue Management. > Haven't > seen anyone implement RSVP on a wide scale, Several have, but not for customer use, for backbone traffic engineering and end-point-pair constrained routing. > due to similar > types of problems. Sounds like QoS is marketing material, > not the stuff networks are built on. Is that still the case? I don't think so. We use TOS fields and WRED to implement early field trials of QOS. Set at entrance, arbitrate within network and at egress. We've used this to help solve many engineering problems, but not to sell different services to customers. You see, customers don't like knowing that there is congestion in the network. And lately w/ big pipes we haven't had much congestion, so there's very little 'lack of resources' to allocate to folks. Now, inter-provider QOS is a big deal, but it's going to a generation behind the VPN / backbone QOS introduction. > How the heck are people able to deploy native-IP networks > with these kinds of limitations/problems with QoS? Or did I > miss something about QoS recently? I think what most people miss here is the assumption that they will be able to dynamically construct source-destination paths with granular QOS. You won't have the tools to build your own private idaho on a minute by minute basis. IP networks are not about that, yet. Instead, what people can expect in the next 3-18 months are variable levels of service, wherein a user may subscribe to 1 of 8 QOS levels, or 4 QOS levels, with in-and-out of profile classes. So, the typical example we use is: Gold - premium Silver - high quality Bronze - best effort Latency - no delay To achieve Latency class, the routers must have multiple queues and be able to schedule between them. So, 'RT' [real time] applications are not readily available on most IP networks, unless the RT applications can tolerate some latency, which most can. To achieve G,S,B, you just need a relative prioritization, like WRED. Now, for more practical matters, the tools, and horsepower [cpu, ram] exist in some router vendor products to set TOS bits on entry, and arbitrate relative priority with WRED within the network. Yes, it takes big new cards [1 year old], but it absolutely can be done. Another issue that many folks look at is if you do an objective src-dest pair path with a given quality of service, or if you arbitrate based on the what is admitted to the communal network. Kind of the ATM v. FR debate. Which is used more today? And when folks use ATM, do they do anything nifty with it, or just run ABR, which is really fast FR. MPLS is a large component of this. Consider Frame Relay. Frame Relay does 3 simple things: * classifies traffic by DLCI/Source pairs * source-routes traffic through an abstracted path * marks and reacts to frames as in profile or out of profile [DE bit set]. With MPLS and TOS, we can mimic Frame Relay down to the wire. How long do you think it will be before IP networks are carrying Frame Relay PVCs? Or better yet, selling Frame Relay Like services over native IP using MPLS? But they don't yet. Because there's more to the game than just having the tools. Some bugs have to be worked out. Limitations have to be learned. Systems have to be built to support new paradigms. Marketing folks have to find ways to integrate the products into the existing pool. Sales and ops folks have to be educated. But that doesn't take too long :-) -alan