Subject: [Dime] Re: RPH Example

From: ken carlberg <[email-masked]>
Date: Fri, 2 Nov 2007 17:32:18 -0400

Hannes,

First, my apologies for the very tardy response.  And second, thanks  
for the extended thoughts below.  It helps clarify the question you  
raised previously.

Now, taking your example as is, I have no disagreement.....*within*  
the context of the scenario you describe.  However, one can take a  
different approach and consider SIP operating in a walled garden, or  
even in a B2BUA with co-resident SBCs.  In either of these cases, QoS  
is derived from a statistical estimate where one correlates a  
bandwidth range per call (which are congruent with data paths) and one  
traffic engineers the paths accordingly.  In other words, there are  
efforts that *loosely* emulate some circuit switched designs that  
aren't reliant on direct references to QoS.   They simply count calls  
and use a max count to  minimize the chance of congestion.  Thus, I  
can still have an interest to prioritize calls, but I may not have a  
need to articulate anything about QoS in my signaling or data packets.

And again, I'm in agreement with your subsequent email where QoS  
profiles can be defined that only include the subset of QoS parameters  
that are needed.  But, I go back to the email exchange I came across  
where someone didn't have an interest in your QoS parameters draft in  
order to support their need to respond to Priority parameters because  
they had no interest in QoS.

In viewing the situation as a whole, I think it might be better to  
look into defining an optional AVP extension to rfc-4740 that  
correlates to the resource priority field of rfc-4412.

cheers,

-ken

On Oct 28, 2007, at 8:17 AM, Hannes Tschofenig wrote:

> Hi Ken,
>
> let me give you a concrete example.
>
> Let's assume a SIP proxy receives a RPH and wants to ask the AAA  
> server whether this user is authorized to use this specific RPH.
> Here is how this could look like, assuming that Filter-Rules are not  
> important in this specific case (they are optional anyway).
>
>
> AAA client -> AAA server:
> ----------------------------
>
> * QoS-ObjectType
>
> with the information that the provided QoS information is of type  
> "QoS-Desired". The semantic is
> "Please authorize the indicated QoS"
>
> * RPH Priority Parameter (from Section 4.11 of
> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt) 
>  encapsulated
> in the QoSBlob AVP (as the only QoS parameter in this example).
>
> These two AVPs are encapsulated in the QoSBlob-Group and contained  
> in the QoS-Resources AVP. This encapsulation is simply necessary  
> when you use grouped AVPs. Without using grouped AVPs one would have  
> to add additional fields to indicate how the individual AVPs relate  
> to each other.
>
> Note that the QoS-Profile AVP, which indicates the QoS profile, is  
> not necessary in this example since the RPH Priority refers to a  
> parameter from the base profile document. (This is not yet in the  
> draft since we haven't published the updated draft based on the  
> provided feedback yet).
>
>
>
> AAA client <- AAA server:
> ----------------------------
>
> Authorization successful or failed. No QoS information needs to be  
> repeated here in our example.
>
>
> Now you tell me what should be further removed. Is this really  
> complicated or does the current document just look complicated?
>
>
> Ciao
> Hannes
>
> ken carlberg wrote:
>>
>> On Oct 26, 2007, at 11:17 AM, Hannes Tschofenig wrote:
>>
>>> Hi Ken,
>>>
>>> ken carlberg wrote:
>>>> Hannes,
>>>>
>>>> What are your thoughts about defining a new AVP exclusively for  
>>>> priority?  I don't have concerns about the inclusion of priority  
>>>> in the QoS parameters draft.  However, I recently came across an  
>>>> email exchange related to IMS where one of the participants  
>>>> didn't want to consider using the QoS parameters draft for  
>>>> validating SIP R-P information because of the bundled QoS.
>>> Can you more specific on how the desired approach would look like?
>>
>> at a very high level, an approach that strips out the QoS elements  
>> discussed in
>> draft-ietf-dime-diameter-qos-01.txt
>> draft-ietf-dime-qos-parameters-01.txt
>> and focuses on the application of AAA of Priority values we may see
>>> from protocols like SIP and its R-P header.  And yes, this probably
>> equates to thinner documents :-)
>>
>> -ken
>

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 6 Nov 2007 16:49:53 +0100

Hi Ken, 

> for the extended thoughts below.  It helps clarify the question you  
Don't worry.

> need to articulate anything about QoS in my signaling or data packets.

I fully understand this usage scenario. 

> they had no interest in QoS.

That's fine as well. 
In that particular organization where this work is done they would just
register a new profile that only indicates what type of priority values
would be used. 

As a consequence, there wouldn't be a single "QoS attribute" (note that
I believe that priority values are also QoS values) flying between the
Diameter Client and the Diameter server.  

> correlates to the resource priority field of rfc-4412.
My above suggestion would essentially do what you have in mind. 

Ciao
Hannes