Re: [Dime] Dime: Diameter Overload IETF requirements, review

[Ben Campbell <[e-mail]>]

On Dec 7, 2012, at 9:24 AM, [e-mail] wrote:

>> [em] One solution uses existing messages as a carrier, piggybacking on them.  This can be done by an implementation without any change in the specification of the messages that are being used.  
>> 
>> [LM] It is exactly the issue for me! :) I think that you want to say that existing commands can be extended with changing the CCF specification and it is true. The application (and its related specification/documentation) using this command will change! And it is what I highlight in my comment and in the proposed change.
> 
> I'm not sure what you mean by the application changing in the piggyback case. Assuming the application specification uses the * [ AVP ] construct, an _implementation_ can add the OC AVPs without a change in the specification of specification. Yes, the implementation changes, but the spec doesn't have to. Given, there might be benefit to updating the spec, particularly if you want to describe application-specific behaviors rather than accepting the base behavior. But that's not a _requirement_, right?
> 
> What are we missing?
> 
> [LM] it is not the application specification that "uses the *[AVP]" but the CCF specification of a given command. And an application is not only defined by the command code format specifications. Set of AVP, error codes and so on are also part of the application. So adding new AVP to existing application IS a change of the application and related application specification, even if this addition is compliant with the CCF specification of the given command. You will have to describe at least that these new AVPs have to be carried in a specific set of commands when considering existing applications. I think that it the use of "specification" that causes problems here. And it is why I've proposed the change in REQ2.

I see your point, but the goal of that language was that you don't necessarily have to do that. For example, lets assume you have a spec for application "Foo" that defines a set commands, AVPs (including *[AVP] ), and their semantics. You also have a spec for piggybacked overload control, that defines additional AVPs that can be added to any message, their semantics, and at least one basic overload control algorithm. (I'm using piggybacked for the sake of argument here, since I think we agree that the issues are different if we have a separate OC application)

If all an implementer wants to use is the the basic OC algorithm, they merely implement both specs, adding the OC AVPs (as completely specified in the OC mechanism spec) to the Foo commands. You don't have to have a revised Foo spec to use the OC spec. It's analogous to a "mix in" pattern, if you will.

That being said, there may be real benefits to updating the Foo spec. For example, Foo might need an algorithm other than the base one. Or maybe it needs to define how to prioritize requests in overload conditions. Maybe Foo is a 3GPP spec, and they want to _require_ OC.

The idea is, you don't have to go back and do a mass update of every application to make OC useful. You can do it over time, as needed.

Thanks!

Ben.