Re: [Dime] [dime] #35: additional report types are proposed

[<[e-mail]>]

If I'm correct, the following condition:

       d) The values of the Origin-Host and Origin-Realm AVPs in the  request
          match the values of the Destination-Host and Destination-Realm
          AVPs respectively of the received message that contained the OC-
          OLR AVP.

is not correct as the message containing the OC-OLR AVP is an answer and there is Destination-Host or Destination-Realm AVPs in an answer.

If you want to clarify something, it can be in the section describing the agent behavior. And such clarification will be that when an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client (no need of the origin-realm).

Lionel

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
Envoyé : mercredi 5 février 2014 17:43
À : MORAND Lionel IMT/OLN; ext Nirav Salot (nsalot); [e-mail]
Objet : RE: [Dime] [dime] #35: additional report types are proposed

Even if some feel this is implicit, it should not harm to add the d) condition explicitly please.

-----Original Message-----
From: ext [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, February 05, 2014 4:08 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); [e-mail]
Subject: RE: [Dime] [dime] #35: additional report types are proposed

Isn't it implicit?
An answer is sent to the origin-host of the corresponding request. The agent is not the targeting point of the answer and is not supposed to be the reacting node. Now if an agent wants to act on behalf a client not supporting the DOCI mechanism at the application, this agent will have to maintain a binding for this client. This requirement is not bound to the overload control mechanism but to any function provides by the agent on behalf of downstream clients. 

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
Envoyé : mercredi 5 février 2014 10:32
À : ext Nirav Salot (nsalot); MORAND Lionel IMT/OLN; [e-mail]
Objet : RE: [Dime] [dime] #35: additional report types are proposed

Nirav,
... and this natural requirement is missing from the current draft.

To address this requirement we could replace the descriptions for report types 0 and 1 with the decriptions of my proposed report types 2 and 3 respectively.

As a consquence, however, the agent in the given example configuration would have to store always OLRs per client even when S wants all clients to do the same throttling. Would that be acceptable?

Ulrich


-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[e-mail]] 
Sent: Wednesday, February 05, 2014 10:03 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]; [e-mail]
Subject: RE: [Dime] [dime] #35: additional report types are proposed

Ulrich,

I do not think so.
If we believe that there should be host-specific OLR and if we want to support the model when the agent acts as reacting node (on behalf of the client(s)), then the agents are naturally required to store OLR per client/host behind the agent (based on the destination-host AVP in the answer message).

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
Sent: Wednesday, February 05, 2014 2:24 PM
To: Nirav Salot (nsalot); [e-mail]; [e-mail]
Subject: RE: [Dime] [dime] #35: additional report types are proposed

Hi Lionel, Nirav,

your argument only holds in configurations where the client is the reacting node.

In a configuration like this


+-------+
| C1    |          +------+
|       |----------|  A   |               +------+
+-------+          |      |               | S    |
                   |      |---------------|      |
+-------+          |      |               +------+
| C2    |----------|      |
|       |          +------+
+-------+
where clients C1 and C2 do not support DOIC and the same agent A takes the role of the reacting node on behalf of both C1 and C2 the situation is different. According to the current version of the draft this will result in big mess with frequent replacements of OLRs in A when e.g. S requests a 50% reduction from C1 and 0% reduction from C2. 

Best regards
Ulrich




-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of ext Nirav Salot (nsalot)
Sent: Wednesday, February 05, 2014 5:50 AM
To: [e-mail]; [e-mail]
Subject: Re: [Dime] [dime] #35: additional report types are proposed

Same view as Lionel below.
New report types seem more confusing than adding value.

The reporting node knows the host which is going to receive the message (and hence report within the message) and hence it can generate "host specific" report and it insert into the message.
No need to define new report types for achieving this.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, February 04, 2014 10:48 PM
To: [e-mail]
Subject: Re: [Dime] [dime] #35: additional report types are proposed

I don't see the added-value of these new report types.
In any case the reporting node will decide which reduction value to send to each node and the reacting node will behave accordingly to the value received in the OLR. So what is the point to say "this value applies to you only"?

Lionel

-----Message d'origine-----
De : DiME [mailto:[e-mail]] De la part de dime issue tracker Envoyé : mardi 4 février 2014 16:39 À : MORAND Lionel IMT/OLN Cc : [e-mail] Objet : Re: [Dime] [dime] #35: additional report types are proposed

#35: additional report types are proposed

Description changed by [e-mail]:

Old description:

> With regard to Overload Mitigation Differentiation per Client (#33) 
> two additional report types are proposed:
>
>    2  A host per client report.  The overload treatment should apply to
>       requests for which all of the following conditions are true:
>       a) The Destination-Host AVP is present in the request and its value
>          matches the value of the Origin-Host AVP of the received message
>          that contained the OC-OLR AVP.
>       b) The value of the Destination-Realm AVP in the request matches 
> the
>          value of the Origin-Realm AVP of the received message
>          that contained the OC-OLR AVP.
>       c) The value of the Application-ID in the Diameter Header of the
>          request matches the value of the Application-ID of the Diameter
>          Header of the received message that contained the OC-OLR AVP.
>       d) The values of the Origin-Host and Origin-Realm AVPs in the 
> request
>          match the values of the Destination-Host and Destination-Realm
>          AVPs respectively of the received message that contained the OC-
>          OLR AVP.
>
>    3  A realm per client report.  The overload treatment should apply to
>       requests for which all of the following conditions are true:
>       a) The Destination-Host AVP is absent in the request.
>       b) The value of the Destination-Realm AVP in the request matches 
> the
>          value of the Origin-Realm AVP of the received message
>          that contained the OC-OLR AVP.
>       c) The value of the Application-ID in the Diameter Header of the
>          request matches the value of the Application-ID of the Diameter
>          Header of the received message that contained the OC-OLR AVP.
>       d) The values of the Origin-Host and Origin-Realm AVPs in the 
> request
>          match the values of the Destination-Host and Destination-Realm
>          AVPs respectively of the received message that contained the OC-
>          OLR AVP.

New description:

 The -01 draft does not address the 3GPP requirement to allow reporting  DOIC endpoints to request different amount of load reduction from  different clients (see TR 29.809 clause 6.4.7).
 Since 3GPP is the main consumer of DOIC it is proposed to address this  requirement by adding two new report types.
 two additional report types are proposed:

    2  A host per client report.  The overload treatment should apply to
       requests for which all of the following conditions are true:
       a) The Destination-Host AVP is present in the request and its value
          matches the value of the Origin-Host AVP of the received message
          that contained the OC-OLR AVP.
       b) The value of the Destination-Realm AVP in the request matches the
          value of the Origin-Realm AVP of the received message
          that contained the OC-OLR AVP.
       c) The value of the Application-ID in the Diameter Header of the
          request matches the value of the Application-ID of the Diameter
          Header of the received message that contained the OC-OLR AVP.
       d) The values of the Origin-Host and Origin-Realm AVPs in the  request
          match the values of the Destination-Host and Destination-Realm
          AVPs respectively of the received message that contained the OC-
          OLR AVP.

    3  A realm per client report.  The overload treatment should apply to
       requests for which all of the following conditions are true:
       a) The Destination-Host AVP is absent in the request.
       b) The value of the Destination-Realm AVP in the request matches the
          value of the Origin-Realm AVP of the received message
          that contained the OC-OLR AVP.
       c) The value of the Application-ID in the Diameter Header of the
          request matches the value of the Application-ID of the Diameter
          Header of the received message that contained the OC-OLR AVP.
       d) The values of the Origin-Host and Origin-Realm AVPs in the  request
          match the values of the Destination-Host and Destination-Realm
          AVPs respectively of the received message that contained the OC-
          OLR AVP.

--

-- 
--------------------------------------+---------------------------
 Reporter:  [e-mail]  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  new
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/35#comment:2>
dime <http://tools.ietf.org/wg/dime/>

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.