Re: [Dime] DOIC: Self-Contained OLRs

[Steve Donovan <[e-mail]>]

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]
> *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 J, 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
>
>  
>
>  
>