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

["John H. Shuler" <[e-mail]>]

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 <[e-mail]>
> Organization: IBM
> Date: Mon, 10 Nov 2003 20:49:58 +0100
> To: "John H. Shuler" <[e-mail]>
> Cc: [e-mail]
> 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: [e-mail]
>>> Reply-To: [e-mail]
>>> Date: Mon, 10 Nov 2003 12:00:03 -0500
>>> To: [e-mail]
>>> Subject: Diffserv-interest digest, Vol 1 #113 - 3 msgs
>>> 
>>> Send Diffserv-interest mailing list submissions to
>>> [e-mail]
>>> 
>>> 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
>>> [e-mail]
>>> 
>>> You can reach the person managing the list at
>>> [e-mail]
>>> 
>>> 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 ([e-mail])
>>>  3. Re: QoS in diffserv network (Brian E Carpenter)
>>> 
>>> --__--__--
>>> 
>>> Message: 1
>>> Date: Sun, 09 Nov 2003 19:26:48 +0100
>>> From: Brian E Carpenter <[e-mail]>
>>> Organization: IBM
>>> To: Feng Y <[e-mail]>
>>> CC: [e-mail]
>>> 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: [e-mail]
>>> Organization: Alcatel,
>>> To: Brian E Carpenter <[e-mail]>
>>> Cc: Feng Y <[e-mail]>, [e-mail]
>>> 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="[e-mail]">
>>> <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 <[e-mail]>
>>> Organization: IBM
>>> To: [e-mail]
>>> CC: Feng Y <[e-mail]>, [e-mail]
>>> Subject: Re: [Diffserv-interest] QoS in diffserv network
>>> 
>>>> [e-mail] 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
>>> 
>>> 
>>> End of Diffserv-interest Digest
>> 
>> _______________________________________________
>> Diffserv-interest mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
> 
> NEW ADDRESS <[e-mail]> PLEASE UPDATE ADDRESS BOOK


_______________________________________________
Diffserv-interest mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/diffserv-interest