Re: [Diffserv-interest] QoS in diffserv network

Brian E Carpenter <brc@zurich.ibm.com> Sun, 09 November 2003 18:29 UTC

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’s
> bandwidth and silver service was allocated x/2 percent of
> the link’s 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