|
See may comments inline below.
----- Here is my take on the examples you gave below: [Joe] Generally in agreement however I have some concerns about using highest absolute priority for all routing traffic. My view is that a rate based scheduler (WFQ or WRR, etc.) with higher weight (like 3 x typical peak traffic) assigned may be a better option. So the question is why have we defined an option in the draft for a network administrator to have two service classes for network control traffic? Here are some of the reasons why having two service classes, one that uses absolute priority and the other that uses rate queuing be useful. Some operators have a requirement that telephony traffic have a path restoration time in hundreds of milliseconds from link or router failures. Their network is large and hieratical. They need to distribution of very precise network timing information (like stratum 3). etc. My suggestion is that network operators start with one class, but if they have determined the one is not sufficed we have defined the structure that allows them to have two.
EF for TDM-like services such as IP telephony, circuit em, and possibly (depending on your attitude) interactive video services. Engineered such that it is never oversubscribed under even the most extreme conditions. Yields low latency and jitter.
[Joe] In the core network or on high speed links (OC12 and above) for the above condition, I see no problem with aggregating telephony, circuit em and interactive video traffic into the same service class or queue. The issue arises on access, aggregation and many enterprise networks where links speeds are much lower, congestion is real and frequent. Therefore providing separation and different treatments between telephony and video services is needed. Voice packets are of small fixed size and are emitted at a constant rate whereas video packets are variable size and much bigger up to 1.5K bytes. Also video codec have the ability to change their encoding rate based on feedback from the network when congestion occurs whereas audio codec that are in use do not. Current human expectation of the service is also different, voice better be as good as the PSTN or it has limited usefulness. Therefore control of jitter and end-to-end delays for voice and video can be different. Y.1541 provide guidelines that telephony voice service should have end-to-end jitter of less then 50ms and one way delay including, codec processing times of less than 150ms. To achieve this type of performance, separation of telephony and video flows is need on lower speed links.
[Joe] OK, similar to Multimedia Streaming service class
with AF3x.
[Joe] Ok, similar to Low Latency Data service class and
the draft uses AF2x. BE for everything else - Best Effort internet services, etc. No distinction between "standard" and "low priority". This is both. BE is subject to complete blocking under extreme conditions, but these conditions should almost never occur with proper network engineering. In fact, the apps that use it should not even know when they are blocked even for several seconds, since they are totally elastic. Service providers will price and differentiate based on their performance on this class as well as the others. If someone is intense about blocking, they can pay to up their service to AF1 or even AF4.
[Joe] Agree for ISP solutions. Why do you need more? All services can be addressed using
these basic classes, plus policy-based tweaks on policers and shapers and
queuing systems (WFQ or CBQ). If a customer wants a better quality than is
"typical" of a particular service, they can pay to bump up a class
(except to the control class). CIR on EF and AF4 will not be oversubscribed.
The payback from excessive attention to detail in management is negligible at
best. Any problems that occur will be due to failure to properly engineer the
network bandwidth or access policies.
[Joe] What you are suggesting for carrier core network with high speed links and sufficed bandwidth is a reasonable approach. But what do you do in access networks, enterprise WANs, WLANs and service providers that have lower speed connectivity and congestion is real?
It looks like I need to add a section showing a different breakdown of applications into service classes for carrier core networks. I'm thinking of starting of with 4 classes: - A class for control - A class for real-time traffic (both elastic and inelastic) telephone, video conferencing, TV broadcast, etc. - A class with guaranteed CIR and low latency data traffic - And class for best effort traffic
Each class can be further subdivided if more service differentiation is need.
Comments? Regards, Joe. |