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

[<[e-mail]>]

-----Message d'origine-----
De : Ben Campbell [mailto:[e-mail]] 
Envoyé : vendredi 7 décembre 2012 16:47
À : MORAND Lionel OLNC/OLN
Cc : Eric McMurry; THIEBAUT, LAURENT (LAURENT); [e-mail]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review


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.

[LM] I agree in the principle! But again, I'm not speaking about documentation issue. About a dedicated new application for OC, there is no impact on application. However, to support OC specific AVPs over existing FOO commands, any application using these FOO commands will be enhanced, right? Of course, the requirement is that this enhancement should not cause backward compatible issues with existing implementation. After, how and when introduce this upgrade in the existing nodes is only an operational issue. If you can ensure that the changes required to support OC do not cause the creation of a new application (cf. section 1.3 of RFC 6733), you are in the safe side. And I'm not saying anything else by "Support of this mechanism over existing Diameter applications MUST NOT require major changes that would lead to the need to define a new Diameter application." If this requirement is fulfilled, you don't have to upgrade at the same time all the Diameter peers (client, server, proxy) supporting the existing application.

About documenting how to support OC over existing applications, you can do it in different ways: companion document, update of the existing specification, etc. But it is not something that matters here.

Cheers.

Lionel



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.