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

"John H. Shuler" <johnshuler@mac.com> Mon, 10 November 2003 19:13 UTC

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