Subject: [Dime] Making decisions regarding QoS Work

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 07 May 2007 22:20:59 +0200

Hi all,

working on the WG status update I noticed that we are behind schedule 
with our Diameter QoS work and subsequently I have had a chat with Dan 
about this subject.

At the last IETF meeting we had a presentation regarding recently 
submitted QoS documents (see 
http://www1.ietf.org/mail-archive/web/dime/current/msg01338.html). In 
short, we made a document management action by splitting the work into:

1) Quality of Service Parameters
http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt

This document just describes the different QoS parameters.

2) Quality of Service Attribute
http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt

This document redefines the QoS-Filter-Rule AVP based on the previously 
mentioned QoS parameters. It needs to be aligned with 
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt 
as that document progresses. This is a short document.

3) Quality of Service Application

This document describes the Diameter QoS application.

Document #2 (and therefore document #1) is needed by the 3GPP for Rel.7 
(from a functionality point of view although the current reference 
points to the Diameter QoS application draft). Hence, there is a 
considerable amount of pressure to get the work done. #3 needs more work 
particularly with respect to question (c) below.

We need to make three decisions in order to move the work forward.

a) Are there objections to turn 
draft-korhonen-dime-qos-parameters-00.txt into a WG item?

b) Are there objections to turn 
draft-korhonen-dime-qos-attributes-00.txt into a WG item?

c) What content from 
http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requirements-01 
should be incorporated into 
http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 and pushed to 
future work?

Please respond to (a), (b) and/or (c) by 19th May 2007.

Ciao
Hannes

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

---

From: <[email-masked]>
Date: Wed, 9 May 2007 05:46:06 +0200

Hi all,

Having my own vested interests on these I support having
a) & b) as WG items.

No comment on c) yet.

Cheers,
	Jouni

> Hi all,
> 
> working on the WG status update I noticed that we are behind 
> schedule with our Diameter QoS work and subsequently I have 
> had a chat with Dan about this subject.
> 
> At the last IETF meeting we had a presentation regarding 
> recently submitted QoS documents (see 
> http://www1.ietf.org/mail-archive/web/dime/current/msg01338.ht
> ml). In short, we made a document management action by 
> splitting the work into:
> 
> This document redefines the QoS-Filter-Rule AVP based on the 
> previously mentioned QoS parameters. It needs to be aligned 
> with 
> Document #2 (and therefore document #1) is needed by the 3GPP 
> for Rel.7 (from a functionality point of view although the 
> current reference points to the Diameter QoS application 
> draft). Hence, there is a considerable amount of pressure to 
> get the work done. #3 needs more work particularly with 
> respect to question (c) below.
> 
> http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 
> and pushed to future work?
>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 09 May 2007 18:04:31 +0800

Hi all,
c)
I think the following from Sun's draft could be moved to the QoS draft:

(1) 2.2 Resource Control models which give an overview of push & pull models
(2) 2.4 Functional framework & 2.5 its use cases
(3) We need section 3 describing new "server-initiated" commands. However
the AVPs need more consideration for e.g. some AVP like
QoS-Authorization-Resources to be added? Also PI-Request-Type AVP is
unnecessary as the RCDE will use ASR, RAR for terminate, update purposes.
(4) Section 4 which describe session initiation, update & termination for
push model. This draft implies extending & using the RFC 3588 server state
machine at RCDE. But this is not agreed by the WG yet.

B. R.
Tina
+86-755-28972912 (Office)    +86-13922884380 (Mobile)
Messengers:
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber:
[email-masked]    Google talk: [email-masked]

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 09, 2007 11:46 AM
Subject: RE: [Dime] Making decisions regarding QoS Work

Hi all,

No comment on c) yet.

Cheers,
Jouni

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 9 May 2007 15:50:32 -0500

Hi All,

Concerning the item c) - QoS application, as I commented some time ago,
the current draft only covers the NE (e.g. router)/endpoint initiated
policy Pull model, however, the Push model in which the QoS attributes
are proactively installed by the policy server is not yet addressed. 

A bunch of network technologies and deployment scenarios are requiring
the Push model now, and several SDOs have defined the Push model as a
requirement in policy control framework, e.g. ETSI TISPAN, DSL Forum,
ITU-T NGN and CableLabs (maybe WiMAX forum), it is also envisaged as the
evolution of policy control mechanism since it can mitigate the
dependence of the QoS control on the endpoint's capability and simplify
the endpoint's implementation. 

Two options to move forward this QoS application work in my mind:
1) Define a single WG item to cover both Pull and Push models
2) Define two WG items to address Pull and Push model separately

I personally prefer to create a single WG item to address both Pull and
Push models. Certainly, we need to look into details how to integrate
the Resource-control-application ID into the QoS application draft.

Cheers,
Dong   

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]] 
Sent: Wednesday, May 09, 2007 6:05 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Dime] Making decisions regarding QoS Work

Hi all,
c)

(1) 2.2 Resource Control models which give an overview of push & pull
models
(2) 2.4 Functional framework & 2.5 its use cases
(3) We need section 3 describing new "server-initiated" commands.
However the AVPs need more consideration for e.g. some AVP like
QoS-Authorization-Resources to be added? Also PI-Request-Type AVP is
unnecessary as the RCDE will use ASR, RAR for terminate, update
purposes.
(4) Section 4 which describe session initiation, update & termination
for push model. This draft implies extending & using the RFC 3588 server
state machine at RCDE. But this is not agreed by the WG yet.

B. R.
Tina
+86-755-28972912 (Office)    +86-13922884380 (Mobile)
Messengers:
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU
Jabber:
[email-masked]    Google talk: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 09, 2007 11:46 AM
Subject: RE: [Dime] Making decisions regarding QoS Work

Hi all,

No comment on c) yet.

Cheers,
Jouni

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 10 May 2007 17:22:49 -0400

Dear Hannes and all,

I support making a) and b) WG documents. I need some more time to review
and comment on the item c).

-Kuntal

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, May 07, 2007 3:21 PM
> To: [email-masked]
> Subject: [Dime] Making decisions regarding QoS Work
> 
> Hi all,
> 
> This document redefines the QoS-Filter-Rule AVP based on the
previously
> mentioned QoS parameters. It needs to be aligned with
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.tx
t

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 15 May 2007 08:24:59 -0400

a) I think draft-korhonen-dime-qos-parameters-00.txt should be a WG
item.
b) I have mixed ideas about draft-korhonen-dime-qos-attributes-00.txt.
The current document does not provide much information about semantics.
>From syntax point of view, I guess even without this document, QoS AVPs
could be added to relevant messages, if they have the AVP wildcard.
Probably we first need to decide about the scope of this draft.
c) AFAICS, although draft-ietf-dime-diameter-qos-00 is defining a
generic mechanism, its tone does not provide enough emphasis on the
"push-mode" operation, whereas in
draft-sun-dime-diameter-resource-control-requirements-01 this mode is
explained more clearly. IMHO, this is an area, where
draft-ietf-dime-diameter-qos-00 can be improved.

   Thanks,
   Tolga

> Sent: Monday, May 07, 2007 4:21 PM
> To: [email-masked]
previously

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 18 May 2007 17:19:32 -0400

Support for the push model is already a part of 
draft-ietf-dime-diameter-qos-00.txt, as outlined
in Section 4.4.  However, the text also notes the
limitations of this model, in that the discovery
problem needs to be solved.  To initiate a session,
the Authorizing Entity would need to discover the
name of a Diameter Client for use in the Destination-Host
AVP.  I would like to see a scalable and open specification
for how to do this on the global Internet before we
add more text about the push model to the draft.  I
have heard some proposals from various SDOs such as
keeping a giant table of IP addresses (of UEs) mapped
to Diameter Clients.  I think such solutions aren't
scalable in scenarios where the Authorizing Entity is
in a different administrative domain from the Network 
Element.  As noted in the draft, the push model is
only applicable when the Authorizing Entity and the
Network Element are local to each other, i.e., in the
same administrative domain.  I would hope that our 
architecture does not require e.g., a SIP server to
be local to the domain providing network access.  We
should keep in mind the end-to-end principle and not
try to facilitate the creation of walled gardens.

Personally, I would like to see endpoints deploy a
network-layer protocol (such as NSIS) for requesting
QoS from the network rather than relying on SIP for
this purpose.  SIP is an application layer that should
be located anywhere on the Internet, not coupled to the
packet path.  I would like to see support for an
authorization token in the form of an NAI that can be
used for routing the request to the proper Authorizing
Entity in the usual way (i.e., routing based on the
User Name AVP).

-Pete

Sun, Dong (Dong) wrote:
> Hi All,
> 
> Concerning the item c) - QoS application, as I commented some time
> ago, the current draft only covers the NE (e.g. router)/endpoint
> initiated policy Pull model, however, the Push model in which the QoS
> attributes are proactively installed by the policy server is not yet
> addressed.    
> 
> A bunch of network technologies and deployment scenarios are
> requiring the Push model now, and several SDOs have defined the Push
> model as a requirement in policy control framework, e.g. ETSI TISPAN,
> DSL Forum, ITU-T NGN and CableLabs (maybe WiMAX forum), it is also
> envisaged as the evolution of policy control mechanism since it can
> mitigate the dependence of the QoS control on the endpoint's
> capability and simplify the endpoint's implementation.      
> 
> I personally prefer to create a single WG item to address both Pull
> and Push models. Certainly, we need to look into details how to
> integrate the Resource-control-application ID into the QoS
> application draft.   
> 
> Cheers,
> Dong
> 
> models (2) 2.4 Functional framework & 2.5 its use cases
> purposes. (4) Section 4 which describe session initiation, update &
> termination for push model. This draft implies extending & using the
> RFC 3588 server state machine at RCDE. But this is not agreed by the
> WG yet.     
> 
> B. R.
> Tina
>> with our Diameter QoS work and subsequently I have had a chat with
>> Dan about this subject. 
>> 
>> ml). In short, we made a document management action by splitting the
>> work into: 
>> 
>> previously mentioned QoS parameters. It needs to be aligned with
>> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-r
>> ules-02.txt as that document progresses. This is a short document.
>> 
>> 
>> Document #2 (and therefore document #1) is needed by the 3GPP for
>> Rel.7 (from a functionality point of view although the current
>> reference points to the Diameter QoS application draft). Hence, there
>> is a considerable amount of pressure to get the work done. #3 needs
>> more work particularly with respect to question (c) below.
>> 
>> http://tools.ietf.org/html/draft-sun-dime-diameter-resource-co
>> ntrol-requirements-01 should be incorporated into