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

Hi,

I think we've got some confusion on the point of the requirement. Tom is correct that many Diameter implementations decompose things in that particular way. But the requirement is not about stack architecture, it's about protocol documentation. I don't think any of us expect that you can take advantage of a new OC mechanism without making changes to _software_.

The point is, you can make those changes to _software_ without waiting for whatever spec defines the application to be revised. That may not be important to all implementors, but, for example, lets say you are implementing some of the 3GPP interfaces. You can implement and negotiate _basic_ OC without waiting for the next 3GPP release to revise the specs.

On Dec 9, 2012, at 3:02 PM, "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