Re: [Dime] AD review: draft-ietf-dime-overload-reqs version 9

[Benoit Claise <[e-mail]>]

Hi Ben,

[not sure if that email was actually sent. Resending]

> Hi Benoit,
>
> Do I read correctly that this particular issue requires no further action?
I checked with the document shepherd, and you are right. No further 
action required on this issue.
Please post a draft with the other agreed changes, and I'll progress the 
document

Regards, Benoit
>
> A few more comments inline:
>
> On Jul 21, 2013, at 9:00 AM, Benoit Claise <[e-mail]> wrote:
>
>> On 19/07/2013 23:09, Ben Campbell wrote:
> [...]
>
>>> On Jul 16, 2013, at 8:28 AM, Eric McMurry <[e-mail]>
>>>   wrote:
>>>
>>>> ah, thanks for catching that.  Ben and I had been discussing this but I see responding to it was lost in the shuffle.  My apologies.
>>>>
>>>> The definition uses the term resources, which could include a number of things.  For the case where insufficient bandwidth would prevent overload, I think that would only be true for a very simple topology.  With multiple connections to multiple elements, agents, shared backend resources, or any other more complex topologies, bandwidth issues could indeed manifest into overload issues that meet the definition.
>>>>
>>>> I suspect that I am not understanding your point fully though.  Perhaps Ben can take a stab if I am not making sense.
>>>>
>>>>
>>> I think the issue may be that we never meant for "resources" to necessarily mean "local resources". For example, an agent could itself become overloaded because it's not getting responses from an upstream server. This could be simple because the downstream view of the server appears overloaded in aggregate to downstream clients. (This is very close to your idea of "system" overload, I think.) But the agent could also suffer truly local overload due to queues or memory filling up, the need to retransmit requests, etc.
>>>
>>> For the non-agent case, a server might depend on a remote database. If network congestion causes responses from the database server to be lost or slow down, the Diameter server can become overloaded.
>>>
>>> Would it help if we added a note to point out that the mentioned "resources" do not necessarily have to be local to the Diameter node?
>>>
>> I was able to narrow my source of confusion to a very specific point: what is an upstream diameter node?
>> I took this "overload" definition:
>>     Overload occurs when an element, such as a Diameter server or agent,
>>     has insufficient resources to successfully process all of the traffic
>>
>> it is receiving.
>> Then I took this sentence:
>>     External resources can include upstream Diameter nodes; for example,
>>     a Diameter agent can become effectively overloaded if one or more
>>     upstream nodes are overloaded.  While overload is not the same thing
>>     as network congestion, network congestion can reduce a Diameter nodes
>>     ability to process and respond to requests, thus contributing to
>>     overload.
>>
>> In my mind, I saw a picture like this:
>>
>>                                        Overloaded
>>                                        Upstream
>>                                        Diameter                                      Diameter
>>                                       Node                                             Node
>>           -------------------->---------X
>>                        request
>>
>> So I was thinking: the Diameter node (on the right, on the drawing) didn't receive the request. So according to the definition, it can't be overloaded.
> I agree that the node on the right is not overloaded in this example. But if the one on the left is an agent, the fact that transactions are failing between it and the node on the right may reduce it's ability to handle inbound requests from clients.
>
>> I guess that you had a picture like this in mind.
>>                                                                                              Overloaded
>>                                                                                              Upstream
>>                                        Diameter                                      Diameter
>>                                        Node                                             Node
>>                                                    --------------------> request
>>                                                                                     X<----------   (*)
>>
>> (*) the reply never arrived because the Overloaded Upstream Diameter Node is well ... overloaded
> That is one possible case. A particularly bad one, even, since the node on the left is likely to start retrying requests.
>
> Another example would be when a node depends on a non-Diameter remote resource. Imagine the same picture as the previous one, but the node on the right is a database server. If there's network congestion between the Diameter node and the database server, the Diameter node may not be able to operate at normal capacity.
>
>> After checking  "Upstream" in RFC 6733, we're should be fine.
>>
>>    Figure 7 provides an example of a message forwarded upstream by a
>>     Diameter relay.
>>
>>         +---------+ 1. Request  +---------+ 2. Request  +---------+
>>         | Access  |------------>|Diameter |------------>|Diameter |
>>         |         |             |         |             |  Home   |
>>         | Device  |<------------|  Relay  |<------------| Server  |
>>         +---------+  4. Answer  +---------+  3. Answer  +---------+
>>                    (Missing AVP)           (Missing AVP)
>>
>> My confusion. sorry.
> No Problem--It seems like 6733 uses "upstream" and "downstream" differently than I am used to. (Same with "client" and "server").
>
> Thanks!
>
> Ben.
>
>
>