Subject: [Dime] Proposal for error response wording (issue 85)

From: Steve Donovan <[email-masked]>
Date: Mon, 20 Oct 2014 12:49:29 +0200

We came to the following agreements on error responses:

- Servers rejecting a Diameter request due to an overload condition 
should send a 3002 DIAMETER_TOO_BUSY error response.

- Agents rejecting a Diameter request due to an overload condition 
should send a 5012 DIAMETER_UNABLE_TO_COMPLY.

I propose that we generalize this to the following:

- Reporting nodes rejecting a Diameter request due to an overload 
condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response.

- Reacting nodes rejecting a Diameter request due to an overload 
condition SHOULD send a UNABLE-TO-COMPLY.

This would mean that an agent acting as a reporting node (i.e.; server 
doesn't support DOIC or agent is acting as a server front end) would 
sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; 
a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response.

I propose adding this to a new section 4.2.4.  The existing 4.2.4 on 
agent behavior will be deleted.

I will hold off making this change until tomorrow (Tuesday morning).

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2014 12:10:17 -0500

I agree that we should generalize these, but I think the direction is not quite right. More inline:

> On Oct 20, 2014, at 5:49 AM, Steve Donovan <[email-masked]> wrote:
> 
> - Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response.
> 
> - Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY.
> 
> - Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response.
> 
> - Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY.

I don't think we should state this in terms of reaction and reporting nodes. I think we should generalize to expected behavior. Also, in the case where the downstream node does not support DOIC, I'm not sure it makes sense to say the throttling node is really a reporting node (for that particular relationship.)

My suggestion is we say that, if the throttling node has sufficient information to determine that the request is not likely to succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that information, it SHOULD send TOO-BUSY.   (we should discuss why this is not a MUST if we have the conditionals in place.)

Then we could go on to say that a reaction node (or agent) would typically fall under the first category, and a reporting node (or server) would typically fall under the second. But there certainly may be cases where a reacting node does not know if other paths could work, and where a reporting node might know that they couldn't. 

> 
> This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response.
> 
> I propose adding this to a new section 4.2.4.  The existing 4.2.4 on agent behavior will be deleted.
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Mon, 20 Oct 2014 21:41:05 +0000

Hi,

I think that:
- TOO_BUSY should be restricted to server answer
- UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmission is required
- UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when retransmission to an alternate peer could be better.

As a second step, we could enhance the answer message (in this draft or in a separate draft if preferred) with an error message (e.g. "Error-Diagnostic") that could provide further information to "new" node that will be then able to adapt their behavior.
So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Diagnostic set to e.g. "severe overload", besides the OLR in the answer, will know that retransmission on the path or a on a different path will likely cause the same error. If no error-diagnostic is sent back or ignored by the non-supporting-DOOIC node, we will go back to the situation prior this draft.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : lundi 20 octobre 2014 19:10
À : Steve Donovan
Cc : [email-masked]
Objet : Re: [Dime] Proposal for error response wording (issue 85)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2014 17:21:20 -0500

> On Oct 20, 2014, at 4:41 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi,
> 
> I think that:

One of the reasons I think we need to state this by intended result and not by role in the network, is that I expect that an overloaded agent (according to the agent overload draft) might send TOO-BUSY. And a server that acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a Destination-Host AVP.

---

From: <[email-masked]>
Date: Tue, 21 Oct 2014 04:53:16 +0000

I agree.

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

---

From: Steve Donovan <[email-masked]>
Date: Tue, 21 Oct 2014 09:04:07 +0200

I'll work Ben's suggestion into the draft.  I expect it to go into the 
existing Error Response section.

I don't think we have time to define an error-diagnostic AVP.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 21 Oct 2014 10:27:59 +0200

I have incorporated the following text into the document in the 
existing, previously empty, section 7. Error Response Codes.

I will wait until tomorrow to close issue 85 to allow for discussion of 
the proposed wording.

I have attached the diff as this wording is not in the draft.

Regards,

Steve

---

    When a DOIC node rejects a Diameter request due to throttling, the
    DOIC node needs to select the appropriate error response code.  This
    determination is made based on the probability of the request
    succeeding if retried on a different path.

    The DIAMETER_TOO_BUSY response code SHOULD be used when the request
    is likely to succeed on a different path.

       For instance, if the request arrived at the reporting node without
       a Destination-Host AVP then the reporting node might determine
       that there is an alternative Diameter node that could successfully
       process the request and that retrying the transaction would not
       negatively impact the reporting node.

    The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to
    indicate that the request should not be retried.  This is used when
    the request is not likely to succeed on a different path and retrying
    would consume valuable resources during an occurance of overload.

       For instance, if the request arrived at the reporting node with a
       Destination-Host AVP populated with its own Diameter identity then
       the reporting node can assume that retrying the request would
       result in it coming to the same reporting node.

       A second example is when an agent that supports the DOIC solution
       is preforming the role of a reacting node for a non supporting
       client.  Requests that are rejected as a result of DOIC throttling
       in this scenario would generally be rejected with a
       DIAMETER_UNABLE_TO_COMPLY response code.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 Oct 2014 09:46:31 -0500

Did we intend to include anything about Lionel's suggestion on UNABLE_TO_DELIVER?  (I am neutral on that--I just wanted to make sure we didn't forget to consider it.)

I also have one comment inline. Otherwise it looks good to me.

> On Oct 21, 2014, at 3:27 AM, Steve Donovan <[email-masked]> wrote:
> 
> I have incorporated the following text into the document in the existing, previously empty, section 7. Error Response Codes.
> 
> I will wait until tomorrow to close issue 85 to allow for discussion of the proposed wording.
> 
>    DOIC node needs to select the appropriate error response code.

Do we have separate text saying the node MUST send an error? If not, I suggest changing this to "... MUST respond with an appropriate error response code."

The change from "the" to "an" was intentional. Since we are using SHOULD below for the actual choice, I assume we intend to leave room for an implementation to make other choices if it has a good reason. 

>  This
>>> De : DiME [
>>> mailto:[email-masked]
>>> ] De la part de Ben Campbell
>>> Cc : 
>>> [email-masked]
> <Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 22 Oct 2014 06:55:01 +0200

It wasn't clear to me when that would be used.  We can certainly update 
the text if someone has an agreeable suggestion for what that text 
should be.

In the mean time, I'm going to close the issue and leave this question 
to be resolved during review of the updates.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 22 Oct 2014 08:33:13 +0200

Ben,

I missed the other comment.  The MUST wording you suggest will be in the 
next revision of the -04 draft.

Yes on your question about the SHOULD.  Do you think we need wording 
saying that implementations can make other choices if they have good reason?

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Oct 2014 09:11:26 -0500

> On Oct 22, 2014, at 1:33 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ben,
> 
> I missed the other comment.  The MUST wording you suggest will be in the next revision of the -04 draft.
> 
> Yes on your question about the SHOULD.  Do you think we need wording saying that implementations can make other choices if they have good reason?

That's what SHOULD means on it's own. We might get push back to suggest some potential "good reasons". (None come to mind at the moment...)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Oct 2014 09:11:58 -0500

> On Oct 22, 2014, at 9:11 AM, Ben Campbell <[email-masked]> wrote:
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Oct 2014 09:13:33 -0500

>> That's what SHOULD means on it's own. We might get push back to suggest some potential "good reasons". (None come to mind at the moment...)

I guess one potential good reason would be if we (or someone) created new error codes in the future to distinguish these scenarios from other uses of the existing codes. We've talked about fixing that with a diagnostic AVP, but that's not written in stone.

---

From: <[email-masked]>
Date: Wed, 22 Oct 2014 14:26:51 +0000

I will try to come back with a proposal on UNABLE_TO_DELIVER and also the new AVP after -04.
The existing text for 04 is OK and can be anyway extended if required.

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : mercredi 22 octobre 2014 16:12
À : Steve Donovan
Cc : MORAND Lionel IMT/OLN; [email-masked]
Objet : Re: [Dime] Proposal for error response wording (issue 85)

> That's what SHOULD means on it's own. We might get push back to 
> suggest some potential "good reasons". (None come to mind at the 
> moment...)
> 
>> 
>> Steve
>> 
>>> Did we intend to include anything about Lionel's suggestion on 
>>> UNABLE_TO_DELIVER?  (I am neutral on that--I just wanted to make 
>>> sure we didn't forget to consider it.)
>>> 
>>>>>> On Oct 20, 2014, at 4:41 PM, <[email-masked]> 
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I think that:
>>>>>> Envoyé : lundi 20 octobre 2014 19:10 À : Steve Donovan Cc :
>>>>>> [email-masked]
>>>>>> 
>>>>>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan 
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>> 
>>>>>> I don't think we should state this in terms of reaction and 
>>>>>> reporting nodes. I think we should generalize to expected 
>>>>>> behavior. Also, in the case where the downstream node does not 
>>>>>> support DOIC, I'm not sure it makes sense to say the throttling 
>>>>>> node is really a reporting node (for that particular 
>>>>>> relationship.)
>>>>>> 
>>>>>> _________________________________________________________________
>>>>>> ________________________________________________________
>>>>>> 
>>>>>> Ce message et ses pieces jointes peuvent contenir des 
>>>>>> informations confidentielles ou privilegiees et ne doivent donc 
>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>> 
>>>>>> This message and its attachments may contain confidential or 
>>>>>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>>>>> __________________________________________________________________
>>>>> _______________________________________________________
>>>>> 
>>>>> Ce message et ses pieces jointes peuvent contenir des informations 
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre 
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>> 
>>>>> This message and its attachments may contain confidential or 
>>>>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 22 Oct 2014 16:51:40 +0200

Perfect, thanks.

Steve