Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

From: Steve Donovan <[email-masked]>
Date: Mon, 02 Dec 2013 09:54:31 -0600

Nirav,

I agree with Lionel that what you propose would result in either a new
report-type or abatement algorithm.  There needs to be a way of telling
the reacting node why the new AVP is present.  There could be, for
instance, two different extensions that need the same AVP included in
the overload report.  We need a way of indicating to the reacting node
which of those extensions should be used.

Steve

On 11/28/13 10:11 AM, Nirav Salot (nsalot) wrote:
>
> Hi Lionel,
>
>  
>
> I am not sure if defining new ReportType for every new AVP 3GPP would
> add for a specific application would be a good solution.
>
> I thought ReportType would indicate if the corresponding OC-OLR should
> be used while sending the traffic towards the host or towards the realm.
>
> So from that point of view, all the OC-OLR generated by the server
> should have ReportType=host. i.e. when the reacting node sends the
> traffic towards that host, it should make use of the corresponding
> OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as
> well as 3GPP application specific AVPs.
>
>  
>
> In general, I was just thinking that it may be good idea to define
> some of the principles such as
>
> -          More than one instances of OC-OLR with ReportType=host may
> be present in the answer message if the OC-OLR definition is extended
> by the application using the same. In that case, it is the
> responsibility of the application to define the valid combination of
> OC-OLR instances in a given message
>
> -          If the reporting node includes more than one instance of
> OC-OLR, the reporting node shall always include all the active
> instances of OC-OLR in a response message.
>
> -          When the reacting node receives one or more instances of
> OC-OLR with the given ReportType and with new timestamp value, it
> should overwrite all the existing OC-OLR of the same ReportType.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, November 28, 2013 7:39 PM
> *To:* Nirav Salot (nsalot)
> *Cc:* [email-masked]
> *Subject:* RE: DOIC: Multiple instance of OC-OLR AVP (of the same
> type) within a response message
>
>  
>
> Hi Nirav,
>
>  
>
> The Report Type should be able to differentiate such cases. In your
> example, I would define a specific Report type.
>
> But difficult to appraise all the future use cases. But for me, the
> main use of the report type is to differentiate OC-OLR received in the
> same message.
>
> And it is the reasons of my recommendation. Actually, the exact
> wording will be a "SHOULD" saying that it is recommended but you may
> have serious reasons to do otherwise.
>
>  
>
> Lionel
>
>  
>
> *De :*Nirav Salot (nsalot) [mailto:[email-masked]]
> *Envoyé :* jeudi 28 novembre 2013 13:00
> *À :* MORAND Lionel IMT/OLN
> *Cc :* [email-masked] <mailto:[email-masked]>
> *Objet :* RE: DOIC: Multiple instance of OC-OLR AVP (of the same type)
> within a response message
>
>  
>
> Lionel,
>
> 3gpp may define an optional avp which can be included by the reporting
> node if it wishes to do so. E.g. APN can be additionally included by
> the reporting node to indicate APN specific overload within the given
> application.
> In that case, the reporting node may also want to indicate application
> level overload without including the APN (e.g. this overload report is
> applicable to all other APNs).
>
> And hence there is a possibility of including multiple instances of
> the overload report.
>
> I am not suggesting that 3gpp will define APN (or any other avp)
> within overload report. But later, if 3gpp need to define the same,
> then corresponding handling needs to be defined within IETF now.
>
> Regards,
> Nirav.
>
> On Nov 28, 2013 3:56 PM, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi Nirav,
>
>  
>
> Not sure to understand the proposal or question.
>
> The OLR is significant per application (piggybacking principle). So if
> the 3GPP decides to add specific AVPs in the OLR (that will be
> possible), what would be the need to add the OLR without the specific
> 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Nirav Salot
> (nsalot)
> *Envoyé :* jeudi 28 novembre 2013 10:33
> *À :* [email-masked] <mailto:[email-masked]>
> *Objet :* [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same
> type) within a response message
>
>  
>
> Hi,
>
>  
>
> As I understand IETF will define the base overload control solution as
> part of DOIC. Then 3GPP would adopt the defined solution for each of
> its application.
>
> When that happens, 3GPP might want to add 3GPP specific AVP within
> OC-OLR AVP. Based on the current definition of the OC-OLR AVP this
> should be allowed since it contains "* [AVP]" in its definition.
>
> e.g. for a given application 3GPP decides to add information into
> OC-OLR which changes the scope of the OC-OLR from application level to
> the provided information level.
>
> Additionally, the reporting may want to advertise the OC-OLR at the
> application level scope -- i.e. the OC-OLR without any 3GPP specific info.
>
>  
>
> So if the above is allowed, we will have the possibility of the
> reporting node wanting to include two instances of OC-OLR with the
> Report-Type="host".
>
> And then we need to define the handling of multiple instances of
> OC-OLR in the DOIC draft.
>
>  
>
> So the questions are,
>
> -          Is 3GPP (or any other SDO) allowed to extend the definition
> of OC-OLR by adding information into it?
>
> -          If no, can we guarantee that application level scope of
> OC-OLR (which is what we have defined currently) is sufficient (and
> not restricting) to all the applications of 3GPP?
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> _________________________________________________________________________________________________________________________
>  
> 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.
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

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

Nirav,

I think I understand your concern. It may occur that we need that a reacting node should apply two different OLR when sending a request towards one specific host.
Then, we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application, I think this is your interpretation, but... we can as well consider a new ReportType=applicX_ReportY, that may apply e.g. for any request send to this application, or just for this application+host, and then Host could be another AVP to be included in the OLR, or we could define expected behaviour when defining this new ReportType.

Would this cover your concerns? If not, could you try to provide an example that requires two OLR with ReportType=host?

A part from that, a question for all, if we extend ReportType, does it need to be done by IETF, or could it be done per application by 3GPP?

Thanks
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Hi Lionel,

I am not sure if defining new ReportType for every new AVP 3GPP would add for a specific application would be a good solution.
I thought ReportType would indicate if the corresponding OC-OLR should be used while sending the traffic towards the host or towards the realm.
So from that point of view, all the OC-OLR generated by the server should have ReportType=host. i.e. when the reacting node sends the traffic towards that host, it should make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as well as 3GPP application specific AVPs.

In general, I was just thinking that it may be good idea to define some of the principles such as

-          More than one instances of OC-OLR with ReportType=host may be present in the answer message if the OC-OLR definition is extended by the application using the same. In that case, it is the responsibility of the application to define the valid combination of OC-OLR instances in a given message

-          If the reporting node includes more than one instance of OC-OLR, the reporting node shall always include all the active instances of OC-OLR in a response message.

-          When the reacting node receives one or more instances of OC-OLR with the given ReportType and with new timestamp value, it should overwrite all the existing OC-OLR of the same ReportType.

Regards,
Nirav.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: [email-masked]
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Hi Nirav,

The Report Type should be able to differentiate such cases. In your example, I would define a specific Report type.
But difficult to appraise all the future use cases. But for me, the main use of the report type is to differentiate OC-OLR received in the same message.
And it is the reasons of my recommendation. Actually, the exact wording will be a "SHOULD" saying that it is recommended but you may have serious reasons to do otherwise.

Lionel

De : Nirav Salot (nsalot) [mailto:[email-masked]]
Envoyé : jeudi 28 novembre 2013 13:00
À : MORAND Lionel IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Lionel,

3gpp may define an optional avp which can be included by the reporting node if it wishes to do so. E.g. APN can be additionally included by the reporting node to indicate APN specific overload within the given application.
In that case, the reporting node may also want to indicate application level overload without including the APN (e.g. this overload report is applicable to all other APNs).

And hence there is a possibility of including multiple instances of the overload report.

I am not suggesting that 3gpp will define APN (or any other avp) within overload report. But later, if 3gpp need to define the same, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.
On Nov 28, 2013 3:56 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nirav,

Not sure to understand the proposal or question.
The OLR is significant per application (piggybacking principle). So if the 3GPP decides to add specific AVPs in the OLR (that will be possible), what would be the need to add the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?

Lionel

De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : jeudi 28 novembre 2013 10:33
À : [email-masked]<mailto:[email-masked]>
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Hi,

As I understand IETF will define the base overload control solution as part of DOIC. Then 3GPP would adopt the defined solution for each of its application.
When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AVP this should be allowed since it contains "* [AVP]" in its definition.
e.g. for a given application 3GPP decides to add information into OC-OLR which changes the scope of the OC-OLR from application level to the provided information level.
Additionally, the reporting may want to advertise the OC-OLR at the application level scope - i.e. the OC-OLR without any 3GPP specific info.

So if the above is allowed, we will have the possibility of the reporting node wanting to include two instances of OC-OLR with the Report-Type="host".
And then we need to define the handling of multiple instances of OC-OLR in the DOIC draft.

So the questions are,

-          Is 3GPP (or any other SDO) allowed to extend the definition of OC-OLR by adding information into it?

-          If no, can we guarantee that application level scope of OC-OLR (which is what we have defined currently) is sufficient (and not restricting) to all the applications of 3GPP?

Regards,
Nirav.

Thank you.

Thank you.

---

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

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

> Then, we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application, I think this is your interpretation, but… we can as well consider a new ReportType=applicX_ReportY, that may apply e.g. for any request send to this application, or just for this application+host, and then Host could be another AVP to be included in the OLR, or we could define expected behaviour when defining this new ReportType.
>  

   Section 4.6 defines a new "Overload Report Type" registry with its
   initial assignments.  New types can be added using the Specification
   Required policy [RFC5226].

So no.. as long as the report type value is documented somewhere in a publicly available document that can be expected to be around for long enough.

Good point that this came up. We need to define the handling procedure for an OLR whose report type is not understood by the receiver.

- Jouni

> Cc : [email-masked]
> On Nov 28, 2013 3:56 PM, "[email-masked]" <[email-masked]> wrote:
> Hi Nirav,
>  
> À : [email-masked]
> Additionally, the reporting may want to advertise the OC-OLR at the application level scope – i.e. the OC-OLR without any 3GPP specific info.
>

---

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

Hi Nirav,

For now, I couldn't see the need to have more than one instance of the overload report with the same report-type, i.e. host or realm. But to allow extensibility if needed in the future, whether some texts can be written in the IETF e.g. Multiple OC-OLR AVPs exist with different report types, if it is not the case, it is the application where multiple OC-OLR AVPs are allowed with the same report type to specify the details how to differentiate the information contained in these OC-OLR AVPs. Thus we can move on without having to addressing the issue now in the base solution.

Best Regards,
Susan

From: Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 8:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Lionel,

Regards,
Nirav.

Lionel

Hi,

So the questions are,

Regards,
Nirav.

Thank you.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 13:25:50 -0600

Susan, am I correct in reading that to mean that while it may only make sense to have one host report or one realm report, this may not be true for all future report types, and that it should be up to the definition of each report type to allow or disallow multiple instances? If so, I agree.

Any report type that allows multiple instances will need to describe how to handle (or avoid) potential conflicts.

On Dec 9, 2013, at 4:12 AM, Shishufeng (Susan) <[email-masked]> wrote:

> Hi Nirav,
>  
> For now, I couldn’t see the need to have more than one instance of the overload report with the same report-type, i.e. host or realm. But to allow extensibility if needed in the future, whether some texts can be written in the IETF e.g. Multiple OC-OLR AVPs exist with different report types, if it is not the case, it is the application where multiple OC-OLR AVPs are allowed with the same report type to specify the details how to differentiate the information contained in these OC-OLR AVPs. Thus we can move on without having to addressing the issue now in the base solution.
>  
> Best Regards,
> Susan
>

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 10 Dec 2013 02:46:16 +0000

Hi Ben,

Try to make it more clear. 

So far, there are only two report types defined, i.e. host and realm. In the future, if more overload reports are needed for the same report type, e.g. for the same host but for different APNs, it should be up to the Diameter application where this is to be applied to define how to differentiate and use the multiple OC-OLR instances. One possible way could be to extend the report type with more types or values for such differentiation, as discussed previously, while there might be other ways e.g. with definition of new AVPs inside or outside OC-OLR AVP.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 3:26 AM
To: Shishufeng (Susan)
Cc: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

On Dec 9, 2013, at 4:12 AM, Shishufeng (Susan) <[email-masked]> wrote:

> De : DiME [mailto:[email-masked]] De la part de Nirav Salot 
> (nsalot) Envoyé : jeudi 28 novembre 2013 10:33 À : [email-masked] Objet 
> : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) 
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 21:09:59 -0600

> So far, there are only two report types defined, i.e. host and realm. In the future, if more overload reports are needed for the same report type, e.g. for the same host but for different APNs, it…

Okay, then I partially agree. But I think the rules for whether (and how) you allow multiple instances of the same report type should be per report type, rather than per application. I have trouble thinking of a situation where the rules for a given report type would be different between one application and another. (But I would welcome an example to change my mind :-)  )

Thanks!

Ben.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 10 Dec 2013 03:21:24 +0000

Hi Ben,

The APN example as Nirav raised may only be applicable to some 3GPP applications, e.g. S6a, Rx, Gx but not for others, e.g. Cx, Sh, Ro. Thus if some of the applications need more granularity of the overload report for the same host or realm, it should be them to define the details. If we extend report type for differentiation of such kinds of reports, it can be the applications to define the new report types, maybe with addition of new AVPs.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 11:10 AM
To: Shishufeng (Susan)
Cc: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Thanks!

Ben.