Subject: [Dime] Issue #30

From: Steve Donovan <[email-masked]>
Date: Mon, 17 Mar 2014 14:03:34 -0500

All,

We reached the tentative agreement in the DIME meeting on the following:

OC-Supported-Features handling:

Agreed: OC-Supported-Features AVP MUST be included in all answer
messages (we had already agreed that it must be included in all request
messages).
Agreed: Reacting node advertises all supported algorithms;
Agreed: Reporting node responds with the single algorithm it will be using;
Agreed: Handling of other feature bits is defined in the extension drafts

Based on this I believe we need the text changes outlined below.

Let me know if I have missed any.

If we agree on the text changes then we can close the issue and I'll
update the document accordingly.

Regards,

Steve

-----

Section 5.3.2, paragraph 1:

Change:

The answer message
   initiating endpoint MAY announce as many supported capabilities as it
   has (the announced set is a subject to local policy and
   configuration). However, at least one of the announced capabilities
   MUST be the same as received in the request message.

To:

The reporting node MUST include the OC-Supported-Features AVP in all
response messages for transactions where the request message included
the OC-Supported-Features AVP.  The reporting node MUST announce support
of the single algorithm that the reporting node will request the
reacting node to use to mitigate overload instances.  The reporting node
MUST NOT change the selected algorithm during a period of time that it
is in an overload state and, as a result, is sending OC-OLR AVPs in
answer messages. 

    Note: There will always be at least one algorithm supported by both
the reacting and reporting nodes as all nodes that support DOIC must
support the loss algorithm defined in this document.

The handling of feature bits in the OC-Feature-Vector AVP that are not
associated with overload abatement algorithms MUST be specified by the
extension that defines the feature.

Paragraph 2:

Change:

The answer message initiating endpoint MUST NOT include any overload
   control solution defined AVPs into its answer messages if the request
   message initiating endpoint has not indicated support at the
   beginning of the created session (or transaction in a case of non-
   session state maintaining applications). The same also applies if
   none of the announced capabilities match between the two endpoints.

To:

The reporting node MUST NOT include the OC-Supported-Features AVP,
OC-OLR AVP or any other overload control AVPs defined in extension
drafts in response messages for transaction where the request message
does not include the OC-Supported-Features AVP.  Lack of the
OC-Supported-Features AVP in the request message indicates that the
sender of the request message does not support DOIC.

Section 5.5.2, Paragraph 1:

Change:

   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP or indirectly remembering the previously
   used traffic abatement algorithm with the given reporting node.

To: (removing the last portion of the last sentence)

   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Mar 2014 09:14:39 -0500

+1, with a minor suggested edit:

>    applies the traffic abatement based on the commonly supported

s/"commonly supported"/selected

"Commonly supported" is no longer descriptive. There may be several commonly supported algorithm, but the reporting node selects just one.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 21 Mar 2014 08:31:26 -0500

Having seen no further discussion on this issue, I will close it with
the agreed to text based on Ben's suggested change below.

Regards,

Steve