Minutes for DIME at interim-2014-dime-1
minutes-interim-2014-dime-1-1

Please find below the minutes of the interim that was held in Sophia-Antipolis,
France, October 16-17, 2014. These minutes capture: - the discussions and
conclusions on the remaining open issues on the draft "Diameter Overload
Indication Conveyance" (draft-ietf-dime-ovli-03.txt) - the work plan for the
completion of the draft towards a WGLC and IESG review

Regards,

Lionel

*********************

Attendees:

Jouni Khoronen
Lionel Morand
Ben Campbell
Steve Donnovan
Martin Dolly
Ulrich Wiehe
Jean-Jacques trottin
maria cruz bartolome
benoit claise
Susan Shi

Agreed agenda:

THURSDAY, October 16, 2014
0930-1230  Morning Session I
Meeting Room: S905 ROYA

* Meeting Preliminaries
- Note Well
- Note takers
- Agenda bashing

* Status of the draft since IETF90
- Changes in v04
- Closed Issues
- Pending open issues
- New open Issues

THURSDAY, October 16, 2014
1400-1800  Afternoon Session I
Meeting Room: S905 ROYA

* Review of the proposed solutions and Discussion on new/pending open issues
(1/2)

FRIDAY, October 17, 2014
0930-1230  Morning Session II
Meeting Room: S905 ROYA

* Review of the proposed solutions and Discussion on new/pending open issues
(2/2) * Conclusions

FRIDAY, October 17, 2014
1400-1700  Afternoon Session II
Meeting Room: S905 ROYA

* DOIC next steps and working procedure till WGLC/IETF91
* Wrap-up & Conclusion
* End of the meeting

* Status of the draft since IETF90

The meeting started by a review of the pending open issues presented by Steve
and a prioritization of the points to address during the meeting. It was agreed
that any editorial issues can be fixed easily by offline discussions. It was
agreed that we need to clarifications any points related to the definition of
the report types, DOIC nodes behaviour and maintenance of the overload control
states. In this optic, issues #23, #66, #67 and #85 were considered as the
points to address in priority, as a number of other issues will depend on these
ones. The rest of the two days meeting was dedicated to the resolution of
pending open issues.

* Review of the proposed solutions and Discussion on new/pending open issues

--Issue #23: DOIC behavior for realm overload

Summary: there is some inconsistency regarding the handling of request without
destination-host AVP. This could be illustrated by the following example: When
reaching a node receiving request without Destination-Host AVP and performing
node selection (e.g. SLF in 3GPP), what happens if there is an active Overload
Control State (OCS) for the selected node? The different pieces of text found
in the current draft could lead to "redundant" abatements.

Output of the discussion:
It was agreed that:
- the "host" report type applies to:
        - request containing the Destination-Host AVP
        - request with no Destination-Host AVP BUT the node processing the
        request is responsible of the selection of the node which the request
        must be addressed to.

- the "realm" report type applies to request without the destination AND the
node processing the request does not select the final destination host.

Based on these definitions, the text should be reviewed in order to clarify
that a node can either consume a received/generated OLR or forward the OLR
downstream. The idea is that the same request should not be subjected to
several abatements. For instance, a request with no destination-host AVP that
has survived to a throttling performed by the sending node having an active OCS
of type "realm" should not be throttled by an agent responsible for the final
selection of the node for which there is an active OCS of type "host".

Ben has provided some text to clarify this issue. Comment/feedback are required
in order to incorporate this text in the draft.

--Issue #85: New error response

Summary: Is there a need for a new error response to address requests rejected
due to overload abatement? The required behavior in response to the new code is
to not retry the transaction.

Output of the discussion:
no new error code seems to be required.
DIAMETER_TOO_BUSY can be sent back by overloaded server performing throttling
to nodes supporting DOIC. DIAMETER_UNABLE_TO_DELIVER can be sent by agent
performing throttling to nodes supporting DOIC. DIAMETER_UNABLE_TO_COMPLY can
be sent to node not supporting DOIC. In all the cases, the expected behaviour
is to limit the number of retransmissions sent by the reacting node.
UNABLE_TO_COMPLY as a permanent error is meant to avoid retransmissions. But
UNABLE_TO_DELIVER does not guarantee that, except if a specific notification is
added in the answer message that will indicate to the reacting node how to
behave. One example could be to add a new AVP in the answer (e.g.
"Error-Diagnostic") that will be understand by node supporting DOIC. But this
can also be left for future extension/optimization.

This must be captured in the draft.

Issue #25: Diameter agent behaviour
Issue #27: Behavior of agent acting on behalf of Client that does not support
DOIC Issue #69: Report Type - Realm, with absent Destination-Host

the issues above should be solved along issues #23 and #85 will be closed.

--Issue #67: OCS for Reporting Nodes - Expiry Time

Summary: in the current text describing the OCS information elements, it is
said that Validity Duration and expiry time need to maintained, whereas
actually only the expiry time is required to manage the OCS, this information
element derived from the validation time received in the OLR.

output of the discussion:
It was agreed that OCS information discussed in the draft is given as
illustration of data required to manage the OCS in reporting/reacting node and
this does not imply that each of information element needs to be locally
stored. For instance, some data element can be derived from others. It was also
discussed how many times a reporting node needs to send an OLR with the
validation duration set to "0" to indicate that the overload situation is over.
It was agreed that the reporting node has to send the OLR with validation
duration "0" as long as all the reacting maintaining a corresponding active OCS
have received the OLR. If there is a way for the reporting node to ensure that
all the nodes will receive the OLR as soon as sent, the OLR can be even sent
only once.

This needs to be captured in the draft.

--Issue #66

Summary: it is unclear what happens when non-supporting agent modifies the
Origin-Host AVP in a Diameter answer that contains a host report from a server.

Output of the discussion:
it is not possible to describe the expected behaviour of a proxy, as proxy
manipulation is out of scope of the standardization. SO the consensus is the
following one: the current solution assumes that there is no origin-host AVP
manipulation. If there is scenario in which a proxy does it, it is up to the
vendor and/or operator network that such origin-host manipulation does not
impact the DOIC mechanism.

--Issue #58: Multiple Reporting Nodes for realm-routed-request type reports

Summary: In deployments where more than one node is configured to take the role
of a reporting node for realm-routed-request reports, reacting nodes may
receive in different answer messages different realm-routed-request type OLRs
inserted by the different reporting nodes.

Output of the discussion:
Initially, it was proposed to add a new AVP in OLR of type "realm", e.g.
OC-Source AVP, identifying the node inserting the OLR and enabling the reacting
to detect that OLR are coming from different sources. We came up with a second
approach which would not require adding the OC-Source AVP: the proposal would
be to rely on sequence number generated on time basis.  In this case, sequence
numbers used by different agent responsible for the realm will be in sync. Each
approach will be further described and the group will decide the preferred
approach and if we have time to get this into the 04 draft (and the subsequent
RFC). If not, this will go into an extension draft.

--Issue #70: Appendix B - Example

Summary: some inconsistency in the description of the behaviour of the agent.

Output of the discussion:
it was agreed that this section was used as check-list to see if nothing is
missing in the OC mechanism. This section will be removed from the final
version of the draft.

--Issue #71:
Summary: Answer message may not include OC-OLR and still the reporting node be
overloaded, since it is considered as "no change"

Output of the discussion:
the proposed text is OK

--Issue #72: Reacting Node Behaviour when OC-OLR is not received

Summary: A clarification is required to consider that an answer message may not
include OC-OLR and still the reporting node be overloaded, since it is
considered as "no change",

Output of the discussion:
to ensure that all the (potential) reacting nodes have received the OLR, it is
agreed that OLR should be included in every message... unless the responding
node has a mean to know that the OLR has been received (e.g. static
configuration). A proper text needs to be provided.

--Issue #73: Clarifications on the M-bit

Summary: Mbit is mentioned in different places in the 03 draft (sections 4.3, 6
and 6.8). It is proposed clarifications to ensure a good consistency between
the different sections.

Output of the discussion:
It is agreed that the draft should just refer to the RFC6733 for everything
regarding the M-bit setting. How and when to set the M-bit is defined in the
base protocol.

--Issue #74: Move section 3.7

Summary: Proposal to move this section to an Appendix. It provides good
information but having it as part of section 3 decreases the readability of the
document.

Output of the discussion:
Actually the section is 3.6 and it is ok to move this section into annex.

--Issue #75: Proposed changes to Terminology section

Summary: Propose to add a few and change a few definitions in the terminology
section.

Output of the discussion:
Principle OK but the section should be reviewed. "host-routed" and
"realm-routed" should be added into this section.

--Issue #76: add report type as part of OCS information

Summary: Propose to add report type as part of the information included in the
OCS of a reporting node.

Output of the discussion:
It is agreed that this information may not be part of exact parameter to manage
OCS. However, as the section 4.2.1.2 just provides examples of data to store,
it is OK to include Report type as part of possible OCS information.

--Issue #77: Section 4.2.3 - Reporting node behavior (overload report handling)

Summary: add text regarding inclusion of OC-Validity-Duration AVP and report
type in the OLR

Output of the discussion:
This change is not required as the ABNF of OLR shows that these AVPs are fixed
AVPs and then always present in the OLR.

--Issue #78: Remove section 5.2

Summary: this section is redundant with text provided in other section.

Output of the discussion:
OK to remove the section

--Issue #79: remove the editor's note from section 5.4

summary: Propose to remove the following editor's note from section 5.4 as the
suggested guidance already exists.

Output of the discussion: OK

--Issue #80: OC-Supported-Features

Summary: Propose removing the following from the last paragraph. Also propose
removing the editor's note:

Output of the discussion:
Any text related to node behaviour should be removed as this section must only
define the AVP. Behaviour of the node should be describe in other sections.

--Issue #81: 6.3. OC-OLR AVP

Summary:  some text was added to decide what to do with multiple OLR of same
type.

Output of the discussion:
This change is not needed as the existing text states "no more than one OLR of
the same type".

--Issue #82: 6.4. OC-Sequence-Number AVP

Summary: proposed that SQN are unique per OLR and between two DOIC nodes.

Output of the discussion:
Principle is OK. It is also clarified that the SQN needs to maintain as long as
the OCS is active.

--Issue #84: 6.6. OC-Report-Type AVP
Summary: proposed to clarify that the default value of the OC-Report-Type AVP
is 0 (i.e. the host report).

Output of the discussion:
Because it is agreed that the report type will be in every OLR (fixed
position), it is obvious that there is no need to define a default value when
absent The discussion was initially raised when it is was proposed to make
optional the presence of the Report-Type in the OLR, which was not accepted.
Conclusion was that OC-Report-Type is mandatory, and fixed position. No default
value is applicable

Work plan/Timeline:
- Submission of version -04 before the submission cut-off (27/10)
- Additional meeting during the IETF meeting to finalize the draft
- move the document to WGLC as soon as possible after IETF meeting.