Subject: [Dime] Updated QoS Drafts

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Mar 2007 12:50:47 +0200

Hi all,

new versions of the QoS documents are available as you have seen from 
the draft
announcements. I would like to clarify the relationship between the 
documents:

http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00

   This document describes the Diameter QoS application.

http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt

   This document contains QoS parameters taken from an NSIS working 
group document
   and placed into a separate document. We did this to (a) improve 
readability, (b) remove
   functionality that is not needed for the Diameter action and to (c) 
at the same time
   leverage existing work. Currently we assume that the same registry is 
used.
   The final decision depends on the policy for adding new parameters to 
the registry.

   These QoS parameters are utilized by 
<draft-ietf-dime-diameter-qos-00>, by
   <draft-korhonen-dime-qos-attributes-00.txt> and by corresponding RADIUS
   documents.

http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt

   This document defines the Extended-QoS-Filter-Rule in the spirit of the
   QoS-Filter-Rule.
   Unlike the <draft-ietf-dime-diameter-qos-00> document it addresses 
scenarios
   where the updated QoS-Filter-Rule attribute is carried within other 
applications.
   It therefore only addresses a limited set of scenarios. One could 
compare the
   approach  with the mobility documents.
 
   This document also assumes that an extended version of the 
IPFilterRule attribute
   is available. Currently, the required extensions are described in
   <draft-ietf-dime-diameter-qos-00> and "imported" into this document.
   There is ongoing work in the RADEXT working group to define a more 
powerful
   version of the IPFilterRule / NAS-Traffic-Rule, see
   http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt

   We obviously need to align our work with the RADEXT working group with
   regard to this aspect since the newly defined attribute will be made 
available as
   described in the Diameter Compatibility section of
   <draft-ietf-radext-filter-rules-02.txt>.

http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requirements-01

  This document takes a different spin and extends the 
<draft-ietf-dime-diameter-qos-00>
  document by supporting a "generic push" approach. By "generic push" I 
refer to the
  ability of an arbitrary entity, such as an SIP proxy, to signal to 
another box.
  Note that this is not the same as the server-initiated communication.

Ciao
Hannes

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

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 7 Mar 2007 17:21:08 -0600

Hi,
Some clarifications and comments:
~~~~~~~~~~~~~
-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 5:51 AM
To: [email-masked]
Subject: [Dime] Updated QoS Drafts

Hi all,
...
...
"
http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requ
irements-01

"
~~~~~~~~~~~~~~~~~

[Dong] The "Push model" defined in above I-D doesn't aim to define the
ability of an arbitrary entity, such as a SIP proxy, to signal to
another box. This document actually addresses the same interface as in
the current QoS application (draft-ietf-dime-diameter-qos-00). Since the
current QoS application only supports the Pull model that is not
suitable for some circumstances (e.g. when the network elements cannot
trigger the QoS authorization request and/or the endpoint does not
support any QoS signaling/capability, which is quite common in wireline
networks), the I-D intends to complement current QoS application
document and make a generic framework in order to support various
networks, endpoints and applications.
Currently, this document mainly focuses on discussing the requirements
and framework of a generic resource control system, and also proposes
some potential solutions to solve the issue. IMO, it will be better to
integrate this document with QoS application document together to
formulate a single document on this subject since the scope and
objective of these two are quite similar. 

I'd like to get others' opinion on the integration of these two
documents.

P.S.: the solution proposed in this document is kind of Diameter server
initiated communication. There are some discussions on this issue in the
exploder recently triggered by an ITU-T liaison, it has not yet reached
a consensus though. 

Regards,
Dong

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Mar 2007 12:04:42 +0200

Hi Dong,

thanks for your clarifications. Please find some comments below:

> Some clarifications and comments:
I agree that draft-ietf-dime-diameter-qos-00 is not particularly strong 
on the description of  server-initiated  communication.
This is, however, a basic feature of the Diameter Base protocol.
 
Typically, server-initiated messages are still sent after the initial 
session setup took place based on an interaction with the Diameter client.
For example, you have a network access authentication procedure taking 
place. Then, during the lifetime of the session some authorization 
relevant aspects change at the Diameter server and it initiates a 
re-authorization exchange.

> objective of these two are quite similar. 
I agree that it would be good to integrate features whenever possible.
We just need to figure out how todo that.

Ciao
Hannes

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 8 Mar 2007 16:10:15 -0600

Hi Hannes,

Concerning the integration of features into QoS application, I'd like to
have discussion on some high level issues before getting into detailed
edits. 
some items could be considered in my mind. Once we have consensus on
these items, the relevant mechanisms can be discussed afterwards.
1. Support of Push Model as defined in the "resource control application
requirements"
I feel it is critical to support both Pull and Push models in the same
framework. The Push model here refers to the case that no Diameter
session is pre-established from NE (Diameter Client) to authorizing
entity (Diameter server). In fact, the Push model is perceived as the
trend to support the policy control due to the merits of flexibility,
complexity and scalability required on the underlying network
technologies. Further details can be found in the aforementioned
document. 

2. Extension of the scope of QoS application 
The current QoS application mainly addresses one aspect of resource
control/policy enforcement, i.e. bandwidth and performance metrics.
Although it is one of the most important aspects, it would be good to
include some other aspects, e.g. NAT traversal and NAPT control since
these functions are commonly collocated with QoS policy enforcement in
the same NE, which results in some correlation between them, e.g. the
change of media flow IP 5-tuple.

3. Compatibility of command codes with other SDOs
I have no strong preference on the command codes, but just concerned
about the usage of the QoS application in reality due to the
incompatibility. Just wondering if it is possible to make 3GPP/PP2
modify their specs according to the command codes currently defined in
QoS application document? If not, who will use this document in the
implementation? For which kind of use cases?

Regards,
Dong

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, March 08, 2007 5:05 AM
To: Sun, Dong (Dong)
Cc: [email-masked]
Subject: Re: [Dime] Updated QoS Drafts

Hi Dong,

Sun, Dong (Dong) wrote:
>   document by supporting a "generic push" approach. By "generic push" 
> I refer to the

> the current QoS application (draft-ietf-dime-diameter-qos-00). Since 
> the current QoS application only supports the Pull model that is not 

> support any QoS signaling/capability, which is quite common in 
> wireline networks), the I-D intends to complement current QoS 
> application document and make a generic framework in order to support 
> various networks, endpoints and applications.
>   
 
session setup took place based on an interaction with the Diameter
client.

> P.S.: the solution proposed in this document is kind of Diameter 
> server initiated communication. There are some discussions on this 
> issue in the exploder recently triggered by an ITU-T liaison, it has 
> not yet reached a consensus though.
>   

Ciao
Hannes

---

From: Avi Lior <[email-masked]>
Date: Thu, 22 Mar 2007 00:40:20 -0400

The Diameter QoS Application was written to server a particular need.

I think we should incorporate a push and a pull model into that document.

Its not like some SDO is waiting for us to finish this work.  We do probably need to work on the QoS attributes and we should be using the approach of working on them outside this document.  We need to finish the QoS attribute work fast.

Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183

From: Hannes Tschofenig
Sent: Thu 3/8/2007 5:04 AM
To: Sun, Dong (Dong)
Cc: [email-masked]
Subject: Re: [Dime] Updated QoS Drafts

Hi Dong,

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 09:09:07 +0100

Hi Avi, 

> From: Avi Lior [mailto:[email-masked]] 
> Sent: 22. maaliskuuta 2007 6:40
> To: Hannes Tschofenig; Sun, Dong (Dong)
> Cc: [email-masked]
> Subject: RE: [Dime] Updated QoS Drafts
> 
>  
>  
> Its not like some SDO is waiting for us to finish this work.  

3GPP wants it now for rel-7.. even though the reference is still
to draft-tschofenig-dime-diameter-qos-01. The stuff 3GPP is after
is in the WG qos draft as well.

Cheers,
	Jouni

> We do probably need to work on the QoS attributes and we 
> should be using the approach of working on them outside this 
> document.  We need to finish the QoS attribute work fast.
>  
> ________________________________
> 
> From: Hannes Tschofenig
> I agree that draft-ietf-dime-diameter-qos-00 is not 
> particularly strong on the description of  server-initiated  
> communication.
> Typically, server-initiated messages are still sent after the 
> initial session setup took place based on an interaction with 
> the Diameter client.
> For example, you have a network access authentication 
> procedure taking place. Then, during the lifetime of the 
> session some authorization relevant aspects change at the 
> Diameter server and it initiates a re-authorization exchange.
>