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

[Maria Cruz Bartolome <[e-mail]>]

Fine for me as well.
Thanks

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 16:18
To: [e-mail]
Subject: Re: [Dime] [dime] #35: additional report types are proposed

+1 on adding an agent behavior sub-section to section 5.5 and that it
should capture Ulrich's wording that an agent must be able to differentiate OLRs and the resulting abatement on a per client basis.

Steve

On 2/10/14 5:09 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi all
>
> I also agree with Lionel and Nirav. As Ulrich proposes, I also think good to have a clarification and the hereafter proposed sentence from Ulrich in agent behavior (when acting on behalf of the client) is OK for me:
> "When an agent receives an OLR in response to a request initiated by a client not supporting DOIC, this agent, acting on behalf of the client, needs to (or MUST) bind the received OLR to the origin-host in the request of the client".
>
> JJacques
>
>
> -----Message d'origine-----
> De : DiME [mailto:[e-mail]] De la part de 
> [e-mail] Envoyé : mercredi 5 février 2014 17:55 À : 
> Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); 
> [e-mail] Objet : Re: [Dime] [dime] #35: additional report types 
> are proposed
>
> 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.
>
> --
>

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