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

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Jul 2013 11:41:19 +0200

Dear authors,

Thanks for the two new draft version.

I still see two issues.

1.

      1.2
      <http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-09#section-1.2>.
      Causes of Overload

    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_.

    ...

    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.

I'm not discussing whether or not bandwidth is an overload cause, I note
a discrepancy in the definition.

  "A Diameter [RFC6733] node is said to be overloaded when it has
insufficient resources to successfully process all of the Diameter
requests that it receives."

If there is not enough bandwidth, the application-layer Diameter node
doesn't receive the Diameter requests. Therefore, it is not overloaded.

Now, there is a difference if you start to speak about a system overload
(for the lack of a better term) where the system is composed of client
and server. In that case, the "system" contains the link, and the
bandwidth limitation is a valid cause of system overload.

I hope I explained myself correctly.

2.
We discussed this text, and it seems that you forgot to include it.

         A element communicating via protocols other than Diameter that is
         also using a Diameter application needs to be able to signal to
         Diameter peers that it is experiencing overload regardless of the
         cause of the overload, since the overload will affect that
    element's
         ability to process Diameter transactions.
         The element may also need
         to signal this on other protocols depending on its function and
    the
         architecture of the network and application it is providing
    services
         for.  Whether that is necessary can only be decided within the
         context of that architecture and application.

    Proposal: An element that doesn't use Diameter exclusively
         needs to be able to signal to  Diameter peers that it is
    experiencing overload
         regardless of the cause of the overload, since the overload
    will affect that element's
         ability to process Diameter transactions. If the element
    communicates
         with other protocols than Diameter, it may also need
         to signal the overload situation on these protocols depending
    on its function and the
         architecture of the network and application it is providing
    services
         for.  Whether that is necessary can only be decided within the
         context of that architecture and use cases.

    Answer: I like your language in general and propose we incorporate
    it.  We had intended "application" to mean "an application (or use)
    of Diameter" rather than a "Diameter application", which seem to
    have unfortunately distinct meanings--better to avoid it entirely.

Regards, Benoit

---

From: Eric McMurry <[email-masked]>
Date: Tue, 16 Jul 2013 08:28:10 -0500

Thanks Benoit,

Comments inline.

Eric

On Jul 16, 2013, at 4:41 , Benoit Claise <[email-masked]> wrote:

> 1.2.  Causes of Overload
>    it is receiving.

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.

>     cause of the overload, since the overload will affect that element's 
>     to signal this on other protocols depending on its function and the 
>     architecture of the network and application it is providing services 
>     needs to be able to signal to  Diameter peers that it is experiencing overload 
>     regardless of the cause of the overload, since the overload will affect that element's 
>     ability to process Diameter transactions. If the element communicates 
>     to signal the overload situation on these protocols depending on its function and the 
>     architecture of the network and application it is providing services 
> Answer: I like your language in general and propose we incorporate it.  We had intended "application" to mean "an application (or use) of Diameter" rather than a "Diameter application", which seem to have unfortunately distinct meanings--better to avoid it entirely.

not sure how I missed that, but also my fault.  Thanks for catching.  I will fix that for the 10 version to be submitted as soon as the embargo lifts.

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Jul 2013 16:09:31 -0500

On Jul 16, 2013, at 8:28 AM, Eric McMurry <[email-masked]> wrote:

>> it is receiving
>> .

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?

[...]

Thanks!

Ben.

---

From: Benoit Claise <[email-masked]>
Date: Sun, 21 Jul 2013 16:00:49 +0200

> 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:

Then I took this sentence:

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 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

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.

Regards, Benoit

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Jul 2013 15:36:14 -0500

Hi Benoit,

Do I read correctly that this particular issue requires no further action?

A few more comments inline:

[...]

> I was able to narrow my source of confusion to a very specific point: what is an upstream diameter node?
>                                      Node                                             Node 
> 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.

>                                       Node                                             Node 
> (*) 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.

>                   (Missing AVP)           (Missing AVP)

No Problem--It seems like 6733 uses "upstream" and "downstream" differently than I am used to. (Same with "client" and "server").

Thanks!

Ben.

---

From: Benoit Claise <[email-masked]>
Date: Sat, 27 Jul 2013 17:36:48 +0200

Hi Ben,

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

> 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

---

From: Eric McMurry <[email-masked]>
Date: Mon, 29 Jul 2013 07:32:05 +0200

Hi Benoit,

done:

URL:             http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-10.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs
Htmlized:        http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-10
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-overload-reqs-10

Thanks again for your help with this.

Eric

On Jul 27, 2013, at 17:36 , Benoit Claise <[email-masked]> wrote:

> 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
>>