Re: [Dime] DOIC: Self-Contained OLRs

["Shishufeng (Susan)" <[e-mail]>]

Hi Ben,

For the last one, what I meant was that with the mechanism proposed in the base document, it can be extended to address the out-of-band transmission or adding a dedicated application as listed in your last two pros when needed in the future. 

There might be some benefit with use of self-contained OLR if we are sure that the use cases for out-of-band transmission and dedicated application need to be addressed. While so far the implicit OLRs can satisfy the requirements from 3GPP, and other use cases for out-of-band transmission and dedicated application are not clear to 3GPP and may never be addressed. A right solution is what we need for now.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[e-mail]] 
Sent: Thursday, December 12, 2013 6:42 AM
To: Shishufeng (Susan)
Cc: [e-mail] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs


On Dec 9, 2013, at 9:58 PM, Shishufeng (Susan) <[e-mail]> wrote:

> 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.

I think the reason it may not be a key issue is that we didn't have a solution for it. I am personally not fond of having to treat 100% overload as different from all other cases.

We currently do not allow OLRs in requests, although the solution I had in mind might actually need to do that. But if we need to send OLRs in requests, we will need something like self-contained OLRs, or we have to limit ourselves to application specific solutions.


> -          The last three pros are mainly for the case of overload of agent, if I understood them correctly.

The 4th one is. The last 2 are not specific to agents. (If anything, the last one is inspired more for true end-to-end overload indication.)

> 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.

I'm not sure I follow your last sentence. If you mean AVPs for application-id, etc, that go _in_ the OLR, then that's pretty much the same thing as (at least partially) self-contained OLRs




>  
> Best Regards,
> Susan
>  
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Tuesday, December 10, 2013 7:53 AM
> To: [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]> 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