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

From: <[email-masked]>
Date: Mon, 3 Mar 2014 08:25:04 +0000

Hi Jouni,

Doing a separate I-D updating the RFC6733 to provide guidelines and recommendations on the use of TOO_BUSY and non-answer cases was already proposed in Porto. This is needed independently of the DOIC mechanism.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : vendredi 28 février 2014 18:46
À : Ben Campbell
Cc : [email-masked]
Objet : Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC

Ben,

On Feb 25, 2014, at 1:11 AM, Ben Campbell <[email-masked]> wrote:

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

"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? 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 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 response to a realm-routed request?

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

- Jouni

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

_______________________________________________
DiME mailing list
[email-masked]
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.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 3 Mar 2014 09:13:38 +0000

> Doing a separate I-D updating the RFC6733 to provide guidelines and recommendations on the use of TOO_BUSY and non-answer cases was already proposed in Porto. This is needed independently of the DO…

Sure. I just wanted to re-emphasize that.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Mon, 3 Mar 2014 09:23:17 +0000

> Sure. I just wanted to re-emphasize that.

Do we expect DOIC to normatively reference that draft? I think that if DOIC depends on TOO_BUSY to be used in a way that is not supported by 6733, we would have to do so.

If so, we would need that draft to exist and progress ahead of or in tandem with DOIC.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 3 Mar 2014 10:36:47 +0000

> Do we expect DOIC to normatively reference that draft? I think that if DOIC depends on TOO_BUSY to be used in a way that is not supported by 6733, we would have to do so.

I do not understand the reason why would we want to deliberately build
that kind of dependency into DOIC I-D. To me it would be the other way
around, since it is a specific deployment case independent of the DOIC
base solution.

> If so, we would need that draft to exist and progress ahead of or in tandem with DOIC.

Just thinking out loud.. the DOIC I-D could e.g. just state this use
case is up to separate document and not even referencing which one.
We really do not need to name the document in the DOIC base IMHO.

This is of course only my personal view..

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Mon, 3 Mar 2014 10:42:50 +0000

> This is of course only my personal view..

Maybe I misunderstood, but I gathered we were talking about a proposal to have DOIC specify sending TOO_BUSY to realm-routed requests. I interpret the 6733 language to forbid that. So I don't think we can propose doing that in DOIC, but leave the details to another draft without a normative reference. 

OTOH, if the idea is to not mention the which responses to send to a non-DOIC client when a request is throttled and leave the whole thing to another draft, then we would not have a dependency. (But we might have an interop problem due to underspecification.)

---

From: Steve Donovan <[email-masked]>
Date: Mon, 03 Mar 2014 11:14:56 +0000

It seems that we need two things.

First, we need to specify the response(s) sent by an agent for throttled 
requests received from a 6733 node.

Second, we need to define the 6733+ node that supports the yet to be 
defined enhanced Too-Busy logic.

If we include the second in the initial version of the DOIC document 
then there is a dependency on the enhanced Too-Busy document.

I propose that we focus on the first case and decide if we update DOIC 
if and when the definition of enhanced Too-Busy logic exists.

Steve