Subject: [Dime] Review of draft-tschofenig-dime-overload-arch-00.txt

From: Alan DeKok <[email-masked]>
Date: Tue, 23 Jul 2013 20:05:17 -0400

Hannes asked me to review the documents.  While I've been avoiding
Diameter, many of the principles are similar across AAA protocols.

  Over all the document seems reasonable, and describes a consistent
architecture.

  My biggest issue is Section 4.3, the "Exchange of Load Info"
discussion.  I have some concerns here.

  Such signaling doesn't work well across proxies.  i.e. For the diagram
in Section 4.3, the Diameter servers can signal load information to the
load balancer.  However, the load balancer does not signal load
information to clients.

  Even if the load balancer did signal load to the client, what does it
signal?  It has to aggregate load information across all Diameter
servers.  It's not clear how that would be done.

  I discussed a potentially better system with Hannes earlier today.
The idea is essentially a single queue, multiple-server method.  It's
similar to that used in some stores:

http://puzzlor.editme.com/queue
http://www.ask.com/answers/39346021/why-a-single-queue-with-multiple-servers-performs-better-than-each-server-having-their-own-queue

  The method requires no feedback from the server to the load balancer.
 The load balancer simply monitors requests and responses.  The
algorithm can be implemented by a load balancer, or a client which has
multiple home servers.

  The idea (in short) is to keep track of a number C, which is the count
of requests sent to a home server which have not yet seen a response.
The goal is to keep C the same across all N home servers in a load
balance pool.

  When a new request comes in, the load balancer chooses a home server H
with the lowest C value, and increments C.  If there are multiple home
servers with the same lowest C value, one is chosen at random.

  The result is that servers require no additional signaling to the load
balancer.  Offered load is spread evenly across home servers of equal
responsiveness.  Where one home server accepts more load than the
others, it is sent more offered load.

  The rest of the document involves signaling of overload information.
Signaling overload is more useful than signaling load-balance
information.  However, I think statements like the following in 5.2.3
are inflexible:

   INCREASING_OVERLOAD          1  The Diameter server uses this value
      to inform the client that overload has increased and that the
      Diameter client shall decrease the sending rate into half
      (calculated over the last 10 minutes).

  Why would the sending rate decrease by half?  Why not any other value?

  It may be better for the Diameter server to simply respond with a
message saying "I'm busy.  Retry this request in N seconds".  That
message solves two purposes.  One, it signals overload, which is a good
thing.  Two, it allows the server to selectively control the clients
back-off method.

  Experience shows that making decisions in the server is simpler and
more flexible than making decisions in the client.  The only issue I see
here is that this signaling would have to be in-band.

  i.e. a Diameter client sends a request X, and instead of receiving a
normal reply, it receives an error reply indicating the re-transmission
timer.  This may be fit in with the current diameter practice.  I'm not
familiar enough to say for sure.

  The algorithm for the load-balancing solution is simple.  It's been
implemented in at least one AAA server for a decade, with no known issues.

  The algorithm for retransmission signaling is less obvious.  Both the
information to be tracked, and the algorithm are unknown.

  I believe that these approaches would be simpler and more robust than
alternatives.

  I'll spend some time modeling various algorithms for the
retransmission signaling.  The solution seems simple to me, but is also
not obvious right now.

  Alan DeKok.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jul 2013 21:11:14 -0500

Hi Alan,

At risk of this being a big thing to ask--could you also take a look at draft-roach-dime-overload-ctrl-03? It would be useful to have your opinion on all the current Diameter overload control proposals.

draft-ietf-dime-overload-reqs-09 might also be useful for context on the discussion so far.

Thanks!

Ben.

On Jul 23, 2013, at 7:05 PM, Alan DeKok <[email-masked]> wrote:

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

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 24 Jul 2013 16:52:26 +0300

With respect to _all_ proposals there is also draft-korhonen-dime-ovl-01 ;-)

- jouni

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Jul 2013 09:08:11 -0500

Oops, sorry. I had actually meant my second sentence to expand my request to cover _all_ the drafts. I clearly did not make that clear :-)

Thanks!

Ben.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 24 Jul 2013 10:11:42 -0400

> At risk of this being a big thing to ask--could you also take a look at draft-roach-dime-overload-ctrl-03? It would be useful to have your opinion on all the current Diameter overload control propo…

  Here's my initial impression.  I hope it's clear.

...
    The inclusion of load and
   overload information in existing messages has the property that the
   frequency with which information can be exchanged increases as load
   on the system goes up.

  I would hazard a guess and say that for 99% of the messages between
nodes A and B, the load information is relatively static.  i.e. it
changes slowly over time.  This means that "always-on" signing is efficient.

  In the grand scheme of things, it's probably not too much to worry
about.  Networks are fast and getting faster.  So adding a bit more to
each message isn't serious.

  Adding *periodic* load information to messages would fulfill the same
goal.

Section 2 - Overload scopes

  To me, in-band signaling like this is a problem.  The issue seems to
be that we require a AAA routing protocol.  That protocol would signal
whether realm A was reachable, and if so, what path(s) could be used to
reach it.

  Describing it as a routing protocol seems better to me.  As seen by
this comment in Section 3:

   OPEN ISSUE: SIP Overload Control includes a sequence parameter to
   ensure that out-of-order messages do not cause the receiver to act on
   state that is no longer accurate.

  A routing protocol would ensure that state changes are propogated
smoothly through the network, without out-of-order issues.  It may use a
sequence number, but dealing with order would be an explicit design goal
of the protocol.

...
   To implement overload control, Diameter nodes need to keep track of
   three important metrics for each of the scopes for which information
   has been received: the overload metric for the scope, ...

 This is the first introduction of "overload metric".  What is it?  What
does it mean?

...
   In order to allow recipients of overload information to perform
   certain performance optimizations, we also define a new command flag,
   called 'O'verload.  This bit, when set, indicates that the message
   contains at least one Load-Info AVP with a non-zero Overload-Metric
   -- in other words, the sending node is overloaded for at least one
   context.  See Section 7.4 for the definition of the 'O'verload bit.

  What does the overload bit *mean*?  The sending node is overloaded.
Ok... what does the client *do* with that information?  There should be
a sentence here introducing the idea that the client does something with
the data.

  Later, we have an explanation:

   If one or more matching scope entries are in overload, then the
   sending node determines which scope is most overloaded.  The sending
   node then sends, drops, or otherwise modifies handling of the request
   according to the negotiated overload control algorithm, using the
   Overload-Metric from the selected scope entry as input to the
   algorithm.

 That covers the missing information from above.

   When determining which requests are impacted by the overload control
   algorithm, request senders MAY take into account the type of message
   being sent and its contents.  For example, messages within an
   existing session may be prioritized over those that create a new
   session.  The exact rules for such prioritization will likely vary
   from application to application.

  This worries me.  A lot.  Let me explain.

  Having multiple algorithms increases system complexity.  Having a
*client* implement algorithms is even more problematic.  Maybe Diameter
is different, but my experience with RADIUS shows that it's best to
assume clients are the dumbest things around.

  Keeping the complexity in the server means that there are fewer places
in the network which need this complexity.  Servers already have a lot
of complexity to deal with various policies, so adding more isn't too
difficult.

  My experience is that it's better to define *actions* for clients,
instead of *states* and algorithms.  i.e. "come back in 5 seconds" is
simpler for a client than "server is in state X, please implement
algorithm Y".

  It means that the server can implement *any* algorithm, and all
clients will support it.  We only require the "overload" signaling to
include the standard network parameters related to time and bandwidth.

- send no more than X messages / s
- retransmit this message in X seconds
- etc.

  So the server can run the algorithm, and inform the client as to it's
expected behavior.  No negotiation is required.  The client just has to
signal it's capability to understand the time / bandwidth messages.

  It's simpler, easier to understand, easier to implement, and likely to
be more flexible and robust.

  The rest of the document describes such signaling.  But calling it
"Overload" confuses the issue (IMHO).  Maybe it could be "messaging
QoS", or something similar.  The idea is that it's *normal* to signal
changing circumstances between peers.  It's not an exceptional or
"overload" situation.

  e.g. Say I want to switch traffic from server A to server B.  To do it
gradually, I make server A signal that it has gradually lower throughput
over time, and server B signals it has gradually higher throughput over
time.

  The end result is that the traffic moves from A to B without any
sudden "spikes".  The alternative would be to suddenly signal that
server A is down, and all of the clients have to suddenly deal with the
loss of a server.

Section 3.5 Load Processing

   While the remainder of the mechanism described in this document is
   aimed at handling overload situations once they occur, it is far
   better for a system if overload can be avoided altogether.  In order
   to facilitate overload avoidance, the overload mechanism includes the
   ability to convey node load information.

  I agree here.  I think this document doesn't go far enough.  As I said
above, load signaling is *normal*.  Overload is just a signal that
accepted load is approaching zero.

  I suggest revamping the document to treat load changes as normal,
rather than as exceptional.  It would make it clearer (to me, at least)
what the goal is: managing traffic.  Instead of managing exceptional
circumstances.

3.5.1.  Sending Load Information

  As noted earlier, I have objections to this approach.  Signaling load
information is confusing to me.  e.g. "OK, the server is overloaded...
what do I *do* now?"

  It should be something like "Signaling Connection Parameters" or
"Signaling Requested Sending Behavior".  That is an *active* statement.
 "Signaling Load Information" is a *passive* statement.  It doesn't lead
the reader to believe he needs to *do* anything with the information.

...
   The client then examines the currently reported loads for each of the
   three servers.  In this example, we are asserting that the reported
   load metrics are as follows:

  This section is a bit opaque to me.  It's not clear *why* these
calculations are being done.  I presume it's taking a convolution of the
suggested load distribution with the servers current load.  But it's not
clear.

...
   A Diameter node entering the overload state for any of the scopes
   that it uses with its peers will calculate a value for its Overload
   Metric, in the range of 0 to 100 (inclusive).  This value indicates
   the percentage traffic reduction the Diameter node wishes its peers
   to implement.

  This is good.  I would prefer that the earlier parts of the document
explain the method.  i.e. the earlier parts have motivation, but not a
short description of how it works.  Such explanations serve to motivate
the rest of the document, and put it into a conceptual framework.

  I have concerns with signaling a percentage traffic reduction.  What
if the server is overloaded, signals a reduction, and the traffic has
already lowered?  The client would seem to lower it's already lowered
traffic.  The client then sends less traffic than the server can accept.

  It would be better to signal throughput instead.  i.e. "limit
throughput to X messages/s".  When the traffic on the client lowers, it
discovers that it is already compliant with the request.  And does nothing.

  That's my $0.02 for now.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 24 Jul 2013 21:30:00 -0400

This is my review of draft-korhonen-dime-ovl-01.

  It's easier to understand this draft after reviewing the other two.  I
also find this one clearer.  Ideas are presented and motivated before
they're discussed in detail.  This gives a framework for the later
detailed discussion.

  Over all, the design seems to be more in line with what I've been
recommending in my other reviews.  As a result, I don't have too many
comments.

  The document doesn't mention load balancing, which would be useful to
have.  Ideas from the other documents could be applicable.

  My other reviews contain suggestions for additional (or less)
signaling, which also could apply here.

- I disagree with the word "overload".  Signaling load status should
  be part of normal behavior, instead of an "overload" condition

- load balancing can be done automatically by clients, requiring
  minimal interaction with servers

- servers should send behavior requests to the clients (e.g. throttle
  traffic to X messages/s) instead of state changes ("I'm overloaded")

- signaling realm availability would better be part of a global AAA
  routing protocol, instead of a hop-by-hop load-balancing protocol

  Alan DeKok.

---

From: Eric McMurry <[email-masked]>
Date: Thu, 25 Jul 2013 10:24:36 +0200

Hi Alan,

Thanks for the taking the time to provide comments!

discussion inline.

Eric

>  Adding *periodic* load information to messages would fulfill the same

yes.  we've gone back and forth on this a few times.  The current approach is optimized for the receiver so that it can pull out the information any time it desires, which can be done periodically.  This is just a choice between compute or network resource usage.

> sequence number, but dealing with order would be an explicit design goal

I'm not sure I fully understand this, but I'll take a shot.  This note was pointing out something to think about when there are multiple connections between peers.  The protocol should be fine with this as overlapped information possible here is on a short enough time scale to not interact with the critical control information.  However, it points out that some more consideration of this is needed to be sure of that.

I understand your point about out of band.  That would make sense for several reasons.  However, using the existing protocol is highly desirable since it is already in place and can support this.

> This is the first introduction of "overload metric".  What is it?  What

It is first mentioned in the overview and there is a section with its definition.  It is the number used by the control algorithm for deciding/altering it actions.  For example, it could be used to request a percentage of traffic to be dropped when used with a drop algorithm.

> That covers the missing information from above.

so having the introduction of the new bit in the higher level behavior section was the source of confusion?

> be more flexible and robust.

yes, Diameter clients are different.  They tend to be sophisticated servers doing a number of functions with Diameter being used for some of their control signaling.  Their other functions usually require the use of other protocols and they may have to consider information in making overload control decisions that servers do not have.  The requirements draft may be helpful for describing the problem domain for this (http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-09)

> changing circumstances between peers.  It's not an exceptional or

interesting idea on renaming.  I'm curious what others think of this.

> what the goal is: managing traffic.  Instead of managing exceptional

Good comment.  A pass through to emphasize proactive control more could be helpful.

> information is confusing to me.  e.g. "OK, the server is overloaded...

The load information is the info used for proactive mitigation.  It carries no implication that overload is happening.  That is handled by the rest of the information.

As far as what to do with it, not specifying that was intentional.  What to do with load information is implementation specific.  Load balancing is what usually pops into people's heads.  But that is not the only option.

I think part of the confusion here may be Load-Info (grouped) vs. Load (reported load for proactive mitigation) AVP naming.  This has caught me before too.  I think renaming Load-Info to Overload-Control-Info or some such would be helpful.  I understand your earlier comment about naming to indicate that this is ongoing information, but we also need to be careful not to imply that the information is intended for uses other than overload control (that can certainly be done, but we need to constrain what we are designing for).

> the reader to believe he needs to *do* anything with the information.

There isn't any requirement for a recipient to do anything with the information.  In many cases they can do things that will help with proactive overload mitigation though, such as the simple load balancing example.

> suggested load distribution with the servers current load.  But it's not

this example just uses the load information to scale SRV weights, so you have the gist of it.  It is non-normative and just an example of how load information can be used.  Perhaps some of the discussed name changing will help illustrate that the load information usage is different than the reactive overload control information.

> the rest of the document, and put it into a conceptual framework.

We could talk about this earlier as an example.  The actual behavior though depends on the algorithm and is extensible, so we have to be careful not to paint the language into a corner.

> discovers that it is already compliant with the request.  And does nothing.

you're not the only one to think that :-)  we have to pick a default algorithm to use and drop has the nice characteristic of being quite simple.  What actually happens here is up for debate.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 25 Jul 2013 12:47:15 +0000

Eric,

I prefer "Overload" versus QoS messaging"

Regards,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric McMurry
Sent: Thursday, July 25, 2013 4:25 AM
To: Alan DeKok
Cc: [email-masked]
Subject: Re: [Dime] Review of draft-roach-dime-overload-ctrl-03

Hi Alan,

discussion inline.

Eric

---

From: Alan DeKok <[email-masked]>
Date: Thu, 25 Jul 2013 08:50:06 -0400

> I understand your point about out of band.  That would make sense for several reasons.  However, using the existing protocol is highly desirable since it is already in place and can support this.

  Using the existing protocol is fine.  I'm just wary of overloading a
link-layer QoS protocol, and turning into a multi-hop routing protocol.

  It would be better (IMHO) to signal routing changes independent from
link changes.

> so having the introduction of the new bit in the higher level behavior section was the source of confusion?

  Yes.  If the first use of "overload metric" assumes you know the
meaning, it's confusing.  e.g. Section 1.3 says:

   ... Overload-Metric (which is input to the negotiated
   load abatement algorithm).

  It might as well be called "foo".  It's an opaque input parameter,
with no meaning, and no context.

  I find it clearer to lay out the document by introducing a concept,
defining it, giving a hint as to how it's used, and then later using it
in a more complex context.

> yes, Diameter clients are different.  They tend to be sophisticated servers doing a number of functions with Diameter being used for some of their control signaling.  Their other functions usually…

  I scanned it.  I'll take a deeper look.

> As far as what to do with it, not specifying that was intentional.  What to do with load information is implementation specific.

  Then I'm not sure why this document is useful.  It would seem to be
useful to describe both the data, and how the data is used.

> this example just uses the load information to scale SRV weights, so you have the gist of it.  It is non-normative and just an example of how load information can be used.  Perhaps some of the disc…

  I was looking for an English explanation of what was going on.  Right
now, the calculation looks a lot like:

A = 5
B = 6
C = 10

D = A * B / C + 2*A
E = D^A + C

  ??? OK, that's nice.  WHY is this being done?  What does it mean?

> you're not the only one to think that :-)  we have to pick a default algorithm to use and drop has the nice characteristic of being quite simple.  What actually happens here is up for debate.

  Traffic is bursty.  Let's say a server gets a burst of 100Mbps
traffic.  It signals to the client "drop traffic by 90%".  By the time
the message makes it to the client, the burst is over.  Traffic is down
to 5Mbps.  So the client happily caps it at .5Mbps, which is not what
the server wanted.

  Signaling a percentage drop is meaningless, because it's taken at a
time on the server.  The client doesn't know when that measurement was
done on the server.

  So either you signal "percentage drop AND (servers' load OR server
time)", or you just signal "limit traffic to X bps".  Both have the same
effect.  The second is simpler.

  Alan DeKok.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 25 Jul 2013 10:59:32 -0400

You might also want to take a look at 

draft-ietf-soc-overload-control-13 

 and

draft-ietf-soc-overload-rate-control-04

While SIP is different from DIME, the SIP overload work was, in some 
senses, the "inspiration" for the DIME overload work, and some of the same 
issues were addressed.

In particular, there was the same concern about "loss based" vs "rate 
based" throttling, resulting in two separate drafts.  Both use the same 
(in band)  communications protocol, and the same parameters, but use 
different parameter values , and different default algorithms.

I agree that it is, in general, better  for the server to tell the client 
"do this", rather than "this is my status, you figure out what to do". But 
DIME may not match the "in general" situation.

Janet

[email-masked] wrote on 07/25/2013 08:50:06 AM:

> From: Alan DeKok <[email-masked]>
> To: Eric McMurry <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: 07/25/2013 08:50 AM
> Subject: Re: [Dime] Review of
> Sent by: [email-masked]
> 
> 
> > yes, Diameter clients are different.  They tend to be 
> sophisticated servers doing a number of functions with Diameter 
> being used for some of their control signaling.  Their other 
> functions usually require the use of other protocols and they may 
> have to consider information in making overload control decisions 
> that servers do not have.  The requirements draft may be helpful for
> describing the problem domain for this (http://tools.ietf.org/html/
> draft-ietf-dime-overload-reqs-09)
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Jul 2013 11:08:19 -0500

On Jul 25, 2013, at 9:59 AM, Janet P Gunn <[email-masked]> wrote:

> While SIP is different from DIME, the SIP overload work was, in some senses, the "inspiration" for the DIME overload work, and some of the same issues were addressed. 
> 
> In particular, there was the same concern about "loss based" vs "rate based" throttling, resulting in two separate drafts.  Both use the same (in band)  communications protocol, and the same parameters, but use different parameter values , and different default algorithms. 
> 
> I agree that it is, in general, better  for the server to tell the client "do this", rather than "this is my status, you figure out what to do".  But DIME may not match the "in general" situation. 

It may also be worth pointing out that, at least in draft-roach-dime-overload-ctrl, you really don't have a case of "here's my status, figure it out" in general. Peers negotiate an algorithm, and that algorithm specifies what the client should do. The algorithms are extensible, so it would be possible to make one that fits the "sender figures it out" model, but there's no assumption of that.

For the loss-based algorithm included in the draft, the overload metric specifies a percentage reduction. For example, a metric of 50 means the client should reduce traffic by 50. While that still gives the client some leeway in determining which requests to drop, that's considerably different from saying "I'm 50% overloaded; figure it out." In fact, while we're sometimes imprecise here in conversation,  there's no assumption in that algorithm that "reduce your offered load by 50%" maps in any way to "I'm overloaded by 50%".

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Jul 2013 17:07:35 -0500

Hi Alan, thanks for the detailed feedback. Please see comments inline:

Thanks!

Ben.

>  Adding *periodic* load information to messages would fulfill the same

As Eric said separately, we've had a fair amount of discussion on this point. The idea was to avoid forcing the peer to keep too much state--anytime it needed to worry about "load" it could pull that information out of the most recent message.

> this comment in Section 3:

It's possible that this proposal could be used as a routing protocol, but that's not the intended scope, and I don't think that a routing protocol is would be considered chartered work for DIME. The point of the proposal is to allow Diameter nodes to proactively request that peers reduce their offered load. I think this is different than availability per se, in that a service is either available or it's not.  One can always request offered load be reduced to zero, which I suppose is the same as "unavailable", but most cases should not need to go that far.

> sequence number, but dealing with order would be an explicit design goal

draft-roach-dime-overload-ctrl only describes sending overload/load info between immediate peers. Unlike RADIUS,  Diameter only runs over connection-based transports.  Out of order messages should not be a problem. OTOH, there's been some discussion about allowing overload info to non-adjacent nodes. If we were to do that, we'd probably need to think about the possibility of out-of-order messages.

> This is the first introduction of "overload metric".  What is it?  What

As Eric mentioned, it's first described in the 2nd paragraph of the introduction. Is that description insufficient?

> a sentence here introducing the idea that the client does something with

I'm not sure I understand the confusion on this one. The O flag means that the message contains overload information, in the form of a Load-Info AVP with a non-zero Overload-Metric value. Would it help to remove the mention of the Load-Info AVP and Overload-Metric and simply say " ... indicates that the message contains information about an active overload condition"?

> That covers the missing information from above.

Actually, that describes the meaning of the overload information in the message, but not the overload flag. The flag is entirely an optimization so the peer knows to look for the overload metric.  We spoke to implementors that were concerned about having to parse the entire message to determine if they needed to apply overload treatments. The flag gives a fast way to determine that. Basically, the assertion of an overload condition is entirely done inside the Load-Info AVP. The flag has no semantic meaning beyond "look in Load-Info, there's important stuff there.")
This could probably use clarification.

>  This worries me.  A lot.  Let me explain.

That's probably badly written. The point is not that request senders get to decide which messages are impacted by the overload control algorithm. That's handled explicitly by the scope AVPs. The point is, that when deciding which messages to drop among the set of impacted messages, the client has some leeway. For example, if using the "loss" algorithm with an overload-metric of 50, the client gets to decide which 50% messages gets dropped. (Note that some other algorithm could include stricter rules).

> assume clients are the dumbest things around.

There are areas where Diameter is different, and areas where it is not. It does tend to support more complex applications that RADIUS, where there may be more application-specific request interdependencies. But even if it were the same, I don't know how a server could tell the client what to do with messages that haven't been sent yet.

> of complexity to deal with various policies, so adding more isn't too
The reasoning is the client understands more about the underlying application, and any resulting request interdependencies,  than the server. 

> simpler for a client than "server is in state X, please implement

I think there's a bit of a misconception there. The point is not to say " the server is in state X, please implement Y". The algorithm is negotiated up front. The Overload-Metric is an input into that algorithm. It really isn't a description of server state. For example, if the loss algorithm is in effect, a Overload-Metric of 50% means "reduce offered load by 50% (of what you would have otherwise sent)". It does _not_ mean "I am overloaded by 50%". (The client might could infer that, but I suspect it would not be correct a good bit of the time.)

> - send no more than X messages / s

I'm not sure how, from the perspective of your previous concerns, this is any different. The client still gets to decide which X messages make the cut any given second. And in the context of the draft, this is no different than negotiating a rate-limit application which interprets the Overload-Metric to be a number of messages per second, then sending an overload metric of X.

(Admittedly the draft does not describe a rate-limit algorithm, but there's been discussion that we may need one.)

> - retransmit this message in X seconds

That falls into the category of reactive vs proactive overload control. I think it might be worthwhile fixing DIAMETER_TOO_BUSY to allow a server to express that sort of thing. But I think we would do that in a separate draft.

> signal it's capability to understand the time / bandwidth messages.

How is signaling the capacity to understand the time/bandwidth messages different than negotiating support for a rate-limit algorithm?

> server A is down, and all of the clients have to suddenly deal with the

I think this can be accomplished with the "Load" information. I can see separating that out as a separate mechanism. We've included it because we think the overload aspects can work a lot better if you know something about the active load going on in non-overloaded nodes. Peers can make smarter decisions about how to reduce load on an overloaded server. In particular, we have a requirement to not cause cascade failures or unstable oscillations. Basically we want to avoid causing a second node to go into overload because we moved traffic there from a previously overloaded node.

> what the goal is: managing traffic.  Instead of managing exceptional

To be clear, changes in "load" are not exceptional, and can be used as an input into load balancing at any time. That differs from "overload", which can be best interpreted as "I urgently need a reduction in offered load".

> information is confusing to me.  e.g. "OK, the server is overloaded...

This section is not about overload. It's about current load in non-overloaded conditions. I'm not sure how that's different from the "non-exceptional" load processing you mentioned in the previous paragraphs.

> suggested load distribution with the servers current load.  But it's not

There are two aspects of load. One is relative static capacity. For example, are all the servers in a cluster the same size? In Diameter, that can be expressed with the DNS SRV "weight" field (as in the example). It can also be provisioned into a peer table. The other is dynamic load, i.e. how loaded is the server right now. 

The idea is that 50% availability of a big server is different than 50% availability of a small server.

(I suspect you are right that there is room for clarification in the text.)

> the rest of the document, and put it into a conceptual framework.

Keep in mind, this is how the "loss" algorithm works, and it's in the section defining the loss algorithm. Other algorithms could interpret Overload-Metric differently. (e.g. the previous example of a rate-limit algorithm treating it as max messages per second.)

The idea is that the mechanism in the draft is a framework that allows extensible algorithms.The previous sections talk about how the overload-metric AVP is an input into the agreed algorithm. 

That being said, there's almost always room for clarification, and we might could do something in the earlier sections like "Overload-Metric is an input into the negotiated overload-abatement algorithm. For example, in the "loss" algorithm [section X], Overload-Metric indicates a percentage traffic reduction"

> discovers that it is already compliant with the request.  And does nothing.

There's room for discussion as to whether "loss" is the best choice for the mandatory-to-implement algorithm. It has the advantage of being simple to implement, and has been shown to work well in other areas (e.g. SIP Overload). OTOH, I think a number of working group participants would prefer a rate-limit algorithm as the mandatory to implement.

In any case, algorithms are extensible. We can always add new ones as we get deployment experience.

---

From: Eric McMurry <[email-masked]>
Date: Thu, 25 Jul 2013 23:36:55 +0200

> It would be better (IMHO) to signal routing changes independent from

I'm still a bit lost here.  This signaling piggybacks directly in Diameter messages and doesn't define any link or transport protocols.  It does not signal link changes or routing changes.  Can you point me to the language in the draft that is giving that impression?

> I scanned it.  I'll take a deeper look.

understood.  It was a good review for a scan.  I wasn't complaining, just trying to answer your question.

> useful to describe both the data, and how the data is used.

There is more than one thing going on here.  I was talking about the load information used for proactive mitigation.  The document also describes overload control information which has more constraints on its usage.

> ??? OK, that's nice.  WHY is this being done?  What does it mean?

Does the text in 3.4 talking about proactive mitigation help with this?

> effect.  The second is simpler.

This depends entirely on the traffic mix and the number of clients.  In some cases it is true, in others (i.e. less bursty traffic, large numbers of clients, ...), it is not.  I don't disagree that rate based control would be better in many instances.  It requires more consideration for the types of use cases and topologies that are expected to be typical (similar to what happened in SIP overload as Janet pointed out).  Of course, either one may not be appropriate in some cases, which is why it's extensible.  Thanks for the vote on rate based.  I think there will be more discussion on this coming from several folks.