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

Thanks for clarifying your thoughts Laurent.

I think we're all on the same page that some changes are likely to happen to support overload control in the application specifications and that this is the right level to consider priorities and other application specific behaviors.  Where we seem to be getting wrapped up though is whether those changes will be required to use an overload control mechanism.  I agree changes at the application specifications are a good idea, but I do not think they are required for basic operation of an overload control mechanism.  I don't see why a mechanism (including the two proposals) could not be used without any changes to application specifications.

In your example with an end point implemented as a stack and and application layer, handling of an overload control protocol could be done in either place.  Decisions about what to do would make sense at the application level, but the implementation could do that in an interoperable fashion  without needing a new specification, for protocol or behavior, with, for example, a drop or throttle algorithm that made no consideration of priority.

I think it is important for the design of an overload control mechanism to support operation without application specification changes.  It will allow some overload control to be implemented even before application specifications are updated.  It will also ensure that the mechanism can be used for application specifications that will not be, or do not need to be, updated.  Having a basic overload control mechanism in place will be an improvement over current conditions.  We can then further improve this, by updating application specifications, to cover cases like those you mention for S6a.

Thanks,

Eric

On Dec 9, 2012, at 15:02 , "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@ALCATEL-LUCENT.COM> wrote:

>  
>  
> Hello all
> I'd like to highlight the comment from Tom that touches the topic we wanted to address via our (unfortunate as it raised (too) much discussion) comment on REQ 2
>  
> Let’s Consider a Diameter end point SW is split up into 2 parts:
> ·         a base Diameter stack
> ·         an application SW
> Even though the application *protocol* is NOT touched by Diameter overload (thanks to * [AVP]), it seems questionable that only the base Diameter stack would handle the changes due to the Diameter overload control we are defining (and that thus the application SW would be untouched). Said otherwise something will have to change in the Behaviour of the source application.
>  
> One of the reasons is that only the application knows the relative priority of the various procedures and of the various users: e.g. taking the 3GPP S6a as an example (= MME as a kind of authenticator accessing the subscriber database i.e. the HSS), only the MME SW (as opposed to the Diameter stack or diameter agent en route between the S6a client and server) knows that
> o        an Update location is of higher priority than a Purge
> o        User Lionel is a high priority user while user Laurent is low tier user
> o        a request is associated with an emergency
> o        etc…
>  
> So the application behaviour/SW is likely to be changed
>  
> May be a solution is to change second part of the REQ2 into "It MUST NOT require protocol specification changes for existing Diameter applications" (hinting that a behaviour change is possible)
> Best regards
> Laurent
> ALCATEL-LUCENT
>  
> Disclaimer: this mail is not meant to promote any of the 2 solutions on the table. It is JUST about requirements.
>  
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Tom Taylor
> Envoyé : samedi 8 décembre 2012 04:17
> À : lionel.morand@orange.com
> Cc : dime@ietf.org
> Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review
>  
> Ben, I think the problem is that a Diameter implementation can be
> thought of as a base part and an application-specific part. A message
> comes in, gets processed by the Diameter base part, then the application
> is passed the type of message and the parts not consumed by base. So
> some extra information is tacked on in that optional AVP part. Either
> the base recognizes it and deals with it, or the application does. If
> the application is to handle it, the application has to expect it --
> that is, the specification of the application includes the additional data.
>  
> On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote:
> > 
> > 
> > -----Message d'origine----- De : Ben Campbell
> > [mailto:ben@nostrum.com] Envoyé : vendredi 7 décembre 2012 16:47 À :
> > MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT
> > (LAURENT); dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload
> > IETF requirements, review
> > 
> > 
> > On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com 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.
> >> 
> ...
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime