Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06]

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 22 Jul 2008 17:40:39 -0500

Hi Tolga,
 
Thanks for review and comments. see my responses inline...
copy to all authors in case they have further comments.
 
Rgs,
Dong

-------- Original Message -------- 
Subject:        [Dime] Comments for draft-ietf-dime-diameter-qos-06     
Date:   Fri, 18 Jul 2008 11:19:22 -0400 
From:   Asveren, Tolga <[email-masked]>  
To:     <[email-masked]> 

1- Use of the same Application-Id for push/pull models
It sounds reasonable to me to think nodes which support only a single
mode. How can we guarantee that messages land to the right server
considering that the same Application-Id is used for both of them?
[Sun, Dong (Dong)]  The trigger for initiating the push and pull models
is different, for example, when a new request from the PEP is recevied,
the Server will start the pull model. In fact, the push and pull are
sharing the same state machine per se. the main difference is just how
to establish a Diameter session. The enhancement is to allow the
Diameter Server to establish a session with a local trigger instead of
the trigger from the Diameter client (i.e. NE/PEP). Therefore, I don't
think the same application-Id causes any problem, especially for the
pull model since push/pull is able use the same server (certainly they
can also have separate server according to the configuration).

2- 3. Framework
   "After receiving the
   authorization request from the AppS or the NE, the AE decides the
   appropriate mode (i.e.  Push or Pull).  The usage Push or Pull mode
   can be determined by the authorizing entity either statically or
   dynamically."
I think I am missing something here. Don't we have always push mode if
the authorization request is received from AppS? Or are we talking about
a hybrid model where first AppS contacts the Authorizing Entity,
receives a token, hands it over to media layer, and this token is used
in turn by NE for pull mode?
[Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my
understanding is that the push and pull models can be decided by AE on
per call session basis (i.e. dynamically), or can be pre-configured for
one of them (i.e. statically). If this is correct, the texts may be
modified as follows for clarity:

 "The push and pull models can be decided by the AE on per call session
basis (i.e. dynamically), or can be pre-configured for one of them (i.e.
statically). Without any pre-configuration, when receiving a new
authorization request from the Apps or a local trigger, the AE starts
the Push model; when receiving a new authorization request from the NE,
the AE starts the Pull model."

[Sun, Dong (Dong)] Tina,  I thought the initial texts come from you.
could you verify my comment or give some further clafication. are you ok
with the modified texts? 

I will update the document accordingly if no objection. 

3- 3. Framework
   "For Push mode, the authorizing entity needs to identify the
   appropriate NE(s) to which QoS authorization information needs to be
   pushed.  It might determine this based on information received from
   the AppS, such as the IP addresses of media flows."
It could be a good idea to give a bit more information about this:
- This is hard to do as Authorizing Entity would need to have
information about routing decisions of NEs for a particular flow
-  QoS in the core network is usually not scarce
-  QoS on the access side is scarce
-  It is not difficult for the Authorizing Entity to determine NEs
facing the access side as usually this information is stored somewhere
when the endpoint attaches to the network and does not change per IP
flow.
[Sun, Dong (Dong)]  my understanding is the NEs for Policy enforcement
are usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the
discovery of these NEs is not necessarily based on the routing info,
instead, it can be preconfigured. 

In addition, i think this draft mainly focuses on the mechanism and
protocol. It can be used for both access and core networks. the QoS
status you described looks like well known, not sure how much it may
add.

4- 3.4 QoS Application Requirements

      "Identity-based Routing
      The QoS AAA protocol MUST route AAA requests to the Authorizing
      Entity, based on the provided identity of the QoS requesting
      entity or the identity of the AE encoded in the provided
      authorization token."

I think it is responsibility of the QoS application -not QoS AAA
protocol- to perform routing decision based on identity. The application
decided for the host/realm and the protocol routes the message based on
that.

I think it could be better to have a global change in this section:
QoS AAA protocol ==> QoS AAA application

[Sun, Dong (Dong)]  looks ok to me.

5- 3.4 QoS Application Requirements
      "Sending Accounting Records
      The NE SHOULD be able to send accounting records for a particular
      QoS reservation state to an accounting entity."
Is this a QoS AAA application requirement? It is stated as a requirement
on NE.

[Sun, Dong (Dong)]  it is for NE, since we decided to remove the
accounting related texts, this one could be gone, IMHO. 

6- 4.2 Session Establishment
   "When a QoS-Authz-Request
   (QAR, see Section 5.1) message with a new session ID is received, the
   AE operates in the Pull mode; when other triggers are received, the
   AE operates in the Push mode."
Would this shut down the door for certain failure recovery scenarios?
For example AE goes down and a backup AE takes over. IMO it is a nice
feature if the backup can continue existing sessions without a need to
synchronizing state with the failed active AE. This can be achieved by
carrying enough information about session state in the message itself
(AFAIR, DCCA can do this nicely). The approach I quoted makes this
impossible. For certain scenarios backup AE would determine the required
mode wrong. I suggest the decision for push/pull is not based on message
name but on the message content.

[Sun, Dong (Dong)]  I think this is the most straightforward and
consistent way in terms of state machine to decide the pull/push. and it
will work well for the hot standby case, but indeed, it may have some
issue with cold standby. In general, the failure handling is not
addressed in the draft very much. The question is, do we need to add the
failure handling in detail or not for backup server case? 

7- There were some proposals about a mode, where NE is notified from AE
to reserve resources all the way till the end point. Is this considered
out of scope?

[Sun, Dong (Dong)]  it can be supporoted implicited by the applicaion,
but it is not a different mode, just an implementation of resource
reservation within the bearer layer. it is mentioned in the section 9 as
example.

Thanks,
Tolga

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

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

---

From: Tina TSOU <[email-masked]>
Date: Wed, 23 Jul 2008 10:45:25 +0800

[Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]Hi Tolga, Dong et al,
See comments in line beginning with [Tina: ...]

Cheers from 30 degree hot Shenzhen,
Tina
  ----- Original Message ----- 
  From: Sun, Dong (Dong) 
  To: [email-masked] 
  Cc: [email-masked] ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Tina TSOU ; Glen Zorn 
  Sent: Wednesday, July 23, 2008 6:40 AM
  Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

  Hi Tolga,

  Rgs,
  Dong

  -------- Original Message -------- 
  Subject:        [Dime] Comments for draft-ietf-dime-diameter-qos-06     
  Date:   Fri, 18 Jul 2008 11:19:22 -0400 
  From:   Asveren, Tolga <[email-masked]>  
  To:     <[email-masked]> 

  [Sun, Dong (Dong)]  The trigger for initiating the push and pull models is different, for example, when a new request from the PEP is recevied, the Server will start the pull model. In fact, the push and pull are sharing the same state machine per se. the main difference is just how to establish a Diameter session. The enhancement is to allow the Diameter Server to establish a session with a local trigger instead of the trigger from the Diameter client (i.e. NE/PEP). Therefore, I don't think the same application-Id causes any problem, especially for the pull model since push/pull is able use the same server (certainly they can also have separate server according to the configuration).

  2- 3. Framework
     "After receiving the
  [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my understanding is that the push and pull models can be decided by AE on per call session basis (i.e. dynamically), or can be pre-configured for one of them (i.e. statically). If this is correct, the texts may be modified as follows for clarity:

   "The push and pull models can be decided by the AE on per call session basis (i.e. dynamically), or can be pre-configured for one of them (i.e. statically). Without any pre-configuration, when receiving a new authorization request from the Apps or a local trigger, the AE starts the Push model; when receiving a new authorization request from the NE, the AE starts the Pull model."

  [Sun, Dong (Dong)] Tina,  I thought the initial texts come from you. could you verify my comment or give some further clafication. are you ok with the modified texts? 

  [Tina: As is specified in the document, "the diversity of QoS capabilities
  of endpoints and QoS schemes of network technology leads to the distinction
  on the interaction mode between QoS authorization system and underlying
  NEs". 

  Therefore, I think the hybrid model should be supported. After receiving a
  new authorization request from the AppS, the AE can decide which mode should
  be used based on the information of the request, especially based on the
  information which indicates QoS capability and the access network type. So I
  don't see any problem with the original text. 

  However, as is proposed by Hannes, the <QoS-Capability> AVP could be added
  into the QoS-Request message. Besides, I think the <Access-Network-Type> AVP
  should also be added to indicate the network technology since the network
  technology is another factor affecting the type of QoS Model being used.]

  3- 3. Framework
  [Sun, Dong (Dong)]  my understanding is the NEs for Policy enforcement are usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the discovery of these NEs is not necessarily based on the routing info, instead, it can be preconfigured. 

  In addition, i think this draft mainly focuses on the mechanism and protocol. It can be used for both access and core networks. the QoS status you described looks like well known, not sure how much it may add.

        "Identity-based Routing

  [Sun, Dong (Dong)]  it is for NE, since we decided to remove the accounting related texts, this one could be gone, IMHO. 

  [Sun, Dong (Dong)]  I think this is the most straightforward and consistent way in terms of state machine to decide the pull/push. and it will work well for the hot standby case, but indeed, it may have some issue with cold standby. In general, the failure handling is not addressed in the draft very much. The question is, do we need to add the failure handling in detail or not for backup server case? 

  [Sun, Dong (Dong)]  it can be supporoted implicited by the applicaion, but it is not a different mode, just an implementation of resource reservation within the bearer layer. it is mentioned in the section 9 as example.

  Thanks,
  Tolga

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 23 Jul 2008 12:47:08 -0400

Hi Dong,

A few comments/questions below.

Thanks,
Tolga

> From: Sun, Dong (Dong) [mailto:[email-masked]]
> Sent: Tuesday, July 22, 2008 6:41 PM
> To: Asveren, Tolga
> Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-
> A001034; Avri Doria; Tina TSOU; Glen Zorn
> [Sun, Dong (Dong)]  The trigger for initiating the push and pull
models is
> different, for example, when a new request from the PEP is recevied,
the
> Server will start the pull model. In fact, the push and pull are
sharing
> the same state machine per se. the main difference is just how to
> establish a Diameter session. The enhancement is to allow the Diameter
> Server to establish a session with a local trigger instead of the
trigger
> from the Diameter client (i.e. NE/PEP). Therefore, I don't think the
same
> application-Id causes any problem, especially for the pull model since
> push/pull is able use the same server (certainly they can also have
> separate server according to the configuration).
[TOLGA]My concern here is about message routing rather than the state
machine processing in the server. Let's say a server is capable only to
accommodate pull model (it doesn't know what NE to contact if push model
is required). How can the network intermediaries, e.g. relay agent,
forward the initial request in the session to the right server for push
model? How can they be sure that the server supports push model?
> understanding is that the push and pull models can be decided by AE on
per
> call session basis (i.e. dynamically), or can be pre-configured for
one of
> them (i.e. statically). If this is correct, the texts may be modified
as
> follows for clarity:
the
> Push model; when receiving a new authorization request from the NE,
the AE
> starts the Pull model."
could
> you verify my comment or give some further clafication. are you ok
with
> the modified texts?
are
> usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the
discovery
> of these NEs is not necessarily based on the routing info, instead, it
can
> be preconfigured.
status
> you described looks like well known, not sure how much it may add.
[TOLGA]Even for some of the nodes you mentioned, I would expect routing
to play a role here. For example if there are more than one gateway, AE
needs to know which one it should contact for that particular stream. 
> issue with cold standby. In general, the failure handling is not
addressed
> in the draft very much. The question is, do we need to add the failure
> handling in detail or not for backup server case?
[TOLGA]I agree that details of failure handling may not belong here.
OTOH that the QoS application is failover friendly is a parameter to
consider IMHO. By carrying enough information in each message so that
cold standby elements can be used to take over existing sessions, one
trades small amount of bandwidth and limited CPU cycles for complexity
in software and probably even more CPU cycles. IMHO this is a bargain. I
found this very handy in DCCA. Wouldn't just defining an AVP indicating
the type of service requested (push v.s. pull) solve this problem?
Actually this issue is also tied to Application-Id problem. If different
Application-Ids are used, that implicitly will define the mode
required/used.
> [Sun, Dong (Dong)]  it can be supporoted implicited by the applicaion,
but
> it is not a different mode, just an implementation of resource
reservation
> within the bearer layer. it is mentioned in the section 9 as example.
[TOLGA]I think I couldn't explain well what I meant. The model I am
talking about is that AE tells NE to reserve resources not only in
itself but also through the whole bearer path, e.g. RSVP from edge
router to edge router. Is it possible to do this with this version of
QoS application draft? 
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 23 Jul 2008 14:22:44 -0400

Hi Tina,

One question below.

Thanks,
Tolga

[.. snip ..]
per
one of
as
the
the AE
could
with
> information which indicates QoS capability and the access network
type. So
> I
> into the QoS-Request message. Besides, I think the
<Access-Network-Type>
> AVP
[TOLGA]I just am trying to understand the use case:
I understand that endpoints will have different QoS reservation
capabilities. 
i- I have a device, which can't reserve QoS for the media but can
indicate its desire to do so in signaling. AppS would determine that
push mode is desired.

ii- I have a device, which can't reserve QoS for the media and can't
indicate its desire to do so in signaling. AppS could determine
statically what to do.

iii- I have a device, which can reserve QoS for the media. It uses its
own capabilities whenever it needs. 

I guess what I am trying to figure out is, why decision process does not
belong to AppS? 

For <Access-Network-Type>, I can see that this type of information could
be useful, e.g. a device attached via DOCSIS to IP network v.s. a device
attached via a 3GPP technology. OTOH, isn't this information actually
necessary in AppS so that it can determine whether it should ask for QoS
resources? 
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 23 Jul 2008 18:16:16 -0500

My comments inline...
Rgs,
Dong 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 12:47 PM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann
Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn
Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

Hi Dong,

Thanks,
Tolga

> 1- Use of the same Application-Id for push/pull models It sounds 
> reasonable to me to think nodes which support only a single mode. How 
> can we guarantee that messages land to the right server considering 
> that the same Application-Id is used for both of them?
models is
the
sharing

trigger
same

[TOLGA]My concern here is about message routing rather than the state
machine processing in the server. Let's say a server is capable only to
accommodate pull model (it doesn't know what NE to contact if push model
is required). How can the network intermediaries, e.g. relay agent,
forward the initial request in the session to the right server for push
model? How can they be sure that the server supports push model?
[Dong] The relay agent should route the message according to the
destination address/realm that is filled up by the requestor. I don't
know how the application id will affect this kind of routing.

per
one of
as
the
the AE
could
with

are
discovery
can
status
[TOLGA]Even for some of the nodes you mentioned, I would expect routing
to play a role here. For example if there are more than one gateway, AE
needs to know which one it should contact for that particular stream. 
[Dong] in practice a rendezvous AE or hierarchical AEs will derive the
address of the right gateway according to preconfigured info in a
database or through DNS query. The point is that the NE/PEP is an
anchoring point for certain streams per provisioning, not random routing
for selecting those PEPs (except load balancing). In other words, not
every NE/router is eligible to serve as the PEP in reality.
> QoS AAA protocol ==> QoS AAA application [Sun, Dong (Dong)]  looks ok 
> to me.
> 

addressed

[TOLGA]I agree that details of failure handling may not belong here.
OTOH that the QoS application is failover friendly is a parameter to
consider IMHO. By carrying enough information in each message so that
cold standby elements can be used to take over existing sessions, one
trades small amount of bandwidth and limited CPU cycles for complexity
in software and probably even more CPU cycles. IMHO this is a bargain. I
found this very handy in DCCA. Wouldn't just defining an AVP indicating
the type of service requested (push v.s. pull) solve this problem?
Actually this issue is also tied to Application-Id problem. If different
Application-Ids are used, that implicitly will define the mode
required/used.
[Dong] I don't think it makes sense to mandate this kind of parameter
for failover since it is more useful for one type of failure handling
approach rather than the other. But it is ok to have an optional
parameter but it does add significant overhead in the message. In
addition, not sure why the application id is tied up with this issue,
even in general the routing issue as I explained above. 
I think the failure handling approach should be consistent for all
Diameter applications rather than defining specific one for QoS
application.
but
reservation
[TOLGA]I think I couldn't explain well what I meant. The model I am
talking about is that AE tells NE to reserve resources not only in
itself but also through the whole bearer path, e.g. RSVP from edge
router to edge router. Is it possible to do this with this version of
QoS application draft? 
[Dong] sure. Absolutely. Current QoS application draft does support it
if the NE is able to use the RSVP. However, how to support the RSVP in
the NE (procedure, mechanism) is out of scope in this draft.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 23 Jul 2008 18:16:16 -0500

My comments inline...
Rgs,
Dong 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 12:47 PM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Hi Dong,

Thanks,
Tolga

models is
the
sharing

trigger
same

per
one of
as
the
the AE
could
with

are
discovery
can
status

addressed

but
reservation

---

From: Tina TSOU <[email-masked]>
Date: Thu, 24 Jul 2008 17:17:08 +0800

Hi Dong,
I agree with you:-)

Cheers,
Tina
  ----- Original Message ----- 
  From: Sun, Dong (Dong) 
  To: Asveren, Tolga 
  Cc: [email-masked] ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Tina TSOU ; Glen Zorn 
  Sent: Thursday, July 24, 2008 7:16 AM
  Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

  My comments inline...
  Rgs,
  Dong 

  -----Original Message-----
  From: Asveren, Tolga [mailto:[email-masked]] 
  Sent: Wednesday, July 23, 2008 12:47 PM
  To: Sun, Dong (Dong)
  Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann
  Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn
  Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

  Hi Dong,

  Thanks,
  Tolga

  models is
  the
  sharing

  trigger
  same

  per
  one of
  as
  the
  the AE
  could
  with

  are
  discovery
  can
  status

  addressed

  but
  reservation

---

From: Tina TSOU <[email-masked]>
Date: Thu, 24 Jul 2008 17:22:28 +0800

Hi Tolga,
Good question:-)
Comments in line beginning with [Tina: ...]

Cheers,
Tina
  ----- Original Message ----- 
  From: Asveren, Tolga 
  To: Tina TSOU ; Sun, Dong (Dong) 
  Cc: Glen Zorn ; Avri Doria ; McCann Peter-A001034 ; Tschofenig, Hannes (NSN - FI/Espoo) ; [email-masked] 
  Sent: Thursday, July 24, 2008 2:22 AM
  Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

  Hi Tina,

  One question below.

  Thanks,
  Tolga

  [.. snip ..]
  per
  one of
  as
  the
  the AE
  could
  with
  type. So
  <Access-Network-Type>

  [Tina: The AppS belongs to the service layer and in theory it is unaware of the network technology topology and the network technology. The AppS only sends out an authorization request and expects to get a response. It doesn't need to know how the authorization is done, e.g. in Pull mode or Push mode.]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 24 Jul 2008 11:13:08 -0400

(Continuing in separate threads for each issue for easier tracking.)

Hi Dong,

One comment below.

Thanks,
Tolga

[.. snip ..]
> know how the application id will affect this kind of routing.
[TOLGA]The initial message of a session may have only Destination-Realm.
In such a case Application-Id is used by intermediaries to select the
right server.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 24 Jul 2008 11:25:48 -0400

Hi Dong,

One question below.

Thanks,
Tolga

[.. snip ..]
> every NE/router is eligible to serve as the PEP in reality.
[TOLGA] The point I am missing is how does the AE now the NE(s)/PEP(s)
to be used for a particular stream? The list of such entities on the
path for a stream is obviously determined according to some
algorithm/configuration but I am not sure whether AE has the complete
information. Let's take an example:

        +-------+
        |       |
    +---|  AE   |-----------+
    |   +-------+           |
    |          |            |
    |          |            |
    |          |            |
    |          |            |
    |          |            |
    |          |         +------+
    |          |    .....|      |
  +------+     |    .    | NE2  |
  |      |...........    +------+
  |  NE1 |...........
  +------+     |    .
               |    .
               |    .    +------+
               +----.----|      |
                    .....| NE3  |
                         +------+

How does the AE know whether NE2 or NE3 will be chosen by NE1 for a
particular flow?
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 24 Jul 2008 11:44:20 -0400

Hi Dong,

Comments/questions below.

Thanks,
Tolga

[.. snip ..]
> > consistent way in terms of state machine to decide the pull/push.
and
> it
[TOLGA]
1) One can argue the other way around as well: Why exclude some piece of
information which is useful for certain type of failover mechanism. IMHO
the added overhead is negligible and I am pretty sure much less than the
overhead of a hot standby system (let alone the extra complexity it
requires)

2) If push/pull modes use different Application-Ids that could be used
easily to decide for which mode the message is received. OTOH I agree
that this itself wouldn't help for failover friendliness.

3) There are certainly a few things which can be done in base protocol
to help failover handling. OTOH base protocol is application state
machine agnostic. I don't see how it can help there.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 24 Jul 2008 11:57:35 -0400

Hi Dong,

One question below.

Thanks,
Tolga

> the NE (procedure, mechanism) is out of scope in this draft.
[TOLGA] How to indicate to NE whether it needs to reserve resources only
for itself or also reserve resources through the path (for example with
RSVP)? Is there an AVP for this? 
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 24 Jul 2008 13:18:33 -0500

Tolga,
Comments inline.
Dong 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 11:13 AM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann
/ Application-Id

Hi Dong,

One comment below.

Thanks,
Tolga

[.. snip ..]
[TOLGA]The initial message of a session may have only Destination-Realm.
In such a case Application-Id is used by intermediaries to select the
right server.
[Dong] In the context of QoS application, for the pull mode, the NE
typically is configured by a default policy server or redirect server. I
don't think the scenario you are concerned is a common case in reality
although theoretically the base Diameter protocol may allow this kind of
behavior, but it is not the case for QoS application, IMHO.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 24 Jul 2008 13:30:49 -0500

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 11:26 AM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann
/ AE topology aware?

Hi Dong,

One question below.

Thanks,
Tolga

[.. snip ..]

        +-------+
        |       |
    +---|  AE   |-----------+
    |   +-------+           |
    |          |            |
    |          |            |
    |          |            |
    |          |            |
    |          |            |
    |          |         +------+
    |          |    .....|      |
  +------+     |    .    | NE2  |
  |      |...........    +------+
  |  NE1 |...........
  +------+     |    .
               |    .
               |    .    +------+
               +----.----|      |
                    .....| NE3  |
                         +------+

[Dong] I assume you knew well how to get it in the access network.
You're mainly concerned about the core network case, right? Let's look
at this example: in the core network, each edge router is responsible
for certain access network domains (or in other words, the BRAS/edge
router is configured to route the traffic to a particular edge router in
the core, for the simplicity, assuming NE1 is for 10.1.x.x, NE2 for
10.2.x.x, NE3 for 10.3.x.x, when the AE receives a request from AF with
the global routable IP address of the end user, it can derive the
targeting NE straightforward. Certainly some additional info e.g
IP-tuple, subscriber id and traffic classifier might be useful to
provide further granularity to allocate the right NE as needed
(dependent on the network configuration and Traffic engineering
approach).
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 24 Jul 2008 13:48:51 -0500

Tolga,
Since you agreed that the general failure handling for Diameter is out
of scope in the QoS application. In principle, I don't see the necessity
to include extra overhead as the mandatory parameters. Frankly, the
failure handling of the Diameter Server is a quite comprehensive issue.
Sofar, the QoS application should provide some basic failure handling
e.g. clean up the expired sessions, but I am not sure if it is
appropriate to discuss what you address in the QoS application
exclusively. I assume it should be part of base protocol or separate
document (I am not sure if it already has) since they are supposed to
generic to all applications.

See additional comments inline.

Rgs,
Dong

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 11:44 AM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann
/ failover friendliness

Hi Dong,

Thanks,
Tolga

[.. snip ..]
and

[TOLGA]
1) One can argue the other way around as well: Why exclude some piece of
information which is useful for certain type of failover mechanism. IMHO
the added overhead is negligible and I am pretty sure much less than the
overhead of a hot standby system (let alone the extra complexity it
requires)
[Dong] as indicated, this is not my intention to discuss all possible
varieties for failure handover to the standby Diameter server. I assume
a generic mechanism should be applied to QoS application.

2) If push/pull modes use different Application-Ids that could be used
easily to decide for which mode the message is received. OTOH I agree
that this itself wouldn't help for failover friendliness.
[Dong] Using different application id for push/pull makes the state
mechanism less efficient and does not add too much value for the routing
since the scenarios you are concerned are not common (i.e. the message
cannot provide a destination address) in reality for QoS application,
IMHO. (sorry for saying this).

3) There are certainly a few things which can be done in base protocol
to help failover handling. OTOH base protocol is application state
machine agnostic. I don't see how it can help there.
[Dong] the failover handling you described does not look like a specific
case only for QoS application. In fact the failure of the server does
not affect too much for ongoing bearer sessions since they will remain
anyway. And I am not sure if the NE is the best option to store all
session info due to the cost effectiveness and processing capacity
issues. Maybe the synchronization between two servers is more efficient,
to some extent.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 24 Jul 2008 15:09:34 -0400

Hi Tina,

One more question below.

Thanks,
Tolga

> Sent: Thursday, July 24, 2008 11:58 AM
> To: Asveren, Tolga
> Subject: FW: [Fwd: [Dime] Comments for
draft-ietf-dime-diameter-qos-06]
> 
> 
> 
> ________________________________________
> From: Tina TSOU [mailto:[email-masked]]
> Sent: Thursday, July 24, 2008 5:22 AM
> To: Sun, Dong (Dong); Asveren, Tolga
> A001034; Avri Doria; Glen Zorn
> Subject: Re: [Fwd: [Dime] Comments for
draft-ietf-dime-diameter-qos-06]
> > [Sun, Dong (Dong)] I don't think we are talking about a hybrid
model.
> my
> > new authorization request from the AppS, the AE can decide which
mode
> > should
> [Tina: The AppS belongs to the service layer and in theory it is
unaware
> of the network technology topology and the network technology. The
AppS
> only sends out an authorization request and expects to get a response.
It
> doesn't need to know how the authorization is done, e.g. in Pull mode
or
> Push mode.]
[TOLGA]What you said sounds reasonable but with that model, i.e. AppS
completely unaware of networking technology, would AppS need to ask
authorization for each and every call? As an example let's consider
IMS-mobile. Do we expect AppS to ask for authorization for each call
even for IMS-mobile calls, where actually none of them would have
required push mode of operation?
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Tina TSOU <[email-masked]>
Date: Fri, 25 Jul 2008 15:40:38 +0800

Dear Tolga,
Comments in line demarked with [Tina: ...]

B. R.
Tina
  ----- Original Message ----- 
  From: Asveren, Tolga 
  To: Tina TSOU ; Sun, Dong (Dong) 
  Cc: [email-masked] ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Glen Zorn 
  Sent: Friday, July 25, 2008 3:09 AM
  Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

  Hi Tina,

  One more question below.

  Thanks,
  Tolga

  model.
  mode
  unaware
  AppS
  It
  or
  [Tina: The AppS is aware of the service provided for each call. If the authorization/QoS is needed for a call, the AppS will send a request to AE and then get a response from AE. If the authorization/QoS is not needed for a call, the AppS will not send a request to AE. This has nothing to do with network topology. Furthermore, this behavior of the AppS has nothing to do with the push or pull mode. To put it in another way, if an authorization/QoS is needed for a call, the AppS just sends a request to the AE, and it doesn't need to predict either the push or pull mode would be used. Even if all the calls would require the pull mode of operation, I see no problem that the AppS sends a request for each call, one by one. I believe you didn't mean there would be a batch request for a group of calls, since different calls normally have different start and termination time.]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 Jul 2008 11:12:25 -0400

Hi Dong,

Inline....

Thanks,
Tolga

> Sent: Thursday, July 24, 2008 2:19 PM
> To: Asveren, Tolga
> Subject: RE: [Fwd: [Dime] Comments for
draft-ietf-dime-diameter-qos-06] /
> Application-Id
[TOLGA] How can we make sure that a request requiring push mode
capabilities is delivered to the right server? That was my initial
question. There could be servers which only have authorization
capability but do not have any topology information, i.e. not suitable
for push mode operation. And what type of problems would be introduced
if we used two different Application-Ids?
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 Jul 2008 11:18:17 -0400

Hi Dong,

inline....

Thanks,
Tolga

> Sent: Thursday, July 24, 2008 2:31 PM
> To: Asveren, Tolga
> AE topology aware?
> > >    appropriate NE(s) to which QoS authorization information needs
to
> > be
> > > of these NEs is not necessarily based on the routing info,
instead,
> information. Let's take an example:
[TOLGA]I don't think we can assume that just by destination IP address
the full set of NEs to be traversed can be determined without ambiguity.
My comment was about difficulties associated with push model if
end-to-end reservation is the goal. Just adding a few sentences to
indicate that push model is more suitable for access side reservation
would be enough. In any case, this wasn't a comment impacting normative
sections of the draft so either way is fine for me.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 Jul 2008 11:37:47 -0400

Hi Dong,

inline....

Thanks,
Tolga

> Sent: Thursday, July 24, 2008 2:49 PM
> To: Asveren, Tolga
> failover friendliness
> > >    (QAR, see Section 5.1) message with a new session ID is
received,
> > > feature if the backup can continue existing sessions without a
need
> to
> >
> > > synchronizing state with the failed active AE. This can be
achieved
> by
> > in software and probably even more CPU cycles. IMHO this is a
bargain.
> IMHO. (sorry for saying this).
[TOLGA]IMHO you are introducing unnecessary restrictions for no reason.
Diameter message routing is making use of Application-Id for initial
requests. If you have a problem with this, you should voice your
concerns for the 3588-bis document. Otherwise violating base protocol
principles on a per application basis doesn't make sense to me.
> issues. Maybe the synchronization between two servers is more
efficient,
[TOLGA]I don't think it is ever possible that base protocol can provide
redundancy features to cover for all application redundancy needs
without any involvement from application itself. If you have any
strategy in mind to deal with this problem please tell it.
Actually what I am asking for is to remove a failover-unfriendly feature
rather than adding new stuff to facilitate redundancy. I really don't
understand what is bad about including an AVP indicating the type. I
simply don't buy the overhead argument.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 Jul 2008 12:16:12 -0400

Resending.....

Hi Dong,

inline....

Thanks,
Tolga

received,
need
achieved
bargain.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 Jul 2008 12:34:39 -0400

Hi Tina,

inline....

Thanks,
Tolga

> Sent: Monday, July 28, 2008 11:38 AM
> To: Asveren, Tolga
> Sent: Friday, July 25, 2008 3:41 AM
> Cc: Glen Zorn; Avri Doria; McCann Peter-A001034; Tschofenig, Hannes
(NSN -
> FI/Espoo); [email-masked]
> Cc: [email-masked] ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann
Peter-
> A001034 ; Avri Doria ; Glen Zorn
> draft-ietf-dime-diameter-qos-06]
Peter-
> > Cc: Glen Zorn ; Avri Doria ; McCann Peter-A001034 ; Tschofenig,
Hannes
> > (NSN - FI/Espoo) ; [email-masked]
> > > I think I am missing something here. Don't we have always push
mode
> if
> > > understanding is that the push and pull models can be decided by
AE
> on
> > > be used based on the information of the request, especially based
on
> > > However, as is proposed by Hannes, the <QoS-Capability> AVP could
be
> > added
> [Tina: The AppS is aware of the service provided for each call. If the
> authorization/QoS is needed for a call, the AppS will send a request
to AE
> and then get a response from AE. If the authorization/QoS is not
needed
> for a call, the AppS will not send a request to AE. This has nothing
to do
> with network topology. Furthermore, this behavior of the AppS has
nothing
> to do with the push or pull mode. To put it in another way, if an
> authorization/QoS is needed for a call, the AppS just sends a request
to
> the AE, and it doesn't need to predict either the push or pull mode
would
> be used. Even if all the calls would require the pull mode of
operation, I
> see no problem that the AppS sends a request for each call, one by
one. I
> believe you didn't mean there would be a batch request for a group of
> calls, since different calls normally have different start and
termination
> time.]
[TOLGA]I think we are almost in agreement. So there is still some choice
to be made in AppS based on the QoS needs. In an ideal world, I would
expect the terminal to signal its QoS needs so that AppS can perform an
intelligent decision here. Contacting AE where it actually wasn't
necessary needs to be avoided as much as possible. Otherwise we even
could end up with double-booking, i.e. both the terminal and AppS
reserve resources for the same stream.

BTW, can you explain your proposed semantics for <Access-Network-Type>?
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 28 Jul 2008 11:52:43 -0500

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 11:12 AM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Hi Dong,

Inline....

Thanks,
Tolga

[TOLGA] How can we make sure that a request requiring push mode
capabilities is delivered to the right server? That was my initial
question. There could be servers which only have authorization
capability but do not have any topology information, i.e. not suitable
for push mode operation. And what type of problems would be introduced
if we used two different Application-Ids?
[Dong] Either Application Server or UE or NE needs to perform the
selection of AE according to its capabilities. In the case there are
different AEs for push or pull respectively, a rendezvous AE will make a
selection according to the policy, network technology and/or request
attribute. 
The problem to have two different application id is to mandate the
selection of an AE per its capabilities to the AppS (or NE), it is
inconsistent with the basic rationale of the QoS application (i.e.
maintain the network neutrality). Moreover, it makes the QoS application
and implementations more complex since two packages have to be
developed...
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 28 Jul 2008 12:01:50 -0500

See inline...
Dong 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 11:18 AM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Hi Dong,

inline....

Thanks,
Tolga

to

instead,

[TOLGA]I don't think we can assume that just by destination IP address
the full set of NEs to be traversed can be determined without ambiguity.
My comment was about difficulties associated with push model if
end-to-end reservation is the goal. Just adding a few sentences to
indicate that push model is more suitable for access side reservation
would be enough. In any case, this wasn't a comment impacting normative
sections of the draft so either way is fine for me.
[Dong] I think we are repeating the same argument here ;-). If you are
seeking a theoretical example which the transport network is totally out
of scope for the user traffic control (i.e. no TE, no tunneling, no
provisioning), the Push model indeed has some issue. However, in that
case, I suspect how/why the PEP is needed. 
The end-to-end reservation, to me, is a requirement, rather than a
methodology. We may achieve this objective through a segment by segment
reservation, which the push does work well...
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 28 Jul 2008 12:06:42 -0500

Inline... 
Rgs, - Dong

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 12:16 PM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Resending.....

Hi Dong,

inline....

Thanks,
Tolga

received,
need
achieved

bargain.

[TOLGA]I don't think it is ever possible that base protocol can provide
redundancy features to cover for all application redundancy needs
without any involvement from application itself. If you have any
strategy in mind to deal with this problem please tell it.
Actually what I am asking for is to remove a failover-unfriendly feature
rather than adding new stuff to facilitate redundancy. I really don't
understand what is bad about including an AVP indicating the type. I
simply don't buy the overhead argument.
[Dong]I don't think the approach you described is a specific requirement
only to the QoS application. Then why don't we generalize the issue and
method rather than adding something only to the QoS application. In
addition, it is obvious an optional approach for failure handling, and I
don't think current draft prevents any implementation from adding the
optional parameters as needed.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 Jul 2008 15:56:59 -0400

Hi Dong,

Let's talk over an example because I seriously think we are cross
talking each other and there probably are a few things I don't
understand about QoS application:

Org-1 is the service provider
Org-2 is the IP access provider

App-push is the application-Id for push mode (if different AppIds used)
App-pullthe application-Id for pull mode (if different AppIds used)

AppQ is the application-Id for QoS application (if a single AppId is
used)

                       +-----+
                       |AppS | (Org1)
                       +-----+
                          |
         +-------+        |
 (Org2)  |AE-gw  |--------+
         +-------+
             |
             |
         +-------+
  (Org2) |  AE1  |
         +-------+
             |
             |
         +-------+
  (Org2) |  NE1  |
         +-------+      
A) With different Application-Ids
1- AppS receives a new session request and determines that QoS needs to
be reserved on the access side for a particular flow. It determines (by
whatever means) that the access side is controlled by Org2. 

2- It sends the initial request with Destination-Realm=Org2 and
Application-Id=push. This request reaches AE-gw via standard Diameter
Base Protocol routing (during capability exchange procedure AE-gw
advertised App-push)
[Actually here AppS will need to rely on some provisioning as well as
capability advertisement is not done per realm, i.e. it won't be clear
to AppS that AE-gw supports push-mode for Org2 realm. This IMHO is a
missing piece of functionality in Diameter base protocol but can be
fixed relativel easily]

3- AE-gw routes the message to AE based on standard Diameter base
protocol routing (during capability exchange procedure AE1 advertised
App-push). There could be other AEs in the network which are unable to
process this request because they do not know the binding between IP
addresses and NEs. This is not a problem though as they would advertise
only app-pull during capability exchange procedure)

What is here that violates network neutrality?

B) With a single Application-Id   
1- AppS receives a new session request and determines that QoS needs to
be reserved on the access side for a particular flow. It determines (by
whatever means) that the access side is controlled by Org2.

2- It sends the initial request with Destination-Realm=Org2 and
Application-Id=AppQ. This request reaches AE-gw via standard Diameter
Base Protocol routing (during capability exchange procedure AE-gw
advertised AppQ).

3-  AE-gw needs to route the message based on provisioning. Why? Because
it needs to find an AE which can handle push mode. It can't rely on
capability advertisement because all types of AEs will advertise support
for AppQ.

Is my understanding for single Application-Id correct? If so, with
single Application-Id model there are more steps relying on provisioning
rather than on dynamic capability exchange procedures (and for different
Application-Id model we can make routing completely dynamic with some
minor extensions to the base protocol)

I don't believe two Application-Ids add any significant additional
complexity. If a node can support Diameter Base Protocol (capability
exchange, connection state machine) and QoS application (application
state machine, new AVPs) etc... it is hard for me to believe that two
Application-Ids makes development of such nodes more complex.

It is likely that we will agree to disagree on this one if my
understanding of single Application-Id routing is correct.

Thanks,
Tolga

> Sent: Monday, July 28, 2008 12:53 PM
> To: Asveren, Tolga
Peter-
> > > > reasonable to me to think nodes which support only a single
mode.
> > How
> > > machine processing in the server. Let's say a server is capable
only
> > typically is configured by a default policy server or redirect
server.
> > although theoretically the base Diameter protocol may allow this
kind
> of

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 Jul 2008 16:02:11 -0400

Hi Dong,

I am not proposing to add anything special to QoS application but just
not relying on the type of first command received to determine the QoS
model used. IMHO using an AVP for this purpose is a better approach
because using command type brings extra complexity from cold-standby
system design perspective. Furthermore it is just overloading the
meaning of the command code.

I just wanted to summarize the issue. My current understanding is that
we agree to disagree on this one.

Thanks,
Tolga
> Sent: Monday, July 28, 2008 1:07 PM
> To: Asveren, Tolga
Peter-
> > > >    AE operates in the Pull mode; when other triggers are
received,
> > 1) One can argue the other way around as well: Why exclude some
piece

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 28 Jul 2008 19:02:32 -0500

Tolga,

The scenario A) mandates the application SP being aware of underlying
network technology and operation mode (i.e. push or pull) and making a
selection, which is not the intention of QoS application (and net
neutrality). And I don't think the content provider (let's say youtube)
really cares about which mode is used for the QoS guarantee in the
transport network. 

If you still have question, please give me a call. We can chat about it
in detail.

Regards,
Dong 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 3:57 PM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Hi Dong,

                       +-----+
                       |AppS | (Org1)
                       +-----+
                          |
         +-------+        |
 (Org2)  |AE-gw  |--------+
         +-------+
             |
             |
         +-------+
  (Org2) |  AE1  |
         +-------+
             |
             |
         +-------+
  (Org2) |  NE1  |
         +-------+      

2- It sends the initial request with Destination-Realm=Org2 and
Application-Id=push. This request reaches AE-gw via standard Diameter
Base Protocol routing (during capability exchange procedure AE-gw
advertised App-push) [Actually here AppS will need to rely on some
provisioning as well as capability advertisement is not done per realm,
i.e. it won't be clear to AppS that AE-gw supports push-mode for Org2
realm. This IMHO is a missing piece of functionality in Diameter base
protocol but can be fixed relativel easily]

Thanks,
Tolga

Peter-

mode.
only
server.
kind

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 28 Jul 2008 19:45:41 -0500

Tolga,

Before we move further on the failure handover issue, I'd like to
clarify a basic question (I need some education from the Diameter
experts): in 3588 and 4005, how a new session is recogizied by the
Diameter Server? It seems no one uses the explicit indicator for
identifying a new session, if my understanding is correct. Furthermore,
if we rely on the Diameter client for the indication of new session, it
may cause the problem when the client recovers from the failure, e.g. it
may think the recovered session as a new session. 

As I indicated, the QoS application is intended to keep consistent with
the base protocol and the "mom" protocol 4005. In fact, besides the
session-id, the QoS application also looks at the QoS resources and
other AVPs to decide the transition of the session state.  

I just like to highligh my point: how to handle failover is a general
issue, I don't think the QoS application requires any extra mechanism
compared to any other applications. So I'd like to adapt a generic
mechanism already used by other applications if possible, rather than
creating an "unique" mechanism here.

Regards,
Dong

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 4:02 PM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Hi Dong,

Thanks,
Tolga
Peter-

received,

piece

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 29 Jul 2008 07:42:39 -0400

One of the motivations for introducing a Diameter QoS protocol
was indeed to provide an interface between applications (such
as a streaming video server) and network elements that need
to enforce QoS.  I think net neutrality means documenting this
interface and opening it up to anyone that has a connection
to the "Diameter Cloud".

That being said, I don't have a strong opinion on whether we
should use 1 or 2 Application IDs; personally I think it is
easier for the application endpoint in a user terminal to
provide an authentication token that points to an application
server domain than it is to have the application server figure
out the access network to which the user is attached based only
on its IP address.  This is why the original document had pull-only.
If the AppS can figure out the Destination-Realm of the enforcing
NE(s) then we should use standard Diameter routing based on 
Destination-Realm.  Having a separate application ID for each
mode of operation might lead us down the path of having some
nodes implement only one half of the protocol which could lead
to interoperability problems.

-Pete

Sun, Dong (Dong) wrote:
> network technology and operation mode (i.e. push or pull) and making
> a selection, which is not the intention of QoS application (and net
> neutrality). And I don't think the content provider (let's say
> youtube) really cares about which mode is used for the QoS guarantee
> in the transport network.     
> 
> If you still have question, please give me a call. We can chat about
> it in detail. 
> 
> Regards,
> Dong
> 
> draft-ietf-dime-diameter-qos-06] / Application-Id 
> 
> Hi Dong,
> 
> App-push is the application-Id for push mode (if different AppIds
> used) App-pullthe application-Id for pull mode (if different AppIds
> used)  
> 
> 1- AppS receives a new session request and determines that QoS needs
> to be reserved on the access side for a particular flow. It
> determines (by whatever means) that the access side is controlled by
> Org2.   
> 
> provisioning as well as capability advertisement is not done per
> realm, i.e. it won't be clear to AppS that AE-gw supports push-mode
> for Org2 realm. This IMHO is a missing piece of functionality in
> Diameter base protocol but can be fixed relativel easily]       
> 
> App-push). There could be other AEs in the network which are unable
> to process this request because they do not know the binding between
> IP addresses and NEs. This is not a problem though as they would
> advertise only app-pull during capability exchange procedure)     
> 
> 1- AppS receives a new session request and determines that QoS needs
> to be reserved on the access side for a particular flow. It
> determines (by whatever means) that the access side is controlled by
> Org2.   
> 
> 3-  AE-gw needs to route the message based on provisioning. Why?
> Because it needs to find an AE which can handle push mode. It can't
> rely on capability advertisement because all types of AEs will
> advertise support for AppQ.   
> 
> single Application-Id model there are more steps relying on
> provisioning rather than on dynamic capability exchange procedures
> (and for different Application-Id model we can make routing
> completely dynamic with some minor extensions to the base protocol)  
> 
> 
>>> Peter- A001034; Avri Doria; Tina TSOU; Glen Zorn
>>>>> reasonable to me to think nodes which support only a single mode.
>>>>> How can we guarantee that messages land to the right server
>>>>> models is different, for example, when a new request from the PEP
>>>>> is recevied, the Server will start the pull model. In fact, the
>>>>> push and pull are sharing the same state machine per se. the main
>>>>> difference is just how to establish a Diameter session. The
>>>>> enhancement is to allow the Diameter 
>>>> 
>>>>> trigger from the Diameter client (i.e. NE/PEP). Therefore, I
>>>>> don't think the same application-Id causes any problem,
>>>>> especially for the pull model since 
>>>> 
>>>>> push/pull is able use the same server (certainly they can also
>>>>> have separate server according to the configuration).
>>>> [TOLGA]My concern here is about message routing rather than the
>>>> state machine processing in the server. Let's say a server is
>>>> capable only to accommodate pull model (it doesn't know what NE to
>>>> contact if push model is required). How can the network
>>>> intermediaries, e.g. relay agent, forward the initial request in
>>>> the session to the right server for push model? How can they be
>>>> sure that the server supports push model? [Dong] The relay agent
>>>> should route the message according to the destination
>>>> address/realm that is filled up by the requestor. I don't know how
>>>> the application id will affect this kind of routing. 
>>> [TOLGA]The initial message of a session may have only
>>> Destination-Realm. In such a case Application-Id is used by
>>> intermediaries to select the right server. [Dong] In the context of
>>> QoS application, for the pull mode, the NE typically is configured
>>> by a default policy server or redirect server. I don't think the
>>> scenario you are concerned is a common case in reality 
>> 
>>> kind of behavior, but it is not the case for QoS application, IMHO.
>> different AEs for push or pull respectively, a rendezvous AE will
>> make a selection according to the policy, network technology and/or
>> request attribute. The problem to have two different application id
>> is to mandate the selection of an AE per its capabilities to the
>> AppS (or NE), it is inconsistent with the basic rationale of the QoS
>> application (i.e. maintain the network neutrality). Moreover, it
>> makes the QoS application and implementations more complex since two
>> packages have to be developed...

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 29 Jul 2008 11:48:15 -0400

(Reply for both Pete's and Dong's explanations)

The origin of my question was the doubt whether all nodes would
implement both push and pull modes. I see that this is expected so there
won't be a problem of finding the right server. This makes it
unnecessary to use different Application-Ids from routing perspective (I
am still not sure whether support for both modes will be universal but
it seems I am in minority on this one).

I need clarification on one point though:
Both of you stated AppS knowing that push mode is necessary requires
that it is aware of access network type used the terminal. IMHO it is
more than that: access network type, terminal capabilities, whether QoS
reservation is requested for the session by the enduser all play a role
in this decision AFAICS. Even for access provider it may not be possible
to know the answer for all these questions. 

For example:
1) AppS receives the session request and decides that this type of
session requires QoS reservation
2) It sends a request to the AE
3) How does the AE determine whether a push mode reservation is really
necessary?
  
There seem to be only a single entity with perfect information: the
terminal/enduser. I would expect the endpoint to signal its request for
the AppS to reserve QoS resources as part of the session signaling.

Thanks,
Tolga

> From: McCann Peter-A001034 [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2008 7:43 AM
> Cc: Glen Zorn; Avri Doria; [email-masked]
> Subject: RE: [Dime] [Fwd: Comments for
> /Application-Id
Peter-
mode.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 29 Jul 2008 12:20:54 -0400

Hi Dong,

It is a great help for developers if a message contains information to
reconstruct a session after a failover. If you don't think that this is
a good idea/necessary or creates too much overhead then fine. And
actually this probably would require more than the change I asked.

I don't think there could be a general mechanism to provide all the
support needed for failover friendliness; it is not just about deciding
whether a request is for an existing session but also reconstructing
existing state (which is different for each application). IMHO
DCCA(RFC4006) is a good example.

Thanks,
Tolga 

> Sent: Monday, July 28, 2008 8:46 PM
> To: Asveren, Tolga
Peter-
> > > > > For example AE goes down and a backup AE takes over. IMO it is
a
> > > nice
> > > > > impossible. For certain scenarios backup AE would determine
the
> > > > required
> > > > > mode wrong. I suggest the decision for push/pull is not based
on
> > > > message
> > > > > will work well for the hot standby case, but indeed, it may
have
> > > some
> > > > OTOH that the QoS application is failover friendly is a
parameter
> > > > cold standby elements can be used to take over existing
sessions,
> > one
> > > information which is useful for certain type of failover
mechanism.
> > IMHO
> > > the added overhead is negligible and I am pretty sure much less
than
> > addition, it is obvious an optional approach for failure handling,
and

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 29 Jul 2008 11:23:44 -0500

Tolga,

The AE controlling the access network resources should be able to know
the access technology and decide the push or pull mode. In certain
circumstance, the endpoint may know some info of access network, but I
suspect it might not be a general case, for example, for the femto
network, the cellular UE does not really know/care about the broadband
access. It is the access networks (including the AE in the access
network) that know it.

Moreover, there are many different kinds of endpoints, according the QoS
draft, certain types i.e. Category 1, does not have the capability to
decide the QoS attributes. I believe the draft should and has been able
to support all variants. Not see any issue sofar.  

Rgs,
Dong

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 11:48 AM
To: McCann Peter-A001034; Sun, Dong (Dong)
Cc: Glen Zorn; Avri Doria; [email-masked]
Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06]
/Application-Id

For example:

Thanks,
Tolga

> /Application-Id
> 
> One of the motivations for introducing a Diameter QoS protocol was 
> indeed to provide an interface between applications (such as a 
> streaming video server) and network elements that need to enforce QoS.

> I think net neutrality means documenting this interface and opening it

> up to anyone that has a connection to the "Diameter Cloud".
> 
> That being said, I don't have a strong opinion on whether we should 
> use 1 or 2 Application IDs; personally I think it is easier for the 
> application endpoint in a user terminal to provide an authentication 
> token that points to an application server domain than it is to have 
> the application server figure out the access network to which the user

> is attached based only on its IP address.  This is why the original 
> document had pull-only.
> Destination-Realm.  Having a separate application ID for each mode of 
> operation might lead us down the path of having some nodes implement 
> only one half of the protocol which could lead to interoperability 
> problems.
> 
> -Pete
> 
> Sun, Dong (Dong) wrote:
> > Tolga,
> >

Peter-
mode.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 29 Jul 2008 12:38:21 -0400

Hi Dong,

That the endpoint is able to reserve QoS resources is one thing, that it
knows a particular session requires QoS reservation (not necessarily the
attributes just the need) is another one. I expect the endpoint to know
the latter for sure.

I don't know what would happen for the following case:
1) The terminal is capable of reserving QoS
2) A softclient is running on the terminal which is not making use of
QoS reservation capabilities of the terminal (it is a generic
softclient) but it signals it desire for QoS as part of the session
signaling

Who will initiate the QoS reservation? 

My understanding of your explanation is that if an access network allows
pull model then it won't allow push model as you seem tying the decision
for push/pull model to the access network type (?). Is this always the
case and are we sure that this always will be the case?

Thanks,
Tolga

> Sent: Tuesday, July 29, 2008 12:24 PM
> To: Asveren, Tolga; McCann Peter-A001034

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 29 Jul 2008 11:45:35 -0500

Tolga,
I am opposing any great idea to support the failover. Meanwhile, as far
as I can see, the approach you proposed is just one option. BTW, I am
not saying it does not work.

The bottom line, again, I do seek a common mechanism/framework for the
failover. Sure, in your approach, the detailed application state related
info may vary, but I am not sure if it will make any essential
difference for the mechanism. 

This is a sophiscated and general issue. I don't want to jump into a
special solution for the QoS application since I believe a generic
mechanism (i.e. the common state machine) can help minimize the
development effort as a whole for the Diameter protocol stack. 

As far as I know, it seems the failure approach defined in 4006 (i.e.
"Credit-Control-Failure-Handling" if it is what you refer to) is not yet
widely used by the industry and other SDOs for the time being (due to
the complexity, I guess). Please correct me if I am wrong about this
point.

Rgs,
Dong

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 12:21 PM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Hi Dong,

Thanks,
Tolga 

Peter-
a
the
on
have
parameter
sessions,

mechanism.
than

and

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 29 Jul 2008 11:52:03 -0500

For some dumb endpoints, the AppS can decide whether the QoS reservation
is required or not according to the service attribute and agreement and
initiate the QoS reservation. It is not really sth new.

The selection of push or pull is related to both access network
capability and endpoint capability. However the relationship is pretty
much static for a combination of one type endpoint and access network.
The network can figure out based on the registration and configuration.
Of course, if the endpoint can provide additional info, it also helps,
but all the info from the endpoint should be authorized, which means the
network makes final decision.

Rgs,
Dong 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 12:38 PM
To: Sun, Dong (Dong); McCann Peter-A001034
Cc: Glen Zorn; Avri Doria; [email-masked]
Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06]
/Application-Id

Hi Dong,

Thanks,
Tolga

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 29 Jul 2008 13:15:30 -0400

Hi Dong,

O.K. fair enough.

P.S.: It wasn't just Credit-Control-Failure-Handling AVP I was referring
to but also inclusion of CC-Request-Type, CC-Request-Number etc... in
every message.

Thanks,
Tolga

> Sent: Tuesday, July 29, 2008 12:46 PM
> To: Asveren, Tolga
Peter-
> > may cause the problem when the client recovers from the failure,
e.g.
> > > > Since you agreed that the general failure handling for Diameter
is
> > out
> > > > document (I am not sure if it already has) since they are
supposed
> > > > > > carrying enough information about session state in the
message
> > > > itself
> > > > > > (AFAIR, DCCA can do this nicely). The approach I quoted
makes
> > this
> > > > > > in the draft very much. The question is, do we need to add
the
> > > > failure
> > > > > consider IMHO. By carrying enough information in each message
so
> > > that
> > > > 2) If push/pull modes use different Application-Ids that could
be
> > used
> > > only to the QoS application. Then why don't we generalize the
issue

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 29 Jul 2008 13:20:52 -0400

Hi Dong,

inline....

Thanks,
Tolga

> Sent: Tuesday, July 29, 2008 12:52 PM
> initiate the QoS reservation. It is not really sth new.
[TOLGA]Yes agreed.
> network makes final decision.
[TOLGA]The network can determine certain information when the endpoint
is attaching but this may not be all what is necessary. For example in
the example I provided there is a softclient and access network knows
nothing about it. Who will reserve the QoS in that case? Is it the AppS?
> > unnecessary to use different Application-Ids from routing
perspective
> (I
> > > I think net neutrality means documenting this interface and
opening
should
> > > > AppQ is the application-Id for QoS application (if a single
AppId
> > > > determines (by whatever means) that the access side is
controlled
> > > > determines (by whatever means) that the access side is
controlled
> > > > state machine, new AVPs) etc... it is hard for me to believe
that
> > two
> > > >>>>> models is different, for example, when a new request from
the
> > PEP
> > > >>>>> Server to establish a session with a local trigger instead
of
> > > >>>> capable only to accommodate pull model (it doesn't know what
NE
> > > >>>> address/realm that is filled up by the requestor. I don't
know
> > how
> > > >>> intermediaries to select the right server. [Dong] In the
context
> > > >> selection of AE according to its capabilities. In the case
there
> > > >> request attribute. The problem to have two different
application
> id
> > > >> AppS (or NE), it is inconsistent with the basic rationale of
the
> > QoS
> > > >> makes the QoS application and implementations more complex
since
> > two

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 29 Jul 2008 13:05:42 -0500

Sorry. Found a typo.

" I am opposing any great idea to support the failover."
What I mean, "I am NOT opposing ..."

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 1:16 PM
To: Sun, Dong (Dong)
Cc: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); McCann

Hi Dong,

O.K. fair enough.

Thanks,
Tolga

Peter-
e.g.

is
supposed
message
makes
the
so

be
issue