Subject: [Dime] Ulrich's suggested changes #9 and #10

From: Steve Donovan <[email-masked]>
Date: Tue, 09 Dec 2014 07:35:07 -0600

Ulrich,

Suggested changes 9 and 10 are linked so I'll deal with them in a single 
email:

Section 4.1.3, 1st paragraph:
Existing text:
    Diameter Agents that support DOIC SHOULD ensure that all messages
    relayed by the agent contain the OC-Supported-Features AVP.
Comment: The SHOULD in the first line is not correct based on my next comment.
Proposal: Delete the first paragraph.

Section 4.1.3, 4th paragraph:
Existing text:
    A Diameter Agent SHOULD take on reporting node behavior for Diameter
    endpoints that do not support the DOIC solution.  A Diameter Agent
    detects that a Diameter endpoint does not support DOIC reporting node
    behavior when there is no OC-Supported-Features AVP in an answer
    message for a transaction that contained the OC-Supported-Features
    AVP in the request message.
Comment: The first sentence can reasonably only apply to Diameter agents that are immediate peers to the non-supporting Diameter endpoint. We cannot expect a far-away-agent to take on reporting node behavior when all upstream agents and the server do not support DOIC. Furthermore: When the non-supporting server has two DOIC supporting immediate peer agents which both take on reporting node behavior we end up in problems similar to those identified in the note in section 3.3.
Proposal:Replace the paragaph with:
    A Diameter Agent that is an immediate peer to the Diameter endpoint
    that does not support DOIC SHOULD take on reporting node behavior for
    Diameter endpoints that do not support the DOIC solution.  A Diameter
    Agent detects that a Diameter endpoint does not support DOIC reporting
    node behavior when there is no OC-Supported-Features AVP in an answer
    message for a transaction that contained the OC-Supported-Features
    AVP in the request message.
       Note: Known issues exist if multiple sources for overload reports
       which apply to the same Diameter entity exist.  Reacting nodes
       have no way of determining the source and, as such, will treat
       them as coming from a single source.  Variance in sequence numbers
       between the two sources can then cause incorrect overload
       abatement treatment to be applied for indeterminate periods of
       time.

You point out an interesting issue with agents taking on reporting node 
functionality.

I don't, however, think that an agent that takes on reporting node 
functionality for a non supporting host needs to be adjacent to the 
host.  The important thing is that it has visibility to all of the 
traffic sent to the host.

I suggest keeping the first paragraph but changing the SHOULD to a MAY.

I also suggest changing the SHOULD to a MAY in the fourth paragraph and 
changing the first sentence to:

A Diameter Agent MAY take on reporting node behavior for Diameter 
endpoints that do not support the DOIC solution.  The Diameter Agent 
MUST have visibility to all traffic destined for the non supporting host 
in order to become the reporting node for the Diameter endpoint.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 9 Dec 2014 15:39:32 +0000

Steve,
I agree with your suggestions.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:35 PM
To: [email-masked]
Subject: [Dime] Ulrich's suggested changes #9 and #10

Ulrich,

Suggested changes 9 and 10 are linked so I'll deal with them in a single email:

You point out an interesting issue with agents taking on reporting node functionality.

I don't, however, think that an agent that takes on reporting node functionality for a non supporting host needs to be adjacent to the host.  The important thing is that it has visibility to all of the traffic sent to the host.

I also suggest changing the SHOULD to a MAY in the fourth paragraph and changing the first sentence to:

A Diameter Agent MAY take on reporting node behavior for Diameter endpoints that do not support the DOIC solution.  The Diameter Agent MUST have visibility to all traffic destined for the non supporting host in order to become the reporting node for the Diameter endpoint.

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Dec 2014 17:06:05 -0600

> On Dec 9, 2014, at 7:35 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ulrich,
> 
> A Diameter Agent MAY take on reporting node behavior for Diameter endpoints that do not support the DOIC solution.  

I agree with everything up to there. (Not necessarily for the reasons given, but I've been pushing for this to be MAY or non-normative for a while now :-) )

> The Diameter Agent MUST have visibility to all traffic destined for the non supporting host in order to become the reporting node for the Diameter endpoint.

I see the issue, but I think that answer needs more thought. It seems to disallow the case where you have a pair of agents in an active-active configuration in front of a non-supporting server, unless they sync OCS. I strongly suspect that case will be the rule, at least for telecom deployments.

/Ben

---

From: Steve Donovan <[email-masked]>
Date: Tue, 16 Dec 2014 09:02:28 -0600

Ben,

See inline.

Steve

> I see the issue, but I think that answer needs more thought. It seems to disallow the case where you have a pair of agents in an active-active configuration in front of a non-supporting server, unl…
SRD> I don't think it rules these deployments out, it just points out 
that they might be hard to implement.  "Has visibility" doesn't mean 
"personally handles".  There would need to be state sharing between the 
two agents for it to work correctly, but it can work.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2014 09:07:25 -0600

> On Dec 16, 2014, at 9:02 AM, Steve Donovan <[email-masked]> wrote:
> 
> SRD> I don't think it rules these deployments out, it just points out that they might be hard to implement.  "Has visibility" doesn't mean "personally handles".  There would need to be state sharing between the two agents for it to work correctly, but it can work.
> 

For the record, I think active-active agents will be too common for us to require inter-agent OCS state sharing for it to work.

This problem will also exist for aggregated servers. That is also common place.