Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

From: "dime issue tracker" <[email-masked]>
Date: Mon, 24 Feb 2014 16:19:33 -0000

#57: Handling of "Realm-Routed" Overload report type

 I'm assuming the name of the realm overload report in the -01 version will
 be changed to realm-routed.  This issue applies independent of the actual
 name of the report.

 The current behavior assumed for the realm-routed report is that the
 reacting node, generally the client, will reduce the percentage of realm
 routed requests sent to the reporting node.

 This is actually bad behavior and could result in the client throttling
 traffic that could have been handled by the full set of servers for that
 Diameter application.

 Consider the case where there are n servers for a Diameter application and
 all of those server are able to handle any transaction for that
 application.

 When one of those servers becomes overloaded and wishes to decrease the
 number of new sessions, the primary use of realm-routed requests.  The
 server will generate an OLR of type realm-routed.

 Assume in this case that the other servers are all healthy and able to
 handle new sessions.

 Clients will not have the knowledge that there are other servers in the
 network able to handle the new session and will have no choice but the
 throttle a percentage of the new session requests.  Even when these
 throttled requests could have been handled by any of the non overloaded
 servers.

 The proposal is to specify that realm-routed reports must be handled by
 DOIC-supporting agents.  Agents will understand if there are other servers
 able to handle the new session and, if so, can adjust the percentage of
 requests routed to the overloaded server.

 Agents that handle the realm-routed OLR must remove the request from the
 answer before relaying the answer to client.  This prevents the report
 from being acted on by either multiple agents (if multiple are in the
 path) or by an agent and a client.

 Clients that receive the realm-routed OLR must handle the OLR by
 throttling the requested percentage.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-docdt-dime-
  [email-masked]           |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-docdt-dime-ovli    |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/57>
dime <http://tools.ietf.org/wg/dime/>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 18:51:38 +0000

Steve,

See some comments below please.
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of dime issue tracker
Sent: lunes, 24 de febrero de 2014 17:20
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

 This is actually bad behavior and could result in the client throttling
 traffic that could have been handled by the full set of servers for that
 Diameter application.
[MCruz] This can only happen if the agent has miscalculated the realm overload.

 When one of those servers becomes overloaded and wishes to decrease the
 number of new sessions, the primary use of realm-routed requests.  The
 server will generate an OLR of type realm-routed.
[MCruz] I do not agree. Servers do not generate Realm-routed reports.

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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 13:31:13 -0600

Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of
the meaning of realm-routed-request report (new attempt at a name to try
to make Ulrich happy :-) ).

My definition is that it is a report generated by the server when the
server does not want to receive new sessions. 

Your definition appears to be that it is a report generated by an agent
(or a server is there are no agents in the network?) to indicate that
the network need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can
generate a realm-routed-request report without knowing the status of
servers and their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based
applications.  This could also be applied to pseudo session based
applications and applications that always rely on realm routed requests.

Everyone, which definition applies?

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Feb 2014 14:28:57 -0600

On Feb 24, 2014, at 1:31 PM, Steve Donovan <[email-masked]> wrote:

> Maria Cruz,
> 
> Thanks for the comments.  We obviously have a different understanding of the meaning of realm-routed-request report (new attempt at a name to try to make Ulrich happy :-) ).
> 
> My definition is that it is a report generated by the server when the server does not want to receive new sessions.  
> 
> Your definition appears to be that it is a report generated by an agent (or a server is there are no agents in the network?) to indicate that the network need to handle fewer new sessions.
> 
> I actually think both cases apply but I don't think that an agent can generate a realm-routed-request report without knowing the status of servers and their ability to handle new Diameter sessions.
> 

The version I had in mind from way back could be sent by either, but would apply to all realm-routed requests for the _realm_, regardless of which server would finally get it. This is easy enough if the agent generates it. It's harder if a server generates it, since that server would need full knowledge of the realm. But we should not forbid that possibility.

To my knowledge, we have not defined a way for a server to say "reduce new session requests to _me_, but let other servers speak for themselves." That would require either a new report type, or an AVP to indicate the special treatment (which, btw, would start to approach the idea of "scopes" ;-) )

> Note that I'm discussing this in the context of session-based applications.  This could also be applied to pseudo session based applications and applications that always rely on realm routed requests.
> 

I agree, but will go further to say it applies to any realm-routed requests (that is, requests with no Destination-Host AVP present) for the associated application, but in an application-independent way.  Or more to the point, the set of [session-oriented applications, pseudo-session oriented applications, non-session oriented applications] is the same as the set of [applications].

>> From: DiME [
>> mailto:[email-masked]
>> ] On Behalf Of dime issue tracker
>> To: 
>> [email-masked]; [email-masked]
>> 
>> Cc: 
>> [email-masked]
>>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 07:50:52 +0000

Hi,
I agree with MCruz.

Principle is that the server never sends OLRs with a report type of realm-routed-request (exept the case where the server knows (i.e.is configured) that there is no other server in that realm).

Only agents that are configured to take the role of a reporting node for a realm will insert OLRs with report type of realm-routed-requests into answer messages and the content should be the aggregation of percentages as received in host type OLRs from all the servers in the realm.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

Maria Cruz,

Steve

Steve,

/MCruz

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

 name of the report.

 Diameter application.

 application.

 handle new sessions.

 servers.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 07:11:56 -0600

How do agents learn about a set of servers ability to handle new
sessions (host-less requests) if servers never sent realm-routed-request
reports?

I agree that agents should sent to aggregated report but the servers
need to send RRR reports so the agent can route around them and generate
those aggregated reports.

Steve

On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Hi,
>
> I agree with MCruz.
>
>  
>
> Principle is that the server never sends OLRs with a report type of
> realm-routed-request (exept the case where the server knows (i.e.is
> configured) that there is no other server in that realm).
>
>  
>
> Only agents that are configured to take the role of a reporting node
> for a realm will insert OLRs with report type of realm-routed-requests
> into answer messages and the content should be the aggregation of
> percentages as received in host type OLRs from all the servers in the
> realm.
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, February 24, 2014 8:31 PM
> *To:* Maria Cruz Bartolome; [email-masked];
> [email-masked]
> *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload
> report type
>
>  
>
> Maria Cruz,
>
> Thanks for the comments.  We obviously have a different understanding
> of the meaning of realm-routed-request report (new attempt at a name
> to try to make Ulrich happy :-) ).
>
> Your definition appears to be that it is a report generated by an
> agent (or a server is there are no agents in the network?) to indicate
> that the network need to handle fewer new sessions.
>
>     To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>
>     Cc: [email-masked] <mailto:[email-masked]>
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 14:18:19 +0000

My understanding is that RRR reports are always aggregated reports. Agents generating an RRR report (for use on the DOIC association towards the reacting node) take as an input the host-type reports received on the DOIC associations with the servers.

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, February 25, 2014 2:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

How do agents learn about a set of servers ability to handle new sessions (host-less requests) if servers never sent realm-routed-request reports?

I agree that agents should sent to aggregated report but the servers need to send RRR reports so the agent can route around them and generate those aggregated reports.

Steve

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

Maria Cruz,

Steve

Steve,

/MCruz

-----Original Message-----

 name of the report.

 Diameter application.

 application.

 handle new sessions.

 servers.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 08:23:21 -0600

I'm not comfortable with this model that assumes that agents have a
better understanding then servers on the servers ability to handle new
sessions.

Are you also saying that RRRs can never be sent if an agent is not in
the network? 

RRRs are a way to control a specific type of request, generally requests
that create new sessions, recognizing that those requests are more
expensive than what we have referred to as mid-session requests.

Yes, agents should be able to create aggregated RRR reports but servers
should be able to send them as well.

Steve

On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> My understanding is that RRR reports are always aggregated reports.
> Agents generating an RRR report (for use on the DOIC association
> towards the reacting node) take as an input the host-type reports
> received on the DOIC associations with the servers.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:[email-masked]]
> *Sent:* Tuesday, February 25, 2014 2:12 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome;
> [email-masked]; [email-masked]
> sessions (host-less requests) if servers never sent
> realm-routed-request reports?
>
> need to send RRR reports so the agent can route around them and
> generate those aggregated reports.
>
> Steve
>
>     Principle is that the server never sends OLRs with a report type
>     of realm-routed-request (exept the case where the server knows
>     (i.e.is configured) that there is no other server in that realm).
>
>      
>
>     Only agents that are configured to take the role of a reporting
>     node for a realm will insert OLRs with report type of
>     realm-routed-requests into answer messages and the content should
>     be the aggregation of percentages as received in host type OLRs
>     from all the servers in the realm.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>      
>
>      
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>     Steve Donovan
>     *To:* Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]>;
>     <mailto:[email-masked]>
>     *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed"
>     Overload report type
>
>      
>
>     Maria Cruz,
>
>     Thanks for the comments.  We obviously have a different
>     understanding of the meaning of realm-routed-request report (new
>     attempt at a name to try to make Ulrich happy :-) ).
>
>     My definition is that it is a report generated by the server when
>     the server does not want to receive new sessions. 
>
>     agent (or a server is there are no agents in the network?) to
>     indicate that the network need to handle fewer new sessions.
>
>     I actually think both cases apply but I don't think that an agent
>     can generate a realm-routed-request report without knowing the
>     status of servers and their ability to handle new Diameter sessions.
>

---

From: <[email-masked]>
Date: Tue, 25 Feb 2014 14:24:33 +0000

The general idea is that a reduction is required. This reduction is either towards a specific host or towards the entire realm. Obviously, the realm is equal to the some of the servers inside this realm (for a given application) and the realm reduction is equal to the average of the reduction of each server. I think it was what we have described when discussing the report types needed in the OLR.
Which entity is sending this info is not so relevant. Usually, it will be an agent in front of the realm but it could be also a server when this server is aware of the overload state of other servers in the realm.

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 25 février 2014 15:23
À : Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; [email-masked]; [email-masked]
Objet : Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

I'm not comfortable with this model that assumes that agents have a better understanding then servers on the servers ability to handle new sessions.

Are you also saying that RRRs can never be sent if an agent is not in the network?

RRRs are a way to control a specific type of request, generally requests that create new sessions, recognizing that those requests are more expensive than what we have referred to as mid-session requests.

Yes, agents should be able to create aggregated RRR reports but servers should be able to send them as well.

Steve

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, February 25, 2014 2:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

Steve

Ulrich

Maria Cruz,

Steve

Steve,

/MCruz

-----Original Message-----

 name of the report.

 Diameter application.

 application.

 handle new sessions.

 servers.

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 15:36:44 +0000

I don't think that it is the presence/absence of destination-host in a request that determines whether a session is new.

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, February 25, 2014 3:23 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

Steve

Ulrich

Steve

Ulrich

Maria Cruz,

Steve

Steve,

/MCruz

-----Original Message-----

 name of the report.

 Diameter application.

 application.

 handle new sessions.

 servers.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 10:23:21 -0600

Ulrich,

You of course are correct in the general sense.  There are, however,
many examples where the initial request is sent without the
destination-host and subsequent requests are sent with.

I do admit to over generalizing.  The basic argument is still the same,
there are applications where requests that do not have a
destination-host use that for routing the request that creates the
session on one of a group of servers.  The destination-host is then used
to route subsequent session-associated requests to the correct server. 
The session creating requests represent more work than
session-associated requests and it is thus a valid overload management
strategy to push back on those before pushing back on session-associated
requests.

Steve

On 2/25/14 9:36 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> I don't think that it is the presence/absence of destination-host in a
> request that determines whether a session is new.
>
>  
>
>  
>
> *Sent:* Tuesday, February 25, 2014 3:23 PM
> RRRs are a way to control a specific type of request, generally
> requests that create new sessions, recognizing that those requests are
> more expensive than what we have referred to as mid-session requests.
>
> Yes, agents should be able to create aggregated RRR reports but
> servers should be able to send them as well.
>
> Steve
>
>     My understanding is that RRR reports are always aggregated
>     reports. Agents generating an RRR report (for use on the DOIC
>     association towards the reacting node) take as an input the
>     host-type reports received on the DOIC associations with the servers.
>
>      
>
>     Ulrich
>
>      
>
>     [email-masked] <mailto:[email-masked]>;
>     I agree that agents should sent to aggregated report but the
>     servers need to send RRR reports so the agent can route around
>     them and generate those aggregated reports.
>
>     Steve
>
>         Principle is that the server never sends OLRs with a report
>         type of realm-routed-request (exept the case where the server
>         knows (i.e.is configured) that there is no other server in
>         that realm).
>
>          
>
>         Only agents that are configured to take the role of a
>         reporting node for a realm will insert OLRs with report type
>         of realm-routed-requests into answer messages and the content
>         should be the aggregation of percentages as received in host
>         type OLRs from all the servers in the realm.
>
>          
>
>         Ulrich
>
>          
>
>          
>
>          
>
>          
>
>         *To:* Maria Cruz Bartolome; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         understanding of the meaning of realm-routed-request report
>         (new attempt at a name to try to make Ulrich happy :-) ).
>
>         My definition is that it is a report generated by the server
>         when the server does not want to receive new sessions. 
>
>         Your definition appears to be that it is a report generated by
>         an agent (or a server is there are no agents in the network?)
>         to indicate that the network need to handle fewer new sessions.
>
>         I actually think both cases apply but I don't think that an
>         agent can generate a realm-routed-request report without
>         knowing the status of servers and their ability to handle new
>         Diameter sessions.
>
>         applications.  This could also be applied to pseudo session
>         based applications and applications that always rely on realm
>         routed requests.
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Feb 2014 12:51:34 -0600

I think that both models are reasonable deployments. Our definitions of HRR and RRR should support both approaches. I say this with the caveat that, if a server sends an RRR report, it is claiming authoritative knowledge of all servers in the realm.

Agents sending reports to clients can take _any_ input they want to. That could be host reports from servers, RRR reports from servers, Diameter errors, transport errors, and any number of proprietary methods.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Feb 2014 12:55:59 -0600

On Feb 25, 2014, at 9:36 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> I don’t think that it is the presence/absence of destination-host in a request that determines whether a session is new.

That's absolutely true. But that presence or absence _does_ effect request routing, and by extension, the set of requests that become candidates for overload abatement.

But I agree that the absence destination-host is a poor proxy for determining whether a request will create a session. That's application (and deployment) specific. Our definitions of host and RRR reports should be application independent.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Feb 2014 13:00:52 -0600

On Feb 25, 2014, at 10:23 AM, Steve Donovan <[email-masked]> wrote:

> Ulrich,
> 
> You of course are correct in the general sense.  There are, however, many examples where the initial request is sent without the destination-host and subsequent requests are sent with.

I don't think you can depend on that. Diameter allows you to insert a Destination-Host avp anytime you think a request needs to be handled by a particular server. Unless an application forbids it, that means any given implementation/deployment could decide to put a Destination-Host in an "initial" request. If doing that breaks treatment of the report types, then we need to normatively forbid it, or adjust around the possibility.

> 
> I do admit to over generalizing.  The basic argument is still the same, there are applications where requests that do not have a destination-host use that for routing the request that creates the session on one of a group of servers.  The destination-host is then used to route subsequent session-associated requests to the correct server.  The session creating requests represent more work than session-associated requests and it is thus a valid overload management strategy to push back on those before pushing back on session-associated requests.
> 

I think that, if we want to be able to request downstream nodes to reduce new session requests, but not reduce mid-session requests, we need to explicitly indicate that, and not try to infer that from realm-routing vs host-routing Explicit indication could take the form of a new report type, or some markup in an existing report type.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 13:03:42 -0600

Ben,

I'm asserting that there are valid use cases (3GPP PCC for one) for a
server sending a RRR that only impacts realm routed requests being sent
to that server.  This is different than a RRR that reports on all realm
routed requests sent to any server in the realm.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Feb 2014 13:22:53 -0600

On Feb 25, 2014, at 1:03 PM, Steve Donovan <[email-masked]> wrote:

> Ben,
> 
> I'm asserting that there are valid use cases (3GPP PCC for one) for a server sending a RRR that only impacts realm routed requests being sent to that server.  This is different than a RRR that reports on all realm routed requests sent to any server in the realm.

Then that is something different than they way I expected RRR reports (and I assume others) expected them to be used, and I think it would give incorrect behavior for other use cases. (1)

For example, lets assume a client knows about (either through configuration or dynamic discovery) two next hop destinations (A and B)  that can handle the Foo realm for a given application. It, at least initially, has no idea if those destinations are agents or servers. If that client receives an RRR OLR from A, is it allowed (or even expected)  to shift load to B? My intent for the RRR report type, based on our early discussions of the mixed-state scenario, was no. But I think the way you describe it, the answer would be yes.

I think we are talking about two distinct use cases. One is reporting overload that impacts the entire pool of servers that handle a particular realm+application. Another is is to allow reporting of overload that is created due to some number-of-session constrained resource. I agree both use cases are interesting, and potentially needed. But I don't think a single report type, without further modification, can handle both use cases. 

I also think a single host could be session-constrained, and a pool of servers handling a realm could become session constrained. That suggests we need a way of saying "reduce (new) sessions" that can work for both host and RRR reports. That could be a separate algorithm, or some markup that says "please reduce sessions".  

(1) To some degree, I think we are suffering from our choice to use report-types to distinguish these sort of semantics, rather than the scope concept in the Roach draft. The fundamental difference is an OLR could combine multiple scopes (e.g. "new session for realm Foo at host A"  , but can only have one type. (e.g. "realm foo" or "host a".)

>> On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>> From: ext Steve Donovan [
>>> mailto:[email-masked]
>>> ] 
>>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; 
>>> ] On Behalf Of ext Steve Donovan
>>> To: Maria Cruz Bartolome;

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Feb 2014 10:03:49 +0000

Dear all

About this thread, I am in line with Ulrich and Mcruz comments that realm OLRS are generated  by DOICs DAs dealing with realm, overload.
Regarding Lionel comment that a server, aware of the overload  of other servers, can generate a realm OLR, in fact in this case  the node supports the server functional entity  and a DA  functional entity addressing realm overload. This is common for implementations to do such integrations (eg in 3GPP) but it does not change the content of a functional entity 

Regarding Steve concern, I think (as Ben) this is a new requirement where server would like to drive the behavior of a client on the type of requests. My current understanding is that the server indicates an overload and then this is to the client (and to the DA acting on realm requests) to decide on what is throttled/rerouted and this is quite application dependent. Personally, I do not yet see the need for such a server requirement. 

So this is a new extension to investigate later (including the requiremnt or this extension)) and outside of our currents scope for the baseline draft.

Best regards

Jacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 25 février 2014 20:23
À : Steve Donovan
Cc : [email-masked]
Objet : Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

>>>  I'm assuming the name of the realm overload report in the -01 
>>> version will  be changed to realm-routed.  This issue applies 
>>> independent of the actual  name of the report.
>>>  
>>>  The current behavior assumed for the realm-routed report is that 
>>> the  reacting node, generally the client, will reduce the percentage 
>>> of realm  routed requests sent to the reporting node.
>>>  
>>>  This is actually bad behavior and could result in the client 
>>> throttling  traffic that could have been handled by the full set of 
>>> servers for that  Diameter application.
>>>  Consider the case where there are n servers for a Diameter 
>>> application and  all of those server are able to handle any 
>>> transaction for that  application.
>>>  
>>>  When one of those servers becomes overloaded and wishes to decrease 
>>> the  number of new sessions, the primary use of realm-routed 
>>> requests.  The  server will generate an OLR of type realm-routed.
>>>  Assume in this case that the other servers are all healthy and able 
>>> to  handle new sessions.
>>>  
>>>  Clients will not have the knowledge that there are other servers in 
>>> the  network able to handle the new session and will have no choice 
>>> but the  throttle a percentage of the new session requests.  Even 
>>> when these  throttled requests could have been handled by any of the 
>>> non overloaded  servers.
>>>  
>>>  The proposal is to specify that realm-routed reports must be 
>>> handled by  DOIC-supporting agents.  Agents will understand if there 
>>> are other servers  able to handle the new session and, if so, can 
>>> adjust the percentage of  requests routed to the overloaded server.
>>>  
>>>  Agents that handle the realm-routed OLR must remove the request 
>>> from the  answer before relaying the answer to client.  This 
>>> prevents the report  from being acted on by either multiple agents 
>>> (if multiple are in the

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Feb 2014 06:59:29 -0600

I'm ok with taking the feature that allows a server to control the rate
of new session requests into a separate extension draft.  I was
attempting to solve that problem with the RRR report and that doesn't
quite fit.

I'm also OK with leaving the definition of the RRR Ben outlined it in
previous emails.  It is an overload report that is realm wide in scope
and can be sent by any Diameter node that understands the realm overload
status. 

I will admit that I see limited value of the RRRs because the ability to
control realm wide overload with them is different per application and
is complicated.

The better way of controlling the traffic to the realm as a whole is to
support a true realm overload report as proposed in ticket #55.

Steve