RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt
"Jozef Babiarz" <babiarz@nortelnetworks.com> Mon, 03 November 2003 21:03 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21361 for <diffserv-interest-archive@odin.ietf.org>; Mon, 3 Nov 2003 16:03:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGlqo-0006Rr-95 for diffserv-interest-archive@odin.ietf.org; Mon, 03 Nov 2003 16:03:03 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3L32FK024783 for diffserv-interest-archive@odin.ietf.org; Mon, 3 Nov 2003 16:03:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGlqn-0006Rc-H4; Mon, 03 Nov 2003 16:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGlqa-0006PL-PC for diffserv-interest@optimus.ietf.org; Mon, 03 Nov 2003 16:02:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21322 for <diffserv-interest@ietf.org>; Mon, 3 Nov 2003 16:02:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGlqZ-0004X9-00 for diffserv-interest@ietf.org; Mon, 03 Nov 2003 16:02:47 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AGlqY-0004Wk-00 for diffserv-interest@ietf.org; Mon, 03 Nov 2003 16:02:46 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA3L23515091; Mon, 3 Nov 2003 16:02:03 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <VRTPF1SP>; Mon, 3 Nov 2003 16:02:03 -0500
Message-ID: <E380A44D523BD5118EAE0002A52CE5C409507565@zcard0k8.ca.nortel.com>
From: Jozef Babiarz <babiarz@nortelnetworks.com>
To: "John H. Shuler" <johnshuler@mac.com>, Brian E Carpenter <brc@zurich.ibm.com>
Cc: diffserv-interest@ietf.org
Subject: RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt
Date: Mon, 03 Nov 2003 16:02:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A24D.BA94D184"
Sender: diffserv-interest-admin@ietf.org
Errors-To: diffserv-interest-admin@ietf.org
X-BeenThere: diffserv-interest@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv-interest>, <mailto:diffserv-interest-request@ietf.org?subject=unsubscribe>
List-Id: Differentiated services general discussion <diffserv-interest.ietf.org>
List-Post: <mailto:diffserv-interest@ietf.org>
List-Help: <mailto:diffserv-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv-interest>, <mailto:diffserv-interest-request@ietf.org?subject=subscribe>
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: babiarz@nortelnetworks.com
- RE: [Diffserv-interest] Re: draft-baker-diffserv-… Jozef Babiarz
- Re: [Diffserv-interest] Re: draft-baker-diffserv-… John H. Shuler
- RE: [Diffserv-interest] Re: draft-baker-diffserv-… Dimitry Haskin
- Re: [Diffserv-interest] Re: draft-baker-diffserv-… John H. Shuler
- RE: [Diffserv-interest] Re: draft-baker-diffserv-… Jozef Babiarz
- Re: [Diffserv-interest] Re: draft-baker-diffserv-… John H. Shuler