Subject: [Dime] Review of draft-ietf-dime-qos-attributes-02

From: "Mark Jones" <[email-masked]>
Date: Mon, 15 Oct 2007 16:42:29 -0400

As requested, here is my review of the QoS Attributes draft (02):

Abstract: 

I think this section should explain why the QoSFilterRule AVP needs
extending, i.e. to incorporate support for the QoS parameters defined in
<ref to params draft>.

I suggest replacing the list of applications with a more inclusive
statement: The ability to convey QoS information using these attributes
is available to all new applications and existing applications where
permitted by the command ABNF.

1. Introduction

Same comment as Abstract: replace the list of applications.

I think it would be useful to explain the relationship of this draft to
the other QoS drafts (application and parameters) in this section.

3. Commands, AVPs and Advertising Application Support

I agree with Hannes and suggest removing this section. This draft is
defining AVPs and not a new application. The command ABNF here is
confusing.

4.1.  QoS-Capability AVP

I assume this AVP could also be included in CER/CEA messages. If so it
might be worth explaining this and which QoS-Capability takes precedence
when it also appears in per-session messages.

4.3.  QoS-Resources AVP

The QoS-Resources AVP structure seems overly complex to model a set of
QoS rules. I would have expected to see a QoS Rule grouped AVP that
contains zero or more QoS classifers, a QoS Profile and/or zero or more
QoS Params.  I'd appreciate an explanation of the scenarios that led to
the introduction of the QoS-ID before I propose an alternative (and
hopefully simplified) ABNF.

4.4.  Extended-QoS-Filter-Rule AVP

Typo in first sentence "TheExtended-QoS-Filter-Rule"

IMHO, NAS-Traffic-Rule is a relic from days of a flat-attribute space.
I'd prefer to see traffic classifiers/filters modeled as grouped AVPs as
proposed in 'draft-lior-diameter-classifier-00.txt'. 

4.5.  QoSBlob-Group AVP

It's not clear to me why the QoS-ID AVP is needed in this grouped AVP. I
also suggest renaming this AVP to something more meaningful than Blob
(maybe QoS-Profile-Group?).

4.7.  QoS-ObjectType

I'm unclear on why this AVP is buried in the QoSBlob-Group. When I look
at section 5, this AVP seems to be providing the context for this leg of
the QoS exchange and so I'd expect it to appear directly in the
QoS-Resources AVP. I found ObjectType too vague and suggest renaming
this to the slightly less vague QoS-Context or QoS-Semantics.

4.8.  QoSBlob AVP

Does a single instance of this AVP contain many QoS params? Again I
suggest renaming this to something more meaningful than Blob (maybe
QoS-Parameters?).

4.10.  QoS-Flow-Direction AVP

Is an IANA registry for the flow direction enumerations really
necessary? Doesn't Uplink/Downlink/Both basically cover all scenarios?

5.  Semantics of QoS Parameters

Regarding "QoS-Desired" vs "Minimum-QoS", I assume a server could
respond to a "QoS-Desired" request with a QoS profile that is greater or
less than that requested. However, it would only respond to a
"Minimum-QoS" request with a profile equal or greater than the request.
Is that correct? I think this needs more explanation in this section.

Typo 'Adminission' in the type/direction/semantic table.

6.  Examples

6.3.  QoS Authorization

It would be useful to include an alternative flow where the Server
returns a QoS-Authorized containing a profile that doesn't meet the
Desired-QoS in the request and the client rejects the end host (assuming
I've correctly understood the semantics).

6.4.  Diameter Server Initiated Re-authorization of QoS

Typo in figure: "messag".

6.5.  Diameter Credit Control with QoS Information

Typo in use case description: "Accounitng".

11.1.  Normative References

Missing reference to QoS Application draft (assuming it gets mentioned
in the Introduction as requested).

Potentially Missing:

I expected AVPs describing a collection of QoS rules to contain some
reference to rule precedence. Is this an oversight? Or does the ordering
of the QoS-Resources AVPs in the message imply rule precedence? 

Regards
Mark

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 10:21:35 +0300

Hi Mark,

thanks a lot for the good and detailed review.

> extending, i.e. to incorporate support for the QoS parameters defined in
Sounds good to me.

> permitted by the command ABNF.
Fine with me.

> the other QoS drafts (application and parameters) in this section.
In the discussion with the Diameter QoS application authors we were 
wondering whether it would make sense to have a sort of framework 
document. The text for such a framework already exists in the Diameter 
QoS application document but it would be more visible in a separate 
document. The document would essentially describe how the different 
pieces fit together.

I thought it is worth thinking about it.

> defining AVPs and not a new application. The command ABNF here is
Thanks for the feedback.

> when it also appears in per-session messages.
That's a good hint.
> hopefully simplified) ABNF.
You are essentially saying that
* you don't like the AVP names
* you don't like the QoS-ID AVP

Everything else is fine for you.

> proposed in 'draft-lior-diameter-classifier-00.txt'. 
Well. We can progress draft-lior-diameter-classifier-00.txt but if this 
document has a dependency on it then we will run into a problem since 
the document will be delayed considerably. We are a bit under pressure 
here since the 3GPP is waiting for this document.

> (maybe QoS-Profile-Group?).
The idea was to use the QoS-ID to associate a QoSBlob-Group to a 
Extended-QoS-Filter-Rule instance AND
if subsequent messages have to be sent then the QoS-ID can refer to a 
non-changed parameter.

An example for the 2nd functionality: Assume you exchange the 
QoS-Resources AVP at the beginning of the session. Later, when something 
in the QoS parameter changes but the Extended-QoS-Filter-Rule stay the 
same you just use the same QoS-ID in the QoSBlob-Group again without 
repeating the Extended-QoS-Filter-Rule.

> this to the slightly less vague QoS-Context or QoS-Semantics.
I am fine with the name change. The reason why this AVP is attached to 
the QoS parameters itself and not placed at a higher layer is that the 
semantic is indeed attached to a particular QoS parameter itself. A 
single message may carry more than one QoS parameter with a different 
QoS type.

> necessary? Doesn't Uplink/Downlink/Both basically cover all scenarios?
It is not absolutely necessary. We can also omit it.

> Is that correct? I think this needs more explanation in this section.
There are two cases here. They would most likely be used independently 
of each other.

Case 1: The Diameter Client asks for QoS authorization

When a QoS based on a signaling protocol arrives at a network element 
then you can either
* indicate what you want exactly and when these resources are not 
available then you fail or
* you offer a minimum and the desired values. The minimum represents the 
lower bound.

Now, when the network element forwards this information towards the 
Diameter server than the policy based admission control engine can 
exactly apply this policy.

Case 2: The Diameter Server provisions the Diameter Client with QoS 
information

Imagine a client attaches to the network and the Diameter Server has a 
QoS profile stored with the client. The server attaches the QoS profile 
after a successful network access authentication procedure. Now, instead 
of just providing a single value for the QoS parameter the Diameter 
server might again provide a bit more information in case that these 
resources are not available at the client. He provides a minimum and 
when the Diameter client is not able to provide that minimum then the 
session would either be terminated or continued with best effort; 
depending on the policy.

> I've correctly understood the semantics).

If the Diameter Server is not able to authorize the requested QoS 
parameters provided by the Diameter client then it would reject them 
right away and wouldn't provide information back on how much it would be 
able to authorize. Hence, the QoS-Authorized wouldn't be sent back to 
the Diameter client if the request to the  Diameter server contained a 
Desired-QoS AVP that couldn't be fulfilled.

> in the Introduction as requested).
We don't have a normative dependency on the Diameter QoS application draft.
It is fine to include it into the informative section.

> of the QoS-Resources AVPs in the message imply rule precedence? 
The ordering of the rules indicate precedence. If we haven't mentioned 
that so far then we certainly have to.

Ciao
Hannes