Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #113 - 3 msgs

Brian E Carpenter <brc@zurich.ibm.com> Mon, 10 November 2003 19:52 UTC

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