Re: [Dime] DOIC: Self-Contained OLRs

[Steve Donovan <[e-mail]>]

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]
> *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]
> https://www.ietf.org/mailman/listinfo/dime