From exim@www1.ietf.org  Sun Nov  2 14:49:20 2003
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, 2 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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3A17A.2F2B26A8
Content-Type: text/plain

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


------_=_NextPart_001_01C3A17A.2F2B26A8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Diffserv-interest] Re: Diffserv service classes</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John H. Shuler wrote:</FONT>
</P>

<P><FONT SIZE=3D2>Why make a distinction between &quot;Standard Service =
Class&quot; and &quot;Low Priority</FONT>
<BR><FONT SIZE=3D2>Data&quot;?</FONT>
</P>

<P><FONT SIZE=3D2>[[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.] =
</FONT></P>
<BR>

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

<P><FONT SIZE=3D2>[[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.]</FONT></P>

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

<P><FONT SIZE=3D2>[[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.</FONT></P>

<P><FONT SIZE=3D2>John, thanks for your comments.]</FONT>
</P>

<P><FONT SIZE=3D2>Regards, Joe.</FONT>
<BR><FONT SIZE=3D2>Jozef Babiarz</FONT>
<BR><FONT SIZE=3D2>QoS and Network Architecture</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>email: babiarz@nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2>Tel: (613) 763-6098 ESN:393-6098</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3A17A.2F2B26A8--

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Sun Nov  2 16:54:23 2003
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 QAA26629
	for <diffserv-interest-archive@odin.ietf.org>; Sun, 2 Nov 2003 16:54: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 1AGQAe-0006Ty-1W
	for diffserv-interest-archive@odin.ietf.org; Sun, 02 Nov 2003 16:54:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2Ls463024914
	for diffserv-interest-archive@odin.ietf.org; Sun, 2 Nov 2003 16:54:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGQAb-0006TN-9j; Sun, 02 Nov 2003 16:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGQ9j-0006SU-7m
	for diffserv-interest@optimus.ietf.org; Sun, 02 Nov 2003 16:53:07 -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 QAA26617
	for <diffserv-interest@ietf.org>; Sun, 2 Nov 2003 16:52:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGQ9h-0003DA-00
	for diffserv-interest@ietf.org; Sun, 02 Nov 2003 16:53:05 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGQ9g-0003C5-00
	for diffserv-interest@ietf.org; Sun, 02 Nov 2003 16:53:04 -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 hA2LqJM04696;
	Sun, 2 Nov 2003 16:52:19 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <VRTP1R46>; Sun, 2 Nov 2003 16:52:19 -0500
Message-ID: <E380A44D523BD5118EAE0002A52CE5C40944D19C@zcard0k8.ca.nortel.com>
From: "Jozef Babiarz" <babiarz@nortelnetworks.com>
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
Date: Sun, 2 Nov 2003 16:52:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A18B.95C970DE"
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3A18B.95C970DE
Content-Type: text/plain

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


------_=_NextPart_001_01C3A18B.95C970DE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Diffserv-interest] Re: =
draft-baker-diffserv-basic-classes-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Brian E Carpenter wrote:</FONT>
<BR><FONT SIZE=3D2>John, I guess your comment refers to the draft so I =
changed the subject.</FONT>
</P>

<P><FONT SIZE=3D2>If you want to be sure the authors see your comments, =
you might want to</FONT>
<BR><FONT SIZE=3D2>write to them directly. My reactions inserted =
below.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Brian</FONT>
</P>

<P><FONT SIZE=3D2>&quot;John H. Shuler&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Why make a distinction between &quot;Standard =
Service Class&quot; and &quot;Low Priority</FONT>
<BR><FONT SIZE=3D2>&gt; Data&quot;?</FONT>
</P>

<P><FONT SIZE=3D2>There is a kitchen sink aspect to this draft that =
worries me. Rather than</FONT>
<BR><FONT SIZE=3D2>starting simple, with three or four generic service =
classes, the authors</FONT>
<BR><FONT SIZE=3D2>have chosen to present the union of a number of =
diffserv deployment models.</FONT>
<BR><FONT SIZE=3D2>I think that risks confusing operators by giving =
them too much complexity</FONT>
<BR><FONT SIZE=3D2>to choose from.</FONT>
</P>

<P><FONT SIZE=3D2>[[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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>- Standard service class for Internet =
connectivity</FONT>
<BR><FONT SIZE=3D2>- High Throughput Data service class of IP VPN and =
collection of network data for billing</FONT>
<BR><FONT SIZE=3D2>- Telephony service class for VoIP and signaling =
between voice gateways</FONT>
<BR><FONT SIZE=3D2>- Network Control service classes for routing, =
etc.</FONT>
</P>

<P><FONT SIZE=3D2>This simple example used four of the defined service =
classes.</FONT>
</P>

<P><FONT SIZE=3D2>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 =
&quot;workflow&quot; applications.</FONT></P>

<P><FONT SIZE=3D2>This operator needs: </FONT>
<BR><FONT SIZE=3D2>- Standard </FONT>
<BR><FONT SIZE=3D2>- High Throughput Data </FONT>
<BR><FONT SIZE=3D2>- Low Latency Data </FONT>
<BR><FONT SIZE=3D2>- Multimedia Conferencing </FONT>
<BR><FONT SIZE=3D2>- Telephony </FONT>
<BR><FONT SIZE=3D2>- Network Control</FONT>
</P>

<P><FONT SIZE=3D2>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:</FONT></P>

<P><FONT SIZE=3D2>- Standard </FONT>
<BR><FONT SIZE=3D2>- High Throughput Data </FONT>
<BR><FONT SIZE=3D2>- Low Latency Data </FONT>
<BR><FONT SIZE=3D2>- Multimedia Streaming </FONT>
<BR><FONT SIZE=3D2>- Telephony </FONT>
<BR><FONT SIZE=3D2>- Network Control</FONT>
</P>

<P><FONT SIZE=3D2>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. =
</FONT></P>

<P><FONT SIZE=3D2>- Standard </FONT>
<BR><FONT SIZE=3D2>- High Throughput Data </FONT>
<BR><FONT SIZE=3D2>- Low Latency Data </FONT>
<BR><FONT SIZE=3D2>- Multimedia Streaming </FONT>
<BR><FONT SIZE=3D2>- Multimedia Conferencing</FONT>
<BR><FONT SIZE=3D2>- Telephony </FONT>
<BR><FONT SIZE=3D2>- Network Control</FONT>
<BR><FONT SIZE=3D2>- Administration</FONT>
</P>

<P><FONT SIZE=3D2>I can go through more scenarios that I have come =
across over the years. </FONT>
<BR><FONT SIZE=3D2>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.]</FONT></P>

<P><FONT SIZE=3D2>Regards, Joe.</FONT>
<BR><FONT SIZE=3D2>Jozef Babiarz</FONT>
<BR><FONT SIZE=3D2>QoS and Network Architecture</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>email: babiarz@nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2>Tel: (613) 763-6098 ESN:393-6098</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3A18B.95C970DE--

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Sun Nov  2 17:30:22 2003
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 RAA27376
	for <diffserv-interest-archive@odin.ietf.org>; Sun, 2 Nov 2003 17:30:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGQjT-0007nT-Rh
	for diffserv-interest-archive@odin.ietf.org; Sun, 02 Nov 2003 17:30:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2MU3IP029964
	for diffserv-interest-archive@odin.ietf.org; Sun, 2 Nov 2003 17:30:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGQjS-0007mS-E7; Sun, 02 Nov 2003 17:30:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGQjM-0007lX-1L
	for diffserv-interest@optimus.ietf.org; Sun, 02 Nov 2003 17:29:56 -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 RAA27348
	for <diffserv-interest@ietf.org>; Sun, 2 Nov 2003 17:29:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGQjJ-0003Zg-00
	for diffserv-interest@ietf.org; Sun, 02 Nov 2003 17:29:53 -0500
Received: from smtpout.mac.com ([17.250.248.88])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGQjI-0003Zd-00
	for diffserv-interest@ietf.org; Sun, 02 Nov 2003 17:29:52 -0500
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hA2MTqT7026049;
	Sun, 2 Nov 2003 14:29:52 -0800 (PST)
Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hA2MTpZq013705;
	Sun, 2 Nov 2003 14:29:52 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sun, 02 Nov 2003 14:29:49 -0800
Subject: Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01
	.txt
From: "John H. Shuler" <johnshuler@mac.com>
To: Jozef Babiarz <babiarz@nortelnetworks.com>,
        Brian E Carpenter <brc@zurich.ibm.com>
CC: <diffserv-interest@ietf.org>
Message-ID: <BBCAC55D.149C6%johnshuler@mac.com>
In-Reply-To: <E380A44D523BD5118EAE0002A52CE5C40944D19C@zcard0k8.ca.nortel.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3150628190_14152190"
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>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3150628190_14152190
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

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 =AD even CIR - will typically be
oversubscribed, based on statistical analysis of network traffic.

BE for everything else =8B Best Effort internet services, etc.  No distinctio=
n
between =B3standard=B2 and =B3low priority=B2. 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 =B3typical=
=B2
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=20

"John H. Shuler" wrote:
>=20
> Why make a distinction between "Standard Service Class" and "Low Priority
> Data"?=20

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.=20

[[Joe] The draft tries to address the service differentiation that is neede=
d
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=20
- 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=20
- High Throughput Data
- Low Latency Data=20
- Multimedia Conferencing
- Telephony=20
- Network Control=20

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=20
- High Throughput Data
- Low Latency Data=20
- Multimedia Streaming
- Telephony=20
- Network Control=20

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=20
- High Throughput Data
- Low Latency Data=20
- Multimedia Streaming
- Multimedia Conferencing
- Telephony=20
- Network Control=20
- Administration=20

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 t=
o
know how they can evolve in the future.]

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



--B_3150628190_14152190
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .t=
xt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>Here is my take on the =
examples you gave below:<BR>
<BR>
Total of 5 service classes, ever, for any service:<BR>
Control Class: Highest absolute priority. Never used for anything but contr=
ol. Period.<BR>
<BR>
EF for TDM-like services such as IP telephony, circuit em, and possibly (de=
pending on your attitude) interactive video services. Engineered such that i=
t is never oversubscribed under even the most extreme conditions. Yields low=
 latency and jitter.<BR>
<BR>
AF4 for latency-sensitive (but not particularly jitter-sensitive) traffic s=
uch as unidirectional audio-video streaming, TV broadcast, etc. Jitter is bu=
ffered by end systems. Also available for people who want to pay through the=
 nose for transactional data service (banks may). Very conservatively engine=
ered w.r.t. CIR... Should never block.<BR>
<BR>
AF1 for guaranteed CIR services with some (but not much) delay sensitivity,=
 such as SNA, VPN, etc. This class &#8211; even CIR - will typically be over=
subscribed, based on statistical analysis of network traffic. <BR>
<BR>
BE for everything else &#8212; Best Effort internet services, etc. &nbsp;No=
 distinction between &#8220;standard&#8221; and &#8220;low priority&#8221;. =
This is both. BE is subject to complete blocking under extreme conditions, b=
ut these conditions should almost never occur with proper network engineerin=
g. 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 wel=
l as the others. If someone is intense about blocking, they can pay to up th=
eir service to AF1 or even AF4.<BR>
<BR>
Why do you need more? All services can be addressed using these basic class=
es, plus policy-based tweaks on policers and shapers and queuing systems (WF=
Q or CBQ). If a customer wants a better quality than is &#8220;typical&#8221=
; of a particular service, they can pay to bump up a class (except to the co=
ntrol class). CIR on EF and AF4 will not be oversubscribed. The payback from=
 excessive attention to detail in management is negligible at best. Any prob=
lems that occur will be due to failure to properly engineer the network band=
width or access policies.<BR>
<BR>
Please explain to me why I am wrong.<BR>
<BR>
j<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><B>From: </B>Jozef Babiarz &lt;babiar=
z@nortelnetworks.com&gt;<BR>
<B>Date: </B>Sun, 02 Nov 2003 16:52:18 -0500<BR>
<B>To: </B>Brian E Carpenter &lt;brc@zurich.ibm.com&gt;, &quot;John H. Shul=
er&quot; &lt;johnshuler@mac.com&gt;<BR>
<B>Cc: </B>diffserv-interest@ietf.org<BR>
<B>Subject: </B>RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-clas=
ses-01 .txt<BR>
<BR>
Brian E Carpenter wrote: <BR>
John, I guess your comment refers to the draft so I changed the subject. <B=
R>
<BR>
If you want to be sure the authors see your comments, you might want to <BR=
>
write to them directly. My reactions inserted below. <BR>
<BR>
&nbsp;&nbsp;&nbsp;Brian <BR>
<BR>
&quot;John H. Shuler&quot; wrote: <BR>
&gt; <BR>
&gt; Why make a distinction between &quot;Standard Service Class&quot; and =
&quot;Low Priority <BR>
&gt; Data&quot;? <BR>
<BR>
There is a kitchen sink aspect to this draft that worries me. Rather than <=
BR>
starting simple, with three or four generic service classes, the authors <B=
R>
have chosen to present the union of a number of diffserv deployment models.=
 <BR>
I think that risks confusing operators by giving them too much complexity <=
BR>
to choose from. <BR>
<BR>
[[Joe] The draft tries to address the service differentiation that is neede=
d in carriers and enterprise networks including access networks. I agree tha=
t network administrators both in carrier and enterprise should start off wit=
h only the service differentiation level (service classes) that are required=
 for their business. Let me provide some examples that I worked on so that y=
ou can understand why we have defined the number of service classes.<BR>
<BR>
Carriers wanted to use IP technology for provide telephony service, plus pr=
ovide IP VPN service with CIR as well basic Internet connectivity service. T=
his scenario can be address by configuring the network using the following s=
ervice classes define in the draft.<BR>
<BR>
- Standard service class for Internet connectivity <BR>
- High Throughput Data service class of IP VPN and collection of network da=
ta for billing <BR>
- Telephony service class for VoIP and signaling between voice gateways <BR=
>
- Network Control service classes for routing, etc. <BR>
<BR>
This simple example used four of the defined service classes. <BR>
<BR>
A different operator is deploying the services listed above plus new multim=
edia IP services like desktop video conferencing to go along with telephony,=
 instant massaging plus other &quot;workflow&quot; applications.<BR>
<BR>
This operator needs: <BR>
- Standard <BR>
- High Throughput Data <BR>
- Low Latency Data <BR>
- Multimedia Conferencing <BR>
- Telephony <BR>
- Network Control <BR>
<BR>
Another operator has plans to offer broadcast TV service, pay-per-view, tel=
ephony, two different SLAs for IP VPN services and basic Internet connectivi=
ty. They will need:<BR>
<BR>
- Standard <BR>
- High Throughput Data <BR>
- Low Latency Data <BR>
- Multimedia Streaming <BR>
- Telephony <BR>
- Network Control <BR>
<BR>
A large enterprise is currently configuring their network to support the fl=
owing service classes (using the drafts terminology). Most location will hav=
e a subset of services available with migration to network wide service tran=
sparency in the future. <BR>
<BR>
- Standard <BR>
- High Throughput Data <BR>
- Low Latency Data <BR>
- Multimedia Streaming <BR>
- Multimedia Conferencing <BR>
- Telephony <BR>
- Network Control <BR>
- Administration <BR>
<BR>
I can go through more scenarios that I have come across over the years. <BR=
>
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 t=
o know how they can evolve in the future.]<BR>
<BR>
Regards, Joe. <BR>
Jozef Babiarz <BR>
QoS and Network Architecture <BR>
Nortel Networks <BR>
email: babiarz@nortelnetworks.com <BR>
Tel: (613) 763-6098 ESN:393-6098 <BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3150628190_14152190--


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov  3 11:15:24 2003
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, 3 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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3A225.3D7FC820
Content-Type: text/plain;
	charset="iso-8859-1"

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 




------_=_NextPart_001_01C3A225.3D7FC820
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt</TITLE>

<META content="MSHTML 6.00.2800.1126" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=845483915-03112003><FONT face=Arial color=#0000ff 
size=2>John,</FONT></SPAN></DIV>
<DIV><SPAN class=845483915-03112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=845483915-03112003><FONT face=Arial color=#0000ff size=2>Since 
the jitter level is bound by latency, your AF4 service class seems to be 
incongruous and can be safely removed from the list.&nbsp;What would 
remain&nbsp;appears to be a reasonable grouping of services.</FONT></SPAN></DIV>
<DIV><SPAN class=845483915-03112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=845483915-03112003><FONT face=Arial color=#0000ff 
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=845483915-03112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Dimitry</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John H. Shuler 
  [mailto:johnshuler@mac.com]<BR><B>Sent:</B> Sunday, November 02, 2003 5:30 
  PM<BR><B>To:</B> Jozef Babiarz; Brian E Carpenter<BR><B>Cc:</B> 
  diffserv-interest@ietf.org<BR><B>Subject:</B> Re: [Diffserv-interest] Re: 
  draft-baker-diffserv-basic-classes-01 .txt<BR><BR></FONT></DIV><FONT 
  face=Verdana><SPAN style="FONT-SIZE: 12px">Here is my take on the examples you 
  gave below:<BR><BR>Total of 5 service classes, ever, for any 
  service:<BR>Control Class: Highest absolute priority. Never used for anything 
  but control. Period.<BR><BR>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.<BR><BR>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.<BR><BR>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. <BR><BR>BE for everything else - Best Effort internet services, etc. 
  &nbsp;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.<BR><BR>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.<BR><BR>Please explain to me why I am 
  wrong.<BR><BR>j<BR>
  <HR align=center width="95%" SIZE=3>
  <B>From: </B>Jozef Babiarz &lt;babiarz@nortelnetworks.com&gt;<BR><B>Date: 
  </B>Sun, 02 Nov 2003 16:52:18 -0500<BR><B>To: </B>Brian E Carpenter 
  &lt;brc@zurich.ibm.com&gt;, "John H. Shuler" 
  &lt;johnshuler@mac.com&gt;<BR><B>Cc: 
  </B>diffserv-interest@ietf.org<BR><B>Subject: </B>RE: [Diffserv-interest] Re: 
  draft-baker-diffserv-basic-classes-01 .txt<BR><BR>Brian E Carpenter wrote: 
  <BR>John, I guess your comment refers to the draft so I changed the subject. 
  <BR><BR>If you want to be sure the authors see your comments, you might want 
  to <BR>write to them directly. My reactions inserted below. 
  <BR><BR>&nbsp;&nbsp;&nbsp;Brian <BR><BR>"John H. Shuler" wrote: <BR>&gt; 
  <BR>&gt; Why make a distinction between "Standard Service Class" and "Low 
  Priority <BR>&gt; Data"? <BR><BR>There is a kitchen sink aspect to this draft 
  that worries me. Rather than <BR>starting simple, with three or four generic 
  service classes, the authors <BR>have chosen to present the union of a number 
  of diffserv deployment models. <BR>I think that risks confusing operators by 
  giving them too much complexity <BR>to choose from. <BR><BR>[[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.<BR><BR>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.<BR><BR>- Standard service class for Internet connectivity 
  <BR>- High Throughput Data service class of IP VPN and collection of network 
  data for billing <BR>- Telephony service class for VoIP and signaling between 
  voice gateways <BR>- Network Control service classes for routing, etc. 
  <BR><BR>This simple example used four of the defined service classes. 
  <BR><BR>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.<BR><BR>This 
  operator needs: <BR>- Standard <BR>- High Throughput Data <BR>- Low Latency 
  Data <BR>- Multimedia Conferencing <BR>- Telephony <BR>- Network Control 
  <BR><BR>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:<BR><BR>- Standard <BR>- High Throughput 
  Data <BR>- Low Latency Data <BR>- Multimedia Streaming <BR>- Telephony <BR>- 
  Network Control <BR><BR>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. <BR><BR>- Standard <BR>- High 
  Throughput Data <BR>- Low Latency Data <BR>- Multimedia Streaming <BR>- 
  Multimedia Conferencing <BR>- Telephony <BR>- Network Control <BR>- 
  Administration <BR><BR>I can go through more scenarios that I have come across 
  over the years. <BR>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.]<BR><BR>Regards, 
  Joe. <BR>Jozef Babiarz <BR>QoS and Network Architecture <BR>Nortel Networks 
  <BR>email: babiarz@nortelnetworks.com <BR>Tel: (613) 763-6098 ESN:393-6098 
  <BR><BR></BLOCKQUOTE></SPAN></FONT></BODY></HTML>

------_=_NextPart_001_01C3A225.3D7FC820--

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov  3 13:28:24 2003
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 NAA13589
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 3 Nov 2003 13:28: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 1AGjQp-0005nk-0e
	for diffserv-interest-archive@odin.ietf.org; Mon, 03 Nov 2003 13:28:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3IS2cb022270
	for diffserv-interest-archive@odin.ietf.org; Mon, 3 Nov 2003 13:28:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGjQn-0005lv-UU; Mon, 03 Nov 2003 13:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGjQA-0005lJ-UB
	for diffserv-interest@optimus.ietf.org; Mon, 03 Nov 2003 13:27:23 -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 NAA13549
	for <diffserv-interest@ietf.org>; Mon, 3 Nov 2003 13:27:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGjQ8-000274-00
	for diffserv-interest@ietf.org; Mon, 03 Nov 2003 13:27:20 -0500
Received: from smtpout.mac.com ([17.250.248.88])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGjQ7-000271-00
	for diffserv-interest@ietf.org; Mon, 03 Nov 2003 13:27:19 -0500
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hA3IRET7024973;
	Mon, 3 Nov 2003 10:27:14 -0800 (PST)
Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hA3IQuZq010865;
	Mon, 3 Nov 2003 10:27:14 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 03 Nov 2003 10:26:55 -0800
Subject: Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01
	 .txt
From: "John H. Shuler" <johnshuler@mac.com>
To: Dimitry Haskin <dhaskin@axiowave.com>,
        Jozef Babiarz <babiarz@nortelnetworks.com>,
        Brian E Carpenter <brc@zurich.ibm.com>
CC: <diffserv-interest@ietf.org>
Message-ID: <BBCBDDEF.149D1%johnshuler@mac.com>
In-Reply-To: <EB5FFC72F183D411B38200062957342903FDD06E@r2d2.axiowave.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3150700016_14584362"
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>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3150700016_14584362
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Dimitry,

You are right that AF4 could be removed, given very careful engineering and
management and a few other assumptions. I leave it in because it actually
simplifies operations to have it.

There is a balance that must be struck between the cost of equipment,
facilities, and management. It is technically possible to throw massive
amounts of any of these at the problem and get a workable result. However,
the cost-benefit curves for each is non-linear. More classes is better, up
to a point, because it reduces the bandwidth and engineering requirement.
Then it is worse, mostly because it increases the equipment and management
cost. You seem to feel that 4 is the magic number. Even though I subscribe
to the KISS principle, I feel more comfortable with 5. Most of the really
smart people I know are comfortable in the range of 3-7 total classes. The
point is, it is not 16, or 32...

One consideration is that having more classes seems to work better in
bandwidth-constrained environments such as are found in the access network,
whereas you can get away with murder in the NxOC192 backbone. All for very
well-known queuing theory reasons.

j


From: Dimitry Haskin <dhaskin@axiowave.com>
Date: Mon, 03 Nov 2003 11:12:12 -0500
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

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
> 



--B_3150700016_14584362
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 &n=
bsp;.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>Dimitry,<BR>
<BR>
You are right that AF4 could be removed, given very careful engineering and=
 management and a few other assumptions. I leave it in because it actually s=
implifies operations to have it.<BR>
<BR>
There is a balance that must be struck between the cost of equipment, facil=
ities, and management. It is technically possible to throw massive amounts o=
f any of these at the problem and get a workable result. However, the cost-b=
enefit curves for each is non-linear. More classes is better, up to a point,=
 because it reduces the bandwidth and engineering requirement. Then it is wo=
rse, mostly because it increases the equipment and management cost. You seem=
 to feel that 4 is the magic number. Even though I subscribe to the KISS pri=
nciple, I feel more comfortable with 5. Most of the really smart people I kn=
ow are comfortable in the range of 3-7 total classes. The point is, it is no=
t 16, or 32...<BR>
<BR>
One consideration is that having more classes seems to work better in bandw=
idth-constrained environments such as are found in the access network, where=
as you can get away with murder in the NxOC192 backbone. All for very well-k=
nown queuing theory reasons.<BR>
<BR>
j<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><B>From: </B>Dimitry Haskin &lt;dhask=
in@axiowave.com&gt;<BR>
<B>Date: </B>Mon, 03 Nov 2003 11:12:12 -0500<BR>
<B>To: </B>&quot;'John H. Shuler'&quot; &lt;johnshuler@mac.com&gt;, Jozef B=
abiarz &lt;babiarz@nortelnetworks.com&gt;, Brian E Carpenter &lt;brc@zurich.=
ibm.com&gt;<BR>
<B>Cc: </B>diffserv-interest@ietf.org<BR>
<B>Subject: </B>RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-clas=
ses-01 &nbsp;.txt<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12.0px'><FONT COLOR=3D"#0000FF"><FONT FA=
CE=3D"Arial">John,<BR>
</FONT></FONT><FONT FACE=3D"Verdana"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">Since the jitter level is b=
ound by latency, your AF4 service class seems to be incongruous and can be s=
afely removed from the list. What would remain appears to be a reasonable gr=
ouping of services.<BR>
</FONT></FONT><FONT FACE=3D"Verdana"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">Regards,<BR>
&nbsp;&nbsp;Dimitry<BR>
</FONT></FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D=
"Verdana"> <BR>
</FONT><FONT FACE=3D"Tahoma">-----Original Message-----<BR>
<B>From:</B> John H. Shuler &nbsp;[<a href=3D"mailto:johnshuler@mac.com]">mai=
lto:johnshuler@mac.com]</a><BR>
<B>Sent:</B> Sunday, November 02, 2003 5:30 &nbsp;PM<BR>
<B>To:</B> Jozef Babiarz; Brian E Carpenter<BR>
<B>Cc:</B> &nbsp;diffserv-interest@ietf.org<BR>
<B>Subject:</B> Re: [Diffserv-interest] Re: &nbsp;draft-baker-diffserv-basi=
c-classes-01 .txt<BR>
<BR>
</FONT><FONT FACE=3D"Verdana">Here is my take on the examples you &nbsp;gave =
below:<BR>
<BR>
Total of 5 service classes, ever, for any &nbsp;service:<BR>
Control Class: Highest absolute priority. Never used for anything &nbsp;but=
 control. Period.<BR>
<BR>
EF for TDM-like services such as IP telephony, &nbsp;circuit em, and possib=
ly (depending on your attitude) interactive video &nbsp;services. Engineered=
 such that it is never oversubscribed under even the most &nbsp;extreme cond=
itions. Yields low latency and jitter.<BR>
<BR>
AF4 for &nbsp;latency-sensitive (but not particularly jitter-sensitive) tra=
ffic such as &nbsp;unidirectional audio-video streaming, TV broadcast, etc. =
Jitter is buffered by &nbsp;end systems. Also available for people who want =
to pay through the nose for &nbsp;transactional data service (banks may). Ve=
ry conservatively engineered w.r.t. &nbsp;CIR... Should never block.<BR>
<BR>
AF1 for guaranteed CIR services with some &nbsp;(but not much) delay sensit=
ivity, such as SNA, VPN, etc. This class - even CIR &nbsp;- will typically b=
e oversubscribed, based on statistical analysis of network &nbsp;traffic. <B=
R>
<BR>
BE for everything else - Best Effort internet services, etc. &nbsp;&nbsp;No=
 distinction between &quot;standard&quot; and &quot;low priority&quot;. This=
 is both. BE &nbsp;is subject to complete blocking under extreme conditions,=
 but these conditions &nbsp;should almost never occur with proper network en=
gineering. In fact, the apps &nbsp;that use it should not even know when the=
y are blocked even for several &nbsp;seconds, since they are totally elastic=
. Service providers will price and &nbsp;differentiate based on their perfor=
mance on this class as well as the others. &nbsp;If someone is intense about=
 blocking, they can pay to up their service to AF1 &nbsp;or even AF4.<BR>
<BR>
Why do you need more? All services can be addressed using &nbsp;these basic=
 classes, plus policy-based tweaks on policers and shapers and &nbsp;queuing=
 systems (WFQ or CBQ). If a customer wants a better quality than is &nbsp;&q=
uot;typical&quot; of a particular service, they can pay to bump up a class (=
except to &nbsp;the control class). CIR on EF and AF4 will not be oversubscr=
ibed. The payback &nbsp;from excessive attention to detail in management is =
negligible at best. Any &nbsp;problems that occur will be due to failure to =
properly engineer the network &nbsp;bandwidth or access policies.<BR>
<BR>
Please explain to me why I am &nbsp;wrong.<BR>
<BR>
j<BR>
&nbsp;<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"> <B>From: </B>Jozef Babiarz &lt;babia=
rz@nortelnetworks.com&gt;<BR>
<B>Date: &nbsp;</B>Sun, 02 Nov 2003 16:52:18 -0500<BR>
<B>To: </B>Brian E Carpenter &nbsp;&lt;brc@zurich.ibm.com&gt;, &quot;John H=
. Shuler&quot; &nbsp;&lt;johnshuler@mac.com&gt;<BR>
<B>Cc: &nbsp;</B>diffserv-interest@ietf.org<BR>
<B>Subject: </B>RE: [Diffserv-interest] Re: &nbsp;draft-baker-diffserv-basi=
c-classes-01 .txt<BR>
<BR>
Brian E Carpenter wrote: &nbsp;<BR>
John, I guess your comment refers to the draft so I changed the subject. &n=
bsp;<BR>
<BR>
If you want to be sure the authors see your comments, you might want &nbsp;=
to <BR>
write to them directly. My reactions inserted below. &nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;Brian <BR>
<BR>
&quot;John H. Shuler&quot; wrote: <BR>
&gt; &nbsp;<BR>
&gt; Why make a distinction between &quot;Standard Service Class&quot; and =
&quot;Low &nbsp;Priority <BR>
&gt; Data&quot;? <BR>
<BR>
There is a kitchen sink aspect to this draft &nbsp;that worries me. Rather =
than <BR>
starting simple, with three or four generic &nbsp;service classes, the auth=
ors <BR>
have chosen to present the union of a number &nbsp;of diffserv deployment m=
odels. <BR>
I think that risks confusing operators by &nbsp;giving them too much comple=
xity <BR>
to choose from. <BR>
<BR>
[[Joe] The draft &nbsp;tries to address the service differentiation that is=
 needed in carriers and &nbsp;enterprise networks including access networks.=
 I agree that network &nbsp;administrators both in carrier and enterprise sh=
ould start off with only the &nbsp;service differentiation level (service cl=
asses) that are required for their &nbsp;business. Let me provide some examp=
les that I worked on so that you can &nbsp;understand why we have defined th=
e number of service classes.<BR>
<BR>
Carriers &nbsp;wanted to use IP technology for provide telephony service, p=
lus provide IP VPN &nbsp;service with CIR as well basic Internet connectivit=
y service. This scenario &nbsp;can be address by configuring the network usi=
ng the following service classes &nbsp;define in the draft.<BR>
<BR>
- Standard service class for Internet connectivity &nbsp;<BR>
- High Throughput Data service class of IP VPN and collection of network &n=
bsp;data for billing <BR>
- Telephony service class for VoIP and signaling between &nbsp;voice gatewa=
ys <BR>
- Network Control service classes for routing, etc. &nbsp;<BR>
<BR>
This simple example used four of the defined service classes. &nbsp;<BR>
<BR>
A different operator is deploying the services listed above plus new &nbsp;=
multimedia IP services like desktop video conferencing to go along with &nbs=
p;telephony, instant massaging plus other &quot;workflow&quot; applications.=
<BR>
<BR>
This &nbsp;operator needs: <BR>
- Standard <BR>
- High Throughput Data <BR>
- Low Latency &nbsp;Data <BR>
- Multimedia Conferencing <BR>
- Telephony <BR>
- Network Control &nbsp;<BR>
<BR>
Another operator has plans to offer broadcast TV service, &nbsp;pay-per-vie=
w, telephony, two different SLAs for IP VPN services and basic &nbsp;Interne=
t connectivity. They will need:<BR>
<BR>
- Standard <BR>
- High Throughput &nbsp;Data <BR>
- Low Latency Data <BR>
- Multimedia Streaming <BR>
- Telephony <BR>
- &nbsp;Network Control <BR>
<BR>
A large enterprise is currently configuring their &nbsp;network to support =
the flowing service classes (using the drafts terminology). &nbsp;Most locat=
ion will have a subset of services available with migration to &nbsp;network=
 wide service transparency in the future. <BR>
<BR>
- Standard <BR>
- High &nbsp;Throughput Data <BR>
- Low Latency Data <BR>
- Multimedia Streaming <BR>
- &nbsp;Multimedia Conferencing <BR>
- Telephony <BR>
- Network Control <BR>
- &nbsp;Administration <BR>
<BR>
I can go through more scenarios that I have come across &nbsp;over the year=
s. <BR>
I agree that two or three user service classes is what &nbsp;many operators=
 start off with, however they are not always the same three and &nbsp;they a=
lways like to know how they can evolve in the future.]<BR>
<BR>
Regards, &nbsp;Joe. <BR>
Jozef Babiarz <BR>
QoS and Network Architecture <BR>
Nortel Networks &nbsp;<BR>
email: babiarz@nortelnetworks.com <BR>
Tel: (613) 763-6098 ESN:393-6098 &nbsp;<BR>
<BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"Verda=
na"><BR>
</FONT></SPAN>
</BODY>
</HTML>


--B_3150700016_14584362--


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov  3 16:03:23 2003
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, 3 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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3A24D.BA94D184
Content-Type: text/plain

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 
 


------_=_NextPart_001_01C3A24D.BA94D184
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">
<title>Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>See may comments inline below.</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>-----</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>Here is my take on the examples you gave below:<br>
<br>
Total of 5 service classes, ever, for any service:<br>
Control Class: Highest absolute priority. Never used for anything but control. Period.<br>
<br>
</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>[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.&nbsp;&nbsp; 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. </span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'><br>
<br>
</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>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.</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>[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. </span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'><br>
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.</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>[Joe] OK, similar to Multimedia Streaming service class
with AF3x. <br>
<br>
</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'><br>
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. </span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>[Joe] Ok, similar to Low Latency Data service class and
the draft uses AF2x.<br>
<br>
<br>
</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>BE for everything else - Best Effort internet
services, etc. &nbsp;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.</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>[Joe] Agree for ISP solutions.<br>
<br>
<br>
</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>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.<br>
<br>
Please explain to me why I am wrong.</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>[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? </span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>It looks like I need to add a section showing a different breakdown
of applications into service classes for carrier core networks.</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>I'm thinking of starting of with 4 classes:</span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=1
face=Verdana><span style='font-size:9.0pt;font-family:Verdana'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><span dir=LTR><font size=1 face=Verdana><span
style='font-size:9.0pt;font-family:Verdana'>A class for control</span></font></span></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=1
face=Verdana><span style='font-size:9.0pt;font-family:Verdana'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><span dir=LTR><font size=1 face=Verdana><span
style='font-size:9.0pt;font-family:Verdana'>A class for real-time traffic (both
elastic and inelastic) telephone, video conferencing, TV broadcast, etc.</span></font></span></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=1
face=Verdana><span style='font-size:9.0pt;font-family:Verdana'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><span dir=LTR><font size=1 face=Verdana><span
style='font-size:9.0pt;font-family:Verdana'>A class with guaranteed CIR and low
latency data traffic</span></font></span></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=1
face=Verdana><span style='font-size:9.0pt;font-family:Verdana'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><span dir=LTR><font size=1 face=Verdana><span
style='font-size:9.0pt;font-family:Verdana'>And class for best effort traffic</span></font></span></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>Each class can be further subdivided if more service
differentiation is need.</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>Comments?</span></font></p>

<div>

<p><b><font size=3 color=navy face="Times New Roman"><span style='font-size:
12.0pt;color:navy;font-weight:bold'>Regards, Joe.</span></font></b><font
color=navy><span style='color:navy'> <br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;
font-family:Arial;color:navy'>Jozef Babiarz</span></font><font color=navy><span
style='color:navy'> <br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;
font-family:Arial;color:navy'>QoS and Network Architecture</span></font><font
color=navy><span style='color:navy'> <br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;
font-family:Arial;color:navy'>Nortel Networks</span></font><font color=navy><span
style='color:navy'> <br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;
font-family:Arial;color:navy'>email: babiarz@nortelnetworks.com</span></font><font
color=navy><span style='color:navy'> <br>
</span></font><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>&nbsp;</span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C3A24D.BA94D184--

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov  3 17:02:22 2003
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 RAA26321
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 3 Nov 2003 17:02:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGmlv-0002UX-Co
	for diffserv-interest-archive@odin.ietf.org; Mon, 03 Nov 2003 17:02:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3M23m6009573
	for diffserv-interest-archive@odin.ietf.org; Mon, 3 Nov 2003 17:02:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGmlu-0002Tv-PJ; Mon, 03 Nov 2003 17:02:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGmlT-0002Ql-BJ
	for diffserv-interest@optimus.ietf.org; Mon, 03 Nov 2003 17:01:35 -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 RAA26253
	for <diffserv-interest@ietf.org>; Mon, 3 Nov 2003 17:01:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGmlR-00065R-00
	for diffserv-interest@ietf.org; Mon, 03 Nov 2003 17:01:33 -0500
Received: from a17-250-248-97.apple.com ([17.250.248.97] helo=smtpout.mac.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGmlQ-00065J-00
	for diffserv-interest@ietf.org; Mon, 03 Nov 2003 17:01:32 -0500
Received: from mac.com (smtpin07-en2 [10.13.10.152])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hA3M1UGc026185;
	Mon, 3 Nov 2003 14:01:30 -0800 (PST)
Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id hA3M1Tpa012967;
	Mon, 3 Nov 2003 14:01:30 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 03 Nov 2003 14:01:27 -0800
Subject: Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01
	 .txt
From: "John H. Shuler" <johnshuler@mac.com>
To: Jozef Babiarz <babiarz@nortelnetworks.com>,
        Brian E Carpenter <brc@zurich.ibm.com>
CC: <diffserv-interest@ietf.org>
Message-ID: <BBCC1037.149EB%johnshuler@mac.com>
In-Reply-To: <E380A44D523BD5118EAE0002A52CE5C409507565@zcard0k8.ca.nortel.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3150712888_15339686"
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>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3150712888_15339686
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

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=B9t,
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 ta=
g
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 i=
s
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 =B3borrow=B2 when available, and
everyone can share what=B9s left? Since MM systems tend to be flexible in
terms of encoding rate, adapting dynamically to link speeds, this should no=
t
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=B9t 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 <babiarz@nortelnetworks.com>
Date: Mon, 03 Nov 2003 16:02:02 -0500
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

See may comments inline below.
=20
-----
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 pea=
k
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 operator=
s
start with one class, but if they have determined the one is not sufficed w=
e
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.
=20
[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 an=
d
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 base=
d
on feedback from the network when congestion occurs whereas audio codec tha=
t
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 b=
e
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.
=20

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.
=20
[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.
=20
[Joe] Ok, similar to Low Latency Data service class and the draft uses AF2x=
.



BE for everything else - Best Effort internet services, etc.  No distinctio=
n
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.
=20
[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.
=20
[Joe] What you are suggesting for carrier core network with high speed link=
s
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?
=20
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
=20
Each class can be further subdivided if more service differentiation is
need.
=20
Comments?

Regards, Joe.=20
Jozef Babiarz=20
QoS and Network Architecture
Nortel Networks=20
email: babiarz@nortelnetworks.com
=20



--B_3150712888_15339686
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 &n=
bsp;.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>Joe,<BR>
<BR>
Agree that there are different requirements in metro and backbone than acce=
ss. 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, VBR=
rt, VBRnrt, and UBR). These are roughly equivalent to the four I mapped belo=
w. Other classes (ABR) have not taken off for very good reasons. Putting Con=
trol on its own class should not be a problem, because it should make up a r=
elatively trivial percent of the total bandwidth. If it doesn&#8217;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!<BR>
<BR>
Stratum timing does NOT belong at Layer 3. Period. It belongs at the physic=
al 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 l=
ong distances, and use time stamps within CES frames to tag deviations.<BR>
<BR>
Question is: what problem are you trying to solve?<BR>
<BR>
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 i=
s interesting only in the realm of DIS-aggregating traffic that may come on =
a big pipe to the destination SP.<BR>
<BR>
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 &#8220;borrow&#8221; when availab=
le, and everyone can share what&#8217;s left? Since MM systems tend to be fl=
exible 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 Inter=
net users. If this is a common problem, you either PIR your video, or you bu=
y more bandwidth. Problem solved.(?)<BR>
<BR>
My whole point is: don&#8217;t make more work for yourself or the network p=
roviders. Keep it simple, and keep all realistic tools (engineering, queue m=
anagement, etc.) in mind when proposing the solution.<BR>
<BR>
Perhaps a detailed (realistic) example, including an examination of options=
 and constraints, would help me understand why you feel the need for all the=
se classes and subclasses.<BR>
<BR>
j<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><B>From: </B>Jozef Babiarz &lt;babiar=
z@nortelnetworks.com&gt;<BR>
<B>Date: </B>Mon, 03 Nov 2003 16:02:02 -0500<BR>
<B>To: </B>&quot;John H. Shuler&quot; &lt;johnshuler@mac.com&gt;, Brian E C=
arpenter &lt;brc@zurich.ibm.com&gt;<BR>
<B>Cc: </B>diffserv-interest@ietf.org<BR>
<B>Subject: </B>RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-clas=
ses-01 &nbsp;.txt<BR>
<BR>
See may comments inline below.<BR>
&nbsp;<BR>
-----<BR>
Here is my take on the examples you gave below:<BR>
<BR>
Total of 5 service classes, ever, for any service:<BR>
Control Class: Highest absolute priority. Never used for anything but contr=
ol. Period.<BR>
<BR>
<BR>
[Joe] Generally in agreement however I have some concerns about using highe=
st absolute priority for all routing traffic. My view is that a rate based s=
cheduler (WFQ or WRR, etc.) with higher weight (like 3 x typical peak traffi=
c) assigned may be a better option. So the question is why have we defined a=
n option in the draft for a network administrator to have two service classe=
s for network control traffic? Here are some of the reasons why having two s=
ervice 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 route=
r failures. Their network is large and hieratical. They need to distribution=
 of very precise network timing information (like stratum 3). etc. &nbsp;&nb=
sp;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. <BR>
<BR>
<BR>
<BR>
EF for TDM-like services such as IP telephony, circuit em, and possibly (de=
pending on your attitude) interactive video services. Engineered such that i=
t is never oversubscribed under even the most extreme conditions. Yields low=
 latency and jitter.<BR>
&nbsp;<BR>
[Joe] In the core network or on high speed links (OC12 and above) for the a=
bove condition, I see no problem with aggregating telephony, circuit em and =
interactive video traffic into the same service class or queue. The issue ar=
ises on access, aggregation and many enterprise networks where links speeds =
are much lower, congestion is real and frequent. Therefore providing separat=
ion and different treatments between telephony and video services is needed.=
 Voice packets are of small fixed size and are emitted at a constant rate wh=
ereas 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 feedbac=
k from the network when congestion occurs whereas audio codec that are in us=
e 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 contro=
l of jitter and end-to-end delays for voice and video can be different. Y.15=
41 provide guidelines that telephony voice service should have end-to-end ji=
tter of less then 50ms and one way delay including, codec processing times o=
f less than 150ms. To achieve this type of performance, separation of teleph=
ony and video flows is need on lower speed links. <BR>
&nbsp;<BR>
<BR>
AF4 for latency-sensitive (but not particularly jitter-sensitive) traffic s=
uch as unidirectional audio-video streaming, TV broadcast, etc. Jitter is bu=
ffered by end systems. Also available for people who want to pay through the=
 nose for transactional data service (banks may). Very conservatively engine=
ered w.r.t. CIR... Should never block.<BR>
&nbsp;<BR>
[Joe] OK, similar to Multimedia Streaming service class with AF3x. <BR>
<BR>
<BR>
<BR>
AF1 for guaranteed CIR services with some (but not much) delay sensitivity,=
 such as SNA, VPN, etc. This class - even CIR - will typically be oversubscr=
ibed, based on statistical analysis of network traffic. <BR>
&nbsp;<BR>
[Joe] Ok, similar to Low Latency Data service class and the draft uses AF2x=
.<BR>
<BR>
<BR>
<BR>
BE for everything else - Best Effort internet services, etc. &nbsp;No disti=
nction between &quot;standard&quot; and &quot;low priority&quot;. This is bo=
th. BE is subject to complete blocking under extreme conditions, but these c=
onditions 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 s=
everal seconds, since they are totally elastic. Service providers will price=
 and differentiate based on their performance on this class as well as the o=
thers. If someone is intense about blocking, they can pay to up their servic=
e to AF1 or even AF4.<BR>
&nbsp;<BR>
[Joe] Agree for ISP solutions.<BR>
<BR>
<BR>
<BR>
Why do you need more? All services can be addressed using these basic class=
es, plus policy-based tweaks on policers and shapers and queuing systems (WF=
Q or CBQ). If a customer wants a better quality than is &quot;typical&quot; =
of a particular service, they can pay to bump up a class (except to the cont=
rol class). CIR on EF and AF4 will not be oversubscribed. The payback from e=
xcessive attention to detail in management is negligible at best. Any proble=
ms that occur will be due to failure to properly engineer the network bandwi=
dth or access policies.<BR>
<BR>
Please explain to me why I am wrong.<BR>
&nbsp;<BR>
[Joe] What you are suggesting for carrier core network with high speed link=
s and sufficed bandwidth is a reasonable approach. But what do you do in acc=
ess networks, enterprise WANs, WLANs and service providers that have lower s=
peed connectivity and congestion is real? <BR>
&nbsp;<BR>
It looks like I need to add a section showing a different breakdown of appl=
ications into service classes for carrier core networks.<BR>
I'm thinking of starting of with 4 classes:<BR>
-</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'fon=
t-size:10.0px'> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>A class for con=
trol<BR>
-</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'fon=
t-size:10.0px'> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>A class for rea=
l-time traffic (both elastic and inelastic) telephone, video conferencing, T=
V broadcast, etc.<BR>
-</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'fon=
t-size:10.0px'> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>A class with gu=
aranteed CIR and low latency data traffic<BR>
-</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'fon=
t-size:10.0px'> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>And class for b=
est effort traffic<BR>
&nbsp;<BR>
Each class can be further subdivided if more service differentiation is nee=
d.<BR>
&nbsp;<BR>
Comments?<BR>
<BR>
</SPAN></FONT><FONT COLOR=3D"#000080"><FONT SIZE=3D"5"><FONT FACE=3D"Times New Ro=
man"><SPAN STYLE=3D'font-size:18.0px'><B>Regards, Joe.</B></SPAN></FONT></FONT=
><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:14.0=
px'>Jozef Babiarz</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font=
-size:12.0px'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:14.0=
px'>QoS and Network Architecture</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><S=
PAN STYLE=3D'font-size:12.0px'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:14.0=
px'>Nortel Networks</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'fo=
nt-size:12.0px'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:14.0=
px'>email: babiarz@nortelnetworks.com</SPAN></FONT></FONT><FONT FACE=3D"Verdan=
a"><SPAN STYLE=3D'font-size:12.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'> <=
BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3150712888_15339686--


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Thu Nov  6 13:17:00 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21248
	for <diffserv-interest-archive@odin.ietf.org>; Thu, 6 Nov 2003 13:17:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHogV-0007qN-Cv
	for diffserv-interest-archive@odin.ietf.org; Thu, 06 Nov 2003 13:16:43 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6IGhuk030137
	for diffserv-interest-archive@odin.ietf.org; Thu, 6 Nov 2003 13:16:43 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHofq-0007nA-1N; Thu, 06 Nov 2003 13:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHofJ-0007mW-0s
	for diffserv-interest@optimus.ietf.org; Thu, 06 Nov 2003 13:15:29 -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 NAA21197
	for <diffserv-interest@ietf.org>; Thu, 6 Nov 2003 13:15:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHofH-0005H3-00
	for diffserv-interest@ietf.org; Thu, 06 Nov 2003 13:15:27 -0500
Received: from firewall2.uwindsor.ca ([137.207.233.22] helo=internet2.uwindsor.ca)
	by ietf-mx with smtp (Exim 4.12)
	id 1AHofG-0005Gz-00
	for diffserv-interest@ietf.org; Thu, 06 Nov 2003 13:15:26 -0500
Received: 	id LAA29572; Thu, 6 Nov 2003 11:29:02 -0500
Received: by gateway id 29474620 for <diffserv-interest@ietf.org>; Thu, 06 Nov 2003 11:29:01 -0500
From: "Feng Y" <feng6@uwindsor.ca>
To: diffserv-interest@ietf.org
X-Mailer: CommuniGate Pro Web Mailer v.4.0.6
Date: Thu, 06 Nov 2003 11:29:01 -0500
Message-ID: <web-29474620@uwindsor.ca>
In-Reply-To: <3F9F9F56.2917A11A@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA21198
Subject: [Diffserv-interest] QoS in diffserv network
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>
Content-Transfer-Encoding: quoted-printable


>>=20
>> It is up to the carrier to monitor congestion
periodically to prevent
>> lowest-priority traffic from being too congested. EF
should ALWAYS get
>> through on-time, and AF CIR should always get through,
if somewhat delayed
>> and jittery. The cases when this is NOT true should be
rare and bizarre
>> (earthquakes, major network outages, etc.) unless the
carrier is not doing
>> their job... Which is simply to make sure they engineer
total network
>> bandwidth above the level of peak CIR.
>
>Exactly. Each traffic class (i.e. each queue) needs to be
provisioned for
>the expected load with appropriate over- or
under-provisioning. The new
>thing is that you can over-provision for some traffic and
under-provision
>for other traffic. (New to IP, that is. It's hardly a new
concept.)
>

Can we always assume that a higher service class provides
the same or a better service than any lower service class
in AF? Can the following scenario happen in Diffserv
network?
The gold service was allocated x percent of a link=92s
bandwidth and silver service was allocated x/2 percent of
the link=92s bandwidth, but the traffic intensity of gold
packets was 10 times higher than that of silver packets.

Should the ISP assure that there are not so many gold
packets in service?=20

Thanks

Yang=20

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Fri Nov  7 13:38:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28310
	for <diffserv-interest-archive@odin.ietf.org>; Fri, 7 Nov 2003 13:38: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 1AIBUh-0006D2-Hh
	for diffserv-interest-archive@odin.ietf.org; Fri, 07 Nov 2003 13:38:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Ic3Us023862
	for diffserv-interest-archive@odin.ietf.org; Fri, 7 Nov 2003 13:38:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AIBUf-0006CJ-Ql; Fri, 07 Nov 2003 13:38:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AIBTs-0005y4-Dq
	for diffserv-interest@optimus.ietf.org; Fri, 07 Nov 2003 13:37:12 -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 NAA28283
	for <diffserv-interest@ietf.org>; Fri, 7 Nov 2003 13:37:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AIBTq-0000zE-00
	for diffserv-interest@ietf.org; Fri, 07 Nov 2003 13:37:10 -0500
Received: from smtpout.mac.com ([17.250.248.84])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AIBTp-0000zA-00
	for diffserv-interest@ietf.org; Fri, 07 Nov 2003 13:37:09 -0500
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id hA7IbcfX000801
	for <diffserv-interest@ietf.org>; Fri, 7 Nov 2003 10:37:38 -0800 (PST)
Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hA7Ib5Zq021912
	for <diffserv-interest@ietf.org>; Fri, 7 Nov 2003 10:37:07 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 07 Nov 2003 10:37:03 -0800
From: "John H. Shuler" <johnshuler@mac.com>
To: <diffserv-interest@ietf.org>
Message-ID: <BBD1264F.14AC4%johnshuler@mac.com>
In-Reply-To: <20031107170002.32609.36173.Mailman@www1.ietf.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #111 - 1 msg
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>
Content-Transfer-Encoding: 7bit

RFC 2597 states 

"This memo does not specify that any particular relationship hold between AF
PHB groups and other implemented PHB groups; it requires only that whatever
relationship is chosen be documented. Implementations MAY allow either or
both of these relationships to be configurable. It is expected that this
level of configuration flexibility will prove valuable to many network
administrators."

In other words, it's up to the admin, as long as the rules are clearly
stated. I am a fan of absolute priority (of CIR traffic) between classes,
relative priority within classes. For example:

CIR = PIR for EF traffic. Network "reserves" the EF CIR as committed, and
refuses to admit anything above CIR=PIR.

CIR is committed and reserved for AF4 traffic. Excess traffic between CIR
and PIR receives higher priority than excess traffic for lower priority
groups, even within AF class (e.g. AF1).

CIR for AF1 is oversubscribed based on statistical analysis of historic
network traffic. AF1 CIR may be dropped under extreme conditions.

BE gets whatever is left.

I have no strong opinion about how to treat excess AF traffic vs. BE. My
inclination is to give BE CIR higher priority than any "excess" traffic, but
to treat all "excess" traffic in absolute priority by class. To summarize:

Absolute priority order:
EF
AF4 CIR
AF1 CIR
BE CIR
AF4 excess (medium drop priority)
AF1 excess (mdp)
BE excess (mdp)
Etc.

This way, if a customer wants to increase their service quality, it is clear
what they do: they bump up a class if they want more deterministic
assurance, or they increase PIR if they want a more subtle (and probably
less expensive) improvement.

I would be very interested in hearing from a "real" network administrator
about how s/he sets priorities and policies.

J

> From: diffserv-interest-request@ietf.org
> Reply-To: diffserv-interest@ietf.org
> Date: Fri, 07 Nov 2003 12:00:02 -0500
> To: diffserv-interest@ietf.org
> Subject: Diffserv-interest digest, Vol 1 #111 - 1 msg
> 
> Send Diffserv-interest mailing list submissions to
> diffserv-interest@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> or, via email, send a message with subject or body 'help' to
> diffserv-interest-request@ietf.org
> 
> You can reach the person managing the list at
> diffserv-interest-admin@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Diffserv-interest digest..."
> 
> 
> Today's Topics:
> 
>  1. QoS in diffserv network (Feng Y)
> 
> --__--__--
> 
> Message: 1
> From: "Feng Y" <feng6@uwindsor.ca>
> To: diffserv-interest@ietf.org
> Date: Thu, 06 Nov 2003 11:29:01 -0500
> Subject: [Diffserv-interest] QoS in diffserv network
> 
> 
>>> =20
>>> It is up to the carrier to monitor congestion
> periodically to prevent
>>> lowest-priority traffic from being too congested. EF
> should ALWAYS get
>>> through on-time, and AF CIR should always get through,
> if somewhat delayed
>>> and jittery. The cases when this is NOT true should be
> rare and bizarre
>>> (earthquakes, major network outages, etc.) unless the
> carrier is not doing
>>> their job... Which is simply to make sure they engineer
> total network
>>> bandwidth above the level of peak CIR.
>> 
>> Exactly. Each traffic class (i.e. each queue) needs to be
> provisioned for
>> the expected load with appropriate over- or
> under-provisioning. The new
>> thing is that you can over-provision for some traffic and
> under-provision
>> for other traffic. (New to IP, that is. It's hardly a new
> concept.)
>> 
> 
> Can we always assume that a higher service class provides
> the same or a better service than any lower service class
> in AF? Can the following scenario happen in Diffserv
> network?
> The gold service was allocated x percent of a link=92s
> bandwidth and silver service was allocated x/2 percent of
> the link=92s bandwidth, but the traffic intensity of gold
> packets was 10 times higher than that of silver packets.
> 
> Should the ISP assure that there are not so many gold
> packets in service?=20
> 
> Thanks
> 
> Yang=20
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Diffserv-interest mailing list
> Diffserv-interest@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> 
> 
> End of Diffserv-interest Digest


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Sun Nov  9 13:29:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05588
	for <diffserv-interest-archive@odin.ietf.org>; Sun, 9 Nov 2003 13:29: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 1AIuJ7-0005VE-AE
	for diffserv-interest-archive@odin.ietf.org; Sun, 09 Nov 2003 13:29:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9IT5P1021148
	for diffserv-interest-archive@odin.ietf.org; Sun, 9 Nov 2003 13:29:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AIuJ3-0005U9-UJ; Sun, 09 Nov 2003 13:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AIuIq-0005Tj-P1
	for diffserv-interest@optimus.ietf.org; Sun, 09 Nov 2003 13:28:49 -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 NAA05560
	for <diffserv-interest@ietf.org>; Sun, 9 Nov 2003 13:28:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AIuIo-00050a-00
	for diffserv-interest@ietf.org; Sun, 09 Nov 2003 13:28:46 -0500
Received: from mtagate6.de.ibm.com ([195.212.29.155])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AIuIn-000509-00
	for diffserv-interest@ietf.org; Sun, 09 Nov 2003 13:28:45 -0500
Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged))
	by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9IRhD8042282;
	Sun, 9 Nov 2003 18:27:43 GMT
Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])
	by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9IRRlF219558;
	Sun, 9 Nov 2003 19:27:27 +0100
Received: from zurich.ibm.com (sig-9-145-147-176.de.ibm.com [9.145.147.176])
	by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA43652;
	Sun, 9 Nov 2003 19:27:25 +0100
Message-ID: <3FAE86E8.3AE456E7@zurich.ibm.com>
Date: Sun, 09 Nov 2003 19:26:48 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
MIME-Version: 1.0
To: Feng Y <feng6@uwindsor.ca>
CC: diffserv-interest@ietf.org
Subject: Re: [Diffserv-interest] QoS in diffserv network
References: <web-29474620@uwindsor.ca>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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>
Content-Transfer-Encoding: quoted-printable

below...

Feng Y wrote:
> =

> >>
> >> It is up to the carrier to monitor congestion
> periodically to prevent
> >> lowest-priority traffic from being too congested. EF
> should ALWAYS get
> >> through on-time, and AF CIR should always get through,
> if somewhat delayed
> >> and jittery. The cases when this is NOT true should be
> rare and bizarre
> >> (earthquakes, major network outages, etc.) unless the
> carrier is not doing
> >> their job... Which is simply to make sure they engineer
> total network
> >> bandwidth above the level of peak CIR.
> >
> >Exactly. Each traffic class (i.e. each queue) needs to be
> provisioned for
> >the expected load with appropriate over- or
> under-provisioning. The new
> >thing is that you can over-provision for some traffic and
> under-provision
> >for other traffic. (New to IP, that is. It's hardly a new
> concept.)
> >
> =

> Can we always assume that a higher service class provides
> the same or a better service than any lower service class
> in AF? =


No. There is no "higher" or "lower" built into AF. There
is simply the option of having one or more mutually
independent AF service classes, with an arbitrary number
of four service classes being named AF1, AF2, AF3, AF4
if you choose to use the recommended code points.

If you happen to give each of these classes equal weights
in a WFQ scheme they are all offering the same level of service.

If you happen to give AF2 a higher weight than AF3, you are
choosing to offer more service to AF2 traffic.


> Can the following scenario happen in Diffserv
> network?
> The gold service was allocated x percent of a link=92s
> bandwidth and silver service was allocated x/2 percent of
> the link=92s bandwidth, but the traffic intensity of gold
> packets was 10 times higher than that of silver packets.

That can certainly happen, if you mean that the offered
load to the gold service is ten times greater than the
offered load to the silver service.

> =

> Should the ISP assure that there are not so many gold
> packets in service?

It depends what the SLA for gold and silver say, doesn't
it? There is no rule. It's the ISP's business decision.

My assumption and what I would recommend to an ISP is:

If the offered load on silver equals the bandwidth assigned
to silver, then it should all be transmitted, unless the SLA says
otherwise. And the excess traffic offered to the gold service =

will be at high risk of being dropped, depending on the utilization
of the remaining (100-x-x/2)% of the line.

   Brian

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov 10 03:23:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12606
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 03:23:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJ7KA-0008AV-Us
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 03:23:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAA8N2Wr031376
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 03:23:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJ7K9-00089R-2K; Mon, 10 Nov 2003 03:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJ7JU-00088u-FC
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 03:22:20 -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 DAA12593
	for <diffserv-interest@ietf.org>; Mon, 10 Nov 2003 03:22:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJ7JS-00019D-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 03:22:18 -0500
Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJ7JR-00018j-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 03:22:17 -0500
Received: from bemail03.net.alcatel.be (bemail03.net.alcatel.be [138.203.147.7])
	by relay4.alcatel.be (8.12.10/8.12.10) with ESMTP id hAA8LgeA013838;
	Mon, 10 Nov 2003 09:21:42 +0100
Received: from alcatel.be ([138.203.142.5])
          by bemail03.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003111009214067:533 ;
          Mon, 10 Nov 2003 09:21:40 +0100 
Message-ID: <3FAF4A7B.5010305@alcatel.be>
Date: Mon, 10 Nov 2003 09:21:15 +0100
From: Zoltan.Balint@alcatel.be
Organization: Alcatel,
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian E Carpenter <brc@zurich.ibm.com>
Cc: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
Subject: Re: [Diffserv-interest] QoS in diffserv network
References: <web-29474620@uwindsor.ca> <3FAE86E8.3AE456E7@zurich.ibm.com>
In-Reply-To: <3FAE86E8.3AE456E7@zurich.ibm.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 11/10/2003 09:21:40,
	Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 11/10/2003 09:21:41,
	Serialize complete at 11/10/2003 09:21:41
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
X-Scanned-By: MIMEDefang 2.37
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Brian, Feng,<br>
<blockquote type="cite" cite="mid3FAE86E8.3AE456E7@zurich.ibm.com">
  <blockquote type="cite">
    <pre wrap="">Can we always assume that a higher service class provides
the same or a better service than any lower service class
in AF? 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No. There is no "higher" or "lower" built into AF. There
is simply the option of having one or more mutually
independent AF service classes, with an arbitrary number
of four service classes being named AF1, AF2, AF3, AF4
if you choose to use the recommended code points.

If you happen to give each of these classes equal weights
in a WFQ scheme they are all offering the same level of service.</pre>
</blockquote>
That would be the case when the relative load in those classes was
equal as well. But, since some<br>
classes can be more loaded than others, the service seen in different
classes does not <br>
relate to the index of the AF class. Unless, of course, the scheduler
was strict priority, which does<br>
not conform to the requirements in RFC2597 (minimum bandwidth).<br>
<br>
<br>
Regards,<br>
Zoltan<br>
<br>
&lt;snip&gt;<br>
</body>
</html>


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov 10 10:57:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26211
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 10:57:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJEPV-0004IK-QG
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 10:57:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFv1Yg016502
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 10:57:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJEPV-0004I3-Bz; Mon, 10 Nov 2003 10:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJEPI-0004Hk-TX
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 10:56:49 -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 KAA26178
	for <diffserv-interest@ietf.org>; Mon, 10 Nov 2003 10:56:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJEPF-0006dF-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 10:56:45 -0500
Received: from mtagate7.de.ibm.com ([195.212.29.156])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJEPE-0006cd-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 10:56:44 -0500
Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged))
	by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAAFu1xm066104;
	Mon, 10 Nov 2003 15:56:01 GMT
Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])
	by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAAFu1Y4274500;
	Mon, 10 Nov 2003 16:56:01 +0100
Received: from zurich.ibm.com ([9.145.244.160])
	by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA74580;
	Mon, 10 Nov 2003 16:55:56 +0100
Message-ID: <3FAFB4E5.2C42935F@zurich.ibm.com>
Date: Mon, 10 Nov 2003 16:55:17 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
MIME-Version: 1.0
To: Zoltan.Balint@alcatel.be
CC: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
Subject: Re: [Diffserv-interest] QoS in diffserv network
References: <web-29474620@uwindsor.ca> <3FAE86E8.3AE456E7@zurich.ibm.com> <3FAF4A7B.5010305@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

> Zoltan.Balint@alcatel.be wrote:
> 
> Brian, Feng,
> 
> >> Can we always assume that a higher service class provides
> >> the same or a better service than any lower service class
> >> in AF?
> >>
> >>
> > No. There is no "higher" or "lower" built into AF. There
> > is simply the option of having one or more mutually
> > independent AF service classes, with an arbitrary number
> > of four service classes being named AF1, AF2, AF3, AF4
> > if you choose to use the recommended code points.
> >
> > If you happen to give each of these classes equal weights
> > in a WFQ scheme they are all offering the same level of service.
> >
> That would be the case when the relative load in those classes was equal as well. But, since some
> classes can be more loaded than others, the service seen in different classes does not
> relate to the index of the AF class. 

Zoltan,

There is no such thing as an index; the digit in AF3 is just part of the name.

If two AF classes have equal WFQ weights but different offered loads, they will 
experience different loss and jitter rates, but the service *offered* is the same.
The service *delivered* will vary, but that is a different matter. The two SLAs may 
be different, by allowing different levels of overbooking, but that is why the diffserv 
documents distinguish between the SLA and the SLS [service level specification].

I think we are in agreement, but I want to be precise.

> Unless, of course, the scheduler was strict priority, which does
> not conform to the requirements in RFC2597 (minimum bandwidth).

True.

   Brian

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov 10 14:13:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06530
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 14:13:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJHTH-00026A-T3
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 14:13:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJD7m7008067
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 14:13:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJHTB-00025o-N8; Mon, 10 Nov 2003 14:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJHSM-00024N-V2
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 14:12:10 -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 OAA06468
	for <diffserv-interest@ietf.org>; Mon, 10 Nov 2003 14:11:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJHSK-0002Wg-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 14:12:08 -0500
Received: from a17-250-248-88.apple.com ([17.250.248.88] helo=smtpout.mac.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJHSI-0002Wd-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 14:12:07 -0500
Received: from mac.com (smtpin07-en2 [10.13.10.152])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hAAJC5T7005289
	for <diffserv-interest@ietf.org>; Mon, 10 Nov 2003 11:12:05 -0800 (PST)
Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id hAAJC4pa019254
	for <diffserv-interest@ietf.org>; Mon, 10 Nov 2003 11:12:04 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 10 Nov 2003 11:12:02 -0800
From: "John H. Shuler" <johnshuler@mac.com>
To: <diffserv-interest@ietf.org>
Message-ID: <BBD52302.14B11%johnshuler@mac.com>
In-Reply-To: <20031110170003.3873.58625.Mailman@www1.ietf.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3 msgs
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>
Content-Transfer-Encoding: 7bit

Brian,

I don't believe there is a mandate for SPs to use WFQ within the AF class,
so either WFQ or strict priority queuing is an option. As well, the nature
and degree of priority -- in fact, the entire policy equation -- seems to be
left open, except that there is an implication that AF4 is given some higher
quality/priority than AF1, whether in a weighted or strict sense.

It is my contention, however, that there should be some kind of specific
guidelines provided for this class, especially, since it is in AF where a
lot of the subtlety -- and confusion, and cross-carrier screwups -- can
reside. This is where I believe the proposed draft can have its biggest
impact. That is, not only in delineating further the treatment of AF within
class, but also the rules in assigning traffic types to different classes.

The whole idea is that, without some kind of standardization, multi-service
IP will not take off as it should, because there is no way for a customer to
know that the video (for example) he hands to his regional SP will make it
to the other end in a consistent and reliable way.

j

> From: diffserv-interest-request@ietf.org
> Reply-To: diffserv-interest@ietf.org
> Date: Mon, 10 Nov 2003 12:00:03 -0500
> To: diffserv-interest@ietf.org
> Subject: Diffserv-interest digest, Vol 1 #113 - 3 msgs
> 
> Send Diffserv-interest mailing list submissions to
> diffserv-interest@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> or, via email, send a message with subject or body 'help' to
> diffserv-interest-request@ietf.org
> 
> You can reach the person managing the list at
> diffserv-interest-admin@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Diffserv-interest digest..."
> 
> 
> Today's Topics:
> 
>  1. Re: QoS in diffserv network (Brian E Carpenter)
>  2. Re: QoS in diffserv network (Zoltan.Balint@alcatel.be)
>  3. Re: QoS in diffserv network (Brian E Carpenter)
> 
> --__--__--
> 
> Message: 1
> Date: Sun, 09 Nov 2003 19:26:48 +0100
> From: Brian E Carpenter <brc@zurich.ibm.com>
> Organization: IBM
> To: Feng Y <feng6@uwindsor.ca>
> CC: diffserv-interest@ietf.org
> Subject: Re: [Diffserv-interest] QoS in diffserv network
> 
> below...
> 
> Feng Y wrote:
>> =
> 
>>>> 
>>>> It is up to the carrier to monitor congestion
>> periodically to prevent
>>>> lowest-priority traffic from being too congested. EF
>> should ALWAYS get
>>>> through on-time, and AF CIR should always get through,
>> if somewhat delayed
>>>> and jittery. The cases when this is NOT true should be
>> rare and bizarre
>>>> (earthquakes, major network outages, etc.) unless the
>> carrier is not doing
>>>> their job... Which is simply to make sure they engineer
>> total network
>>>> bandwidth above the level of peak CIR.
>>> 
>>> Exactly. Each traffic class (i.e. each queue) needs to be
>> provisioned for
>>> the expected load with appropriate over- or
>> under-provisioning. The new
>>> thing is that you can over-provision for some traffic and
>> under-provision
>>> for other traffic. (New to IP, that is. It's hardly a new
>> concept.)
>>> 
>> =
> 
>> Can we always assume that a higher service class provides
>> the same or a better service than any lower service class
>> in AF? =
> 
> 
> No. There is no "higher" or "lower" built into AF. There
> is simply the option of having one or more mutually
> independent AF service classes, with an arbitrary number
> of four service classes being named AF1, AF2, AF3, AF4
> if you choose to use the recommended code points.
> 
> If you happen to give each of these classes equal weights
> in a WFQ scheme they are all offering the same level of service.
> 
> If you happen to give AF2 a higher weight than AF3, you are
> choosing to offer more service to AF2 traffic.
> 
> 
>> Can the following scenario happen in Diffserv
>> network?
>> The gold service was allocated x percent of a link=92s
>> bandwidth and silver service was allocated x/2 percent of
>> the link=92s bandwidth, but the traffic intensity of gold
>> packets was 10 times higher than that of silver packets.
> 
> That can certainly happen, if you mean that the offered
> load to the gold service is ten times greater than the
> offered load to the silver service.
> 
>> =
> 
>> Should the ISP assure that there are not so many gold
>> packets in service?
> 
> It depends what the SLA for gold and silver say, doesn't
> it? There is no rule. It's the ISP's business decision.
> 
> My assumption and what I would recommend to an ISP is:
> 
> If the offered load on silver equals the bandwidth assigned
> to silver, then it should all be transmitted, unless the SLA says
> otherwise. And the excess traffic offered to the gold service =
> 
> will be at high risk of being dropped, depending on the utilization
> of the remaining (100-x-x/2)% of the line.
> 
>  Brian
> 
> 
> --__--__--
> 
> Message: 2
> Date: Mon, 10 Nov 2003 09:21:15 +0100
> From: Zoltan.Balint@alcatel.be
> Organization: Alcatel,
> To: Brian E Carpenter <brc@zurich.ibm.com>
> Cc: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
> Subject: Re: [Diffserv-interest] QoS in diffserv network
> 
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
> <title></title>
> </head>
> <body text="#000000" bgcolor="#ffffff">
> Brian, Feng,<br>
> <blockquote type="cite" cite="mid3FAE86E8.3AE456E7@zurich.ibm.com">
> <blockquote type="cite">
>   <pre wrap="">Can we always assume that a higher service class provides
> the same or a better service than any lower service class
> in AF? 
>   </pre>
> </blockquote>
> <pre wrap=""><!---->
> No. There is no "higher" or "lower" built into AF. There
> is simply the option of having one or more mutually
> independent AF service classes, with an arbitrary number
> of four service classes being named AF1, AF2, AF3, AF4
> if you choose to use the recommended code points.
> 
> If you happen to give each of these classes equal weights
> in a WFQ scheme they are all offering the same level of service.</pre>
> </blockquote>
> That would be the case when the relative load in those classes was
> equal as well. But, since some<br>
> classes can be more loaded than others, the service seen in different
> classes does not <br>
> relate to the index of the AF class. Unless, of course, the scheduler
> was strict priority, which does<br>
> not conform to the requirements in RFC2597 (minimum bandwidth).<br>
> <br>
> <br>
> Regards,<br>
> Zoltan<br>
> <br>
> &lt;snip&gt;<br>
> </body>
> </html>
> 
> 
> 
> --__--__--
> 
> Message: 3
> Date: Mon, 10 Nov 2003 16:55:17 +0100
> From: Brian E Carpenter <brc@zurich.ibm.com>
> Organization: IBM
> To: Zoltan.Balint@alcatel.be
> CC: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
> Subject: Re: [Diffserv-interest] QoS in diffserv network
> 
>> Zoltan.Balint@alcatel.be wrote:
>> 
>> Brian, Feng,
>> 
>>>> Can we always assume that a higher service class provides
>>>> the same or a better service than any lower service class
>>>> in AF?
>>>> 
>>>> 
>>> No. There is no "higher" or "lower" built into AF. There
>>> is simply the option of having one or more mutually
>>> independent AF service classes, with an arbitrary number
>>> of four service classes being named AF1, AF2, AF3, AF4
>>> if you choose to use the recommended code points.
>>> 
>>> If you happen to give each of these classes equal weights
>>> in a WFQ scheme they are all offering the same level of service.
>>> 
>> That would be the case when the relative load in those classes was equal as
>> well. But, since some
>> classes can be more loaded than others, the service seen in different classes
>> does not
>> relate to the index of the AF class.
> 
> Zoltan,
> 
> There is no such thing as an index; the digit in AF3 is just part of the name.
> 
> If two AF classes have equal WFQ weights but different offered loads, they
> will 
> experience different loss and jitter rates, but the service *offered* is the
> same.
> The service *delivered* will vary, but that is a different matter. The two
> SLAs may 
> be different, by allowing different levels of overbooking, but that is why the
> diffserv 
> documents distinguish between the SLA and the SLS [service level
> specification].
> 
> I think we are in agreement, but I want to be precise.
> 
>> Unless, of course, the scheduler was strict priority, which does
>> not conform to the requirements in RFC2597 (minimum bandwidth).
> 
> True.
> 
>  Brian
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Diffserv-interest mailing list
> Diffserv-interest@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> 
> 
> End of Diffserv-interest Digest


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov 10 14:52:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08778
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 14:52:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJI4v-0004qW-7o
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 14:52:01 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJq1m8018617
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 14:52:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJI4u-0004pl-Cy; Mon, 10 Nov 2003 14:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJI4C-0004ol-35
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 14:51:16 -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 OAA08720
	for <diffserv-interest@ietf.org>; Mon, 10 Nov 2003 14:51:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJI49-0003Ho-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 14:51:13 -0500
Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw1.hursley.ibm.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJI48-0003HJ-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 14:51:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com)
	by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12)
	id 1AJI3b-0005KC-00; Mon, 10 Nov 2003 19:50:39 +0000
Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com)
	by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12)
	id 1AJI3b-0005K9-00; Mon, 10 Nov 2003 19:50:39 +0000
Received: from zurich.ibm.com ([9.145.244.160])
	by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hAAJobv49676;
	Mon, 10 Nov 2003 19:50:38 GMT
Message-ID: <3FAFEBE6.52164C4@zurich.ibm.com>
Date: Mon, 10 Nov 2003 20:49:58 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
MIME-Version: 1.0
To: "John H. Shuler" <johnshuler@mac.com>
CC: diffserv-interest@ietf.org
Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3 
 msgs
References: <BBD52302.14B11%johnshuler@mac.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Yes, WFQ is an example solution of course, but it's a relatively easy one to think
about.

I do agree we need a best practices document; we're only arguing about its
richness in service classes, I think.

   Brian

"John H. Shuler" wrote:
> 
> Brian,
> 
> I don't believe there is a mandate for SPs to use WFQ within the AF class,
> so either WFQ or strict priority queuing is an option. As well, the nature
> and degree of priority -- in fact, the entire policy equation -- seems to be
> left open, except that there is an implication that AF4 is given some higher
> quality/priority than AF1, whether in a weighted or strict sense.
> 
> It is my contention, however, that there should be some kind of specific
> guidelines provided for this class, especially, since it is in AF where a
> lot of the subtlety -- and confusion, and cross-carrier screwups -- can
> reside. This is where I believe the proposed draft can have its biggest
> impact. That is, not only in delineating further the treatment of AF within
> class, but also the rules in assigning traffic types to different classes.
> 
> The whole idea is that, without some kind of standardization, multi-service
> IP will not take off as it should, because there is no way for a customer to
> know that the video (for example) he hands to his regional SP will make it
> to the other end in a consistent and reliable way.
> 
> j
> 
> > From: diffserv-interest-request@ietf.org
> > Reply-To: diffserv-interest@ietf.org
> > Date: Mon, 10 Nov 2003 12:00:03 -0500
> > To: diffserv-interest@ietf.org
> > Subject: Diffserv-interest digest, Vol 1 #113 - 3 msgs
> >
> > Send Diffserv-interest mailing list submissions to
> > diffserv-interest@ietf.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://www1.ietf.org/mailman/listinfo/diffserv-interest
> > or, via email, send a message with subject or body 'help' to
> > diffserv-interest-request@ietf.org
> >
> > You can reach the person managing the list at
> > diffserv-interest-admin@ietf.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Diffserv-interest digest..."
> >
> >
> > Today's Topics:
> >
> >  1. Re: QoS in diffserv network (Brian E Carpenter)
> >  2. Re: QoS in diffserv network (Zoltan.Balint@alcatel.be)
> >  3. Re: QoS in diffserv network (Brian E Carpenter)
> >
> > --__--__--
> >
> > Message: 1
> > Date: Sun, 09 Nov 2003 19:26:48 +0100
> > From: Brian E Carpenter <brc@zurich.ibm.com>
> > Organization: IBM
> > To: Feng Y <feng6@uwindsor.ca>
> > CC: diffserv-interest@ietf.org
> > Subject: Re: [Diffserv-interest] QoS in diffserv network
> >
> > below...
> >
> > Feng Y wrote:
> >> =
> >
> >>>>
> >>>> It is up to the carrier to monitor congestion
> >> periodically to prevent
> >>>> lowest-priority traffic from being too congested. EF
> >> should ALWAYS get
> >>>> through on-time, and AF CIR should always get through,
> >> if somewhat delayed
> >>>> and jittery. The cases when this is NOT true should be
> >> rare and bizarre
> >>>> (earthquakes, major network outages, etc.) unless the
> >> carrier is not doing
> >>>> their job... Which is simply to make sure they engineer
> >> total network
> >>>> bandwidth above the level of peak CIR.
> >>>
> >>> Exactly. Each traffic class (i.e. each queue) needs to be
> >> provisioned for
> >>> the expected load with appropriate over- or
> >> under-provisioning. The new
> >>> thing is that you can over-provision for some traffic and
> >> under-provision
> >>> for other traffic. (New to IP, that is. It's hardly a new
> >> concept.)
> >>>
> >> =
> >
> >> Can we always assume that a higher service class provides
> >> the same or a better service than any lower service class
> >> in AF? =
> >
> >
> > No. There is no "higher" or "lower" built into AF. There
> > is simply the option of having one or more mutually
> > independent AF service classes, with an arbitrary number
> > of four service classes being named AF1, AF2, AF3, AF4
> > if you choose to use the recommended code points.
> >
> > If you happen to give each of these classes equal weights
> > in a WFQ scheme they are all offering the same level of service.
> >
> > If you happen to give AF2 a higher weight than AF3, you are
> > choosing to offer more service to AF2 traffic.
> >
> >
> >> Can the following scenario happen in Diffserv
> >> network?
> >> The gold service was allocated x percent of a link=92s
> >> bandwidth and silver service was allocated x/2 percent of
> >> the link=92s bandwidth, but the traffic intensity of gold
> >> packets was 10 times higher than that of silver packets.
> >
> > That can certainly happen, if you mean that the offered
> > load to the gold service is ten times greater than the
> > offered load to the silver service.
> >
> >> =
> >
> >> Should the ISP assure that there are not so many gold
> >> packets in service?
> >
> > It depends what the SLA for gold and silver say, doesn't
> > it? There is no rule. It's the ISP's business decision.
> >
> > My assumption and what I would recommend to an ISP is:
> >
> > If the offered load on silver equals the bandwidth assigned
> > to silver, then it should all be transmitted, unless the SLA says
> > otherwise. And the excess traffic offered to the gold service =
> >
> > will be at high risk of being dropped, depending on the utilization
> > of the remaining (100-x-x/2)% of the line.
> >
> >  Brian
> >
> >
> > --__--__--
> >
> > Message: 2
> > Date: Mon, 10 Nov 2003 09:21:15 +0100
> > From: Zoltan.Balint@alcatel.be
> > Organization: Alcatel,
> > To: Brian E Carpenter <brc@zurich.ibm.com>
> > Cc: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
> > Subject: Re: [Diffserv-interest] QoS in diffserv network
> >
> > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> > <html>
> > <head>
> > <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
> > <title></title>
> > </head>
> > <body text="#000000" bgcolor="#ffffff">
> > Brian, Feng,<br>
> > <blockquote type="cite" cite="mid3FAE86E8.3AE456E7@zurich.ibm.com">
> > <blockquote type="cite">
> >   <pre wrap="">Can we always assume that a higher service class provides
> > the same or a better service than any lower service class
> > in AF?
> >   </pre>
> > </blockquote>
> > <pre wrap=""><!---->
> > No. There is no "higher" or "lower" built into AF. There
> > is simply the option of having one or more mutually
> > independent AF service classes, with an arbitrary number
> > of four service classes being named AF1, AF2, AF3, AF4
> > if you choose to use the recommended code points.
> >
> > If you happen to give each of these classes equal weights
> > in a WFQ scheme they are all offering the same level of service.</pre>
> > </blockquote>
> > That would be the case when the relative load in those classes was
> > equal as well. But, since some<br>
> > classes can be more loaded than others, the service seen in different
> > classes does not <br>
> > relate to the index of the AF class. Unless, of course, the scheduler
> > was strict priority, which does<br>
> > not conform to the requirements in RFC2597 (minimum bandwidth).<br>
> > <br>
> > <br>
> > Regards,<br>
> > Zoltan<br>
> > <br>
> > &lt;snip&gt;<br>
> > </body>
> > </html>
> >
> >
> >
> > --__--__--
> >
> > Message: 3
> > Date: Mon, 10 Nov 2003 16:55:17 +0100
> > From: Brian E Carpenter <brc@zurich.ibm.com>
> > Organization: IBM
> > To: Zoltan.Balint@alcatel.be
> > CC: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
> > Subject: Re: [Diffserv-interest] QoS in diffserv network
> >
> >> Zoltan.Balint@alcatel.be wrote:
> >>
> >> Brian, Feng,
> >>
> >>>> Can we always assume that a higher service class provides
> >>>> the same or a better service than any lower service class
> >>>> in AF?
> >>>>
> >>>>
> >>> No. There is no "higher" or "lower" built into AF. There
> >>> is simply the option of having one or more mutually
> >>> independent AF service classes, with an arbitrary number
> >>> of four service classes being named AF1, AF2, AF3, AF4
> >>> if you choose to use the recommended code points.
> >>>
> >>> If you happen to give each of these classes equal weights
> >>> in a WFQ scheme they are all offering the same level of service.
> >>>
> >> That would be the case when the relative load in those classes was equal as
> >> well. But, since some
> >> classes can be more loaded than others, the service seen in different classes
> >> does not
> >> relate to the index of the AF class.
> >
> > Zoltan,
> >
> > There is no such thing as an index; the digit in AF3 is just part of the name.
> >
> > If two AF classes have equal WFQ weights but different offered loads, they
> > will
> > experience different loss and jitter rates, but the service *offered* is the
> > same.
> > The service *delivered* will vary, but that is a different matter. The two
> > SLAs may
> > be different, by allowing different levels of overbooking, but that is why the
> > diffserv
> > documents distinguish between the SLA and the SLS [service level
> > specification].
> >
> > I think we are in agreement, but I want to be precise.
> >
> >> Unless, of course, the scheduler was strict priority, which does
> >> not conform to the requirements in RFC2597 (minimum bandwidth).
> >
> > True.
> >
> >  Brian
> >
> >
> >
> > --__--__--
> >
> > _______________________________________________
> > Diffserv-interest mailing list
> > Diffserv-interest@ietf.org
> > https://www1.ietf.org/mailman/listinfo/diffserv-interest
> >
> >
> > End of Diffserv-interest Digest
> 
> _______________________________________________
> Diffserv-interest mailing list
> Diffserv-interest@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv-interest

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov 10 14:56:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09065
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 14:56:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJI8p-0005VH-9Q
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 14:56:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJu2NY021074
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 14:56:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJI8o-0005Tn-RP; Mon, 10 Nov 2003 14:56:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJI88-0005R4-O3
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 14:55:20 -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 OAA09027
	for <diffserv-interest@ietf.org>; Mon, 10 Nov 2003 14:55:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJI85-0003Nr-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 14:55:17 -0500
Received: from a17-250-248-85.apple.com ([17.250.248.85] helo=smtpout.mac.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJI84-0003No-00
	for diffserv-interest@ietf.org; Mon, 10 Nov 2003 14:55:16 -0500
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hAAJtFIZ015698;
	Mon, 10 Nov 2003 11:55:15 -0800 (PST)
Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hAAJtEZq014350;
	Mon, 10 Nov 2003 11:55:15 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 10 Nov 2003 11:55:12 -0800
Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113
	- 3 msgs
From: "John H. Shuler" <johnshuler@mac.com>
To: Brian E Carpenter <brc@zurich.ibm.com>
CC: <diffserv-interest@ietf.org>
Message-ID: <BBD52D20.14B1A%johnshuler@mac.com>
In-Reply-To: <3FAFEBE6.52164C4@zurich.ibm.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Brian,

I agree. My suggestion would be to keep it simple so as to be easily
implemented as a common denominator standard that works, then refine it over
time after experience demonstrates a need. If it starts out too complicated,
it will be too expensive to implement and therefore usurp the purpose.

j

> From: Brian E Carpenter <brc@zurich.ibm.com>
> Organization: IBM
> Date: Mon, 10 Nov 2003 20:49:58 +0100
> To: "John H. Shuler" <johnshuler@mac.com>
> Cc: diffserv-interest@ietf.org
> Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3
> msgs
> 
> Yes, WFQ is an example solution of course, but it's a relatively easy one to
> think
> about.
> 
> I do agree we need a best practices document; we're only arguing about its
> richness in service classes, I think.
> 
>  Brian
> 
> "John H. Shuler" wrote:
>> 
>> Brian,
>> 
>> I don't believe there is a mandate for SPs to use WFQ within the AF class,
>> so either WFQ or strict priority queuing is an option. As well, the nature
>> and degree of priority -- in fact, the entire policy equation -- seems to be
>> left open, except that there is an implication that AF4 is given some higher
>> quality/priority than AF1, whether in a weighted or strict sense.
>> 
>> It is my contention, however, that there should be some kind of specific
>> guidelines provided for this class, especially, since it is in AF where a
>> lot of the subtlety -- and confusion, and cross-carrier screwups -- can
>> reside. This is where I believe the proposed draft can have its biggest
>> impact. That is, not only in delineating further the treatment of AF within
>> class, but also the rules in assigning traffic types to different classes.
>> 
>> The whole idea is that, without some kind of standardization, multi-service
>> IP will not take off as it should, because there is no way for a customer to
>> know that the video (for example) he hands to his regional SP will make it
>> to the other end in a consistent and reliable way.
>> 
>> j
>> 
>>> From: diffserv-interest-request@ietf.org
>>> Reply-To: diffserv-interest@ietf.org
>>> Date: Mon, 10 Nov 2003 12:00:03 -0500
>>> To: diffserv-interest@ietf.org
>>> Subject: Diffserv-interest digest, Vol 1 #113 - 3 msgs
>>> 
>>> Send Diffserv-interest mailing list submissions to
>>> diffserv-interest@ietf.org
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
>>> or, via email, send a message with subject or body 'help' to
>>> diffserv-interest-request@ietf.org
>>> 
>>> You can reach the person managing the list at
>>> diffserv-interest-admin@ietf.org
>>> 
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Diffserv-interest digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>>  1. Re: QoS in diffserv network (Brian E Carpenter)
>>>  2. Re: QoS in diffserv network (Zoltan.Balint@alcatel.be)
>>>  3. Re: QoS in diffserv network (Brian E Carpenter)
>>> 
>>> --__--__--
>>> 
>>> Message: 1
>>> Date: Sun, 09 Nov 2003 19:26:48 +0100
>>> From: Brian E Carpenter <brc@zurich.ibm.com>
>>> Organization: IBM
>>> To: Feng Y <feng6@uwindsor.ca>
>>> CC: diffserv-interest@ietf.org
>>> Subject: Re: [Diffserv-interest] QoS in diffserv network
>>> 
>>> below...
>>> 
>>> Feng Y wrote:
>>>> =
>>> 
>>>>>> 
>>>>>> It is up to the carrier to monitor congestion
>>>> periodically to prevent
>>>>>> lowest-priority traffic from being too congested. EF
>>>> should ALWAYS get
>>>>>> through on-time, and AF CIR should always get through,
>>>> if somewhat delayed
>>>>>> and jittery. The cases when this is NOT true should be
>>>> rare and bizarre
>>>>>> (earthquakes, major network outages, etc.) unless the
>>>> carrier is not doing
>>>>>> their job... Which is simply to make sure they engineer
>>>> total network
>>>>>> bandwidth above the level of peak CIR.
>>>>> 
>>>>> Exactly. Each traffic class (i.e. each queue) needs to be
>>>> provisioned for
>>>>> the expected load with appropriate over- or
>>>> under-provisioning. The new
>>>>> thing is that you can over-provision for some traffic and
>>>> under-provision
>>>>> for other traffic. (New to IP, that is. It's hardly a new
>>>> concept.)
>>>>> 
>>>> =
>>> 
>>>> Can we always assume that a higher service class provides
>>>> the same or a better service than any lower service class
>>>> in AF? =
>>> 
>>> 
>>> No. There is no "higher" or "lower" built into AF. There
>>> is simply the option of having one or more mutually
>>> independent AF service classes, with an arbitrary number
>>> of four service classes being named AF1, AF2, AF3, AF4
>>> if you choose to use the recommended code points.
>>> 
>>> If you happen to give each of these classes equal weights
>>> in a WFQ scheme they are all offering the same level of service.
>>> 
>>> If you happen to give AF2 a higher weight than AF3, you are
>>> choosing to offer more service to AF2 traffic.
>>> 
>>> 
>>>> Can the following scenario happen in Diffserv
>>>> network?
>>>> The gold service was allocated x percent of a link=92s
>>>> bandwidth and silver service was allocated x/2 percent of
>>>> the link=92s bandwidth, but the traffic intensity of gold
>>>> packets was 10 times higher than that of silver packets.
>>> 
>>> That can certainly happen, if you mean that the offered
>>> load to the gold service is ten times greater than the
>>> offered load to the silver service.
>>> 
>>>> =
>>> 
>>>> Should the ISP assure that there are not so many gold
>>>> packets in service?
>>> 
>>> It depends what the SLA for gold and silver say, doesn't
>>> it? There is no rule. It's the ISP's business decision.
>>> 
>>> My assumption and what I would recommend to an ISP is:
>>> 
>>> If the offered load on silver equals the bandwidth assigned
>>> to silver, then it should all be transmitted, unless the SLA says
>>> otherwise. And the excess traffic offered to the gold service =
>>> 
>>> will be at high risk of being dropped, depending on the utilization
>>> of the remaining (100-x-x/2)% of the line.
>>> 
>>>  Brian
>>> 
>>> 
>>> --__--__--
>>> 
>>> Message: 2
>>> Date: Mon, 10 Nov 2003 09:21:15 +0100
>>> From: Zoltan.Balint@alcatel.be
>>> Organization: Alcatel,
>>> To: Brian E Carpenter <brc@zurich.ibm.com>
>>> Cc: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
>>> Subject: Re: [Diffserv-interest] QoS in diffserv network
>>> 
>>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>>> <html>
>>> <head>
>>> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
>>> <title></title>
>>> </head>
>>> <body text="#000000" bgcolor="#ffffff">
>>> Brian, Feng,<br>
>>> <blockquote type="cite" cite="mid3FAE86E8.3AE456E7@zurich.ibm.com">
>>> <blockquote type="cite">
>>>   <pre wrap="">Can we always assume that a higher service class provides
>>> the same or a better service than any lower service class
>>> in AF?
>>>   </pre>
>>> </blockquote>
>>> <pre wrap=""><!---->
>>> No. There is no "higher" or "lower" built into AF. There
>>> is simply the option of having one or more mutually
>>> independent AF service classes, with an arbitrary number
>>> of four service classes being named AF1, AF2, AF3, AF4
>>> if you choose to use the recommended code points.
>>> 
>>> If you happen to give each of these classes equal weights
>>> in a WFQ scheme they are all offering the same level of service.</pre>
>>> </blockquote>
>>> That would be the case when the relative load in those classes was
>>> equal as well. But, since some<br>
>>> classes can be more loaded than others, the service seen in different
>>> classes does not <br>
>>> relate to the index of the AF class. Unless, of course, the scheduler
>>> was strict priority, which does<br>
>>> not conform to the requirements in RFC2597 (minimum bandwidth).<br>
>>> <br>
>>> <br>
>>> Regards,<br>
>>> Zoltan<br>
>>> <br>
>>> &lt;snip&gt;<br>
>>> </body>
>>> </html>
>>> 
>>> 
>>> 
>>> --__--__--
>>> 
>>> Message: 3
>>> Date: Mon, 10 Nov 2003 16:55:17 +0100
>>> From: Brian E Carpenter <brc@zurich.ibm.com>
>>> Organization: IBM
>>> To: Zoltan.Balint@alcatel.be
>>> CC: Feng Y <feng6@uwindsor.ca>, diffserv-interest@ietf.org
>>> Subject: Re: [Diffserv-interest] QoS in diffserv network
>>> 
>>>> Zoltan.Balint@alcatel.be wrote:
>>>> 
>>>> Brian, Feng,
>>>> 
>>>>>> Can we always assume that a higher service class provides
>>>>>> the same or a better service than any lower service class
>>>>>> in AF?
>>>>>> 
>>>>>> 
>>>>> No. There is no "higher" or "lower" built into AF. There
>>>>> is simply the option of having one or more mutually
>>>>> independent AF service classes, with an arbitrary number
>>>>> of four service classes being named AF1, AF2, AF3, AF4
>>>>> if you choose to use the recommended code points.
>>>>> 
>>>>> If you happen to give each of these classes equal weights
>>>>> in a WFQ scheme they are all offering the same level of service.
>>>>> 
>>>> That would be the case when the relative load in those classes was equal as
>>>> well. But, since some
>>>> classes can be more loaded than others, the service seen in different
>>>> classes
>>>> does not
>>>> relate to the index of the AF class.
>>> 
>>> Zoltan,
>>> 
>>> There is no such thing as an index; the digit in AF3 is just part of the
>>> name.
>>> 
>>> If two AF classes have equal WFQ weights but different offered loads, they
>>> will
>>> experience different loss and jitter rates, but the service *offered* is the
>>> same.
>>> The service *delivered* will vary, but that is a different matter. The two
>>> SLAs may
>>> be different, by allowing different levels of overbooking, but that is why
>>> the
>>> diffserv
>>> documents distinguish between the SLA and the SLS [service level
>>> specification].
>>> 
>>> I think we are in agreement, but I want to be precise.
>>> 
>>>> Unless, of course, the scheduler was strict priority, which does
>>>> not conform to the requirements in RFC2597 (minimum bandwidth).
>>> 
>>> True.
>>> 
>>>  Brian
>>> 
>>> 
>>> 
>>> --__--__--
>>> 
>>> _______________________________________________
>>> Diffserv-interest mailing list
>>> Diffserv-interest@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
>>> 
>>> 
>>> End of Diffserv-interest Digest
>> 
>> _______________________________________________
>> Diffserv-interest mailing list
>> Diffserv-interest@ietf.org
>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
> 
> NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov 10 18:40:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22955
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 18:40:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJLdb-0007YN-Km
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 18:40:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANe3Yv028994
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 18:40:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJLda-0007XN-4V; Mon, 10 Nov 2003 18:40:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJLcb-0007W2-Vm
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 18:39:02 -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 SAA22864;
	Mon, 10 Nov 2003 18:38:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJLcX-0007ZU-00; Mon, 10 Nov 2003 18:38:57 -0500
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJLcX-0007ZR-00; Mon, 10 Nov 2003 18:38:57 -0500
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de)
	by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian))
	id 1AJLcK-0002BX-00; Tue, 11 Nov 2003 00:38:44 +0100
Received: from i72ms1.tm.uni-karlsruhe.de
	([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8)
	by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 1AJLcJ-0003pZ-00; Tue, 11 Nov 2003 00:38:43 +0100
Received: from localhost
	([::1] helo=i72mn12.tm.uka.de ident=3010)
	by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.12)
	id 1AJLcB-0007JC-00; Tue, 11 Nov 2003 00:38:36 +0100
Date: Tue, 11 Nov 2003 00:38:55 +0100
From: Roland Bless <bless@tm.uka.de>
To: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>
Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" <tsvwg@ietf.org>
Message-Id: <20031111003855.5c313dd0.bless@tm.uka.de>
In-Reply-To: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
References: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
Organization: Institute of Telematics, University of Karlsruhe
X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Re: [NSIS] PPS and MF-PHB
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>
Content-Transfer-Encoding: 7bit

Hi Naotaka,

On Fri, 07 Nov 2003 09:36:44 +0900
"MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp> wrote:

> I would like to draw QoS experts attention to the following three documents.
> 
> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt
> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt
> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt
> 
> I am going to make a presentation on Monday morning at TSV WG.

After reading draft-morita-tsvwg-mfphb-00.txt and attending your
presentation, I have some remarks related to this approach:
- I'm not quite sure whether this is really a PHB definition.
  It seems to me, that it is actually a mix of
  * a scheme for measured-based admission control and resource provisioning
  * a Per-Domain Behavior (see RFC 3086)
  * a PHB group description

- The scheme inherently relies on feedback information and it should be made
  clear how the feedback can be provided (you mentioned RTCP as an example,
  what about others?).

- Instead of defining a new PHB, possibly two Class Selector PHBs
  or even an AF class can be used ("green" packets get high priority after
  admission control, "yellow" and "red" packet may be used for probing).
  AF usually gives no guarantees for delay and jitter, however, if AF is
  provisioned properly, "green" packets may get some guarantee.

- For security and robustness, it is essential to police the markings
  for the higher priority. Otherwise the service guarantees for other users
  are violated by a malicious or ill-behaving end-system. Therefore, I think
  first-hop routers should do the policing (based on the feedback
  information?).

- I see some value in the overall approach, but IMHO the proposal may 
  be turned into a description for a measurement-based
  admission control scheme and PDB using Class Selector PHBs.

I copied to the relevant lists (diffserv-interest and tsvwg) as I'm 
interested in other opinions.

Best regards,
 Roland

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Mon Nov 10 23:29:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04801
	for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 23:29:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJQ9G-0007WK-Gq
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 23:29:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB4T2nf028907
	for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 23:29:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJQ9F-0007Vc-CE; Mon, 10 Nov 2003 23:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJQ8W-0007Ua-16
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 23:28:16 -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 XAA04761;
	Mon, 10 Nov 2003 23:28:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJQ8T-0004V9-00; Mon, 10 Nov 2003 23:28:13 -0500
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJQ8T-0004V6-00; Mon, 10 Nov 2003 23:28:13 -0500
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de)
	by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian))
	id 1AJQ8P-0006FO-00; Tue, 11 Nov 2003 05:28:09 +0100
Received: from i72ms1.tm.uni-karlsruhe.de
	([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8)
	by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 1AJQ8P-0000B6-00; Tue, 11 Nov 2003 05:28:09 +0100
Received: from localhost
	([::1] helo=i72mn12.tm.uka.de ident=3010)
	by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.12)
	id 1AJQ8N-0007vB-00; Tue, 11 Nov 2003 05:28:07 +0100
Date: Tue, 11 Nov 2003 05:28:27 +0100
From: Roland Bless <bless@tm.uka.de>
To: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>
Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" <tsvwg@ietf.org>
Message-Id: <20031111052827.348154fd.bless@tm.uka.de>
In-Reply-To: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp>
References: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
	<5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
	<5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp>
Organization: Institute of Telematics, University of Karlsruhe
X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB
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>
Content-Transfer-Encoding: 7bit

Hi Naotaka,

>  >After reading draft-morita-tsvwg-mfphb-00.txt and attending your
>  >presentation, I have some remarks related to this approach:
>  >- I'm not quite sure whether this is really a PHB definition.
>  >  It seems to me, that it is actually a mix of
>  >  * a scheme for measured-based admission control and resource provisioning
                     ^^^^^^^^sorry, should have been: measurement-based admission control
>  >  * a Per-Domain Behavior (see RFC 3086)
>  >  * a PHB group description

> Your understanding is correct, but I do not think it is a mix.
> The key of the PPS is to utilize PHB for admission control.

Hmm, I disagree here. A PHB usually describes an
"externally observable forwarding treatment", basically how
a node treats a packet during the forwarding procedure
(typically boils down to queue management and scheduling issues).
In your case, that both PHBs (MF-H,MF-M) get their own assigned 
resources (bw limitation) and that MF-M has a higher drop precedence
than MF-H. On top of that PHB group you define an admission
control procedure with additional traffic conditioning mechanisms
(your token bucket descriptions). This fits better to a PDB 
description in my opinion. And as you state in section 5:

   The Priority Promotion Scheme can be viewed as a kind of admission
   control.

> The proposed new PHB, MF-PHB refers to two-subclasses,
> but we do not have to define it as a group description.

What you call "sub-classes" are effectively two different PHBs: you will
need two distinct DSCPs and each DSCP will be mapped to a distinct PHB
that will cause a specific packet forwarding treatment. RFC 2475 defines
a PHB group as "a set of one or more PHBs that can only be meaningfully
specified and implemented simultaneously,....". Please, see also RFC 3260
for clarification on the AF class as a PHB group. MF-H makes not much
sense without MF-M and vice versa. However, I think your PPS admission control 
scheme can be applied to an AF class as well as to the CSC PHBs, therefore you 
don't need two new PHBs.

>  >- The scheme inherently relies on feedback information and it should be made
>  >  clear how the feedback can be provided (you mentioned RTCP as an example,
>  >  what about others?).
> 
> Yes, it is.  As the PPS, I would like to describe the feedback mechanims,
> but for a PHB, we do not have to.

Yes, for a PHB you don't have to, but that's exactly why admission control 
should be defined not together with the PHB. EF also requires some form of
admission control to achieve the timely forwarding, but admission control 
procedures are not defined within RFC 3246. Your admission control procedure
will not work without feedback, but the PHBs will. Therefore, define a PDB
that defines constraints for corresponding PHBs.

>  >- Instead of defining a new PHB, possibly two Class Selector PHBs
>  >  or even an AF class can be used ("green" packets get high priority after
>  >  admission control, "yellow" and "red" packet may be used for probing).
>  >  AF usually gives no guarantees for delay and jitter, however, if AF is
>  >  provisioned properly, "green" packets may get some guarantee.
> 
> This kind of disucssion is what I wanted to do.
> Sorry for spending much time on me presentation only.
> Are you refering to Three Color Marker in RFC2697 and RFC2698?

Not exactly, because I was not referring to packet marking, 
but as in those RFCs, I used the color code as an equivalent
for the drop precedence (i.e., "green"=AFx1, "yellow"=AFx2, "red"=AFx3).
Note that, the AF class definition allows also to implement only two (instead of 
three) effective different levels of loss probability for an AF class x.

>  >- For security and robustness, it is essential to police the markings
>  >  for the higher priority. Otherwise the service guarantees for other users
>  >  are violated by a malicious or ill-behaving end-system. Therefore, I think
>  >  first-hop routers should do the policing (based on the feedback
>  >  information?).
> 
> I agree.  Are there any opinion about the description in pps framework document?
> Not sufficient?

Yes, I think some issues in 4.4 need more discussion. E.g., how do you ensure
that the feedback information is correct (you only state that "The behavior
in the direction from the destination to the source should also be correct")?
Some aspects should possibly be moved to the security section.

Best regards,
 Roland

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Tue Nov 11 11:25:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08158
	for <diffserv-interest-archive@odin.ietf.org>; Tue, 11 Nov 2003 11:25:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJbKA-0003yC-J7
	for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 11:25:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGP2R3015250
	for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 11:25:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJbK8-0003xR-Ry; Tue, 11 Nov 2003 11:25:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJOYV-0000nc-S1
	for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 21:46:59 -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 VAA01331;
	Mon, 10 Nov 2003 21:46:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJOYS-0003Ed-00; Mon, 10 Nov 2003 21:46:56 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJOYR-0003Ea-00; Mon, 10 Nov 2003 21:46:55 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAB2krUC004345;
	Tue, 11 Nov 2003 11:46:53 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAB2kqpo001999;
	Tue, 11 Nov 2003 11:46:52 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAB2kp8H000105;
	Tue, 11 Nov 2003 11:46:51 +0900 (JST)
Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA04812;
	Tue, 11 Nov 2003 11:46:51 +0900 (JST)
Received: from morita-ibmthink.lab.ntt.co.jp
	by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA09423;
	Tue, 11 Nov 2003 11:46:49 +0900 (JST)
Message-Id: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp>
X-Sender: nm014@imj.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5
Date: Mon, 10 Nov 2003 20:45:59 -0600
To: Roland Bless <bless@tm.uka.de>
From: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>
Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" <tsvwg@ietf.org>
In-Reply-To: <20031111003855.5c313dd0.bless@tm.uka.de>
References: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
 <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB
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>
Content-Transfer-Encoding: 7bit

At 00:38 03/11/11 +0100, Roland Bless wrote:
 >Hi Naotaka,
 >
 >On Fri, 07 Nov 2003 09:36:44 +0900
 >"MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp> wrote:
 >
 >> I would like to draw QoS experts attention to the following three documents.
 >>
 >> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt
 >> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt
 >> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt
 >>
 >> I am going to make a presentation on Monday morning at TSV WG.
 >
 >After reading draft-morita-tsvwg-mfphb-00.txt and attending your
 >presentation, I have some remarks related to this approach:
 >- I'm not quite sure whether this is really a PHB definition.
 >  It seems to me, that it is actually a mix of
 >  * a scheme for measured-based admission control and resource provisioning
 >  * a Per-Domain Behavior (see RFC 3086)
 >  * a PHB group description

Your understanding is correct, but I do not think it is a mix.
The key of the PPS is to utilize PHB for admission control.
The proposed new PHB, MF-PHB refers to two-subclasses,
but we do not have to define it as a group description.

 >
 >- The scheme inherently relies on feedback information and it should be made
 >  clear how the feedback can be provided (you mentioned RTCP as an example,
 >  what about others?).

Yes, it is.  As the PPS, I would like to describe the feedback mechanims,
but for a PHB, we do not have to.

 >
 >- Instead of defining a new PHB, possibly two Class Selector PHBs
 >  or even an AF class can be used ("green" packets get high priority after
 >  admission control, "yellow" and "red" packet may be used for probing).
 >  AF usually gives no guarantees for delay and jitter, however, if AF is
 >  provisioned properly, "green" packets may get some guarantee.

This kind of disucssion is what I wanted to do.
Sorry for spending much time on me presentation only.
Are you refering to Three Color Marker in RFC2697 and RFC2698?

 >
 >- For security and robustness, it is essential to police the markings
 >  for the higher priority. Otherwise the service guarantees for other users
 >  are violated by a malicious or ill-behaving end-system. Therefore, I think
 >  first-hop routers should do the policing (based on the feedback
 >  information?).

I agree.  Are there any opinion about the description in pps framework document?
Not sufficient?

 >
 >- I see some value in the overall approach, but IMHO the proposal may
 >  be turned into a description for a measurement-based
 >  admission control scheme and PDB using Class Selector PHBs.
 >
 >I copied to the relevant lists (diffserv-interest and tsvwg) as I'm
 >interested in other opinions.

Me, too.

 >
 >Best regards,
 > Roland
 >
 >_______________________________________________
 >tsvwg mailing list
 >tsvwg@ietf.org
 >https://www1.ietf.org/mailman/listinfo/tsvwg

----------------------------------
Naotaka MORITA, Senior Research Engineer, Supervisor
Network Service Systems Laboratories
Information Sharing Laboratory Group
NTT
3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN
Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012
E-mail: morita.naotaka@lab.ntt.co.jp
MSN messenger: moritanaotaka@hotmail.com
NTT home page: http://www.ntt.co.jp/about/e/index.html 



_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Tue Nov 11 12:46:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12970
	for <diffserv-interest-archive@odin.ietf.org>; Tue, 11 Nov 2003 12:46:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJcaY-0005Li-0s
	for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 12:46:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHk1x3020557
	for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 12:46:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJcaX-0005LT-Ph; Tue, 11 Nov 2003 12:46:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJcaO-0005Kg-Em
	for diffserv-interest@optimus.ietf.org; Tue, 11 Nov 2003 12:45: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 MAA12938;
	Tue, 11 Nov 2003 12:45:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJcaM-00072Q-00; Tue, 11 Nov 2003 12:45:50 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJcaL-00072E-00; Tue, 11 Nov 2003 12:45:50 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjlUC028501;
	Wed, 12 Nov 2003 02:45:47 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjlpo001464;
	Wed, 12 Nov 2003 02:45:47 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjl8H019773;
	Wed, 12 Nov 2003 02:45:47 +0900 (JST)
Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id CAA06351;
	Wed, 12 Nov 2003 02:45:46 +0900 (JST)
Received: from morita-ibmthink.lab.ntt.co.jp
	by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id CAA08127;
	Wed, 12 Nov 2003 02:45:44 +0900 (JST)
Message-Id: <5.1.1.11.2.20031110230755.04c76b18@imj.m.ecl.ntt.co.jp>
X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5
Date: Mon, 10 Nov 2003 23:18:37 -0600
To: Roland Bless <bless@tm.uka.de>
From: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>
Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" <tsvwg@ietf.org>
In-Reply-To: <20031111052827.348154fd.bless@tm.uka.de>
References: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp>
 <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
 <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
 <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB
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>
Content-Transfer-Encoding: 7bit

Roland,

At 05:28 03/11/11 +0100, Roland Bless wrote:
 >Hi Naotaka,
 >
 >>  >After reading draft-morita-tsvwg-mfphb-00.txt and attending your
 >>  >presentation, I have some remarks related to this approach:
 >>  >- I'm not quite sure whether this is really a PHB definition.
 >>  >  It seems to me, that it is actually a mix of
 >>  >  * a scheme for measured-based admission control and resource provisioning
 >                     ^^^^^^^^sorry, should have been: measurement-based
 >admission control
 >>  >  * a Per-Domain Behavior (see RFC 3086)
 >>  >  * a PHB group description
 >
 >> Your understanding is correct, but I do not think it is a mix.
 >> The key of the PPS is to utilize PHB for admission control.
 >
 >Hmm, I disagree here. A PHB usually describes an
 >"externally observable forwarding treatment", basically how
 >a node treats a packet during the forwarding procedure
 >(typically boils down to queue management and scheduling issues).
 >In your case, that both PHBs (MF-H,MF-M) get their own assigned
 >resources (bw limitation) and that MF-M has a higher drop precedence
 >than MF-H. On top of that PHB group you define an admission
 >control procedure with additional traffic conditioning mechanisms
 >(your token bucket descriptions). This fits better to a PDB
 >description in my opinion. And as you state in section 5:
 >
 >   The Priority Promotion Scheme can be viewed as a kind of admission
 >   control.

That is right.  I will check the meaning of PDP.

 >
 >> The proposed new PHB, MF-PHB refers to two-subclasses,
 >> but we do not have to define it as a group description.
 >
 >What you call "sub-classes" are effectively two different PHBs: you will
 >need two distinct DSCPs and each DSCP will be mapped to a distinct PHB
 >that will cause a specific packet forwarding treatment. RFC 2475 defines
 >a PHB group as "a set of one or more PHBs that can only be meaningfully
 >specified and implemented simultaneously,....". Please, see also RFC 3260
 >for clarification on the AF class as a PHB group. MF-H makes not much
 >sense without MF-M and vice versa. However, I think your PPS admission control
 >scheme can be applied to an AF class as well as to the CSC PHBs, therefore you
 >don't need two new PHBs.

But the important factor is the bandwidth limitation is shared between two 
sub-classes.
Sequence integrity is another one.
How do I describe such things by isolated PHBs?
Anyway, what is CSC?

 >
 >>  >- The scheme inherently relies on feedback information and it should be made
 >>  >  clear how the feedback can be provided (you mentioned RTCP as an example,
 >>  >  what about others?).
 >>
 >> Yes, it is.  As the PPS, I would like to describe the feedback mechanims,
 >> but for a PHB, we do not have to.
 >
 >Yes, for a PHB you don't have to, but that's exactly why admission control
 >should be defined not together with the PHB. EF also requires some form of
 >admission control to achieve the timely forwarding, but admission control
 >procedures are not defined within RFC 3246. Your admission control procedure
 >will not work without feedback, but the PHBs will. Therefore, define a PDB
 >that defines constraints for corresponding PHBs.

I see.  Again, I will check PDB.

 >
 >>  >- Instead of defining a new PHB, possibly two Class Selector PHBs
 >>  >  or even an AF class can be used ("green" packets get high priority after
 >>  >  admission control, "yellow" and "red" packet may be used for probing).
 >>  >  AF usually gives no guarantees for delay and jitter, however, if AF is
 >>  >  provisioned properly, "green" packets may get some guarantee.
 >>
 >> This kind of disucssion is what I wanted to do.
 >> Sorry for spending much time on me presentation only.
 >> Are you refering to Three Color Marker in RFC2697 and RFC2698?
 >
 >Not exactly, because I was not referring to packet marking,
 >but as in those RFCs, I used the color code as an equivalent
 >for the drop precedence (i.e., "green"=AFx1, "yellow"=AFx2, "red"=AFx3).
 >Note that, the AF class definition allows also to implement only two 
(instead of
 >three) effective different levels of loss probability for an AF class x.

I will soon show you the difference between srTCM and my proposed two-threshold.

 >
 >>  >- For security and robustness, it is essential to police the markings
 >>  >  for the higher priority. Otherwise the service guarantees for other users
 >>  >  are violated by a malicious or ill-behaving end-system. Therefore, I think
 >>  >  first-hop routers should do the policing (based on the feedback
 >>  >  information?).
 >>
 >> I agree.  Are there any opinion about the description in pps framework
 >document?
 >> Not sufficient?
 >
 >Yes, I think some issues in 4.4 need more discussion. E.g., how do you ensure
 >that the feedback information is correct (you only state that "The behavior
 >in the direction from the destination to the source should also be correct")?
 >Some aspects should possibly be moved to the security section.

Thank you.  I will do that.
For the correctness of the feedback information is a target of media 
monitor server.

 >
 >Best regards,
 > Roland
 >
 >_______________________________________________
 >tsvwg mailing list
 >tsvwg@ietf.org
 >https://www1.ietf.org/mailman/listinfo/tsvwg 



_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Tue Nov 11 13:16:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14049
	for <diffserv-interest-archive@odin.ietf.org>; Tue, 11 Nov 2003 13:16:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJd3a-0008Ks-PW
	for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 13:16:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIG2t6032027
	for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 13:16:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJd3Z-0008KH-Fv; Tue, 11 Nov 2003 13:16:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJd2c-0008GS-Pu
	for diffserv-interest@optimus.ietf.org; Tue, 11 Nov 2003 13:15:02 -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 NAA14022;
	Tue, 11 Nov 2003 13:14:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJd2a-0007Ob-00; Tue, 11 Nov 2003 13:15:00 -0500
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJd2a-0007OY-00; Tue, 11 Nov 2003 13:15:00 -0500
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de)
	by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian))
	id 1AJd2S-0002af-00; Tue, 11 Nov 2003 19:14:52 +0100
Received: from i72ms1.tm.uni-karlsruhe.de
	([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8)
	by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 1AJd2R-00009B-00; Tue, 11 Nov 2003 19:14:51 +0100
Received: from i72ms.tm.uni-karlsruhe.de
	([141.3.70.5] helo=i72mn12.tm.uka.de ident=3010)
	by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.12)
	id 1AJd2Q-0000z4-00; Tue, 11 Nov 2003 19:14:50 +0100
Date: Tue, 11 Nov 2003 19:15:12 +0100
From: Roland Bless <bless@tm.uka.de>
To: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>,
        diffserv-interest@ietf.org, "'tsvwg@ietf.org'" <tsvwg@ietf.org>
Subject: Re: [Diffserv-interest] Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB
Message-Id: <20031111191512.0adcff52.bless@tm.uka.de>
In-Reply-To: <5.1.1.11.2.20031110230755.04c76b18@imj.m.ecl.ntt.co.jp>
References: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp>
	<5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
	<5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp>
	<5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp>
	<5.1.1.11.2.20031110230755.04c76b18@imj.m.ecl.ntt.co.jp>
Organization: Institute of Telematics, University of Karlsruhe
X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

On Mon, 10 Nov 2003 23:18:37 -0600
"MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp> wrote:
 
> That is right.  I will check the meaning of PDP.

PDB=Per-Domain Behavior, see RFC 3086.

>  >What you call "sub-classes" are effectively two different PHBs: you will
>  >need two distinct DSCPs and each DSCP will be mapped to a distinct PHB
>  >that will cause a specific packet forwarding treatment. RFC 2475 defines
>  >a PHB group as "a set of one or more PHBs that can only be meaningfully
>  >specified and implemented simultaneously,....". Please, see also RFC 3260
>  >for clarification on the AF class as a PHB group. MF-H makes not much
>  >sense without MF-M and vice versa. However, I think your PPS admission control
>  >scheme can be applied to an AF class as well as to the CSC PHBs, therefore you
>  >don't need two new PHBs.
> 
> But the important factor is the bandwidth limitation is shared between two 
> sub-classes.

Sure, no problem. That's why it is a PHB group.

> Sequence integrity is another one.

You mean that micro-flows should not be reordered if their
packets are marked as MF-H and MF-M alternatingly?
This is also a requirement for the PHBs in an AF class.
However, I don't see how you achieve this with the implementation 
described in 4.1 Fig.3: as soon as you have separate queues
for MF-H and MF-M, reordering may occur.

> How do I describe such things by isolated PHBs?

Confer the AF class definition and read RFC3260 in
addition to that.

> Anyway, what is CSC?

Class Selector Compliant PHB, cf. RFC 2474, sec. 4.2.2.2

> I will soon show you the difference between srTCM and my proposed two-threshold.

No, you don't have to, I support that there are differences. I'm not referring to 
the marking scheme, I'm referring to the AF PHB definition.

> For the correctness of the feedback information is a target of media 
> monitor server.

I'm not sure whether it is reasonable that the scheme depends on
the existence of some additional server.

Regards,
 Roland

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Fri Nov 14 07:15:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07755
	for <diffserv-interest-archive@odin.ietf.org>; Fri, 14 Nov 2003 07: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 1AKcqv-0002hj-Og
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 07:15:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAECF37H010364
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 07: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 1AKcqr-0002gr-Si; Fri, 14 Nov 2003 07:15:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKcqg-0002ga-Ns
	for diffserv-interest@optimus.ietf.org; Fri, 14 Nov 2003 07:14:51 -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 HAA07736
	for <diffserv-interest@ietf.org>; Fri, 14 Nov 2003 07:14:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKcqg-00043v-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 07:14:50 -0500
Received: from web15213.mail.cnb.yahoo.com ([202.3.77.143] helo=web15213.mail.bjs.yahoo.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1AKcqf-00043g-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 07:14:49 -0500
Message-ID: <20031114121416.15063.qmail@web15213.mail.bjs.yahoo.com>
Received: from [202.96.96.35] by web15213.mail.bjs.yahoo.com via HTTP; Fri, 14 Nov 2003 20:14:16 CST
Date: Fri, 14 Nov 2003 20:14:16 +0800 (CST)
From: =?gb2312?q?Jing=20Shen?= <jshen_cad@yahoo.com.cn>
Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3 msgs
To: "John H. Shuler" <johnshuler@mac.com>,
        Brian E Carpenter <brc@zurich.ibm.com>
Cc: diffserv-interest@ietf.org
In-Reply-To: <BBD52D20.14B1A%johnshuler@mac.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA07737
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>
Content-Transfer-Encoding: quoted-printable

I'm not so clear with "overbooking" in DiffServ
network. To my understanding, there will be no
end-to-end explicit bandwidth allocation in DiffServ
Networks. At that of current IP network, ISP just
provides internet access to customers and core network
is overprovisioned to guarantee service quality.  So,
to my expection "logical Golden Service Network" in
DiffServ will not has explict e2e tunnel at all. Where
comes overbooking?=20




 --- "John H. Shuler" <johnshuler@mac.com> =B5=C4=D5=FD=CE=C4=A3=BA>
Brian,
>=20
> I agree. My suggestion would be to keep it simple so
> as to be easily
> implemented as a common denominator standard that
> works, then refine it over
> time after experience demonstrates a need. If it
> starts out too complicated,
> it will be too expensive to implement and therefore
> usurp the purpose.
>=20


=3D=3D=3D=3D=3D
Jing Shen

Data Communication Center
HangZhou TeleCom=20
HangZhou ZJ 310027
P.R.China

' spamcontrol '

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Fri Nov 14 08:45:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10021
	for <diffserv-interest-archive@odin.ietf.org>; Fri, 14 Nov 2003 08:45:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKeG0-0007Xz-Qn
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 08:45:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEDj4Zp028955
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 08:45:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKeFy-0007WW-RI; Fri, 14 Nov 2003 08:45:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKeFu-0007W5-KR
	for diffserv-interest@optimus.ietf.org; Fri, 14 Nov 2003 08:44:58 -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 IAA09983
	for <diffserv-interest@ietf.org>; Fri, 14 Nov 2003 08:44:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKeFt-0005DU-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 08:44:57 -0500
Received: from mtagate7.de.ibm.com ([195.212.29.156])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKeFs-0005DD-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 08:44:56 -0500
Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged))
	by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAEDiCaQ061320;
	Fri, 14 Nov 2003 13:44:16 GMT
Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])
	by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAEDhxHv061086;
	Fri, 14 Nov 2003 14:43:59 +0100
Received: from zurich.ibm.com (sig-9-145-226-156.de.ibm.com [9.145.226.156])
	by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA40972;
	Fri, 14 Nov 2003 14:43:46 +0100
Message-ID: <3FB4DBEC.B56B5F83@zurich.ibm.com>
Date: Fri, 14 Nov 2003 14:43:08 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
MIME-Version: 1.0
To: Jing Shen <jshen_cad@yahoo.com.cn>, diffserv-interest@ietf.org
Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3 
 msgs
References: <20031114121416.15063.qmail@web15213.mail.bjs.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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>
Content-Transfer-Encoding: quoted-printable

Whether a service class is over provisioned or under provisioned
(i.e. overbooked) is just an operational choice by the ISP.
For a PDB built using the EF PHB, it would be bizarre to
under-provision, but for the class selector PHBs, the default
PHB, or an AF class, under-provisioning would be a possible
choice. In fact, in a diffserv deployment, I would expect the
default PDB to be under-provisioned - otehrwise, there would
be little reason to offer "better than default" PDBs.

   Brian

Jing Shen wrote:
> =

> I'm not so clear with "overbooking" in DiffServ
> network. To my understanding, there will be no
> end-to-end explicit bandwidth allocation in DiffServ
> Networks. At that of current IP network, ISP just
> provides internet access to customers and core network
> is overprovisioned to guarantee service quality.  So,
> to my expection "logical Golden Service Network" in
> DiffServ will not has explict e2e tunnel at all. Where
> comes overbooking?
> =

>  --- "John H. Shuler" <johnshuler@mac.com> =B5=C4=D5=FD=CE=C4=A3=BA>
> Brian,
> >
> > I agree. My suggestion would be to keep it simple so
> > as to be easily
> > implemented as a common denominator standard that
> > works, then refine it over
> > time after experience demonstrates a need. If it
> > starts out too complicated,
> > it will be too expensive to implement and therefore
> > usurp the purpose.
> >
> =

> =3D=3D=3D=3D=3D
> Jing Shen
> =

> Data Communication Center
> HangZhou TeleCom
> HangZhou ZJ 310027
> P.R.China
> =

> ' spamcontrol '
> =

> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

-- =

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter =

Distinguished Engineer, Internet Standards & Technology, IBM =


NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Fri Nov 14 13:56:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24365
	for <diffserv-interest-archive@odin.ietf.org>; Fri, 14 Nov 2003 13:56:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKj6x-0007Rl-4P
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 13:56:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEIu3wS028609
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 13:56:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKj6w-0007RH-8H; Fri, 14 Nov 2003 13:56:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKj6O-0007QK-EV
	for diffserv-interest@optimus.ietf.org; Fri, 14 Nov 2003 13:55:28 -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 NAA24313
	for <diffserv-interest@ietf.org>; Fri, 14 Nov 2003 13:55:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKj6L-0002eG-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 13:55:25 -0500
Received: from smtpout.mac.com ([17.250.248.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKj6L-0002eC-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 13:55:25 -0500
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hAEItOvP013745
	for <diffserv-interest@ietf.org>; Fri, 14 Nov 2003 10:55:24 -0800 (PST)
Received: from [192.168.0.3] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hAEItNZq015535
	for <diffserv-interest@ietf.org>; Fri, 14 Nov 2003 10:55:24 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 14 Nov 2003 10:55:22 -0800
From: "John H. Shuler" <johnshuler@mac.com>
To: <diffserv-interest@ietf.org>
Message-ID: <BBDA651A.14BF7%johnshuler@mac.com>
In-Reply-To: <20031114170003.24306.22051.Mailman@www1.ietf.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Bandwidth vs. QoS
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>
Content-Transfer-Encoding: 7bit

Whether a service class is over provisioned or under provisioned
> (i.e. overbooked) is just an operational choice by the ISP.
> For a PDB built using the EF PHB, it would be bizarre to
> under-provision, but for the class selector PHBs, the default
> PHB, or an AF class, under-provisioning would be a possible
> choice. In fact, in a diffserv deployment, I would expect the
> default PDB to be under-provisioned - otehrwise, there would
> be little reason to offer "better than default" PDBs.

If I understand you properly, then we are in agreement. There is plenty of
reason to pay for higher service level, even in an over-engineered
(undersubscribed) network. Although you will get average throughput okay,
you will not receive the same jitter performance assurances (especially)
that you need for interactive video or voice, due to bursty arrival times
for other data. To get rid of this problem, it seems you would have to
engineer your network in excess even of maximum burst arrival rates.

On the other hand, if you are a service provider, why would you pay to
overprovision a network and forego QoS, when a small expense in equipment
will give you the ability to make several times the money on a given amount
of bandwidth, while at the same time providing better service quality to
your customers?

> Today's Topics:
> 
>  1. Re: Re: Diffserv-interest digest, Vol 1 #113 - 3 msgs
> (=?gb2312?q?Jing=20Shen?=)
>  2. Re: Re: Diffserv-interest digest, Vol 1 #113 - 3
>      msgs (Brian E Carpenter)
> 
> --__--__--
> 
> Message: 1
> Date: Fri, 14 Nov 2003 20:14:16 +0800 (CST)
> From: =?gb2312?q?Jing=20Shen?= <jshen_cad@yahoo.com.cn>
> Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3
> msgs
> To: "John H. Shuler" <johnshuler@mac.com>,
>       Brian E Carpenter <brc@zurich.ibm.com>
> Cc: diffserv-interest@ietf.org
> 
> I'm not so clear with "overbooking" in DiffServ
> network. To my understanding, there will be no
> end-to-end explicit bandwidth allocation in DiffServ
> Networks. At that of current IP network, ISP just
> provides internet access to customers and core network
> is overprovisioned to guarantee service quality.  So,
> to my expection "logical Golden Service Network" in
> DiffServ will not has explict e2e tunnel at all. Where
> comes overbooking?=20
> 
> 
> 
> 
> --- "John H. Shuler" <johnshuler@mac.com> =B5=C4=D5=FD=CE=C4=A3=BA>
> Brian,
>> =20
>> I agree. My suggestion would be to keep it simple so
>> as to be easily
>> implemented as a common denominator standard that
>> works, then refine it over
>> time after experience demonstrates a need. If it
>> starts out too complicated,
>> it will be too expensive to implement and therefore
>> usurp the purpose.
>> =20
> 
> 
> =3D=3D=3D=3D=3D
> Jing Shen
> 
> Data Communication Center
> HangZhou TeleCom=20
> HangZhou ZJ 310027
> P.R.China
> 
> ' spamcontrol '
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around=20
> http://mail.yahoo.com=20
> 
> 
> --__--__--
> 
> Message: 2
> Date: Fri, 14 Nov 2003 14:43:08 +0100
> From: Brian E Carpenter <brc@zurich.ibm.com>
> Organization: IBM
> To: Jing Shen <jshen_cad@yahoo.com.cn>, diffserv-interest@ietf.org
> Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3
> msgs
> 
> Whether a service class is over provisioned or under provisioned
> (i.e. overbooked) is just an operational choice by the ISP.
> For a PDB built using the EF PHB, it would be bizarre to
> under-provision, but for the class selector PHBs, the default
> PHB, or an AF class, under-provisioning would be a possible
> choice. In fact, in a diffserv deployment, I would expect the
> default PDB to be under-provisioned - otehrwise, there would
> be little reason to offer "better than default" PDBs.
> 
>  Brian
> 
> Jing Shen wrote:
>> =
> 
>> I'm not so clear with "overbooking" in DiffServ
>> network. To my understanding, there will be no
>> end-to-end explicit bandwidth allocation in DiffServ
>> Networks. At that of current IP network, ISP just
>> provides internet access to customers and core network
>> is overprovisioned to guarantee service quality.  So,
>> to my expection "logical Golden Service Network" in
>> DiffServ will not has explict e2e tunnel at all. Where
>> comes overbooking?
>> =
> 
>>  --- "John H. Shuler" <johnshuler@mac.com> =B5=C4=D5=FD=CE=C4=A3=BA>
>> Brian,
>>> 
>>> I agree. My suggestion would be to keep it simple so
>>> as to be easily
>>> implemented as a common denominator standard that
>>> works, then refine it over
>>> time after experience demonstrates a need. If it
>>> starts out too complicated,
>>> it will be too expensive to implement and therefore
>>> usurp the purpose.
>>> 
>> =
> 
>> =3D=3D=3D=3D=3D
>> Jing Shen
>> =
> 
>> Data Communication Center
>> HangZhou TeleCom
>> HangZhou ZJ 310027
>> P.R.China
>> =
> 
>> ' spamcontrol '
>> =
> 
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
> 
> -- =
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter =
> 
> Distinguished Engineer, Internet Standards & Technology, IBM =
> 
> 
> NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Diffserv-interest mailing list
> Diffserv-interest@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> 
> 
> End of Diffserv-interest Digest


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest



From exim@www1.ietf.org  Fri Nov 14 13:59:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24471
	for <diffserv-interest-archive@odin.ietf.org>; Fri, 14 Nov 2003 13:59:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKj9o-00086m-FN
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 13:59:01 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEIx06B031130
	for diffserv-interest-archive@odin.ietf.org; Fri, 14 Nov 2003 13:59:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKj9o-000860-7O; Fri, 14 Nov 2003 13:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKj9a-00085o-TJ
	for diffserv-interest@optimus.ietf.org; Fri, 14 Nov 2003 13:58:47 -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 NAA24464
	for <diffserv-interest@ietf.org>; Fri, 14 Nov 2003 13:58:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKj9Y-0002hT-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 13:58:44 -0500
Received: from smtpout.mac.com ([17.250.248.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKj9X-0002hQ-00
	for diffserv-interest@ietf.org; Fri, 14 Nov 2003 13:58:43 -0500
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id hAEIwhYN014702;
	Fri, 14 Nov 2003 10:58:43 -0800 (PST)
Received: from [192.168.0.3] (12-235-5-14.client.attbi.com [12.235.5.14])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hAEIwhZq016649;
	Fri, 14 Nov 2003 10:58:43 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 14 Nov 2003 10:58:39 -0800
From: "John H. Shuler" <johnshuler@mac.com>
To: Jing Shen <jshen_cad@yahoo.com.cn>, Brian E Carpenter <brc@zurich.ibm.com>
CC: <diffserv-interest@ietf.org>
Message-ID: <BBDA65DF.14BF9%johnshuler@mac.com>
In-Reply-To: <20031114121416.15063.qmail@web15213.mail.bjs.yahoo.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Overbooking
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>
Content-Transfer-Encoding: 7bit

You don't need to worry about overbooking if you properly engineer bandwidth
and take advantage of DiffServ mechanisms. Although you will never get
absolute, deterministic guarantees, you can get statistical guarantees that
approach determinism while avoiding the huge cost implications of a
signaled, per-flow reservation network.

> From: Jing Shen <jshen_cad@yahoo.com.cn>
> Date: Fri, 14 Nov 2003 20:14:16 +0800 (CST)
> To: "John H. Shuler" <johnshuler@mac.com>, Brian E Carpenter
> <brc@zurich.ibm.com>
> Cc: diffserv-interest@ietf.org
> Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3
> msgs
> 
> I'm not so clear with "overbooking" in DiffServ
> network. To my understanding, there will be no
> end-to-end explicit bandwidth allocation in DiffServ
> Networks. At that of current IP network, ISP just
> provides internet access to customers and core network
> is overprovisioned to guarantee service quality.  So,
> to my expection "logical Golden Service Network" in
> DiffServ will not has explict e2e tunnel at all. Where
> comes overbooking?
> 
> 
> 
> 
> --- "John H. Shuler" <johnshuler@mac.com> 的正文：>
> Brian,
>> 
>> I agree. My suggestion would be to keep it simple so
>> as to be easily
>> implemented as a common denominator standard that
>> works, then refine it over
>> time after experience demonstrates a need. If it
>> starts out too complicated,
>> it will be too expensive to implement and therefore
>> usurp the purpose.
>> 
> 
> 
> =====
> Jing Shen
> 
> Data Communication Center
> HangZhou TeleCom 
> HangZhou ZJ 310027
> P.R.China
> 
> ' spamcontrol '
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com 


_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest