Re: [Dime] DOIC: Self-Contained OLRs

["Nirav Salot (nsalot)" <[e-mail]>]

Steve,

In that case, I do not see any use of "self-contained OLR".
e.g. the server sends application-Y's report in application-X's message. The client may ignore the application-Y's report and hence the server has to ensure to send application-Y's report in application-Y's message as well.
So what is the gain here?

I do not understand the need to define such a mechanism.

Regards,
Nirav.

From: Steve Donovan [mailto:[e-mail]]
Sent: Monday, December 16, 2013 9:42 PM
To: Nirav Salot (nsalot); [e-mail]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

There is nothing in the self-contained overload report proposal the requires cross-application data handling.  An implementation can take advantage of cross-application information if it is able and wants to, but it is not required to do so.

Regards,

Steve
On 12/16/13 9:50 AM, Nirav Salot (nsalot) wrote:
Steve,

SRD> I don't understand what is meant by "requires architectural support".  Is this a way of saying it is more difficult to implement?
As of today, the Diameter message can only contain data specific to one application and based on this, the nodes are designed to handle data/AVP specific to one application.
Thus, cross-application data handling (that you are proposing via "self-contained OLR") is not required to be supported in today's design/architecture of the Diameter node supporting a set of applications.

Regards,
Nirav.

From: Steve Donovan [mailto:[e-mail]]
Sent: Monday, December 16, 2013 6:54 PM
To: Nirav Salot (nsalot); [e-mail]<mailto:[e-mail]>
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

See my response inline.

Regards,

Steve
On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:
Steve,

Why do you always talk about "the application which the Diameter node does not understand?"
What if the reacting node supports two applications and in the message for application-X it receives the overload-report for application-Y?
Do you propose to ignore this report as well?
SRD> The logic behind self contained reports would be that the reactor  use the reports that it makes sense for the reactor to use.  I think your question is what should a reactor do if it supports application-X and application-Y, sends a request for application-X and receives a reply with an overload report for application-Y in the answer to that request. The behavior I would suggest is that the reactor should (not must) honor the overload report for requests sent to application-Y.  If this is particularly difficult for the reactor to achieve then it can wait to receive an overload for application-Y in answers to requests sent on application-Y.



As already indicated earlier, by many of us, handling of application-Y's data in the application-X's message is not how the Diameter applications are designed today. And hence this type of proposal requires architectural support for handling it. And there lies the complexity.
SRD> I don't understand what is meant by "requires architectural support".  Is this a way of saying it is more difficult to implement?


This main drawback was highlighted earlier as well but was conveniently ignored while preparing the pros and cons list for the self-contained OLR.
SRD> Then suggest it be added to the pros and cons list.  But first explain the concept of "requires architectural support".



Regards,
Nirav.

From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
Sent: Thursday, December 12, 2013 7:16 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

Can you explain the complexity behind the cross-application procedure.  The work required is to ignore any application that the Diameter node does not understand.  I don't see this as very complex.

Steve
On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
Yes, I agree consistency is not any longer a problem, since now your intention is that _any_ (and multiple) application data could be conveyed within the same message.
But as mentioned a few times, I consider this not necessary since OLR is sent in every answer.
A part from that, as mentioned by Lionel, this implies a cross-application procedure at both endpoints, that increases complexity and it is not required for our work (RFC7068)

Cheers
/MCruz

From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
Sent: miércoles, 11 de diciembre de 2013 20:09
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

I don't agree with the assertion that self-contained OLRs results in the potential for data inconsistency.  If a reactor receives an overload report for an application that is not supported by the reactor then the reactor can and should ignore that OLR.

The concept of self-contained overload reports would explicitly allow for the contents of the overload report to be different than the message that is carrying the OLR.  As with application-ids, if the reactor doesn't send messages to a reported host or realm then the reactor ignores that part of the overload report.  As such, there is no need to check the implicit data when receiving a self-contained OLR.

Steve
On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:

Hello (and something else now :), fast key combination, I won't be able to repeat,  was the responsible)



As mentioned before, something else on cons side for self-contained:



A part from that,  one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred.

Best regards
/MCruz

From: DiME [mailto:[e-mail]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: miércoles, 11 de diciembre de 2013 19:02
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach scope approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (eg containing a % of traffic reduction) coupled with one or several Overlaod-Infoscope AVPs, an overlaod infoscope identifying an application or a destination host or... . These Overlaod-Infoscope AVPs can be combined  with also  the possibility of  multi instances to have a list of applications, a list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contain an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (the self containment approach) to indicate which application(s), destinations host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self contained approach

Best regards

JJacques



De : DiME [mailto:[e-mail]] De la part de Steve Donovan
Envoyé : mercredi 11 décembre 2013 14:20
À : [e-mail]<mailto:[e-mail]>
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scopes concept in the Roach draft, they are not the same.  As such, I don't agree with your assertion that the previous rejection of the Roach draft requires us to reject self contained overload reports as currently being discussed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi Ben and all

I remind my mail of 05/12, where the self contained OLRs approach is quite similar to the self contained scopes  of Draft Roach which drives to multiply the number of AVPs in the OLRs (AVPs identifying Application, destination Host or even a list of Destination Hosts,  Origin-Host etc ) with all the combinational aspects behind (a list of such combinational were addressed in draft Roach).
This also result in a piggybacking  to be done  in any message , as the self contained OLR may contain many things which are not related to the answer message conveying the self contained OLR . This also  implies that at each hop, the self contained  OLRs are opened to be reprocessed in order to recreate  new self contained OLR(s)  to various destinations.
I remind that, now 6 months ago:
Many companies considered these scopes  approach too much complex, and all people including you  or your colleagues agreed to evolve towards a more simple way to proceed, which drove to the current draft content. This decision is a strong argument that still prevails  for the current baseline described in the current draft.

This is why I remain in favor of the baseline  described in the current  draft, as as I have always and regularly  expressed for  a while.

As also said, when news requirements will appear (eg session group or APN examples)  the baseline is extensible to support these new requirements .  I prefer this way of progressive extensions , rather than to create a self contained OLR  with an  immediate and not needed complexity

Best regards

JJacques


De : DiME [mailto:[e-mail]] De la part de Shishufeng (Susan)
Envoyé : mardi 10 décembre 2013 04:58
À : Ben Campbell; [e-mail]<mailto:[e-mail]> list
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Each solution has its pros and cons. The key point here is to select a right one which could satisfy the requirements but with less resource consuming.

Quick thinking on the pros you listed for self-contained OLR.


-          The first two pros can be seen as optimization, on which we are still arguing if these optimization are worth doing or not, since such optimization brings extra cost.

-          The third one is not a key issue, which could be addressed with several ways as discussed. As a last resort, the overloaded server may send something in a request towards the client to inform the end of the overload.

-          The last three pros are mainly for the case of overload of agent, if I understood them correctly. Overload of agent is still a controversial scenario, we may need more discussion in the future. But anyway, with definition of new AVPs containing the application-id, host, realm information as implied by the piggybacking messages in the draft, as complement to the OLR so far defined, they could reach the same intention as with the self-contained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:[e-mail]]
Sent: Tuesday, December 10, 2013 7:53 AM
To: [e-mail]<mailto:[e-mail]> list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

I am willing to call the discussion concluded for the purposes of what goes in version 01 of the DOIC  draft. But I'd like to poke a little more on what we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, Maria, and Susan), and 3 in favor (Martin, Steve, and obviously me.) I don't think that fits the usual definition of rough consensus. So I'd like to look at the pros and cons a little more explicitly. Here's my view of them. I'm sure others will have other views--but I've yet to see those in the first group explain what they think the pros of implicit OLRs might be beyond those that I've included. I've also omitted any appeal to software layering, since people disputed that already.

It would also be good to hear from anyone who has not already weighed into this.

Self-Contained OLRS:

Pros:

  *   Allows an easy, generic solution to Maria's "all-application" scoped overload use case.
  *   Allows an overloaded node to signal overload for multiple applications at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not being able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requiring inconsistent behavior.
  *   Allows out-of-band transmission of OLRs without a new format
  *   Makes it easier to do things like adding a dedicated application for overload, without a new format. (Yes, I think there's still a use case for that, and I will detail it shortly.)
Cons:


  *   The recipient cannot assume an OLR matches the context of the transaction in which it is received.
  *   It's different than what's in the draft.

Implicit OLRs:

Pros:

  *   The recipient can infer the OLR scope from a combination of the transaction context and the report type. [I don't understand why this is valuable, but am including it since people mentioned it.]
  *   Currently described in the draft.
Cons:

  *   Would need special-case behavior to allow the "all-application" scope.
  *   An overloaded node needs to send a separate report for every supported application.
  *   Needs special-case behavior to solve agent overload
  *   Cannot signal the end of a loss algorithm 100% overload condition
  *   cannot be used out-of-band.
  *   cannot be used with dedicated applications.



On Dec 9, 2013, at 5:09 AM, Jouni Korhonen <[e-mail]<mailto:[e-mail]>> wrote:

OK. Lets call this thread concluded then. I keep the old OC-OLR  semantics
regarding its information context then unmodified.

- Jouni



_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dime








_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dime







_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dime