Subject: FW: [Dime] Updated QoS Drafts

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 8 Mar 2007 23:37:30 -0600

Fyi. seems the following message was not posted to the exploder...

-----Original Message-----
From: Sun, Dong (Dong) 
Sent: Thursday, March 08, 2007 5:10 PM
To: 'Hannes Tschofenig'
Cc: [email-masked]
Subject: RE: [Dime] Updated QoS Drafts

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,

thanks for your clarifications. Please find some comments below:

Sun, Dong (Dong) wrote:
>  
> 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-re
> qu
> irements-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.
> "
> ~~~~~~~~~~~~~~~~~
>
> [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.
>   
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.

> 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 agree that it would be good to integrate features whenever possible.
We just need to figure out how todo that.

> 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.
>   

Ciao
Hannes
 
> Regards,
> Dong
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>   

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