Re: [Dime] OLR applicable for any/all applications

Personally I like Maria-Cruz's suggestion.  But I am also on the side of
including the application-id in the overload report in the first place.

On a related note, the agent overload extension will likely default to
being all applications.  We will need to decide if we allow for getting
more specific by allowing the agent to include a list of impacted
applications.

Steve

On 12/3/13 5:20 AM, lionel.morand@orange.com wrote:
>
> Hi Maria-Cruz,
>
>  
>
> I agree with Nirav's comment: No need of such optimization. OLR is per
> application and if more than one application is used between nodes,
> the OLR will be received on the application related answers.
>
>  
>
> Regards,
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Nirav Salot
> (nsalot)
> *Envoyé :* mardi 3 décembre 2013 10:41
> *À :* Maria Cruz Bartolome; dime@ietf.org
> *Objet :* Re: [Dime] OLR applicable for any/all applications
>
>  
>
> Maria-Cruz,
>
>  
>
> The existing OC-OLR definition (without "All Application" AVP) already
> addresses your use case. E.g. reporting  node includes same value of
> "Reduction-Percentage" in all the application messages sent by it. So
> we don't need "All Application" AVP additionally.
>
> Besides, reporting "Reduction-Percentage" of a different application
> violates the basic principle of the piggybacking.
>
> Finally, in 3GPP (as far as I remember) we do not have any use case of
> two nodes interfacing with each other over more than one application.
> i.e. we have only one application between any pair of nodes and if
> that is so then I fail to see the practicality of the use case you
> have mentioned below.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* Tuesday, December 03, 2013 2:13 PM
> *To:* dime@ietf.org
> *Subject:* [Dime] OLR applicable for any/all applications
>
>  
>
>  
>
> Dear all,
>
>  
>
> There may be a need by a reporting node to request traffic reduction
> for all traffic, application independent, e.g. if an operator's
> network becomes severely overloaded, it may be of interest to signal
> directly general overload to the client. 
>
> In this case, since reacting node obtains affected application from
> the application message, we may need to extend OLR.
>
>  
>
> At least we got following options:
>
>  
>
>  
>
> A)     Define a new optional AVP that could be included into OLR, like
> e.g.:
>
>    OC-OLR ::= < AVP Header: TBD2 >
>               < TimeStamp >
>               [ Reduction-Percentage ]
>               [ ValidityDuration ]
>               [ ReportType ]
>               [All applications]
>             * [ AVP ]
>
>  
>
>  
>
> B)      Extend  ReportTypes like e.g.:
>
>  
>
>    3  Destination-Host All Applications report.  Similar to
> Destination-Host report but it would apply to any application
> regardless the application message this report is received within.
>
>  
>
>    4  Realm (aggregated) All Applicationsreport.  Similar to Realm
> report but it would apply to any application regardless the
> application message this report is received within.
>
>  
>
>  
>
>  
>
> I tend to prefer option A, but let me know your opinions and preferences.
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> _________________________________________________________________________________________________________________________
>
> 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
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime