Subject: [Dime] Diameter Overload Control Requirements

From: Eric McMurry <[email-masked]>
Date: Thu, 17 May 2012 12:43:14 -0500

A new draft has been submitted intended to address requirements for overload control in Diameter.  

http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt

Diameter deployments are growing in size and this is becoming more of an issue.  We have seen significant interest in providing a mechanism to address it.  Hopefully this document is useful as a base for discussion on what is needed and we welcome comments.

Abstract:
       When a Diameter server or agent becomes overloaded, it needs to be able
       to gracefully reduce its load, typically by informing clients to reduce
       sending traffic for some period of time. Otherwise, it must continue to
       expend resources parsing and responding to Diameter messages, possibly
       resulting in congestion collapse. The existing mechanisms provided by
       Diameter are not sufficient for this purpose. This document describes
       the limitations of the existing mechanisms, and provides requirements
       for new overload management mechanisms.

The dime charter has an item,

- Maintaining and/or progressing, along the standards track, the 
Diameter Base protocol and Diameter Applications. This includes 
extensions to Diameter Base protocol that can be considered as enhanced 
features or bug fixes.

that this seems suited to go under and we welcome comment on that as well.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 30 May 2012 02:01:27 +0000

There was an attempt around 2007 to start this work but at that time there wasn't much interest. I don't recall any strong technical objections but Diameter traffic volumes were not as high as now so there wasn't an immediate need. I hope this time it goes through.

A few comments after a quick read:

i- 4.2.  Problems with Explicit Mechanisms

   The Diameter specification is ambiguous on how a client should handle
   receipt of a DIAMETER_TOO_BUSY response.  The base specification
   [I-D.ietf-dime-rfc3588bis] indicates that the sending client should
   attempt to send the request to a different peer.  It makes no
   suggestion that a the receipt of a DIAMETER_TOO_BUSY response should
   affect future Diameter messages in any way.

I think this is reading the RFC3588 in a too literal way. One could argue that similarly there is nothing preventing an implementation to use DIAMETER_TOO_BUSY as input to an adaptive overload control mechanism. OTOH, I would agree that it would be better if this is explicitly mentioned in 3588-bis.

ii- 3.  Existing Mechanisms

   Diameter requires the use of a congestion-managed transport layer,

   currently TCP or SCTP, to mitigate network congestion.  But even with

   a congestion-managed transport, a Diameter node can become overloaded

   at the protocol layer due to the causes described in Section 1.1.

It could be good to mention issues with TCP/SCTP congestion propagation and about using receiver window sizes.

iii- 4.2

        A DIAMETER_TOO_BUSY error can only indicate overload at a "whole server" scope.

I thought that it would indicate overload for the application as indicated in Application-Id. Is there any text in RFC3588 supporting either view?

iv- REQ 15:  The mechanism MUST NOT interfere with the congestion control mechanisms of underlying transport protocols.

Does this mean that there shouldn't be any reliance on indications from underlying transport protocol?

v- REQ 26:  The specification for the overload mechanism SHOULD offer

            guidance on which message types might be desirable to

            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.

I think the guidance should be for which messages should be sent rather than which ones should be processed.

vi- 2.2

   On the other hand, there are cases where the client needs to be able

   to select a particular server from behind an agent.  For example, if

   a Diameter request is part of a multiple-round-trip authentication,

   or is otherwise part of a Diameter "session", it may have a

   DestinationHost AVP that requires the request to be served by server

   1.  Therefore the agent may need to inform a client that a particular

   upstream server is overloaded or otherwise unavailable.

Is this always a feasible approach considering that client may not always know the redundant pair for an overloaded server? Probably a mechanism is needed which allows the server to communicate the identity of a redundant pair. That was also work proposed back in 2007 and which did not move forward due to lack of interest. Maybe it is time to pick it up again. Actually it could be preferable if Redundant Server info can be used directly by Relay Agent (did not analyze in depth whether there are any issues with this approach though)

Thanks,

Tolga

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric McMurry
Sent: Thursday, May 17, 2012 1:43 PM
To: [email-masked]
Subject: [Dime] Diameter Overload Control Requirements

Abstract:

---

From: <[email-masked]>
Date: Wed, 30 May 2012 08:50:31 +0000

(as individual)

Hi Eric, Ben,

I think that it is clear that it is required to further detail how to provide overload control in Diameter based networks, especially in large networks such as mobile networks.

However, in order to see exactly what to do, I think that we should first agree on what are missing pieces in the current specifications. So the section 4 should be further detailed to differentiate what should be clarified (if required) from what should be defined.

After a quick review, here is a set of comments as input for further discussion. The idea is that the set of requirements should be derived from a clear problem statement.

*********************
4.1.  Problems with Implicit Mechanism

   The implicit mechanism doesn't allow an agent or server to inform the
   client of a problem until it is effectively too late to do anything
   about it.  The client does not know to take action until the upstream
   node has effectively failed.  A Diameter node has no opportunity to
   shed load early to avoid collapse in the first place.

   Additionally, the implicit mechanism cannot distinguish between
   overload of a Diameter node and network congestion.  Diameter treats
   the failure to receive an answer as a transport failure.

[Lionel] IMHO, the first priority would be to clarify the relationship between Overload and Network congestion. Another one would be to clarify/verify some assumptions taken as baselines all along the document such as "inform the client of a problem until it is effectively too late to do anything about it". As explained below.

4.2.  Problems with Explicit Mechanisms

[Lionel] in RFC3588-bis, the SHOULD is meant as a strong recommendation for application designers. So for me, the expected behavior of the receiver of this result code is quite clear IMHO. If something needs to be further clarified, it may be the conditions for sending the DIAMETER_TOO_BUSY response. It is assumed that the server will wait for being overloaded but there is nothing preventing the server to apply a specific policy/algorithm allowing the server to modulate the traffic load. 

   There's a strong likelihood that at least some implementations will
   continue to send Diameter requests to an upstream peer even after
   receiving a DIAMETER_TOO_BUSY error.

[Lionel] this would mean that these implementations would not follow the recommendations put in the RFC.

   BCP 41 [RFC2914] describes, among other things, how end-to-end
   application behavior can help avoid congestion collapse.  In
   particular, an application should avoid sending messages that will
   never be delivered or processed.  The DIAMETER_TOO_BUSY behavior as
   described in the Diameter base specification fails at this, since if
   an upstream node becomes overloaded, a client attempts each request,
   and does not discover the need to failover the request until the
   initial attempt fails.

[Lionel] As described above, it depends on the time the first DIAMETER_TOO_BUSY response. But it is clear that this point needs to be further investigated. 

   The situation is improved if implementations follow the [RFC3539]
   recommendation and keep state about upstream peer overload.  But even
   then, the Diameter specification offers no guidance on how long a
   client should wait before retrying the overloaded destination.  If an
   agent or server supports multiple realms and/or applications,
   DIAMETER_TOO_BUSY only offers no way to indicate that it is
   overloaded for one application but not another.  A DIAMETER_TOO_BUSY
   error can only indicate overload at a "whole server" scope.

[Lionel] the DIAMETER_TOO_BUSY response is per application as it is in response to given command request using a specific application-id. But this point is maybe not so clear in the RFC3588bis.

   Agent processing of a DIAMETER_TOO_BUSY response is also problematic
   as described in the base specification.  DIAMETER_TOO_BUSY is defined
   as a protocol error.  If an agent receives a protocol error, it may
   either handle it locally or it may forward the response back towards
   the downstream peer.  (The Diameter specification is inconsistent
   about whether a protocol error MAY or SHOULD be handled by an agent,
   rather than forwarded downstream.)  If a downstream peer receives the
   DIAMETER_TOO_BUSY response, it may stop sending all requests to the
   agent for some period of time, even though the agent may still be
   able to deliver requests to other upstream peers.

[Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded server. So if the Proxy/Relay forwards the response to a downstream client, the client can determine if the "busy" node is the agent or the server based on origin-host of the response. About the behavior of the agent receiving the DIAMETER_TOO_BUSY response, it cannot be found in the base protocol but should be defined par application, even if generic guidelines could be provided.

[Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also to explain that there is also some gray area around its use, especially in a overload control context. For instance, a client receiving this response does not know the reason for which the request has not been delivered (e.g. IP failure, network congestion, etc.) and so it is not possible to provide a finer granularity of the client behavior, depending of different criteria can't be further detailed

Regards,

Lionel Morand

******************

De : [email-masked] [mailto:[email-masked]] De la part de Eric McMurry
Envoyé : jeudi 17 mai 2012 19:43
À : [email-masked]
Objet : [Dime] Diameter Overload Control Requirements

Abstract:

_________________________________________________________________________________________________________________________

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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 30 May 2012 11:24:31 +0200

The I-D and Lionel's comments make a good case about the need for such a piece of work. I would however suggest that we clarify better how we estimate overload and congestion and how we differentiate between overload and congestion caused by Diameter vs. other protocols run by the same hosts and networks. I am somehow unconvinced by the language used by the I-D which talks about 'Diameter networks', there is no such things, we have networks and hosts that run Diameter together with many other protocols, and congestion and overload is caused by their combination. The 3GPP study that is referred does not either focus on Diameter only. We need to understand what are the operational realities and concerns to make sure that we do not develop sophisticated protocol extensions in Diameter, which contribute only to alleviate a fraction of the real problems that operator face. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, May 30, 2012 11:51 AM
> To: Eric McMurry; [email-masked]
> Subject: Re: [Dime] Diameter Overload Control Requirements
> 
> (as individual)
> 
> Hi Eric, Ben,
> 
> I think that it is clear that it is required to further detail how to
> provide overload control in Diameter based networks, especially in
> large networks such as mobile networks.
> 
> However, in order to see exactly what to do, I think that we should
> first agree on what are missing pieces in the current specifications.
> So the section 4 should be further detailed to differentiate what
> should be clarified (if required) from what should be defined.
> 
> After a quick review, here is a set of comments as input for further
> discussion. The idea is that the set of requirements should be derived
> from a clear problem statement.
> 
> *********************
> [Lionel] IMHO, the first priority would be to clarify the relationship
> between Overload and Network congestion. Another one would be to
> clarify/verify some assumptions taken as baselines all along the
> document such as "inform the client of a problem until it is
> effectively too late to do anything about it". As explained below.
> 
> 
> [Lionel] in RFC3588-bis, the SHOULD is meant as a strong recommendation
> for application designers. So for me, the expected behavior of the
> receiver of this result code is quite clear IMHO. If something needs to
> be further clarified, it may be the conditions for sending the
> DIAMETER_TOO_BUSY response. It is assumed that the server will wait for
> being overloaded but there is nothing preventing the server to apply a
> specific policy/algorithm allowing the server to modulate the traffic
> load.
> 
> [Lionel] As described above, it depends on the time the first
> DIAMETER_TOO_BUSY response. But it is clear that this point needs to be
> further investigated.
> 
> [Lionel] the DIAMETER_TOO_BUSY response is per application as it is in
> response to given command request using a specific application-id. But
> this point is maybe not so clear in the RFC3588bis.
> 
> [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded
> server. So if the Proxy/Relay forwards the response to a downstream
> client, the client can determine if the "busy" node is the agent or the
> server based on origin-host of the response. About the behavior of the
> agent receiving the DIAMETER_TOO_BUSY response, it cannot be found in
> the base protocol but should be defined par application, even if
> generic guidelines could be provided.
> 
> [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also to
> explain that there is also some gray area around its use, especially in
> a overload control context. For instance, a client receiving this
> response does not know the reason for which the request has not been
> delivered (e.g. IP failure, network congestion, etc.) and so it is not
> possible to provide a finer granularity of the client behavior,
> depending of different criteria can't be further detailed
> 
> Regards,
> 
> Lionel Morand
> 
> ******************
> 
> Diameter deployments are growing in size and this is becoming more of
> an issue.  We have seen significant interest in providing a mechanism
> to address it.  Hopefully this document is useful as a base for
> discussion on what is needed and we welcome comments.
> 
> Abstract:
> _______________________________________________________________________
> __________________________________________________
> 
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Eric McMurry <[email-masked]>
Date: Wed, 30 May 2012 07:54:32 -0500

Thanks for the comments Tolga.  Responses are inline.

On May 29, 2012, at 21:01 , Asveren, Tolga wrote:

> There was an attempt around 2007 to start this work but at that time there wasn’t much interest. I don’t recall any strong technical objections but Diameter traffic volumes were not as high as now so there wasn’t an immediate need. I hope this time it goes through.
>  

The behavior for DIAMETER_TOO_BUSY is generally underspecified and not using it for this purpose avoids tying that confusion into overload control.  I agree with you that fixing it in 3588-bis would be nice, but that draft is done (approved for RFC).

> It could be good to mention issues with TCP/SCTP congestion propagation and about using receiver window sizes.

We can do that.  I think the point here was that there is an issue at the Diameter layer regardless of what happens at the transport layer.  For example, transports do not address multi hop or multi destination scenarios.

> I thought that it would indicate overload for the application as indicated in Application-Id. Is there any text in RFC3588 supporting either view?

not explicitly.  However, DIAMETER_TOO_BUSY can only be used when a specific server is requested, implying that it has a server scope.

from Ben: This drives home the underspecified nature if too_busy. You have to read between the lines to figure out what you can do with it. I've talked to people who ignore the "specific server" rule because it really doesn't make sense. We interpreted as "server", and you interpreted it as server+application.

This makes interop problematic.

> Does this mean that there shouldn’t be any reliance on indications from underlying transport protocol?

This was intended to keep the Diameter overload control mechanism from preventing the proper operation of whatever transport  it is using.  From Adam: For example, a mechanism that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms.

I recall that at some point we had a requirement for transport independence that would have covered what you are asking about.  I'm not sure when it fell out.  Do you think it makes sense for that to be there?

> I think the guidance should be for which messages should be sent rather than which ones should be processed.

I was thinking in terms of what was going on at an overloaded element for this one.  You have a good point though and it should cover both ends.

> Is this always a feasible approach considering that client may not always know the redundant pair for an overloaded server? Probably a mechanism is needed which allows the server to communicate the…

For a redundant pair that are functionally identical for the purposes of serving the request in the example (and which may use a shared IP, DNS, or some other mechanism outside of Diameter for routing to the pair) the client wouldn't necessarily be able to distinguish the pair mates.  In this case, overload should only be reported if both of the servers are overloaded.  This applies any scenario where multiple servers can transparently serve the same request.  The servers in these cases will have to coordinate reporting of overload. 

A mechanism that allows multiple ways of specifying the scope of the overload would be helpful here.

---

From: Eric McMurry <[email-masked]>
Date: Wed, 30 May 2012 08:36:21 -0500

Hi Lionel,

Thank you for the comments.  Based on your, and Dan's comments, adding more detail to the problem statement and front matter makes sense.  I've responded to your points below.

> After a quick review, here is a set of comments as input for further discussion. The idea is that the set of requirements should be derived from a clear problem statement.

agree.   Overload vs. network congestion could use more clarification.  These are different and network congestion is not what we are trying to solve (transports do this).

> [Lionel] in RFC3588-bis, the SHOULD is meant as a strong recommendation for application designers. So for me, the expected behavior of the receiver of this result code is quite clear IMHO. If somet…

There is mention of this being a transient error, but nothing specific.  I have seen multiple interpretations of the scope the error applies to.  In practice, implementations are using this in different ways.

> [Lionel] this would mean that these implementations would not follow the recommendations put in the RFC.

With no bounds on what transient means, implementations are open to start sending to the server reporting DIAMETER_TOO_BUSY as soon as the next request, although I would think that would not work particularly well.

> [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also to explain that there is also some gray area around its use, especially in a overload control context. For instance, a client re…

Good point.  We can add something on this.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 30 May 2012 18:21:36 +0300

Hi,

I skimmed through the document writeup. Thanks for writing it!  I have a couple of
observations. On the reasons for the overload situation, maybe one should also list
architectural issues and lack of "check points" i.e. if you are in a middle of a
multistep procedure and one of those fail you revert back to zero & restart. There
having a nice Diameter overload control does not help too much if then some earlier
non-Diameter part gets impatient and determines everything failed, even if the
delay/failure is temporary on some Diameter exchange.

Too bad we cannot really have system level solution requirements. In many cases the
overload "signal" needs to be propagated also to non-Diameter functions and elements.
But I guess that is an unsaid assumption here in the solution requirements, right? Is
this what the Req-23 tries to say?

My reading of the solution requirements is that it is already decided that extending
base protocol is the way to go. Basically req-2 states this. I don't think this is
particularly good for a requirements document.

Req-6 mentions a capability advertisement between peers but the later requirements
are more geared towards end-to-end capability advertisement (like req-29..). So
which one is more desired? end-to-end or hop-by-hop or both?

Either req-11 or req-13 should say that the overload indication must not cause even
more signaling into the network. Or is this what the req-14 actually tries to say?

Could you expand the req-15 a bit and give an example of possible cases that lead
to this requirement?

- Jouni

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 May 2012 11:02:15 -0500

> Does this mean that there shouldn't be any reliance on indications from underlying transport protocol?

I think something that's been conflated in this some of the comments so 
far is that network congestion is a different problem than server 
overload. The first problem -- network congestion -- is addressed by TCP 
and SCTP, and I don't think that we could do much to improve upon those 
mechanisms. (This would, in any case, be the wrong place to do so). What 
we're trying to solve is the second problem: server overload.

Even though these are different problems, there is clearly an 
interaction between them. It is possible to do things at the application 
layer that defeats or damages TCP and SCTP's ability to manage 
congestion. One example would be opening multiple TCP connections under 
high load conditions. The point of REQ 15 is that the server overload 
management solution cannot take this or any similar actions that would 
harm network congestion management.

/a

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 30 May 2012 12:44:06 -0400

I support this work, and will have comments later.

Janet Gunn

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:   Eric McMurry <[email-masked]>
To:     [email-masked]
Date:   05/17/2012 01:43 PM
Subject:        [Dime] Diameter Overload Control Requirements
Sent by:        [email-masked]

A new draft has been submitted intended to address requirements for 
overload control in Diameter. 

Diameter deployments are growing in size and this is becoming more of an 
issue.  We have seen significant interest in providing a mechanism to 
address it.  Hopefully this document is useful as a base for discussion on 
what is needed and we welcome comments.

Abstract:
       When a Diameter server or agent becomes overloaded, it needs to be 
able
       to gracefully reduce its load, typically by informing clients to 
reduce
       sending traffic for some period of time. Otherwise, it must 
continue to
       expend resources parsing and responding to Diameter messages, 
possibly
       resulting in congestion collapse. The existing mechanisms provided 
by
       Diameter are not sufficient for this purpose. This document 
describes
       the limitations of the existing mechanisms, and provides 
requirements
       for new overload management mechanisms.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 30 May 2012 16:51:59 +0000

Support too.

Tina

From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: Wednesday, May 30, 2012 9:44 AM
To: Eric McMurry
Cc: [email-masked]; [email-masked]
Subject: Re: [Dime] Diameter Overload Control Requirements

Janet Gunn

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.

________________________________

Abstract:

---

From: Eric McMurry <[email-masked]>
Date: Wed, 30 May 2012 13:06:12 -0500

Thanks for the comments Jouni.  responses inline.

> this what the Req-23 tries to say?

Even without network wide/solution level requirements, we can talk more about how this fits and what is going on  at a higher level.  Solving it across protocols is more of an application level issue though, and best addressed in application level specifications (in 3GPP for example).

> particularly good for a requirements document.

That part of req 2 was intended as an example and does not use requirement language, so I agree with you that it should not be a direct requirement.  That said, addressing this in the base makes sense to me and helps address several of the requirements.

> which one is more desired? end-to-end or hop-by-hop or both?

The requirements were not intended to specify hop-by-hop or end-to-end.  SIP overload control, which informed this, landed on hop-by-hop, but Diameter has some characteristics that are different than SIP.  We were intending to leave this for the mechanism.

> more signaling into the network. Or is this what the req-14 actually tries to say?

14 was intended to cover this when load is high, and it can be implied from 13 also (hopefully).

> Could you expand the req-15 a bit and give an example of possible cases that lead

Adam covered this in his earlier response to Tolga.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 May 2012 14:27:43 -0500

Hi Dan, thanks for the feedback. See comments inline:

> The I-D and Lionel's comments make a good case about the need for such a piece of work. I would however suggest that we clarify better how we estimate overload and congestion and how we differentia…

There's probably room to clarify this, but our expectation was that network congestion would not be in scope for this effort. As Adam mentioned in a separate email, network congestion is probably more a transport protocol issue, not a Diameter issue per se.  We are really talking about Diameter node overload. We also don't expect that we can standardize how a particular Diameter implementation determines it needs to shed load, or how that would interact with other applications. That seems to me to be very implementation and application dependent.

OTOH, once a Diameter implementation determines that it needs to reduce its load, it needs a mechanism to tell Diameter peers to reduce the amount of work they are sending it. That's the part that seems to benefit from standardization.

We recognize that Diameter does not run in a vacuum, and put words to that effect in Section 1. (Third paragraph). We also talked about how Diameter overload can be impacted by non-Diameter dependencies (Section 1.1, Dependency Failures). We of course welcome suggestions on how to further clarify this.

Thanks!

Ben.

[...]

---

From: Jouni <[email-masked]>
Date: Thu, 31 May 2012 00:01:13 +0300

Hi,

> That part of req 2 was intended as an example and does not use requirement language, so I agree with you that it should not be a direct requirement.  That said, addressing this in the base makes se…

Well, "MUST be useable with any existing or future.." and
"MUST NOT require specification changes for existing.." basically
rule out anything that you can stuff into CCF or existing commands
in specs world. So I am left only with base protocol level options.
Just language tweaking..

- Jouni

---

From: Eric McMurry <[email-masked]>
Date: Wed, 30 May 2012 16:11:25 -0500

> in specs world. So I am left only with base protocol level options.

I think those requirements could be met without base level changes.  Perhaps I am misunderstanding your point though.  Do you think that working with existing and future applications and not requiring changes to existing applications are unreasonable requirements?

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 30 May 2012 15:34:54 -0400

We support this work.

Regards,
Kalyani Bogineni
Verizon

>> De : [email-masked] [mailto:[email-masked]] De la part 
>> de Eric McMurry Envoyé : jeudi 17 mai 2012 19:43 À : [email-masked] 
>> extensions to Diameter Base protocol that can be considered as 
>> enhanced features or bug fixes.
>>

---

From: "Shaikh, Viqar A" <[email-masked]>
Date: Wed, 30 May 2012 16:58:32 +0000

I support this work.

Viqar

Abstract:

---

From: <[email-masked]>
Date: Wed, 30 May 2012 23:34:29 +0000

Hi Eric, Thank you for your feedback. Please see additional comments below.

Regards,

Lionel

-----Message d'origine-----
De : Eric McMurry [mailto:[email-masked]] 
Envoyé : mercredi 30 mai 2012 15:36
À : MORAND Lionel RD-CORE
Cc : [email-masked]
Objet : Re: [Dime] Diameter Overload Control Requirements

Hi Lionel,

[Lionel] indeed it is different aspects. And it will be suitable to clarify the difference but also the possible interaction between both.

[Lionel] the landscape of Diameter implementations is wide and time-to-time surprising :)

[Lionel] I might have missed something in your response but DIAMETER_TOO_BUSY is not defined as a transient failure cause but as a permanent error. And the definition of the error is:

   DIAMETER_TOO_BUSY                  3004
      When returned, a Diameter node SHOULD attempt to send the message
      to an alternate peer.  This error MUST only be used when a
      specific server is requested, and it cannot provide the requested
      service.

And the "SHOULD" in the text has to be understood as defined in RFC2119:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

This is why I was saying that the given implementations were not following the recommendation of the RFC (or RFCbis). Nevertheless, I have admitted that it may be required to clarify the use of this error (triggering mechanism, detailed behavior of the client, possible action of agent, etc.)

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 May 2012 22:35:25 -0500

On 5/30/12 18:34, May 30, [email-masked] wrote:
> [Lionel] I might have missed something in your response but DIAMETER_TOO_BUSY is not defined as a transient failure cause but as a permanent error.

Yes, it is. And permanent failures are described: "Errors that fall 
within the permanent failures category are used to inform the peer that 
the request failed, and should not be attempted again."

I would put heavy emphasis on the the two words "the request," 
particularly on the non-plural nature of that phrase. Permanent failures 
are permanent for the specific request they are sent in response to. 
There is no statement, or even implication, anywhere in 3588 or its 
revision that permanent errors have any bearing on future requests.

>   And the definition of the error is:
>
>     DIAMETER_TOO_BUSY                  3004
> This is why I was saying that the given implementations were not following the recommendation of the RFC (or RFCbis).

Yes, it is true that the client "SHOULD attempt to sent THE MESSAGE to 
an alternate peer." Not "messages." "Message."

Let's tease this out a bit. Consider a client. It knows that the 
requests it can send are serviced preferentially by server A. It also 
knows that the same requests can be handled by a backup server B. (This 
arrangement could be detailed through SRV record priorities, 
provisioning, etc.). The client sends request 1 to server A. It gets a 
"DIAMETER_TOO_BUSY" error. Following the normative SHOULD-level 
requirement above, it then sends this same request 1 to server B. Server 
B processes the request, and everyone is happy.

Thirty milliseconds later, the same client wants to send a request 2, 
unrelated to request 1, to the server. Is it in violation of any portion 
of 3588 or 3588bis' normative language if it sends this request 2 to 
server A? If so, could you point out the normative statement it violates?

Thirty seconds later, the client wants to send a request 3. Does that 
change your answer?

How about thirty minutes? Thirty days?

/a

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 31 May 2012 10:06:15 +0200

Hi Ben,

Thank you (and also Adam) for the clarification. If the work focuses on server overload rather than on network overload I suggest this to be explicitly articulated, also the use of language like 'Diameter network' and 'Overload in the Diameter network' is confusing on this respect, as well as the fact that the 'other mechanisms' list in section 3 begins with the transport layer network congestion avoidance mechanisms. 

Regards,

Dan

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2012 10:28 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Eric McMurry; [email-masked]
> > The I-D and Lionel's comments make a good case about the need for
> such a piece of work. I would however suggest that we clarify better
> how we estimate overload and congestion and how we differentiate
> between overload and congestion caused by Diameter vs. other protocols
> run by the same hosts and networks. I am somehow unconvinced by the
> language used by the I-D which talks about 'Diameter networks', there
> is no such things, we have networks and hosts that run Diameter
> together with many other protocols, and congestion and overload is
> caused by their combination. The 3GPP study that is referred does not
> either focus on Diameter only. We need to understand what are the
> operational realities and concerns to make sure that we do not develop
> sophisticated protocol extensions in Diameter, which contribute only to
> alleviate a fraction of the real problems that operator face.
> >
> 
> There's probably room to clarify this, but our expectation was that
> network congestion would not be in scope for this effort. As Adam
> mentioned in a separate email, network congestion is probably more a
> transport protocol issue, not a Diameter issue per se.  We are really
> talking about Diameter node overload. We also don't expect that we can
> standardize how a particular Diameter implementation determines it
> needs to shed load, or how that would interact with other applications.
> That seems to me to be very implementation and application dependent.
> 
> OTOH, once a Diameter implementation determines that it needs to reduce
> its load, it needs a mechanism to tell Diameter peers to reduce the
> amount of work they are sending it. That's the part that seems to
> benefit from standardization.
> 
> We recognize that Diameter does not run in a vacuum, and put words to
> that effect in Section 1. (Third paragraph). We also talked about how
> Diameter overload can be impacted by non-Diameter dependencies (Section
> 1.1, Dependency Failures). We of course welcome suggestions on how to
> further clarify this.
> 
> Thanks!
> 
> Ben.
> 
> [...]
> 
> >
> >
> de
> >> Eric McMurry
> >>        When a Diameter server or agent becomes overloaded, it needs
> to
> >> be able
> >> If you have received this email in error, please notify the sender
> and
> >> delete this message and its attachments.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 31 May 2012 11:32:26 +0300

Hi Eric,

On May 31, 2012, at 12:11 AM, Eric McMurry wrote:

> I think those requirements could be met without base level changes.  Perhaps I am misunderstanding your point though.  Do you think that working with existing and future
>  applications and not requiring changes to existing applications are unreasonable requirements?

No. Definitely not. I was just saying, the req-2 does not, as written
now, give you any other choice than extend or leverage the base
protocol. I am not comfortable with that -- as a requirement to be
documented.

- Jouni

---

From: Eric McMurry <[email-masked]>
Date: Thu, 31 May 2012 08:42:43 -0500

Hey Jouni,

> protocol. I am not comfortable with that -- as a requirement to be

So if we take off the last sentence (the one that refers to the base protocol) would that allay your concern?

Thanks,

Eric

---

From: Eric McMurry <[email-masked]>
Date: Thu, 31 May 2012 08:48:21 -0500

On May 30, 2012, at 22:35 , Adam Roach wrote:

> Yes, it is. And permanent failures are described: "Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again."
> 
> I would put heavy emphasis on the the two words "the request," particularly on the non-plural nature of that phrase. Permanent failures are permanent for the specific request they are sent in response to. There is no statement, or even implication, anywhere in 3588 or its revision that permanent errors have any bearing on future requests.

The only permanent errors I see are the 5xxx class errors (DIAMETER_TOO_BUSY is 3004).  Additionally, sections 8.1 and 8.2 refer to DIAMETER_TOO_BUSY as a transient or temporary error.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 May 2012 09:13:11 -0500

Thanks Dan. We definitely want to be clear on that point, and will try to clarify it in the next revision.

Thanks!

Ben.