Subject: Re: [Dime] DOIC: Base protocol vs application

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Aug 2014 09:08:27 -0500

On Aug 1, 2014, at 12:37 AM, Jouni Korhonen <[email-masked]> wrote:

>>> 
>>> A "node" as a DOICable relay can do DOIC stuff to _any_ application within certain limits. If the "DOIC stuff" is just applying the abatement, then that is OK for _any_ application depending on the abatement algorithm. If the "DOIC stuff" is beyond that e.g. adding/removing DOIC AVPs then the DOICable relay has to be application aware _internally_ i.e. a proxy.. otherwise it might e.g. cause trouble with applications whose messages' CCF has no *[AVP].
>> 
>> Adam did a survey way back when, and found that such applications are vanishingly rare. (Was it just the watchdog application?). Hopefully people won't try to define new applications without *[AVP]/
> 
> I know. *[AVP] was just an example. Another example would be new applications that embed DOIC as a part of their formal CCF and there even changing the location of the DOIC AVP could break the CCF check.

We could offer guidance to not make the DOIC AVPs fixed.

OTOH, I see there might be some issues with interfering with other fixed position AVPs in the CCF, if an relay that doesn't know the CCF changes their position by inserting  DOIC AVPs. We could recommend such relays insert at the end, but there are probably efficiency reasons to add them close to the front. I guess we could say "add close to the top if you understand the CCF, otherwise add at the end."

To be clear, I think the most common use of DOIC at agents would be at proxies, so this becomes an edge case. It's just an edge case I think we need to support.

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 15:50:15 +0000

Hi Ben,

The initial point was not only about inserting OLR in answers, it was also about using "the received load and overload information to support graceful           behavior during an overload condition."

I think that inserting OLR AVP and performing overload abatement actions on behalf of a non-DOICable node require maintaining an overload control state for each associated non-DOIC node. As I said earlier, it would mean also that this node knows how to perform such abatement, which is defined at the application layer.
This is why such actions cannot be performed by a simple Relay but only by a proxy.

Now, I want to make clear the distinction between the role of Relay agent as defined in the RFC6733 and the functions assigned to a Diameter node currently deployed in the networks for request/answer forwarding. If the former is pretty restrictive in terms of functionalities performed by the agent acting as Relay, there is no such restriction regarding the latter. But this is implementation specific and outside the standardization scope.

I still don't see why a forwarding proxy advertising all the applications for which DOIC is supported is not enough to cover your concern. In any case, assuming that "pure" Relay agents would have been deployed in the network, they will have to be upgraded to support DOIC. Along this upgrade, I don't see any issue to modify its role from "Relay" to "Proxy" and add the supported appli-Id in the CER/CEA.

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : vendredi 1 août 2014 16:08
À : Jouni Korhonen
Cc : MORAND Lionel IMT/OLN; [email-masked]
Objet : Re: [Dime] DOIC: Base protocol vs application

_________________________________________________________________________________________________________________________

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.