Subject: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 12:40:02 -0600

There has been no discussion of ticket #27.  I can't even find it on the
DIME list, so I'm copying it here to initiate discussion.

The proposal is for an agent to send a TOO-BUSY response when it
throttles a request from a non supporting client.  The behavior of the
agent in this case would be in the new section to be added to capture
agent behavior as proposed in issue #24 (and various other places).

Steve

-----

The specification is currently missing a definition of the behavior of
agents that are the reacting node for overload reports in the case that
the client does not support the DOIC extension.

We need to add wording that the agent will throttle messages from the
client by the percentage indicated by the reporting node. We need to
determine the error response that will be sent by the agent. Given that
the client does not support the extension, the error will need to be an
existing error -- most likely TOO-BUSY.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Feb 2014 17:11:47 -0600

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

> There has been no discussion of ticket #27.  I can't even find it on the DIME list, so I'm copying it here to initiate discussion.
> 
> The proposal is for an agent to send a TOO-BUSY response when it throttles a request from a non supporting client.  The behavior of the agent in this case would be in the new section to be added to capture agent behavior as proposed in issue #24 (and various other places).
> 

RFC6733 has the following to say about TOO_BUSY

"When returned, a Diameter node SHOULD attempt to send the message to an alternate peer.  This error MUST only be used when a specific server is requested, and it cannot provide the requested saervice."

Do those semantics and limitations apply to this usage? Is there a chance if incorrect behavior from a client that doesn't support DOIC, and therefore is not aware of this new usage of TOO_BUSY? For example, if an agent sends TOO_BUSY due due to a host OLR received from the an upstream server, the client might (actually SHOULD) try to reach that same server via an alternate agent. Is that okay?

I'm not sure I understand the original intent of the MUST only sentence. But the only way I know of to request a specific server is to use D-H. So would we allow the sending of a TOO_BUSY in response to a realm-routed request?

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 20:22:49 -0600

It looks like DIAMETER-TOO-BUSY fits best for requests throttled because 
of a Realm-Routed-Request (RRR) overload report handled by an agent.

The only other option I see for agent handling of host overload reports 
is DIAMETER_UNABLE_TO_COMPLY.

    DIAMETER_UNABLE_TO_COMPLY 5012

       This error is returned when a request is rejected for unspecified
       reasons.

This is the behavior definition:

If the service cannot be
    provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
    message MUST be sent within the accounting request; a Diameter client
    receiving an authorization response for a service that it cannot
    perform MUST NOT substitute an alternate service and then send
    accounting requests for the alternate service instead.

Or we could use DIAMETER_UNABLE_TO_DELIVER

  DIAMETER_UNABLE_TO_DELIVER 3002

       This error is given when Diameter cannot deliver the message to
       the destination, either because no host within the realm
       supporting the required application was available to process the
       request or because the Destination-Host AVP was given without the
       associated Destination-Realm AVP.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Feb 2014 20:41:16 -0600

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

> It looks like DIAMETER-TOO-BUSY fits best for requests throttled because of a Realm-Routed-Request (RRR) overload report handled by an agent.

I'm confused. I interpreted 6733 to explicitly forbid DIAMETER_TO_BUSY for realm routed requests: 

"This error MUST only be used when a specific server is requested..."

What am I missing? (Yes, I recognize "... when a specific server is requested..." is vague.)

> 
> The only other option I see for agent handling of host overload reports is DIAMETER_UNABLE_TO_COMPLY.  

This seems closer to the right semantics for RRRs.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Feb 2014 15:50:59 +0000

Steve, Ben, all,

In my opinion, I think DIAMETER_TOO_BUSY is closer to our purpose.
I find a similarity between a single server getting overloaded (request is routed using specific server, not a realm) and returning back TOO_BUSY, and a Realm getting overload and returning back TOO_BUSY. The reason is the same, the expected "destination" (either one specific host, or whole realm) is not able to serve the request.

Regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: martes, 25 de febrero de 2014 3:41
To: Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC

> Or we could use DIAMETER_UNABLE_TO_DELIVER  DIAMETER_UNABLE_TO_DELIVER 
> 3002
> 

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

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 19:46:10 +0200

Ben,

> "When returned, a Diameter node SHOULD attempt to send the message to an alternate peer.  This error MUST only be used when a specific server is requested, and it cannot provide the requested saerv…

"when a specific server is requested" means the use of Destination-Host to me.

> Do those semantics and limitations apply to this usage? Is there a chance if incorrect behavior from a client that doesn't support DOIC, and therefore is not aware of this new usage of TOO_BUSY? Fo…

I would say this could be a desired behaviour but I am not sure
whether it is okay. DIAMETER_TOO_BUSY is a protocol error, which
means an error-answer, which again probably is completely different
what the server sent (in the above example). Although this is allowed
(see the usage of Error-Reporting-Host AVP) but then RFC 6733 Section
6.2.2. MUST on sending STR to the server does not really fit our use
case.

A client knows from the Origin-Host & Error-Reporting-Host whether the
error came from the final destination or from an intermediate. It can
reason based that whether it needs to find a new server or just an
alternate path.

> I'm not sure I understand the original intent of the MUST only sentence. But the only way I know of to request a specific server is to use D-H. So would we allow the sending of a TOO_BUSY in respon…

I would think twice updates to RFC6733. But if seen necessary,
I would do that in a separate I-D.

- Jouni