Subject: [Dime] QoS Application Review

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 5 Aug 2007 19:39:26 -0400

Please find below my comments after an initial review of QoS application draft. I tried to list first the generic comments/questions and then the ones which are corresponding to specific sections.

  Thanks,
  Tolga

1- As indicated during IETF69 Dime sessions as well, more explanation is necessary for push mode operation; particularly state machines and explanation of the procedures at each step of the operation. IMHO, push and pull modes seem different enough to justify two different applications.

2- An explanation of how failure scenarios need to be handled could be useful.

3- I feel like Credit Control Application (CCA) is what we need for pull mode. Functionality currently defined in the document is quite similar to it. Is the reason, why CCA is not used, addition of new AVPs with M-bit set to CCA commands? I guess, even in this case, one approach is referencing CCA and just defining new commands (with new command codes and the new AVPs) and linking them to CCA commands in terms of semantics (with semantics of the new AVPs explained in QoS document). If not all flexibility provided by CCA is necessary, this could be indicated as well. I will start a new thread about this (what to do if one wants to reuse an existing application -because the semantics provided by that application are a good match- but wants to add a few new AVPs with M-bit set) regarding its impact on Application Design Guideline work.

4- I think for push mode, the direction in the draft is the right one, i.e. using new messages to install QoS reservation.

5- I guess we should cover how emergency sessions are to be handled. I didn't check whether there is an already suitable AVP for this but some AVP identifying the priority of the QoS request could be useful (and semantics about its use should be defined as well)

6- Especially for push mode, there should be a way for NE to signal loss of an existing reservation. This mechanism should allow signaling of loss of a single flow in a session with multiple flows.

7- Some section about different use cases could be a good idea, e.g interaction between different organizations in different scenarios, NAT traversal issues etc.. It could be an idea to have this as a separate document.

8- 
1. Introduction
"However, when bandwidth is scarce and must be carefully
managed, such as in cellular networks, or when applications and
transport protocols lack the capability to perform end-to-end
congestion control, explicit reservation techniques are required."
Why is end-to-end mechanisms not suitable for the first case ("when bandwidth resources are scarce")?

9-
2. Terminology
"Application Server

An application server is a network entity that exchanges signaling
messages with an application endpoint.  It may be a source of
authorization for QoS-enhanced application flows.  For example, a
SIP server is one kind of application server."
I don't think SIP server is the right terminology for that type of functionality. SIP Application Server or SIP proxy seems to be a better example.

10- 
2. Terminology
"Application Endpoint

An application endpoint is an entity in an end user device that
exchanges signaling messages with application servers or directly
with other application endpoints.  Based on the result of this
signaling, the endpoint may make a request for QoS from the
network.  For example, a SIP User Agent is one kind of application
endpoint."
Is it mandatory for Application Endpoint to initiate application signaling before asking for QoS in an end-to-end fashion?

11-
2. Terminology
Network Element
Could be an entity different than a QoS aware router as well, e.g. a cable modem termination system.

12-
2. Terminology
Network Element
"For almost all scenarios this entity triggers the protocol interaction
described in this document."
This sentence ignores push model; "for almost all scenarios" is too strong.

13-
2. Terminology
"Push Mode
In this mode, the QoS authorization process is invoked by the
request from Application Server or local policies in the
Authorizing Entity."
What does "local policies" refer to? What is a real life example for this? Does it refer to something like installing filters statically?

14-
3. Framework
Should cover push model as well.

15-
3. Framework
"If defined properly, the interface between the routers and AAA cloud
would be identical in both cases."
Does this refer to using the same interface for push and pull modes? If so, I guess it is not true, we use different messages. 

16-
3.2.2
When listing what mode is suitable for which type of network, discussing the reasons rather than just listing the names could be better (or just deleting that part completely).

17-
3.3.1
"With the 'Two party scheme' the QoS
resource requesting entity is authenticated by the Network Element
and the authorization decision is made either locally at the Network
Element itself or offloaded to a trusted entity (most likely within
the same administrative domain).  In the former case no Diameter QoS
protocol interaction is required."
Why is QoS protocol interaction necessary for the latter case? I thought this would be completely independent of QoS reservation itself.

18-
Figure 4
I would think that an explicit "Authorization Token Request" is optional and such a token could be included in application signaling based on configuration/policy. It could be a good idea to clarify this in the text or in the figure.

19-
3.3.2
The distinction between "endpoint initiated" and "network initiated" seems a bit artificial to me. At the end, it is *something* signaled by endpoint (or is the idea application server reserving QoS out of the blue?), which triggers the QoS reservation. The level of explicitness of QoS information in that signal doesn't really matter much from QoS application perspective. 

20-
4.1
Parties Involved
"Note that the QoS resource requesting entity is only indirectly
involved in the message exchange.  This entity provides the trigger
to initiate the Diameter QoS protocol interaction by transmitting QoS
signaling messages."
I guess this part is ignoring push mode. The trigger could be application signaling from which corresponding QoS parameters can be extracted.

21-
4.2
Diameter QoS Authorization Session Establishment
"A Signaling-session-Id (if
present) SHOULD be used together with the generated Acc-Multi-
Session-Id AVP (see Section 7.3) for binding the authorization and
the accounting session information in case of end host mobility
(i.e., to correlate the Diameter sessions that are initiated for the
same signaling session from different QoS NE)."
I think we first need to define the semantics how mobility is going to work in such a case. For example, if the new NE is controlled by another organization, how would be the interaction with the initial NE?

22-
IMHO, DIAMETER_SUCCESS instead of DIAMETER_LIMITED_SUCCESS could be used. The expected message flow/behavior is already defined as parts of the procedures. Upon receipt of DIAMETER_SUCCESS, the requesting entity would know what it needs to do next.

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

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 13 Aug 2007 14:03:53 -0400

Hi, Tolga,

Thanks for the detailed review.  Sorry for taking this long to
respond.  See some comments from me below.

Asveren, Tolga wrote:
> Please find below my comments after an initial review of QoS
> application draft. I tried to list first the generic
> comments/questions and then the ones which are corresponding to
> specific sections.   
> 
>   Thanks,
>   Tolga
> 
> 1- As indicated during IETF69 Dime sessions as well, more explanation
> is necessary for push mode operation; particularly state machines and
> explanation of the procedures at each step of the operation. IMHO,
> push and pull modes seem different enough to justify two different
> applications.    

That might be a good idea; however, as was mentioned during the WG
meeting it may be possible to use both modes during a single session,
where some NEs use push mode and some NEs use pull mode.  If we allow
that, it might make more sense to keep a single application.

> 2- An explanation of how failure scenarios need to be handled could

Ok.

> 3- I feel like Credit Control Application (CCA) is what we need for
> pull mode. Functionality currently defined in the document is quite
> similar to it. Is the reason, why CCA is not used, addition of new
> AVPs with M-bit set to CCA commands? 

We didn't see the need to include CCA commands; all the credit-control
information is contained in the QAR/QAA.  The approach in the draft
is much simpler than the CCA and IMHO in contains all the needed
functionality.

> I guess, even in this case, one
> approach is referencing CCA and just defining new commands (with new
> command codes and the new AVPs) and linking them to CCA commands in
> terms of semantics (with semantics of the new AVPs explained in QoS
> document). 

That's essentially what we did; we re-used the Cost-Information,
Cost-Unit, Tariff-Time-Change, and CC-Time AVPs within the
Diameter QoS commands but provided a much simpler framework
in which to work.

> If not all flexibility provided by CCA is necessary, this
> could be indicated as well. I will start a new thread about this
> (what to do if one wants to reuse an existing application -because
> the semantics provided by that application are a good match- but
> wants to add a few new AVPs with M-bit set) regarding its impact on
> Application Design Guideline work.            

Ok let's talk about this.  IMHO the commands in the Diameter QoS
application are the ones we want to use.

> 4- I think for push mode, the direction in the draft is the right
> one, i.e. using new messages to install QoS reservation. 

Ok.

> 5- I guess we should cover how emergency sessions are to be handled.
> I didn't check whether there is an already suitable AVP for this but
> some AVP identifying the priority of the QoS request could be useful
> (and semantics about its use should be defined as well)   

I suppose we might need such an AVP either in QAA or QIR, in the
case where the Authorizing Entity knows about the emergency status;
Alternatively, such a field could be added to NSIS if only the
AE knows about the emergency status.  I am not sure whether 
such a field exists in NSIS - maybe experts could speak up?

> 6- Especially for push mode, there should be a way for NE to signal
> loss of an existing reservation. This mechanism should allow
> signaling of loss of a single flow in a session with multiple flows.  

Are you thinking that the NE might be monitoring the flow for
active traffic, and then timeout when it detects no packets
for a certain period of time?  We need to watch out for confusing
loss of bearer with silence suppression.  Maybe you have in mind
that some specific link-layer trigger that tears-down the flow.
In general, we also may want to react to NSIS signaling that
"politely" tears down a flow.

If we keep every flow as a different Diameter QoS session, it
should be possible to terminate them independently.  Hopefully
we can just use STR / ASR for termination.

> 7- Some section about different use cases could be a good idea, e.g
> interaction between different organizations in different scenarios,
> NAT traversal issues etc.. It could be an idea to have this as a
> separate document.   

Ok let's think about this.

> 8-
> 1. Introduction
> "However, when bandwidth is scarce and must be carefully managed,
> such as in cellular networks, or when applications and transport
> protocols lack the capability to perform end-to-end congestion
> control, explicit reservation techniques are required."   

I see your point - maybe we can remove that clause.

> authorization for QoS-enhanced application flows.  For example, a SIP
> server is one kind of application server."   
> I don't think SIP server is the right terminology for that type of
> functionality. SIP Application Server or SIP proxy seems to be a
> better example.  

I am ok with "SIP Application Server."

> signaling, the endpoint may make a request for QoS from the network. 
> For example, a SIP User Agent is one kind of application endpoint."  
> Is it mandatory for Application Endpoint to initiate application
> signaling before asking for QoS in an end-to-end fashion? 

I think the application negotiation (what codec to use etc.) needs
to complete before a properly formed NSIS reservation is made.
So at least, the signaling must have started before a request 
can be made.  If you look at the SIP Preconditions RFC that's
where RSVP signaling is traditionally integrated.

> cable modem termination system. 

If a given NE is not an IP-addressable entity then it can't
participate in path-coupled signaling.  My preference would 
be to keep the notion of a NE = Router.

> 12-
> 2. Terminology
> Network Element
> "For almost all scenarios this entity triggers the protocol
> interaction described in this document." 

Ok, we can take this out.

> 13-
> 2. Terminology
> "Push Mode
> In this mode, the QoS authorization process is invoked by the request
> from Application Server or local policies in the Authorizing Entity." 
> What does "local policies" refer to? What is a real life example for
> this? Does it refer to something like installing filters statically? 

I think this has to do with some confusion about the role of
the Authorizing Entity.  In my mind the Authorizing Entity
equals either a home subscriber database or an Application Server.
In some people's mind the AE is a local PDF which communicates
over a separate entity to an Application Server.  I'd be ok with
removing "Application Server or local policies in" from the sentence.

> Should cover push model as well.

Ok.

> Does this refer to using the same interface for push and pull modes?
> If so, I guess it is not true, we use different messages. 

It refers to using the same interface whether the AE is a static
subscriber database or an active Application Server.  We should 
clarify.

> 16-
> 3.2.2
> When listing what mode is suitable for which type of network,
> discussing the reasons rather than just listing the names could be
> better (or just deleting that part completely).  

I'd be ok with deleting it.  Dong may have a different opinion.

> Why is QoS protocol interaction necessary for the latter case? I
> thought this would be completely independent of QoS reservation
> itself.  

In the latter case there is a protocol needed between the NE and
the "trusted entity".  In the draft that is assumed to be the
Diameter QoS Application.  However, this is not really two-party
scheme anymore... I'd be ok with removing that part.

> 18-
> Figure 4
> I would think that an explicit "Authorization Token Request" is
> optional and such a token could be included in application signaling
> based on configuration/policy. It could be a good idea to clarify
> this in the text or in the figure.   

It is necessary for the NE to be able to fill in the Destination-Realm
field for proper routing of the QAR (pull mode) or for the
Application Server to fill in the Destination-Realm of the QIR (push
mode).  Thus something needs to be exchanged in the application
signaling; a "token" is an ok name for that, IMHO.  Maybe we can
improve the wording a bit here.

> 19-
> 3.3.2
> The distinction between "endpoint initiated" and "network initiated"
> seems a bit artificial to me. At the end, it is *something* signaled
> by endpoint (or is the idea application server reserving QoS out of
> the blue?), which triggers the QoS reservation. The level of
> explicitness of QoS information in that signal doesn't really matter
> much from QoS application perspective.     

I agree.

> I guess this part is ignoring push mode. The trigger could be
> application signaling from which corresponding QoS parameters can be
> extracted.  

Agreed.  We should re-word.

> 21-
> 4.2
> Diameter QoS Authorization Session Establishment "A
> Signaling-session-Id (if 
> I think we first need to define the semantics how mobility is going
> to work in such a case. For example, if the new NE is controlled by
> another organization, how would be the interaction with the initial
> NE?   

Need to think about this one some more.

> 22-
> IMHO, DIAMETER_SUCCESS instead of DIAMETER_LIMITED_SUCCESS could be
> used. The expected message flow/behavior is already defined as parts
> of the procedures. Upon receipt of DIAMETER_SUCCESS, the requesting
> entity would know what it needs to do next.   

Ok with me.

-Pete

---

From: Tina TSOU <[email-masked]>
Date: Tue, 14 Aug 2007 20:06:11 +0800

Hi all,
Basically, are we saying we are going to use Credit Control Appl. for PULL 
mode, and QoS Appl. for PUSH mode?

B. R.
Tina

----- Original Message ----- 
From: "McCann Peter-A001034" <[email-masked]>
To: "Asveren, Tolga" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 14, 2007 2:03 AM
Subject: RE: [Dime] QoS Application Review

Hi, Tolga,

Ok.

Ok.

Ok.

I agree.

Ok with me.

-Pete

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 21 Aug 2007 09:19:43 -0400

Hi Pete,

Please find below a few more questions/comments (and sorry for the late
reply).

  Thanks,
  Tolga

> that, it might make more sense to keep a single application.
[TOLGA] Using different modes could be possible to reserve resources for
a single service session, but this probably would map to multiple
sessions from Diameter perspective. It seems to me that push and pull
modes are quite different from protocol operations perspective. Both in
terms of document organization/readability purposes and also for message
routing purposes (e.g. if there is an authorizing entity, which can
support only pull-mode scenarios, messages for push-mode sessions should
not be routed to it)two applications could be a good alternative.

[..snip..]
> application are the ones we want to use.
[TOLGA]I agree. I think the current approach in the QoS document is in
the right direction. We keep preaching to define new
commands/applications when new mandatory AVPs are added/semantics are
changed, so I guess this is a good example of what one should do.

[..snip..]
> such a field exists in NSIS - maybe experts could speak up?
[TOLGA]Even if there is support from NSIS, we may need an
emergency-level AVP for push mode.
> "politely" tears down a flow.
[TOLGA] What I had in mind was more close to what you described second.
For example to allocate resources for an emergency call, it could be
necessary to release some resources which are previously allocated for
another call. I think it makes sense to notify PDF of such cases, so
that it takes necessary action.
> we can just use STR / ASR for termination.
[TOLGA] That could help simplify things from protocol perspective. PDF
would need to associate different Diameter sessions to a single service
session but I guess this should be fine.