Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Thu, 7 Feb 2013 14:10:05 +0000

Hello all

Thanks Eric and Ben. I owe you some further answers and comments (LTH2) and apologize for being a  bit late.

Please consider them inline starting with LTH2 and consider they are NOT aiming at pushing any solution.

Best Regards

Laurent

ALCATEL-LUCENT

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]]
Envoyé : jeudi 31 janvier 2013 00:48
À : Eric McMurry; THIEBAUT, LAURENT (LAURENT)
Cc : [email-masked]
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi, please see comments inline.

(Apologies for the late response--I'm catching up on email after vacation.)

On Jan 24, 2013, at 1:04 PM, Eric McMurry <[email-masked]> wrote:

> Thanks Laurent.

> comments inline.

> Eric

> On Jan 24, 2013, at 9:27 , "THIEBAUT, LAURENT (LAURENT)" <[email-masked]> wrote:

>> Hello all

>> Please find below our remarks on draft draft-ietf-dime-overload-reqs-03 about Diameter Overload Control Requirements

>> These remarks address topics we have already addressed over Dime but for which we think some enhancements to the text is needed.

>> We hope to converge quickly as we believe that based on these small enhancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved forward into the IETF standardization process.

>> 1.    REQ 2:   The mechanism MUST allow Diameter nodes to support overload

>>             control regardless of which Diameter applications they

>>             support. The mechanism MUST allow Diameter applications

>> to be aware of an overload situation.

>> We believe that a proper handling of a Diameter server overload is to report it at the level of its Diameter client applications in order for them to take proper decisions. This may mean to send signalling towards non Diameter entities.

>> This may relate with the comment made by Hannes.

> As in the current draft, do you think this requirement can be interpreted to say that a diameter stack should handle overload without application intervention and that implementations of overload control mechanisms are required to act in that fashion?

> I'm struggling a bit with this since I'm reading it as a requirement on implementations of the overload control mechanism (as opposed to requirements on the specification of the mechanism).  Is it reasonable to require a stack to not handle overload control by itself?

My personal opinion is that the draft should not talk about software architecture--just protocol behavior.

OTOH, I'm not sure if Laurent meant to refer to the separation between the Diameter application and stack on a Diameter node, or the client application that Diameter is supporting.  If the second, I agree putting a few words to that effect could be useful.  (For example, if the Diameter client at a NAS cannot successfully perform an authorization, it might have to cleanly reject a network attachment attempt. The details of that rejection would be out of scope for the overload control mechanism, but the client would still need to Do the Right Thing)

[LTH2] This means that the mechanisms to carry Diameter overload shall be able to carry this information up to the Diameter application within the Diameter peer node (Diameter client/server)

>> 2.       We recommend to add following requirement:

>> REQ xx:  The overload control mechanism MUST allow networks to properly support Diameter signalling related with emergency and/or priority users.

>> This aspect is mentioned in Req 26 but only as a general guidance while this is a strong operational requirement.

>> "For example, it may be more beneficial to process messages for

>>             existing sessions ahead of new sessions, or to give priority

>>             to requests associated with emergency sessions or with high

>>             priority users."

> What does this mean for a mechanism?  How would it be done?

This seems to me to be more like a more application specific requirement than a generic Diameter requirement. If so, I think that would be better specified in whatever document might exist to specify how a particular application might incorporate the overload control mechanism. (For example, in a 3GPP document.)

[LTH2] Even though this is not listed as a requirement with a number "Req xx", it is important that the definition of the protocol that carries Diameter overload information keeps this important guideline in mind.

Req 26 states "For example, it **may** be more beneficial to process messages for existing sessions ahead of new sessions, or to give priority to requests associated with emergency sessions or with high priority users.  ". While "may" is OK for the priority for existing sessions, it is too weak for the "emergency sessions or high priority users".

Would following wording within REq26 be acceptable:

For example, it may be more beneficial to process messages for existing sessions ahead of new sessions, and it is required to give priority to requests associated with emergency sessions or with high priority users.

>> 3.    REQ 35:  The mechanism SHOULD provide a method for exchanging

>>             overload and load information between elements that are

>>             connected by intermediaries that do not support the

>>             mechanism.

>> We recommend to replace "The mechanism SHOULD provide a method" by "The mechanism MUSTprovide a method"  as it is a key requirement for deployments especially via intermediate networks.

> Personally, I'm on the fence here.  The main issue I have is that any end to end, or end to information source method that passes through intermediaries that don't support the mechanism brings with it an absolute requirement for end to end security.  Given the state of end to end security, this will cause substantial delay to deployment of overload control.  There is a middle ground where a mechanism that could support end to end is required to only be used hop by hop without end to end security in place.  That may be compatible with the suggested change to the requirement but it will have to be considered.

> There is also the consideration that a mechanism that requires hop-by-hop action for overload control could be a reasonable or necessary approach, given the potential complexity of the networks involved and the implications of that on what the overload information contains.

> At any rate, if the change is made, we must also add the additional security requirement ensuring that the mechanism is not used without end to end security (this is implied by REQ 28, but it needs to be made explicit).

I think I concur with Eric here--there's a potential for some surprises here.  I think we need more analysis of the security and architectural implications of true hop-by-hop vs allowing non-adjacent nodes to communicate overload information. I wonder if we can delegate that to the actual mechanism work, or a separate document than this one?

[LTH2]I'd insist on this as otherwise it prevents Diameter overload information to be passed via intermediate networks (e.g. IPX) that do not yet support the Diameter overload information related protocol. Is a Diameter Agent required to understand all Diameter AVP? Especially when they would not be tagged as NOT Mandatory?

>> 4.       We recommend to add following requirement

>> REQ yy:  The mechanism MUST support a default overload algorithm. This will facilitate interoperability especially between Networks.

> I think this would make explicit what is implicit now.  I don't see any issue with adding it.  Others should certainly feel free to contradict me on that.

I concur. (that we should add the explicit statement, not that people should contradict you :-)  )

[...]

---

From: Eric McMurry <[email-masked]>
Date: Thu, 7 Feb 2013 09:00:15 -0600

Hi Laurent,

Thanks for the responses.  Please see comments inline.

Eric

> [LTH2] This means that the mechanisms to carry Diameter overload shall be able to carry this information up to the Diameter application within the Diameter peer node (Diameter client/server)  

[em]   I think I still don't understand the requirement here.  It sounds like an implementation detail to me.  If we were to require that an overload control mechanism provide some information to an application above it (note that application can mean multiple things here), then the overload control mechanism would have to provide some sort of application level API to comply, right?  I think implementations are likely to do this anyways, but it doesn't need to be done in an interoperable fashion (that would require specification).  I may still be missing your point though.

> >> “For example, it may be more beneficial to process messages for
> >>             priority users.”
> [LTH2] Even though this is not listed as a requirement with a number “Req xx”, it is important that the definition of the protocol that carries Diameter overload information keeps this important guideline in mind.
> Req 26 states “For example, it **may** be more beneficial to process messages for existing sessions ahead of new sessions, or to give priority to requests associated with emergency sessions or with high priority users.  ”. While “may” is OK for the priority for existing sessions, it is too weak for the “emergency sessions or high priority users”.  

[em] I think taking out the emergency services example may be a good solution here.  The definition of what to do with emergency message is probably best left to specifications that deal with that directly.

> >> We recommend to replace “The mechanism SHOULD provide a method” by “The mechanism MUSTprovide a method”  as it is a key requirement for deployments especially via intermediate networks.
> >
> [LTH2]I’d insist on this as otherwise it prevents Diameter overload information to be passed via intermediate networks (e.g. IPX) that do not yet support the Diameter overload information related protocol. Is a Diameter Agent required to understand all Diameter AVP? Especially when they would not be tagged as NOT Mandatory?

[em]  I don't understand the last part of your statement.  Are you referring to a piggybacked approach to conveying the overload information?  (I understand you are not advocating any particular solution.  I'm just trying to understand your questions)

As to the general point though, as I said earlier, I'm fine with making this a must as long as e2e security is also a must.  I don't think there is agreement on making e2e security a must though, and I would certainly rather not do that.  Perhaps we can tie that requirement directly to this one.  For example:

REQ 35:  The mechanism MUST provide a method for exchanging
             overload and load information between elements that are
             connected by intermediaries that do not support the
             mechanism.  Any exchange of overload and load information between
	     non-adjacent nodes MUST be encrypted for the full path between the
	     non-adjacent nodes and have the source of the information verified.

My preference though is still to leave this as is, so further analysis can be done as part of the mechanism work.

[...]

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Thu, 7 Feb 2013 19:11:26 +0000

Hello Eric

Thanks for your feedback

Trying to reformulate

1) About Req 2: I meant that the mechanisms to carry Diameter overload must be able to carry this information up to the Diameter peer nodes (Diameter client/server)

2) Based on your feedback, I understand that indeed having a dedicated requirement for emergency is too much. This is why I suggested the rewording of an informative  sentence in Req26 as follows:
For example, it may be more beneficial to process messages for existing sessions ahead of new sessions, and it is required to give priority to requests associated with emergency sessions or with high priority users.

3) As long as it is agreed/understood by the Dime group that "the possibility of passing overload information via intermediate agents that do not support the extension" is required, I am fine.

Best Regards

Laurent
ALCATEL-LUCENT

________________________________
De : Eric McMurry [mailto:[email-masked]]
Envoyé : jeudi 7 février 2013 16:00
À : THIEBAUT, LAURENT (LAURENT)
Cc : Ben Campbell; [email-masked]
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Laurent,

Eric

On Feb 7, 2013, at 8:10 , "THIEBAUT, LAURENT (LAURENT)" <[email-masked]<mailto:[email-masked]>> wrote:

Hello all

Best Regards
Laurent
ALCATEL-LUCENT

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]<http://nostrum.com/>]
Envoyé : jeudi 31 janvier 2013 00:48
À : Eric McMurry; THIEBAUT, LAURENT (LAURENT)
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

On Jan 24, 2013, at 1:04 PM, Eric McMurry <[email-masked]<mailto:[email-masked]>> wrote:

> Thanks Laurent.
>
> comments inline.
>
>
> Eric
>
>
> On Jan 24, 2013, at 9:27 , "THIEBAUT, LAURENT (LAURENT)" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>
>>
>> Hello all

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 8 Feb 2013 14:00:55 +0000

Hi Eric

About the REQ2 with the addition of : The mechanism MUST allow Diameter applications to be aware of an overload situation.
I think it is a central point of discussion. Regarding the usage of Diameter in 3GPP environment which is my concern, as Laurent,  I consider that the client  at the source of Diameter requests  (so not an intermediate DA) has to be involved in an overload situation, not only to reduce the traffic as such but on the way it will do it. Quite often in a 3GGP case, the involved Diameter  client will have to trigger some behavior towards the mobile terminals . Whatever the way overload handling  is implemented in the client and the role of the Diameter stack , the triggering of UE behavior will be at the application level, which then has to be aware of the overload situation (so the above additional statement in REQ2).
A second point behind this statement, is that, if requested, the overload information must be propagated up to the Diameter client for an accurate handling  and not to be stopped by an intermediate agent who considers it handles the overload by itself  and does not need to propagate the overload information  upstream.

I don't say that it is systematic and in 3GPP it will depend of the application case, it is why we write "must allow".

Best regards

JJacques

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of THIEBAUT, LAURENT (LAURENT)
Sent: jeudi 7 février 2013 20:11
To: Eric McMurry
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hello Eric

Thanks for your feedback

Trying to reformulate

Best Regards

Laurent
ALCATEL-LUCENT

Cc : Ben Campbell; [email-masked]<mailto:[email-masked]>

Hi Laurent,

Eric

Hello all

Best Regards
Laurent
ALCATEL-LUCENT

---

From: Ben Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 16:53:45 -0600

> For example, it may be more beneficial to process messages for existing sessions ahead of new sessions, and it is required to give priority to requests associated with emergency sessions or with hi…

Hi,

I think one possible issue here is the assumption that emergency sessions priority is always true is incorrect. There may well be uses of diameter that do not have such requirements. Most uses in a _telecom_ environment will. How about something like the following: 

"... For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. ..."

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 11 Feb 2013 07:43:00 +0000

Hi Eric

About the REQ2 with the addition of : The mechanism MUST allow Diameter applications to be aware of an overload situation.
I think it is a central point of discussion. Regarding the usage of Diameter in 3GPP environment which is my concern, as Laurent,  I consider that the client  at the source of Diameter requests  (so not an intermediate DA) has to be involved in an overload situation, not only to reduce the traffic as such but on the way it will do it. Quite often in a 3GGP case, the involved Diameter  client will have to trigger some behavior towards the mobile terminals . Whatever the way overload handling  is implemented in the client and the role of the Diameter stack , the triggering of UE behavior will be at the application level, which then has to be aware of the overload situation (so the above additional statement in REQ2).
A second point behind this statement, is that, if requested, the overload information must be propagated up to the Diameter client for an accurate handling  and not to be stopped by an intermediate agent who considers it handles the overload by itself  and would not propagate the overload information  upstream.

Best regards

JJacques

Hello Eric

Thanks for your feedback

Trying to reformulate

Best Regards

Laurent
ALCATEL-LUCENT

---

From: "Stura, Marco, Vodafone Italy" <[email-masked]>
Date: Mon, 11 Feb 2013 10:04:16 +0000

Hi,

While I agree that the Diameter application should be aware of the overload situation and the Diameter client should be involved to reduce the traffic, I'm not sure we can rely on UE/terminal behaviour. As I have seen in many deployments not all devices behave and react properly to e.g. Retry-After header (actually none ...), hence I would not design an overload mechanism for a Diameter interface that rely on inferring some specific behaviour to a device.....

BR,
Marco

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, February 11, 2013 8:43 AM
To: [email-masked]
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
Importance: Low

Hi Eric

Best regards

JJacques

Hello Eric

Thanks for your feedback

Trying to reformulate

Best Regards

Laurent
ALCATEL-LUCENT

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Mon, 11 Feb 2013 13:22:14 +0000

Hello Marco

The idea is not so much to 100% rely on the behaviour of the UE, but to make sure that The Diameter Overload mechanism [defined in DIME] MUST allow that the Diameter application is aware of the overload situation in order for this Diameter client to be involved in the mechanisms used to reduce the traffic to the congested node, mechanisms which *may* include sending relevant signaling to the UE.

Best Regards

Laurent
ALCATEL-LUCENT

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Stura, Marco, Vodafone Italy
Envoyé : lundi 11 février 2013 11:04
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi,

BR,
Marco

Hi Eric

Best regards

JJacques

Hello Eric

Thanks for your feedback

Trying to reformulate

Best Regards

Laurent
ALCATEL-LUCENT

---

From: Eric McMurry <[email-masked]>
Date: Sat, 16 Feb 2013 13:31:24 -0600

I still favor removing the emergency services example entirely to avoid confusion, but this language is okay with me if folks are happy with it.

Thanks,

Eric

---

From: Eric McMurry <[email-masked]>
Date: Sat, 16 Feb 2013 13:46:42 -0600

Hi JJacques,

I'm not sure this is the same thing that Laurent was saying.  My impression of his comments (which may be incorrect) was what he was talking about within a single node.  His requirement was that the mechanism provide information up to whatever the real application of that node is and allow it to exert control over the overload control signaling.  For example (apologies to those not familiar with 3GPP terminology), an MME communicating with and HSS, where both support overload control, would need to coordinate overload related actions for that Diameter interface along with it's non-Diameter interfaces (such as towards eNodeBs or serving gateways).  To do that, the higher level application functions of an MME need to have access to Diameter overload information and the ability to influence Diameter overload control for that interface to the HSS.  Is this the gist of what you were getting at, Laurent?

I think what you are saying here is more that intermediate elements should not have the ability to alter overload control signaling for information that is scoped to elements on either side of them.  Is that right?

thanks,

Eric

On Feb 11, 2013, at 1:43 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> wrote:

> I don’t say that it is systematic and in 3GPP it will depend of the application case, it is why we write “must allow”.
>  
>  
> Best regards
>  
> JJacques
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of THIEBAUT, LAURENT (LAURENT)
> Cc: [email-masked]
> 3) As long as it is agreed/understood by the Dime group that “the possibility of passing overload information via intermediate agents that do not support the extension” is required, I am fine.
>  
> Best Regards
> Laurent 
> ALCATEL-LUCENT
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 20 Feb 2013 15:12:02 -0500

Being actively involved with one type of "emergency" messages, I prefer 
that protocol documents NOT specify how "emergency" requests should be 
treated.

I much prefer wording that simply says that the overload protocol will not 
prevent the node from applying "local policy" with regard to selecting 
which messages to reject,  as long as the desired reduction in traffic is 
achieved.

Here is the current SIP wording

"During an overload condition, a SIP client needs to prioritize
   requests and select those requests that need to be rejected or
   redirected.  This selection is largely a matter of local policy.  It
   is expected that a SIP client will follow local policy as long as the
   result in reduction of traffic is consistent with the overload
   algorithm in effect at that node.  Accordingly, the normative
   behaviour in the next three paragraphs should be interpreted with the
   understanding that the SIP client will aim to preserve local policy
   to the fullest extent possible.

   A SIP client SHOULD honor the local policy for prioritizing SIP
   requests such as policies based on message type, e.g., INVITEs versus
   requests associated with existing sessions.

   A SIP client SHOULD honor the local policy for prioritizing SIP
   requests based on the content of the Resource-Priority header (RPH,
   RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
   indicate high priority requests that should be preserved as much as
   possible during overload.  The RPH contents can also indicate a low-
   priority request that is eligible to be dropped during times of
   overload.

   A SIP client SHOULD honor the local policy for prioritizing SIP
   requests relating to emergency calls as identified by the SOS URN
   [RFC5031] indicating an emergency request.

   A local policy can be expected to combine both the SIP request type
   and the prioritization markings, and SHOULD be honored when overload
   conditions prevail."

Obviously the DIME wording can not be  as specific, as there are not 
specific "emergency related" markings.

Maybe something like
"During an overload condition, a DIAMETER node  needs to prioritize
   requests and select those requests that need to be rejected or
   redirected.  This selection is largely a matter of local policy.  It
   is expected that a DIAMETER node will follow local policy as long as 
the
   result in reduction of traffic is consistent with the overload
   algorithm in effect at that node.  Accordingly, the normative
   behaviour in the next two paragraphs should be interpreted with the
   understanding that the SIP client will aim to preserve local policy
   to the fullest extent possible.

   A DIAMETER node SHOULD honor the local policy for prioritizing DIAMETER
   requests such as policies based on type, e.g., messages  associated
   with existing sessions vs messages associated with new sessions

   A DIAMETER node  SHOULD honor the local policy for prioritizing 
DIAMETER 
  requests associated with Emergency sessions vs. messages associated with
  non-Emergency sessions.

  A local policy can be expected to combine both the message  type
   and the Emergency  identification, and SHOULD be honored when overload
   conditions prevail."

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.

[email-masked] wrote on 02/16/2013 02:31:24 PM:

> From: Eric McMurry <[email-masked]>
> To: Ben Campbell <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: 02/16/2013 02:31 PM
> Sent by: [email-masked]
> 
> I still favor removing the emergency services example entirely to 
> avoid confusion, but this language is okay with me if folks are happy 
with it.
> > On Feb 7, 2013, at 1:11 PM, "THIEBAUT, LAURENT (LAURENT)" 
> <[email-masked]> wrote:
> > 
> >> 2) Based on your feedback, I understand that indeed having a 
> dedicated requirement for emergency is too much. This is why I 
> suggested the rewording of an informative  sentence in Req26 as follows:
> >> For example, it may be more beneficial to process messages for 
> existing sessions ahead of new sessions, and it is required to give 
> priority to requests associated with emergency sessions or with high
> priority users. 
> >> 
> >> 
> > 
> > Hi,
> > 
> > I think one possible issue here is the assumption that emergency 
> sessions priority is always true is incorrect. There may well be 
> uses of diameter that do not have such requirements. Most uses in a 
> _telecom_ environment will. How about something like the following: 
> > 
> > "... For example, it may be more beneficial to process messages 
> for existing sessions ahead of new sessions. Some networks may have 
> a requirement to give priority to requests associated with emergency
> sessions. ..."
> > 
> > 
>