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

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

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>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>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