RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt

["Jozef Babiarz" <[e-mail]>]

See may comments inline below.

 

-----

Here is my take on the examples you gave below:

Total of 5 service classes, ever, for any service:
Control Class: Highest absolute priority. Never used for anything but
control. Period.



[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. 

 


AF4 for latency-sensitive (but not particularly jitter-sensitive) traffic
such as unidirectional audio-video streaming, TV broadcast, etc. Jitter is
buffered by end systems. Also available for people who want to pay through
the nose for transactional data service (banks may). Very conservatively
engineered w.r.t. CIR... Should never block.

 

[Joe] OK, similar to Multimedia Streaming service class with AF3x. 




AF1 for guaranteed CIR services with some (but not much) delay sensitivity,
such as SNA, VPN, etc. This class - even CIR - will typically be
oversubscribed, based on statistical analysis of network traffic. 

 

[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.

Please explain to me why I am wrong.

 

[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. 
Jozef Babiarz 
QoS and Network Architecture 
Nortel Networks 
email: [e-mail]