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

[Steve Donovan <[e-mail]>]

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

On 10/21/14, 4:46 PM, Ben Campbell wrote:
> 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 <[e-mail]> 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.
>>
>> 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.
> 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
>>     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.
>>
>>
>>
>>
>> On 10/21/14, 6:53 AM, [e-mail] wrote:
>>> I agree.
>>>
>>> Lionel
>>>
>>> Envoyé depuis mon Sony Xperia SP d'Orange
>>>
>>> ---- Ben Campbell a écrit ----
>>>
>>>
>>>
>>>> On Oct 20, 2014, at 4:41 PM, <[e-mail]> <[e-mail]>
>>>>   wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think that:
>>>> - TOO_BUSY should be restricted to server answer
>>>>
>>> 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.
>>>
>>>
>>>> - 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:[e-mail]
>>>> ] De la part de Ben Campbell
>>>> Envoyé : lundi 20 octobre 2014 19:10
>>>> À : Steve Donovan
>>>> Cc :
>>>> [e-mail]
>>>>
>>>> Objet : Re: [Dime] Proposal for error response wording (issue 85)
>>>>
>>>> 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 <[e-mail]>
>>>>>   wrote:
>>>>>
>>>>> 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.
>>>>>
>>>> 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.
>>>>>
>>>>> I will hold off making this change until tomorrow (Tuesday morning).
>>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>>
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>
>>>>
>>>> _________________________________________________________________________________________________________________________
>>>>
>>>> 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.
>>>>
>>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> 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.
>>>
>>>
>>>
>> <Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html>
>