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

[Steve Donovan <[e-mail]>]

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

On 2/26/14 4:03 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> 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:[e-mail]] De la part de Ben Campbell
> Envoyé : mardi 25 février 2014 20:23
> À : Steve Donovan
> Cc : [e-mail]
> Objet : Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>
> On Feb 25, 2014, at 1:03 PM, Steve Donovan <[e-mail]> 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".)
>
>> Steve
>>
>>
>> On 2/25/14 12:51 PM, Ben Campbell wrote:
>>> 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.
>>>
>>> On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) 
>>> <[e-mail]>
>>>  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:[e-mail]
>>>> ]
>>>> Sent: Tuesday, February 25, 2014 2:12 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; 
>>>> [e-mail]; [e-mail]
>>>>
>>>> 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
>>>>
>>>> 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:[e-mail]
>>>> ] On Behalf Of ext Steve Donovan
>>>> Sent: Monday, February 24, 2014 8:31 PM
>>>> To: Maria Cruz Bartolome;
>>>> [e-mail]; [e-mail]
>>>>
>>>> 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.  
>>>>
>>>> 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
>>>>
>>>> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>>>> Steve,
>>>>  
>>>> See some comments below please.
>>>> /MCruz
>>>>  
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:[e-mail]
>>>> ] On Behalf Of dime issue tracker
>>>> Sent: lunes, 24 de febrero de 2014 17:20
>>>> To: 
>>>> [e-mail]; [e-mail]
>>>>
>>>> Cc: 
>>>> [e-mail]
>>>>
>>>> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload 
>>>> report type
>>>>  
>>>> #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.
>>>> [MCruz] This can only happen if the agent has miscalculated the realm overload.
>>>>  
>>>>  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.
>>>> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>>>>  
>>>>  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.
>>>>  
>>>>  
>>>>  
>>>>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>