Re: [Dime] DOIC: Self-Contained OLRs

[Steve Donovan <[e-mail]>]

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