Subject: [Dime] Minutes of the Dime Interim Meeting

From: <[email-masked]>
Date: Tue, 21 Oct 2014 11:42:21 +0000

Hi,

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.

_________________________________________________________________________________________________________________________

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.