RE: [Diffserv-interest] Re: Diffserv service classes

"Jozef Babiarz" <babiarz@nortelnetworks.com> Sun, 02 November 2003 19:49 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 OAA23207 for <diffserv-interest-archive@odin.ietf.org>; Sun, 2 Nov 2003 14:49:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGODd-0002MC-To for diffserv-interest-archive@odin.ietf.org; Sun, 02 Nov 2003 14:49:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2Jn15v009050 for diffserv-interest-archive@odin.ietf.org; Sun, 2 Nov 2003 14:49:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGODc-0002LJ-R1; Sun, 02 Nov 2003 14:49:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGODB-0002KQ-SV for diffserv-interest@optimus.ietf.org; Sun, 02 Nov 2003 14:48:34 -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 OAA23162 for <diffserv-interest@ietf.org>; Sun, 2 Nov 2003 14:48:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGOD9-000258-00 for diffserv-interest@ietf.org; Sun, 02 Nov 2003 14:48:31 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGOD8-00024X-00 for diffserv-interest@ietf.org; Sun, 02 Nov 2003 14:48:30 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2JlqL02139; Sun, 2 Nov 2003 14:47:53 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <VRTP1R15>; Sun, 2 Nov 2003 14:47:52 -0500
Message-ID: <E380A44D523BD5118EAE0002A52CE5C40944D18E@zcard0k8.ca.nortel.com>
From: Jozef Babiarz <babiarz@nortelnetworks.com>
To: "John H. Shuler" <johnshuler@mac.com>, diffserv-interest@ietf.org
Subject: RE: [Diffserv-interest] Re: Diffserv service classes
Date: Sun, 02 Nov 2003 14:47:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A17A.2F2B26A8"
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 H. Shuler wrote:

Why make a distinction between "Standard Service Class" and "Low Priority
Data"?

[[Joe] Some enterprise network administrators may want to provide Low
Priority Data service (less than the Standard or best-effort) so that under
heavy traffic load they stop forwarding packets in the Low Priority Data
service classes until such time as the load in Standard and other classes is
reduced. However, I would not expect that ISPs would what to offer Low
Priority Data service.] 


In fact, it seems the most useful outcome of this paper is to help service
providers standardize across and between their networks as to service class
treatment for different service types. For this reason, it seems the best
thing to do is, rather than to create these semi-artificial classes and
sub-classes, to get quite specific about how to mark each specific service,
e.g. IP telephony, SNA, HTTP, FTP, unidirectional video, interactive
multimedia, etc.

[[Joe] The draft does define specific DSCP marking for a service/application
or a group of services/applications that have similar traffic
characteristics and performance requirements. In the draft, under each
service class, there are examples of services/applications and how they
should be marked. The reason why we use DSCP marking per service classes and
not per service/application is that there are potentially hundreds of
different services/applications that will use the network but we have
determined that only small number of different traffic forwarding behaviors
(service classes) is needed.]

You have gone part of the way to this goal, but have put
what seems to be an artificial middle step into the process... These service
classes. I can see why you would do this in an attempt to consolidate the
classes for ease of management, but by the time you are done, you have so
many classes and variations that you have defeated this purpose anyway. And
the net goal of standardizing treatment across the network is still not
achieved because of the multiple options for several of the services.

[[Joe] For carrier networks, we have determined that up to six different
service classes for user traffic is/will be need and one or two for network
administration and operation will be sufficient. For enterprise networks,
usually one service classes for network administration and operational usage
and up to six of seven for user traffic. This does not mean that every
network needs to support all the defined service classes, but only the ones
that they need to provide service differentiation for.

John, thanks for your comments.]

Regards, Joe.
Jozef Babiarz
QoS and Network Architecture
Nortel Networks
email: babiarz@nortelnetworks.com
Tel: (613) 763-6098 ESN:393-6098