Re: [Dime] DOIC: Self-Contained OLRs

[Jouni Korhonen <[e-mail]>]

On Nov 28, 2013, at 12:27 AM, Ben Campbell <[e-mail]> wrote:

> Hi,
> 
> I mentioned in another thread that I prefer putting an explicit ReportType AVP in an OLR, rather than

The more I spent time thinking/writing the actual procedures on the endpoints,
the more it makes sense to me to keep the ReportType in the OC-OLR. Even if the
baseline does not have agent overload etc, the ReportType fits well to the
"endpoint principle" we have in the draft. It indeed gives more tools to make
a host vs. realm base decision on the reacting node and is plain more clear.

I skip the rest of the mail.. too much text ;-)


- Jouni





> making a responding node infer the type or meaning of the OLR from a Diameter request that corresponds to the answer containing the OLR. My reasons for that go beyond just ReportType, so I'm starting a separate thread.
> 
> As currently described, a consumer of an OLR must infer several things from other context. In most cases, that context is in the Diameter answer that carries the OLR. For example, the OLR implicitly refers to the application identified by the Application-Id field of the enclosing answer, the realm identified by Origin-Realm, and so on. This means that the "meaning" of an OLR cannot be determined from the OLR contents alone; OLRs only have meaning in the context of the enclosing answer. If you moved an OLR from one answer to another, it's meaning may change completely.
> 
> I think this approach is a mistake. I would greatly prefer that we explicitly include such values in the OLR itself, for multiple reasons:
> 
> 1) It's more complex to interpret implicit, contextual values than explicit values. The consumer cannot simply look at the OLR; it must look in various other AVPs to find all the information it needs. For example, I think a common software design for overload control processing to be separated from application processing. The consumer cannot simply hand the OLR to that module and expect things to work. The OC module must not only parse the OLR, but parse any other AVPs that are relevant. As OLR contents get extended (assumedly following the same strategy as the base spec), the number of "context" avps that must be interpreted can grow large. This approach is error prone, and will likely encourage brittle, hard-to-maintain code. Self-contained OLRs would keep all the information related to overload in one place. making for simpler implementations.
> 
> 2) It's more complex for the reporting node to send implicit values than explicit values. The sender cannot simply set the context to match the OLR--all those other AVPs have application or protocol layer meanings. Once a reporting node realizes that it is overloade, it has to wait for the right answer that contains the right context before it can send the OLR. This is particularly troublesome for agents, since they will typically have to insert OLRs into answers created by other nodes. 
> 
> If the reporting node screws this up, the meaning of the OLR may change significantly. So again, implicit meaning gives us error prone implementations. Self-contained OLRs are simpler to create and send.
> 
> 3) Implicit values don't work at all for certain problems. For example, if an agent needs to originate an OLR, it typically needs to insert that OLR into an existing Diameter answer created by a server. It can't create its own answer without affecting the application state. If the responding node assumes the OLR comes from or refers to the node identified by the Origin-Host AVP in the enclosing answer, things break. (For examples of when an agent needs to send OLRs that are distinct from those sent by a server, see Steve's agent overload draft, or my dh/dr example.)
> 
> OTOH, explicit values will work for all cases where we need to associate some arbitrary value with an OLR.
> 
> 4) Implicit values seriously constrain the future evolution of Diameter OC standards. For example, lets say we find a good reason to allow OLRs to be sent out of band, or be sent in a dedicated Diameter application. If overload reports were self-contained, one could just reuse the report format we specify here. But if the meaning of an OLR depends on the way it's transported, this won't work. We would have to create a new or significantly modified OLR format if we found a need to transport OLRs in different ways. Self-contained OLRs would allow much greater flexibility.
> 
> So, in summary, I think that self-contained OLRs would lead to simpler implementations, less brittle deployments, and more flexibility for future evolution of standards.
> 
> Thanks!
> 
> Ben.
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime