[Dime] Fwd: Feedback on overload set of docs

[Hannes Tschofenig <[e-mail]>]

Hi all, 

I asked Sebastien to provide feedback about the overload documents I recently submitted to the working group to determine how difficult it would be to implement them in freeDiameter. Sebastien is the person behind freeDiameter (as most of you know). 

Ciao
Hannes

> From: ext Sebastien
> Sent: 7/21/2013 17:35
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Subject: Feedback on overload set of docs
> 
> Hi Hannes,
> 
> I have read the set of documents for overload 
> (draft-ietf-dime-overload-reqs-07, 
> draft-tschofenig-dime-overload-arch-00, draft-tschofenig-dime-dlba-00, 
> draft-tschofenig-dime-overload-piggybacking-00)
> 
> Concerning the load-balancing application, it should be quite 
> straight-forward to implement this. There are already some metrics 
> available in freeDiameter to get a hint of the current load, and there 
> is also all the support in freeDiameter to implement any load-balancing 
> algorithm you like. I even have an example of a load-balancing 
> application [1] that is based on the load of the different backend 
> servers (but measured by the number of pending requests for those 
> servers, not by information received remotely). Note that for the part 
> about PPID, you'd have to change some code in the lower layer of 
> freeDiameter, as such control is not provided through the normal API of 
> the framework (at the moment at least).
> 
> The requirements document distinguish between the "global" load of a 
> Diameter node (let's call this Base Protocol Load) and a specific 
> application load. All the metrics I have in freeDiameter concern only 
> the base protocol load. If a specific application wanted to use some 
> mechanism to report its own load, it would have to implement this logic 
> itself. One the other hand, I don't see how your DLBA fits with this 
> requirement either...
> 
> ...I guess your plan is to address this with the piggybacked AVPs in the 
> application's messages. Note that for this piggy-backed mechanism, I do 
> not really see the value of the "Supported-Feature" AVP: it is not 
> important for the client to signal the support of the mechanism to the 
> server, as it can ignore the piggybacked AVPs anyway if it does not 
> understand them.
> 
> For implementing the piggybacking, it is easy to add an AVP to a 
> message, but it is more difficult to know when / where to do it. Today 
> all the applications provided in freeDiameter consume the requests 
> synchronously, so their load state directly matchs the "base protocol 
> load" (i.e. as soon as one application becomes overloaded, the complete 
> node is overloaded). If you want to have an application-specific load, 
> you need to "consume" quickly the request received by your application 
> callback and just store it for asynchronous processing. Then your 
> application load state will be the status of this asynchronous 
> processing queue. This requires some additional logic, and I do not have 
> any example available publicly at the moment -- although I know some 
> users have implemented such logic successfully already.
> 
> I hope this answers your question :-)
> 
> I have some additional comments on 
> http://tools.ietf.org/html/draft-tschofenig-dime-overload-arch-00 (just 
> FYI, feel free to ignore those)
> 
> 3. Architectural Principles:
> I don't understand the issue with rejecting Requests ("requires 
> signaling to the Diameter clients") => this is exactly the same as when 
> the authentication fails for example. Today when I try to use my phone 
> during new year's eve, the call just fails, I don't receive a status 
> that the network is too busy (and I would not care). The information 
> that it is failing because of overload is only useful to the Diameter 
> nodes that could take a corrective action, such as sending to another 
> backend. As you know Diameter base protocol already has a status 
> DIAMETER_TOO_BUSY. An agent that receives this status can choose to 
> resend the request to another backend or forward the error to the 
> client. A Diameter client that receives this error can treat it is the 
> same way as a failure to authenticate, since it is an error, and just 
> deny the access to the user -- and an error message can be included as 
> well in the Diameter answer, that can be forwarded to the connecting device.
> 
> 5.2.3. Overload AVP.
> I am not sure "increasing overload" and "decreasing overload" makes any 
> sense. You can quantify the load, e.g. from 0% to 100%, then you are in 
> overload state where the Diameter server is not able to handle any new 
> request until it has processed the previous ones (because there is a 
> resource shortage). That's consistent with your Load AVP from 0 to 10. 
> Or, we have a different definition for Overload state, that I am not 
> familiar with.
> 
> In freeDiameter, the situation is as follow:
> - a given server has a given processing capability, resulting in a given 
> maximum throughput (the limit).
> - if the messages are incoming with a rate lower than this limit, 
> everything is well.
> - when there is a burst of messages that goes over the limit rate, the 
> messages start to be queued and the processing is slightly delayed. The 
> more the queue length increases, the more the messages are delayed.
> - there is a limit to the maximum length of the queue in freeDiameter, 
> once this limit is reached the framework does not read from the network 
> socket until the next message is processed -- the lower layer congestion 
> control will then start to kick in.
> - when I measure the "load" of the framework, it is the length of the 
> queue. I know I am overloaded if the length is equal to the maximum for 
> the queue.
> 
> 
> I am also not sure that the Overload information can be useful for the 
> Diameter client (when you write: "The increase and decrease of the 
> sending rate refers to new requests to the same realm and the same 
> application ID as the message carrying the overload information."). In 
> some real-life setups I have seen, the requests are dispatched by an 
> agent to different backends in the same realm depending on for e.g. the 
> User-Name (some users having been migrated to a new server). So, even if 
> one backend is overloaded, it does not mean that the complete realm 
> cannot answer anymore. Do you expect an agent to intercept this AVP in 
> such situation?
> 
> [1] rt_load_balance extension. The complete code takes less than 100 
> lines with comments: 
> http://www.freediameter.net/hg/freeDiameter-proposed/file/e72c9dad62ac/extensions/rt_load_balance/rt_load_balance.c
> 
> Cheers,
> Sebastien.
>