RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt
Dimitry Haskin <dhaskin@axiowave.com> Mon, 03 November 2003 16:15 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 LAA08663 for <diffserv-interest-archive@odin.ietf.org>; Mon, 3 Nov 2003 11:15:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGhM7-0006mF-4F for diffserv-interest-archive@odin.ietf.org; Mon, 03 Nov 2003 11:15:04 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3GF34H026047 for diffserv-interest-archive@odin.ietf.org; Mon, 3 Nov 2003 11:15:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGhM6-0006lc-2b; Mon, 03 Nov 2003 11:15:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGhLZ-0006l4-Ng for diffserv-interest@optimus.ietf.org; Mon, 03 Nov 2003 11:14:30 -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 LAA08638 for <diffserv-interest@ietf.org>; Mon, 3 Nov 2003 11:14:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGhLY-00008c-00 for diffserv-interest@ietf.org; Mon, 03 Nov 2003 11:14:28 -0500
Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1AGhLY-000087-00 for diffserv-interest@ietf.org; Mon, 03 Nov 2003 11:14:28 -0500
Message-ID: <EB5FFC72F183D411B38200062957342903FDD06E@r2d2.axiowave.com>
From: Dimitry Haskin <dhaskin@axiowave.com>
To: "'John H. Shuler'" <johnshuler@mac.com>, Jozef Babiarz <babiarz@nortelnetworks.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 11:12:12 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A225.3D7FC820"
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>
John, Since the jitter level is bound by latency, your AF4 service class seems to be incongruous and can be safely removed from the list. What would remain appears to be a reasonable grouping of services. Regards, Dimitry -----Original Message----- From: John H. Shuler [mailto:johnshuler@mac.com] Sent: Sunday, November 02, 2003 5:30 PM To: Jozef Babiarz; Brian E Carpenter Cc: diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt 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. 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. 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. 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. 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. 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. j _____ From: Jozef Babiarz <babiarz@nortelnetworks.com> Date: Sun, 02 Nov 2003 16:52:18 -0500 To: Brian E Carpenter <brc@zurich.ibm.com>, "John H. Shuler" <johnshuler@mac.com> Cc: diffserv-interest@ietf.org Subject: RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt Brian E Carpenter wrote: John, I guess your comment refers to the draft so I changed the subject. If you want to be sure the authors see your comments, you might want to write to them directly. My reactions inserted below. Brian "John H. Shuler" wrote: > > Why make a distinction between "Standard Service Class" and "Low Priority > Data"? There is a kitchen sink aspect to this draft that worries me. Rather than starting simple, with three or four generic service classes, the authors have chosen to present the union of a number of diffserv deployment models. I think that risks confusing operators by giving them too much complexity to choose from. [[Joe] The draft tries to address the service differentiation that is needed in carriers and enterprise networks including access networks. I agree that network administrators both in carrier and enterprise should start off with only the service differentiation level (service classes) that are required for their business. Let me provide some examples that I worked on so that you can understand why we have defined the number of service classes. Carriers wanted to use IP technology for provide telephony service, plus provide IP VPN service with CIR as well basic Internet connectivity service. This scenario can be address by configuring the network using the following service classes define in the draft. - Standard service class for Internet connectivity - High Throughput Data service class of IP VPN and collection of network data for billing - Telephony service class for VoIP and signaling between voice gateways - Network Control service classes for routing, etc. This simple example used four of the defined service classes. A different operator is deploying the services listed above plus new multimedia IP services like desktop video conferencing to go along with telephony, instant massaging plus other "workflow" applications. This operator needs: - Standard - High Throughput Data - Low Latency Data - Multimedia Conferencing - Telephony - Network Control Another operator has plans to offer broadcast TV service, pay-per-view, telephony, two different SLAs for IP VPN services and basic Internet connectivity. They will need: - Standard - High Throughput Data - Low Latency Data - Multimedia Streaming - Telephony - Network Control A large enterprise is currently configuring their network to support the flowing service classes (using the drafts terminology). Most location will have a subset of services available with migration to network wide service transparency in the future. - Standard - High Throughput Data - Low Latency Data - Multimedia Streaming - Multimedia Conferencing - Telephony - Network Control - Administration I can go through more scenarios that I have come across over the years. I agree that two or three user service classes is what many operators start off with, however they are not always the same three and they always like to know how they can evolve in the future.] Regards, Joe. Jozef Babiarz QoS and Network Architecture Nortel Networks email: babiarz@nortelnetworks.com Tel: (613) 763-6098 ESN:393-6098
- 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