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

["John H. Shuler" <[e-mail]>]

Joe,

Agree that there are different requirements in metro and backbone than
access. I would contend that the backbone may require even fewer than 5
(maybe 3), and that Access is still okay with 5. Interesting, though, that
ATM seems to have solved the problem even in Access using 4 service classes
(CBR, VBRrt, VBRnrt, and UBR). These are roughly equivalent to the four I
mapped below. Other classes (ABR) have not taken off for very good reasons.
Putting Control on its own class should not be a problem, because it should
make up a relatively trivial percent of the total bandwidth. If it doesn¹t,
then you are running the wrong protocols, or you have a network thrash (or
virus, or attack) going on that will toast your traffic anyway!

Stratum timing does NOT belong at Layer 3. Period. It belongs at the
physical layer. That gives you, effectively, your highest priority level
(0). SPs can always get Stratum timing off of GPS when they need it
end-to-end over long distances, and use time stamps within CES frames to tag
deviations.

Question is: what problem are you trying to solve?

If problem is to help Service Providers (SPs) reach common ground on how to
peer services between networks, then all the granularity you are defining is
interesting only in the realm of DIS-aggregating traffic that may come on a
big pipe to the destination SP.

Today, in access, voice and data are on separate pipes, non-sharable. Okay,
so when you converge these pipes, why not maintain a policy that says that
voice gets up to 1 Mbps CIR, but video can ³borrow² when available, and
everyone can share what¹s left? Since MM systems tend to be flexible in
terms of encoding rate, adapting dynamically to link speeds, this should not
be a serious problem. Worst case, again, is that if you have lots of phone
calls and video conferencing going on, you will have annoyed Internet users.
If this is a common problem, you either PIR your video, or you buy more
bandwidth. Problem solved.(?)

My whole point is: don¹t make more work for yourself or the network
providers. Keep it simple, and keep all realistic tools (engineering, queue
management, etc.) in mind when proposing the solution.

Perhaps a detailed (realistic) example, including an examination of options
and constraints, would help me understand why you feel the need for all
these classes and subclasses.

j


From: Jozef Babiarz <[e-mail]>
Date: Mon, 03 Nov 2003 16:02:02 -0500
To: "John H. Shuler" <[e-mail]>, Brian E Carpenter
<[e-mail]>
Cc: [e-mail]
Subject: RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01
.txt

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]