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

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 6 Dec 2012 14:16:44 +0100

Dear all

In the objective of relying on IETF specifications to handle Diameter overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of the draft-ietf-dime-overload-reqs-01.

We consider the list of REQs described in the IETF draft as quite extensive and all REQs relevant. We have the few additional comments to submit to the upcoming Dime review:

*       We suggest to put more emphasis in REQ1 on the fact this is both for load (preventive) and overload (reactive). A possible writing:
REQ 1:   The overload mechanism MUST provide a communication method for Diameter nodes to exchange load and overload information.

*       About REQ 2 ("The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications"), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 "allowing for the possibility of increased feedback for information piggybacked" as the piggybacking mechanism may impact the application. May be a solution is to suppress this second part of the REQ2 (" It MUST NOT require specification changes for existing Diameter applications") or review the wording.

*       On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of the "which message types might be desirable to send or process over others during times of overload" should be left for each application to define (for " ...  Diameter specific considerations). If this reading of REQ 26 is shared, a possible rewording could be:
REQ 26:  The generic specification for the overload mechanism SHOULD offer overall guidance on which message types might be desirable to send or process over others during times of overload, based on Diameter-specific considerations.  For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. A precise specification of the relative priorities of message types in case of overload would anyhow be under the responsibility of each application.

*       We expressed the point that overload handling should take into account that some messages may have a high priority (eg when related to an emergency or a high priority user").  This handling would  be application dependent and so entering the REQ 26 as an overall guidance but it could be mentioned in REQ 26 as an example with the possible wording
" For example, it may be more beneficial to process messages for existing sessions ahead of new sessions and to give priority to requests associated with emergency sessions or with high priority users"

*       Last sentence of REQ 35 appears unclear, wording may be reviewed or this sentence may be suppressed.

.
Best regards

JJacques Trottin
Alcatel-Lucent delegate to 3GPP CT4

---

From: Eric McMurry <[email-masked]>
Date: Thu, 6 Dec 2012 08:05:29 -0600

Thanks for the comments!

responses inline.

Eric

On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> wrote:

> Dear all
>  
>  
> In the objective of relying on IETF specifications to handle Diameter overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of thedraft-ietf-dime-overload-reqs-01.
>  
> We suggest to put more emphasis in REQ1 on the fact this is both for load (preventive) and overload (reactive). A possible writing:
> REQ 1:   The overload mechanism MUST provide a communication method for Diameter nodes to exchange load andoverload information.
>  

sounds reasonable to me.

> About REQ 2 (“The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications”), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 “allowing for the possibility of increased feedback for information piggybacked”as the piggybacking mechanism may impact the application. May be a solution is to suppress this second part of the REQ2 (“ It MUST NOT require specification changes for existing Diameter applications”) or review the wording.

The intent of this was not to say that applications can not be changed to make use of overload control, just that they won't be required to.  I think with either of the proposed mechanisms based on these requirements, this would be met.  They can be used without any alteration to applications.  That said, overload control will work better with consideration for how each application can be impacted and how it should respond.  

The second part of REQ 13 is only commentary on the scaling properties of existing messaging, but in general piggybacking can be done without impacting applications.  This requires a * [ AVP ] in the applications messages though.  Adam did a survey of all the applications he could find when he was writing the proposed mechanism and did not find any examples where this was not the case (and this is recommended by the base protocol).

>  
> On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of the “which message types might be desirable to send or process over others during times of overload” should be left for each application to define (for “ …  Diameter specific considerations). If this reading of REQ 26 is shared, apossible rewording could be:

I believe that was the point it was trying to get across.  I think your last sentence would add some clarity.

>  
> We expressed the point that overload handling should take into account that some messages may have a high priority (eg when related to an emergency or a high priority user”).  This handling would  be application dependent and so entering the REQ 26 as an overall guidance but it could be mentioned in REQ 26 as an example with the possible wording
> “ For example, it may be more beneficial to process messages for existing sessions ahead of new sessions and to give priority to requests associated with emergency sessions or with high priority users”

I don't have any issue with that.  What was there was intended as only the simplest example.  There are many ways to do this.  Adding one more example shouldn't hurt, but we probably don't want to go down the path of listing possibilities here.

>  
> Last sentence of REQ 35 appears unclear, wording may be reviewed or this sentence may be suppressed.

We can probably strike that.  What do you think, Ben?

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Dec 2012 08:38:44 -0600

On Dec 6, 2012, at 8:05 AM, Eric McMurry <[email-masked]> wrote:

>> 
>>  
>> 	• Last sentence of REQ 35 appears unclear, wording may be reviewed or this sentence may be suppressed.
> 

The point was to say that sharing data between non-adjacent nodes might require a different mechanism than exchanging between adjacent nodes. But, whether that is true or not, it's not necessary to say it here. I concur with striking it.

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Thu, 6 Dec 2012 16:48:00 +0100

Hello all

About Req2, we understand that based on the usage of the *[ AVP ], there is no need to update the ""ABNF"" of the protocol describing the various Diameter applications!  Nevertheless the behaviour of the application, i.e. the SW using that "unchanged protocol" will have to be changed anyhow to support Diameter overload control. Can we reword Req2 into

The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications *but is likely to require a change of the behaviour of an entity supporting a Diameter application and the Diameter overload mechanism.*

This "is likely" is NOT an IETF normative wording (MUST, SHOULD,...) as the part of the sentence that is being added is more of an explanatory / clarification nature (I hope).

Best regards

Laurent
ALCATEL-LUCENT

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Eric McMurry
Envoyé : jeudi 6 décembre 2012 15:05
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : [email-masked]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

Thanks for the comments!

responses inline.

Eric

On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]<mailto:[email-masked]>> wrote:

Dear all

sounds reasonable to me.

 *   About REQ 2 ("The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications"), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 "allowing for the possibility of increased feedback for information piggybacked"as the piggybacking mechanism may impact the application. May be a solution is to suppress this second part of the REQ2 (" It MUST NOT require specification changes for existing Diameter applications") or review the wording.

 *   On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of the "which message types might be desirable to send or process over others during times of overload" should be left for each application to define (for " ...  Diameter specific considerations). If this reading of REQ 26 is shared, apossible rewording could be:
REQ 26:  The generic specification for the overload mechanism SHOULD offer overall guidance on which message types might be desirable to send or process over others during times of overload, based on Diameter-specific considerations.  For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. A precise specification of the relative priorities of message types in case of overload would anyhow be under the responsibility of each application.

.
Best regards

JJacques Trottin

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Dec 2012 10:02:50 -0600

On Dec 6, 2012, at 9:48 AM, "THIEBAUT, LAURENT (LAURENT)" <[email-masked]> wrote:

>  
>  
> Hello all
> About Req2, we understand that based on the usage of the *[ AVP ], there is no need to update the ““ABNF”” of the protocol describing the various Diameter applications!  Nevertheless the behaviour of the application, i.e. the SW using that “unchanged protocol” will have to be changed anyhow to support Diameter overload control. Can we reword Req2 into
> This “is likely” is NOT an IETF normative wording (MUST, SHOULD,…) as the part of the sentence that is being added is more of an explanatory / clarification nature (I hope).

I have mixed feelings about this, and I think it has to do with the definition of "application".  If we do this right, the _base_ Diameter overload control behavior should come to any application, old or new, for "free", assuming the definition of that application included the *[ AVP ] construction. That's in the strict sense of what constitutes a "Diameter Application". If the application would benefit from more application specific behaviors, they can always add them.

OTOH, the definition of an "interface" that uses one or more "applications" is highly likely to change, if for no reason that to require support of OC.

I propose an indented paragraph with a couple of sentences to explain this, rather than making it part of the same sentence as the normative requirement.

> 	• We suggest to put more emphasis in REQ1 on the fact this is both for load (preventive) and overload (reactive). A possible writing:
> 	• About REQ 2 (“The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications”), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 “allowing for the possibility of increased feedback for information piggybacked”as the piggybacking mechanism may impact the application. May be a solution is to suppress this second part of the REQ2 (“ It MUST NOT require specification changes for existing Diameter applications”) or review the wording.
>  
> 	• On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of the “which message types might be desirable to send or process over others during times of overload” should be left for each application to define (for “ …  Diameter specific considerations). If this reading of REQ 26 is shared, apossible rewording could be:
> 	• We expressed the point that overload handling should take into account that some messages may have a high priority (eg when related to an emergency or a high priority user”).  This handling would  be application dependent and so entering the REQ 26 as an overall guidance but it could be mentioned in REQ 26 as an example with the possible wording

---

From: <[email-masked]>
Date: Thu, 6 Dec 2012 17:50:34 +0000

Hi,

I think that we should not misuse "application" and "specification" here. The problem is not about change in the specification but about change in the Diameter application. 

In my understanding, the intention of the second sentence of REQ2 is to say that the support of OC mechanism must not imply major extensions of existing Diameter Applications, which would cause the definition of a new application and the allocation of a new Application-id, as per RFC6733.

But of course, if required, existing applications can be slightly enhanced to support OC without major impacts (e.g. using optional AVPs), and then no need for new Application-id, and then the related specification will have to be updated to describe how to support this new feature.

If my understanding is correct, would the following change be agreeable?

OLD:

   REQ 2:   The overload [control] mechanism MUST be useable with any existing or
            future Diameter application.  It MUST NOT require
            specification changes for existing Diameter applications.

NEW:

   REQ 2:   The overload [control] mechanism MUST be useable with any existing or
            future Diameter application.  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.

By the way, I think that we are working on a mechanism to control overload and not a mechanism for overload, right. Should "overload mechanism" be replaced by "overload control mechanism" all over the document?

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : jeudi 6 décembre 2012 17:03
À : THIEBAUT, LAURENT (LAURENT)
Cc : [email-masked]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

On Dec 6, 2012, at 9:48 AM, "THIEBAUT, LAURENT (LAURENT)" <[email-masked]> wrote:

> This "is likely" is NOT an IETF normative wording (MUST, SHOULD,.) as the part of the sentence that is being added is more of an explanatory / clarification nature (I hope).

> 	. We suggest to put more emphasis in REQ1 on the fact this is both for load (preventive) and overload (reactive). A possible writing:
> 	. About REQ 2 ("The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications"), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 "allowing for the possibility of increased feedback for information piggybacked"as the piggybacking mechanism may impact the application. May be a solution is to suppress this second part of the REQ2 (" It MUST NOT require specification changes for existing Diameter applications") or review the wording.
>  
> 	. On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of the "which message types might be desirable to send or process over others during times of overload" should be left for each application to define (for " .  Diameter specific considerations). If this reading of REQ 26 is shared, apossible rewording could be:
> 	. We expressed the point that overload handling should take into account that some messages may have a high priority (eg when related to an emergency or a high priority user").  This handling would  be application dependent and so entering the REQ 26 as an overall guidance but it could be mentioned in REQ 26 as an example with the possible wording
> 	. Last sentence of REQ 35 appears unclear, wording may be reviewed or this sentence may be suppressed.
>  

_________________________________________________________________________________________________________________________

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.

---

From: Eric McMurry <[email-masked]>
Date: Thu, 6 Dec 2012 12:12:50 -0600

>           to the need to define a new Diameter application.

sounds reasonable, but it's a bit less strong.  It would be good for the mechanism to work without requiring any changes to applications.  This is achievable and I think both proposed mechanisms could be used over, or alongside, existing applications without any changes to the applications.  Applications may provide additional specification on top of this, which the requirements do not at all prevent now.  I gather some would like additional language spelling this out though.

> By the way, I think that we are working on a mechanism to control overload and not a mechanism for overload, right. Should "overload mechanism" be replaced by "overload control mechanism" all over…

I suppose we have plenty of mechanisms for overload already.

I think I had intended to do just this at one point, but it must have fallen out of my head.

[...]

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Thu, 6 Dec 2012 19:24:32 +0100

Hello Lionel
The point was not on the protocol itself (so the change you mentioned was not per se requested/hinted by our text).
We wanted to highlight that even though there are no new application related AVP being required (because the generic "overload-control" AVP provides enough signalling capability for load/overload control), there will be a need for a standard group (e.g. 3GPP for 3GPP based applications) to define the *behaviour* of the Diameter (client/server) application upon reception of this "overload-control" AVP.

Said otherwise, even though there is the * [AVP], the diameter overload control AVP and generic specifications we are going to define is not a free meal for the definition of the application.  
Best regards
Laurent
ALCATEL-LUCENT 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 6 décembre 2012 18:51
À : Ben Campbell; THIEBAUT, LAURENT (LAURENT)
Cc : [email-masked]
Objet : RE: [Dime] Dime: Diameter Overload IETF requirements, review

Hi,

OLD:

NEW:

Lionel

---

From: <[email-masked]>
Date: Thu, 6 Dec 2012 18:32:29 +0000

Hi Eric,

Please see below.

Regard,

Lionel

-----Message d'origine-----
De : Eric McMurry [mailto:[email-masked]] 
Envoyé : jeudi 6 décembre 2012 19:13
À : MORAND Lionel OLNC/OLN
Cc : Ben Campbell; THIEBAUT, LAURENT (LAURENT); [email-masked]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

[LM] Both solutions consider "piggybacking" and piggybacking of any new info over existing commands is actually a change into the Diameter application. But what we want is to make this change as smooth as possible for existing application. And it is the requirement that I read in REQ2.

Now if it is about "alongside" i.e. with no protocol change at all on existing application, the second sentence REQ2 would be anyway irrelevant because you could say that for any other protocol e.g. "this mechanism MUST NOT require specification changes for existing SIP or HTTP or whatever"

[...]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Dec 2012 12:41:07 -0600

>            to the need to define a new Diameter application.

WFM

> By the way, I think that we are working on a mechanism to control overload and not a mechanism for overload, right. Should "overload mechanism" be replaced by "overload control mechanism" all over…

Agreed. Overload can happen just fine without any help from us :-)

---

From: Eric McMurry <[email-masked]>
Date: Thu, 6 Dec 2012 12:46:15 -0600

Thanks Lionel.  comments inline.

Eric

> Now if it is about "alongside" i.e. with no protocol change at all on existing application, the second sentence REQ2 would be anyway irrelevant because you could say that for any other protocol e.g…

[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.  The other solution uses a separate application that does not use, or alter, any existing messages.  This could also be done without any change in the specification of other applications.  I'm confused as to what changes would be required in any applications for an element to use either of the mechanisms?  Desired, yes (as Laurent was pointing out), but not required.

[...]

---

From: <[email-masked]>
Date: Fri, 7 Dec 2012 09:42:51 +0000

Hi Eric,

I think that I understand the misunderstanding. Please see below

> Now if it is about "alongside" i.e. with no protocol change at all on existing application, the second sentence REQ2 would be anyway irrelevant because you could say that for any other protocol e.g…

[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.

The other solution uses a separate application that does not use, or alter, any existing messages.  This could also be done without any change in the specification of other applications. 

[LM] So the second sentence will be always true i.e. no impact at all on existing applications.  

 I'm confused as to what changes would be required in any applications for an element to use either of the mechanisms?  Desired, yes (as Laurent was pointing out), but not required.

[LM] I hope that clarifies my point... that is not (so) different from yours and Laurent's one! 

[...]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 7 Dec 2012 09:04:19 -0600

H Lionel, see comments inline:

> [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 spec…

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?

---

From: <[email-masked]>
Date: Fri, 7 Dec 2012 15:24:31 +0000

Hi Ben, see below.

Regards,

Lionel

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

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.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 7 Dec 2012 09:47:28 -0600

> [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. S…

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.

---

From: <[email-masked]>
Date: Fri, 7 Dec 2012 16:19:50 +0000

-----Message d'origine-----
Envoyé : vendredi 7 décembre 2012 16:47

[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

---

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Dec 2012 22:16:49 -0500

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, [email-masked] wrote:
>
>
> -----Message d'origine----- De : Ben Campbell
> [mailto:[email-masked]] Envoyé : vendredi 7 décembre 2012 16:47 À :
> MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT
> (LAURENT); [email-masked] Objet : Re: [Dime] Dime: Diameter Overload
> IETF requirements, review
>
>
>>> [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.
>>
...

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Sun, 9 Dec 2012 22:02:48 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de Tom Taylor
Envoyé : samedi 8 décembre 2012 04:17
À : [email-masked]
Cc : [email-masked]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

On 07/12/2012 11:19 AM, [email-masked] wrote:

...

DiME mailing list

[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Sun, 9 Dec 2012 21:32:03 -0600

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)" <[email-masked]> wrote:

> Let’s Consider a Diameter end point SW is split up into 2 parts:
> ·         a base Diameter stack
> ·         an application SW
> o        etc…

---

From: Eric McMurry <[email-masked]>
Date: Sun, 9 Dec 2012 21:54:42 -0600

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 10 Dec 2012 21:00:11 +0100

Hi all

About this long discussion on REQ2, I hereafter give some additional comments

1)      Regarding Lionel's remark,  the fact to add related overload AVPs to existing commands of a given Diameter application means these AVPs are now part of the Diameter application which should deal with them, so impacting the application.

On another side, in REQ13, piggybacking is mentioned as an example of a solution for this REQ13 .  With  piggybacking, the message is only used as transporter of the related overload AVPs.   As messages from different Diameter applications may be transferred over the same connection,  from my understanding, we may have a solution where  the overload AVPs are transported in any message of any application and relate or are specific to the same Diameter application as the message one or to another application or be application independent. Here  can we say these transported AVPs are sometimes  part of the Diameter Application and sometimes no?

Although this is a solution level discussion, it directly relates to the REQ2 sentence: "It MUST NOT require specification changes for existing Diameter applications".

I am rather in favor of Lionel's remark and on the text he proposes. When an AVP is conveyed in a command of an application, it is part of this Diameter application. The same AVPs may be used by different Diameter applications. Then it is a matter of implementation: these overload  AVPS or some of them may be processed by a separate application-independent function in a node, so to minimize  impact on existing applications, but it is implementation.

2)      In Req1 it is stated that the overload mechanism objective is "to provide a communication method ...to exchange the overload information", so no more , no less from my understanding.  Then there are requirements on the Diameter node behaviors. I have  no issue with the many  REQs for managing and optimizing well this information exchange (eg REQ 9, 13, 14, 19...) by nodes . It is another topic on how the exchanged information is then used by nodes. I am also OK with the REQs starting with "the mechanism MUST allow nodes to ... (REQ7) , "...MUST provide a way to (REQ 22)' as we are still speaking of the exchanged information  which  allows nodes to... . I think we should also use this type of wording for a few requirements  eg for REQ 7  "the mechanism  must ensure  that the system remains stable" as it is not the exchanged information  which stabilize the system, but the nodes behavior on the basis of information exchanges.

3)      This document does not address any overload algorithm which will be key on how the exchanged information is then used by nodes.   From a 3GPP angle, the approach ALU foresees is to use the Dime method to exchange the overload information, eventually by extending the information exchanged (REQ 33, 34),   and to specify nodes behaviors about overload handling according to the Diameter application (corresponding to a 3GPP interface) and the overload algorithm.

Eric's mail mentions a basic operation of an overload control mechanism, which should correspond to an overload algorithm. Has Dime the intent to specify some general overload algorithms?

4)      I remind the question of priority  given to some users that 3GPP will have to handle. Generally, it is the client that should  manages such priorities and signals it to the server but the intermediate Diameter agents are not neutral there and should have the relevant information to behave correctly (eg to not drop a message for a priority user). On Req 26 ,we proposed  an additional wording "" For example, it may be more beneficial to process messages for existing sessions ahead of new sessions and to give priority to requests associated with emergency sessions or with high priority users". Do you think it is sufficient, or should we have a normative statement (not only an example)?

Best regards

JJacques

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric McMurry
Sent: lundi 10 décembre 2012 04:55
To: THIEBAUT, LAURENT (LAURENT)
Cc: [email-masked]
Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review

Thanks,

Eric

On Dec 9, 2012, at 15:02 , "THIEBAUT, LAURENT (LAURENT)" <[email-masked]<mailto:[email-masked]>> wrote:

Hello all

*         a base Diameter stack
*         an application SW

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Tom Taylor
Envoyé : samedi 8 décembre 2012 04:17
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

On 07/12/2012 11:19 AM, [email-masked]<mailto:[email-masked]> wrote:
> [mailto:[email-masked]<http://nostrum.com>] Envoyé : vendredi 7 décembre 2012 16:47 À :
> (LAURENT); [email-masked]<mailto:[email-masked]> Objet : Re: [Dime] Dime: Diameter Overload
> On Dec 7, 2012, at 9:24 AM, [email-masked]<mailto:[email-masked]> wrote:
>
...

---

From: Eric McMurry <[email-masked]>
Date: Mon, 10 Dec 2012 14:43:25 -0600

Hi JJaques,

please see comments inline.

Thanks,

Eric

On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> wrote:

> 1)      Regarding Lionel’s remark,  the fact to add related overload AVPs to existing commands of a given Diameter application means these AVPs are now part of the Diameter application which should deal with them, so impacting the application.
>  
> Although this is a solution level discussion, it directly relates to the REQ2 sentence: “It MUST NOT require specification changes for existing Diameter applications”.
> I am rather in favor of Lionel’s remark and on the text he proposes. When an AVP is conveyed in a command of an application, it is part of this Diameter application. The same AVPs may be used by different Diameter applications. Then it is a matter of implementation: these overload  AVPS or some of them may be processed by a separate application-independent function in a node, so to minimize  impact on existing applications, but it is implementation.

I believe the requirements in this doc apply to the definition of a standard for an overload control mechanism.  They are not direct requirements on any implementation that may follow that standard.  This is a key distinction.  An implementation may do things that are not in a standard and can still be compliant with that standard depending on how the standard was crafted.

So, as I see it, these comments make sense when talking about implementations and I am in agreement with them.  However, the requirements are about standards definition.  I think for purposes of discussion of req 2, we need to think in terms of application implementation and application specification.  Use of the unqualified term 'application' is causing confusion, at least for me.

>  
> 2)      In Req1 it is stated that the overload mechanism objective is “to provide a communication method …to exchange the overload information”, so no more , no less from my understanding.  Then there are requirements on the Diameter node behaviors. I have  no issue with the many  REQs for managing and optimizing well this information exchange (eg REQ 9, 13, 14, 19…) by nodes . It is another topic on how the exchanged information is then used by nodes. I am also OK with the REQs starting with “the mechanism MUST allow nodes to … (REQ7) , “…MUST provide a way to (REQ 22)’ as we are still speaking of the exchanged information  which  allows nodes to… . I think we should also use this type of wording for a few requirements  eg for REQ 7  “the mechanism  must ensure  that the system remains stable” as it is not the exchanged information  which stabilize the system, but the nodes behavior on the basis of information exchanges.

that is a good point.  I agree with changing req 7 like this.  Assuming others do as well, I'll look though for other examples at the same time.

> Eric’s mail mentions a basic operation of an overload control mechanism, which should correspond to an overload algorithm. Has Dime the intent to specify some general overload algorithms?

Each of the current mechanism proposals in place have defined defaults for algorithm and I think we're all on the same page that a minimal set (one or two) should be supported as default.

>  
> 4)      I remind the question of priority  given to some users that 3GPP will have to handle. Generally, it is the client that should  manages such priorities and signals it to the server but the intermediate Diameter agents are not neutral there and should have the relevant information to behave correctly (eg to not drop a message for a priority user). On Req 26 ,we proposed  an additional wording ““ For example, it may be more beneficial to process messages for existing sessions ahead of new sessions and to give priority to requests associated with emergency sessions or with high priority users”. Do you think it is sufficient, or should we have a normative statement (not only an example)?

I think that should be sufficient.  If we start doing something normative here, we restrict the flexibility of applications to define their own behavior.  do you think there are things we can do here that will be in common for all possible applications?

[...]

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Dec 2012 14:57:50 -0600

Hi,

I've added some comments inline:
Thanks!

Ben.

On Dec 10, 2012, at 2:43 PM, Eric McMurry <[email-masked]> wrote:

[...]

> So, as I see it, these comments make sense when talking about implementations and I am in agreement with them.  However, the requirements are about standards definition.  I think for purposes of di…

I concur that this entire draft is about requirements on the _specification_ of an OC mechanism, not any particular _implementation_. But I think this particular requirement goes further, as it talks about how the mechanism might impact other _specifications_, namely specifications of standardized Diameter applications. So the point about making sure our language is clear about implementation vs specification is doubly true.

> that is a good point.  I agree with changing req 7 like this.  Assuming others do as well, I'll look though for other examples at the same time.

I'm not sure I agree on this point. As Eric mentions in the next section (below), we expect the overload mechanism to include a default overload algorithm, as well as a communications method. If we don't have requirements for that, we should. (Are we talking manditory-to-implement?)

So I think Req 7 means more than just saying that it MUST be possible for nodes to use the exchanged information to ensure stability. It means that the default algorithm MUST ensure stability.

> Each of the current mechanism proposals in place have defined defaults for algorithm and I think we're all on the same page that a minimal set (one or two) should be supported as default.

(see previous comment)

> I think that should be sufficient.  If we start doing something normative here, we restrict the flexibility of applications to define their own behavior.

I concur. The normative statement is that the _specification_ SHOULD offer guidance. The example is merely there to clarify the sort of guidance we have in mind. Nothing in this document should be interpreted to mean we have already figured out the _content_ of that guidance.

>  do you think there are things we can do here that will be in common for all possible applications?

I think that's highly unlikely. Even the guidance itself is most likely to be non-normative.

---

From: <[email-masked]>
Date: Tue, 11 Dec 2012 09:46:51 +0000

Hi Eric,

Just on this point:
"Use of the unqualified term 'application' is causing confusion, at least for me."

As I said, it is the use of 'specification' that causes confusion in REQ2.
I can understand that some new folks may encounter some difficulties in understanding the wording used in Diameter specifications e.g. RFC3588, RFC 6733, all the related RFCs specifying Diameter 'applications' or even the title of the draft Diameter Applications Design Guidelines<http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-16> ...
But I don't think that it is a reason to change the definition or even introduce more confusion.

Based on this discussion, I'm more and more convinced that the correct wording for the REQ2 should be something based on my proposal:

OLD:

NEW:

Regards,

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Eric McMurry
Envoyé : lundi 10 décembre 2012 21:43
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : [email-masked]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

Hi JJaques,

Thanks,

Eric

On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all

[...]

---

From: Eric McMurry <[email-masked]>
Date: Tue, 11 Dec 2012 07:59:32 -0600

Hi Lionel,

I'm not arguing against changing the language in req 2.  This discussion has made it quite clear that needs to happen.

The alternate proposals I have seen do not say the same thing though and are weaker requirements.  It is important for the resulting OC mechanism to work without requiring changes to the specification of an application.  Perhaps you have a better way of saying this.  For example, I would expect the OC mechanism to work between an MME and HHS without touching 29.272.  Can you propose alternate language that captures this?

Thanks!

Eric

On Dec 11, 2012, at 3:46 , [email-masked] wrote:

> Hi Eric,
>  
> Just on this point:
> “Use of the unqualified term 'application' is causing confusion, at least for me.”
>  
> As I said, it is the use of ‘specification’ that causes confusion in REQ2.
> I can understand that some new folks may encounter some difficulties in understanding the wording used in Diameter specifications e.g. RFC3588, RFC 6733, all the related RFCs specifying Diameter ‘applications’ or even the title of the draft Diameter Applications Design Guidelines …
> But I don’t think that it is a reason to change the definition or even introduce more confusion.
>  
> Based on this discussion, I’m more and more convinced that the correct wording for the REQ2 should be something based on my proposal:
>  
> OLD:
>

---

From: <[email-masked]>
Date: Tue, 11 Dec 2012 15:06:05 +0000

Hi Eric,

The way to document the support of the OC mechanisms in existing applications is up to the people managing the document defining the given application (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various ways. They can even decide to create a completely new application if it is preferred. For me, it is out of the scope of the definition of the mechanism itself and then not part of the requirement.

>From a Diameter point of view, the important point is that the foreseen solution has to be designed to be used along or over existing applications. And when used over existing applications, the required changes must not imply the creation of a new application (as clarified in the proposal). The solution designers can rely on the RFC 6733 and the draft Diameter Applications Design Guidelines<http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-16> to see if the solution meets this requirement.

Regards,

Lionel

De : Eric McMurry [mailto:[email-masked]]
Envoyé : mardi 11 décembre 2012 15:00
À : MORAND Lionel OLNC/OLN
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

Hi Lionel,

Thanks!

Eric

On Dec 11, 2012, at 3:46 , [email-masked]<mailto:[email-masked]> wrote:

Hi Eric,

Just on this point:

OLD:

NEW:

Regards,

Lionel

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Eric McMurry

Hi JJaques,

Thanks,

Eric

Hi all

[...]

Thank you.

---

From: Eric McMurry <[email-masked]>
Date: Tue, 11 Dec 2012 09:39:41 -0600

Hi Lionel,

Please see inline. 

Thanks,

Eric

> The way to document the support of the OC mechanisms in existing applications is up to the people managing the document defining the given application (IETF, 3GPP, other SDOs, vendors, etc.) and th…

of course.  I am not proposing any restrictions on how application specifications are updated.

> From a Diameter point of view, the important point is that the foreseen solution has to be designed to be used along or over existing applications. And when used over existing applications, the required changes must not imply the creation of a new application (as clarified in the proposal). The solution designers can rely on the RFC 6733 and the draft Diameter Applications Design Guidelines to see if the solution meets this requirement.

I am not making my point clear.  I see the important point being that the specification of  existing applications do not have to be updated at all.  This includes your point, but is a stricter requirement.  It would be possible to design an OC mechanism that met your requirement that still required changes to the specification of existing applications.

---

From: <[email-masked]>
Date: Tue, 11 Dec 2012 16:17:47 +0000

Hi Eric,

It is where I'm lost in your argumentation. If the specification of the application is not updated at all, how do you want to reflect that the OC mechanism is now supported over this application?

Again, I think that the requirement is that any agent supporting the existing application should not have to be forced to be upgraded when introducing the new OC mechanism. Only the client, server and/or dedicated proxies have to be upgraded to support the new functionality.

And how to document that is out of scope. It could be a reference to a companion document, addition of extra informative text, etc. But we should not mix both aspects here. Only the requirements at the protocol level are relevant in this draft.

Lionel

Envoyé : mardi 11 décembre 2012 16:40

Hi Lionel,

Please see inline.

Thanks,

Eric

On Dec 11, 2012, at 9:06 , [email-masked]<mailto:[email-masked]> wrote:

Hi Eric,

---

From: Eric McMurry <[email-masked]>
Date: Tue, 11 Dec 2012 11:11:02 -0600

Hi Lionel,

I think the OC mechanism can not claim support over any particular application.  It needs to be application independent and should work with any application.  I'm not seeing that reflecting that the OC mechanism is supported over an application is necessary.

To your second point, I think this is orthogonal to req 2.  There are requirements around the OC mechanism supporting a mixed environment of supporting and non-supporting elements.  I don't think this is exactly what you are saying, but is related.  Do you think there is a need for a new requirement here?

I agree that how to change any application specs is out of scope.  That is what I was trying to say with my first comment.

Thanks,

Eric

On Dec 11, 2012, at 10:17 , [email-masked] wrote:

> Hi Eric,
>  
> It is where I’m lost in your argumentation. If the specification of the application is not updated at all, how do you want to reflect that the OC mechanism is now supported over this application?
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Dec 2012 16:22:52 -0600

Hi Lionel, see comments inline:

> It is where I’m lost in your argumentation. If the specification of the application is not updated at all, how do you want to reflect that the OC mechanism is now supported over this application?

You don't, at least not at the specification level. (An implementation might allow one to select whether OC is in effect for any given application, but that's an orthogonal issue).

We've intended "application independence" to be a goal for the OC mechanism from the beginning. Maybe it's worth exploring what that means.

The idea is that you don't have to decide (or document) whether OC is supported for a particular application. You can use it across all applications that a particular node supports. Now, that doesn't mean you can't add application specific algorithm optimizations, or describe specific application-level behaviors (e.g. request prioritization ) for overload conditions. But the idea is that you don't _have_ to do that in general.

The discussion about documentation so far is really more of a process question than a technical question. We want to make it possible to deploy OC for a given application without having to revise the specs (IETF RFCs, 3GPP TSs, etc) for that application. We do that by defining default behavior that we expect to be at least useful in most cases. That is, we don't leave sections that "MUST be described in the Diameter application specification" 

I believe this is possible using either the piggy-back model or the dedicated application model. In the piggy-back case, we document OC AVPs that can be used with _any_ application that includes the *[AVP] construct. Any implementation that doesn't understand the OC mechanism would simply fail to negotiate use of the mechanism, and ignore any OC negotiation AVPs that occur in the CER. This does not require any change to the original application specification, since the *[AVP] construct means compliant implementations can handle (or at least ignore) arbitrary AVPs without damage.

In the dedicated application case, if you successfully negotiate support for the OC application in the CER/CEA exchange, you can start sharing OC info. Implementations can apply that info to messages in any application, without requiring changes to the definition of that application.

We recognize that people may want to revise application definition specs to describe application-specific OC behaviors. But they shouldn't have to do so to use the default behaviors..

> Again, I think that the requirement is that any agent supporting the existing application should not have to be forced to be upgraded when introducing  the new OC mechanism. Only the client, server…

That's a different requirement than the one intended by Req 2.  (Nothing in Req 2 should be interpreted to say you don't need to update _software_).  I think it will be a hard one to achieve, except possibly in the case of pure relay agents (which I'm still not convinced exist in the wild.). Proxy agents will certainly need to implement OC support for OC to be useful. Hopefully section 2 illustrates why that is the case--if not, it may need some clarification.

> And how to document that is out of scope. It could be a reference to a companion document, addition of extra informative text, etc. But we should not mix both aspects here. Only the requirements at…

I agree that this draft doesn't need to say how application-specific OC support gets documented for any specific application. (The mechanism draft(s) _might_ need to do so for some circumstances, but I don't think we are far enough along on those to know one way or another.) 

 I disagree that protocol requirements are all that's relevant in the this draft, as I think Req 2 is implied by the very idea of application-independence. (OTOH, maybe we could restate it in terms of application independence rather than documentation--but the implication would remain.)

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Thu, 13 Dec 2012 17:26:26 +0100

Hello all
While we understand that JJ comments on REQ2 still raises discussion, can it be concluded that there is some sort of agreement on the other comments expressed by JJ?

Best regards
Laurent
ALCATEL-LUCENT

_____________________________________________
De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : jeudi 6 décembre 2012 14:17
À : [email-masked]
Cc : THIEBAUT, LAURENT (LAURENT)
Objet : Dime: Diameter Overload IETF requirements, review

Dear all

.
Best regards

JJacques Trottin

---

From: Ben Campbell <[email-masked]>
Date: Mon, 17 Dec 2012 16:06:58 -0600

> While we understand that JJ comments on REQ2 still raises discussion, can it be concluded that there is some sort of agreement on the other comments expressed by JJ?

Yes, we've incorporated the comments on all but REQ2 into our working copy, and marked Req2 as being the subject of ongoing discussion.

Thanks!

Ben.

> 	• About REQ 2 (“The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications”), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 “allowing for the possibility of increased feedback for information piggybacked” as the piggybacking mechanism may impact the application. May be a solution is to suppress this second part of the REQ2 (“ It MUST NOT require specification changes for existing Diameter applications”) or review the wording.
>  
> 	• On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of the “which message types might be desirable to send or process over others during times of overload” should be left for each application to define (for “ …  Diameter specific considerations). If this reading of REQ 26 is shared, a possible rewording could be:

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 31 Dec 2012 13:42:55 -0500

They look OK to me, except for the word "anyhow" which can be removed 
without changing the sense.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   "THIEBAUT, LAURENT (LAURENT)" 
<[email-masked]>
To:     "[email-masked]" <[email-masked]>
Date:   12/13/2012 11:31 AM
Subject:        Re: [Dime] Dime:  Diameter Overload IETF requirements, 
review: comments on Req 1, 26, 35
Sent by:        [email-masked]

 
Hello all 
While we understand that JJ comments on REQ2 still raises discussion, can 
it be concluded that there is some sort of agreement on the other comments 
expressed by JJ?
 
Best regards
Laurent
ALCATEL-LUCENT

Dear all

In the objective of relying on IETF specifications to handle Diameter 
overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of 
the draft-ietf-dime-overload-reqs-01.
 
We consider the list of REQs described in the IETF draft as quite 
extensive and all REQs relevant. We have the few additional comments to 
submit to the upcoming Dime review: 
 
We suggest to put more emphasis in REQ1 on the fact this is both for load 
(preventive) and overload (reactive). A possible writing:
REQ 1:   The overload mechanism MUST provide a communication method for 
Diameter nodes to exchange load and overload information.
 
About REQ 2 (“The overload mechanism MUST be useable with any existing or 
future Diameter application.  It MUST NOT require specification changes 
for existing Diameter applications”), an existing application may evolve 
to support an overload mechanism, especially when the overload handling 
may rely on certain application dependent behaviors (which would be within 
3GPP scope for applications defined by 3GPP). It also may have a 
consistency issue with REQ13 “allowing for the possibility of increased 
feedback for information piggybacked” as the piggybacking mechanism may 
impact the application. May be a solution is to suppress this second part 
of the REQ2 (“ It MUST NOT require specification changes for existing 
Diameter applications”) or review the wording. 
 
On REQ 26, we have the following reading we consider important: the 
specifications of the diameter load/overload control can only give an 
overall guidance. Actual and precise specification of the “which message 
types might be desirable to send or process over others during times of 
overload” should be left for each application to define (for “ …  Diameter 
specific considerations). If this reading of REQ 26 is shared, a possible 
rewording could be: 
REQ 26:  The generic specification for the overload mechanism SHOULD offer 
overall guidance on which message types might be desirable to send or 
process over others during times of overload, based on Diameter-specific 
considerations.  For example, it may be more beneficial to process 
messages for existing sessions ahead of new sessions. A precise 
specification of the relative priorities of message types in case of 
overload would anyhow be under the responsibility of each application.
 
We expressed the point that overload handling should take into account 
that some messages may have a high priority (eg when related to an 
emergency or a high priority user”).  This handling would  be application 
dependent and so entering the REQ 26 as an overall guidance but it could 
be mentioned in REQ 26 as an example with the possible wording
“ For example, it may be more beneficial to process messages for existing 
sessions ahead of new sessions and to give priority to requests associated 
with emergency sessions or with high priority users”
 
Last sentence of REQ 35 appears unclear, wording may be reviewed or this 
sentence may be suppressed.
 
. 
Best regards
 
JJacques Trottin