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

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 3 Dec 2013 08:42:50 +0000

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 Applications report.  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

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 3 Dec 2013 11:26:06 +0200

Hmm.. wasn't there just recently rather strong opposition 
to include anything beyond "implicit" information into the
OLR?

- Jouni

On Dec 3, 2013, at 10:42 AM, Maria Cruz Bartolome <[email-masked]> wrote:

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

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 3 Dec 2013 09:34:16 +0000

Not exactly.
It was opposition to duplicate information.

Cheers
/MCruz

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: martes, 03 de diciembre de 2013 10:26
To: Maria Cruz Bartolome
Cc: [email-masked]
Subject: Re: [Dime] OLR applicable for any/all applications

Hmm.. wasn't there just recently rather strong opposition to include anything beyond "implicit" information into the OLR?

- Jouni

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 3 Dec 2013 09:41:25 +0000

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:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: [email-masked]
Subject: [Dime] OLR applicable for any/all applications

Dear all,

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

              [All applications]

            * [ AVP ]

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 3 Dec 2013 13:09:57 +0200

We had an attempt to have applications other than
the piggybacked from the very beginning. That was
also ruled out. What has changed since?

- Jouni

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 11:20:25 +0000

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:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : mardi 3 décembre 2013 10:41
À : Maria Cruz Bartolome; [email-masked]
Objet : Re: [Dime] OLR applicable for any/all applications

Maria-Cruz,

Regards,
Nirav.

Dear all,

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

              [All applications]

            * [ AVP ]

_________________________________________________________________________________________________________________________

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.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 03 Dec 2013 09:39:39 -0600

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:[email-masked]] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* Tuesday, December 03, 2013 2:13 PM
> *To:* [email-masked]
> *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.
>
>  
>
>    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.
>
>  
>
>  
>
>  
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 03 Dec 2013 09:43:06 -0600

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, [email-masked] 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:[email-masked]] *De la part de* Nirav Salot
> (nsalot)
> *Envoyé :* mardi 3 décembre 2013 10:41
> *À :* Maria Cruz Bartolome; [email-masked]
> *Objet :* Re: [Dime] OLR applicable for any/all applications
>
>  
>
> Maria-Cruz,
>
>  
>

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 17:00:26 +0000

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:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 3 décembre 2013 16:40
À : [email-masked]
Objet : Re: [Dime] OLR applicable for any/all applications

Nirav,

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

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dime] OLR applicable for any/all applications

Dear all,

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

              [All applications]

            * [ AVP ]

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 03 Dec 2013 12:00:13 -0600

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, [email-masked] 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:[email-masked]] *De la part de* Steve Donovan
> *Envoyé :* mardi 3 décembre 2013 16:40
> *À :* [email-masked]
> implement a combined HSS and EIR, causing the MME to communicate S6a
> and S13 over the same connection.
>
> Steve
>
>     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:[email-masked]] *On Behalf Of *Maria
>     Cruz Bartolome
>     *To:* [email-masked] <mailto:[email-masked]>
>     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.
>
>      
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 17:20:54 -0600

I do not object. I used this as an argument in the past that we should label the OLR with the application ID, but people thought it was okay to require the overloaded node to send a separate OLR for each application.  (I don't agree with that, by the way, I just gave up the argument for the moment.)

 But I can't help but noting that this would be automatically handled with self-contained OLRs :-)  That is, by defining that the absence of an application-ID, or possibly some wildcard value, as meaning "all applications".

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:52:17 +0000

Hi MCruz,

I don't see any use case at least in 3GPP for this. There is no more than one application between two nodes so far. And even the case is valid, it could be reached by multiple sending of the overload report per application, which could be seen as an optimization in the future if there is clear scenario for such an optimization.

Best Regards,
Susan

From: Maria Cruz Bartolome [mailto:[email-masked]]
Sent: Tuesday, December 03, 2013 4:43 PM
To: [email-masked]
Subject: [Dime] OLR applicable for any/all applications

Dear all,

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

              [All applications]

            * [ AVP ]

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 9 Dec 2013 10:55:02 +0000

Hello,

Yes, I agree with comments received, this could be considered an optimization.
Then I agree about do not including this in the baseline document.

Best regards
/MCruz

From: Shishufeng (Susan) [mailto:[email-masked]]
Sent: lunes, 09 de diciembre de 2013 11:52
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] OLR applicable for any/all applications

Hi MCruz,

Best Regards,
Susan

Dear all,

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

              [All applications]

            * [ AVP ]