Re: [Dime] DOIC: Self-Contained OLRs

[Ben Campbell <[e-mail]>]

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
>