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

[Steve Donovan <[e-mail]>]

Lionel,

I'm just pointing out that it is not a valid assumption that only a
single application will be carried across a connection.  We should not
ignore that fact.

Steve


On 12/3/13 11:00 AM, [e-mail] wrote:
>
> Hi Steve,
>
>  
>
> The collocation of multiple functions in the same node does not imply
> interaction between these functions. And because it is
> implementation-dependent, it was considered that such use cases should
> be left out for further investigations.
>
>  
>
> Regards,
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:[e-mail]] *De la part de* Steve Donovan
> *Envoyé :* mardi 3 décembre 2013 16:40
> *À :* [e-mail]
> *Objet :* Re: [Dime] OLR applicable for any/all applications
>
>  
>
> Nirav,
>
> Agents handle multiple applications over a single connection.
>
> It is also possible that implementations can support multiple 3GPP
> functions in a single node.  For instance, someone might decide to
> implement a combined HSS and EIR, causing the MME to communicate S6a
> and S13 over the same connection.
>
> Steve
>
> On 12/3/13 3:41 AM, Nirav Salot (nsalot) wrote:
>
>     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:[e-mail]] *On Behalf Of *Maria
>     Cruz Bartolome
>     *Sent:* Tuesday, December 03, 2013 2:13 PM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *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
>
>      
>
>      
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     [e-mail] <mailto:[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.