Subject: [Dime] WLGC #1 for draft-ietf-dime-ovli-05

From: Jouni Korhonen <[email-masked]>
Date: Thu, 04 Dec 2014 00:31:31 +0200

Folks,

We have had a considerable update on the DOIC draft based on the 
comments from the interim meeting, Honolulu meeting and discussions held 
lately on the mailinglist. Authors/chairs think the -05 draft is now 
ready for a WGLC and the rest of the potential comments can be handled 
as WGLC comments.

This email starts a two week WGLC #1 for draft-ietf-dime-ovli-05. The 
WGLC ends 18th Dec 2014 EOB (CET+1). Post your review comments and 
concerns to the mailinglist. Also make use of the issue tracker 
(remember to select "severity" as "in WG last call").

Lionel & Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 8 Dec 2014 10:06:11 +0000

Dear Lionel & Jouni,

here are my review comments. 
I think those are all not contentious.
Best regards
Ulrich

Section 3, last paragraph:
Existing text:
   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unchanged.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.
Comment: while this is all not wrong, the existing text may convey the erring impression that there cannot be a DOIC supporting agent on the path between a reporting node and an adjacent reacting node. 
Proposal: It is proposed to add the following sentence at the end of the paragraph:
   Another example is where one or more Diameter agents that do support
   DOIC may exist between a given pair of reporting and reacting nodes,
   as long as those agents pass OC-specific AVPs through unchanged.

Section 3.2, 6th paragraph:
Existing text:
   The OC-Feature-Vector AVP will contain an indication of support for
   the loss overload abatement algorithm defined in this specification
   (see Section 5).  This ensures that there is at least one commonly
   supported overload abatement algorithm between the reporting node and
   the reacting node(s) in the path of the request.
Comment: I agree that within a given path between client and server there may be more than one reacting nodes. But a given reporting node on that path does not have more than one adjacent reacting nodes on that given path to which it sends OLRs. I don't say that the existing text is wrong, but it is misleading. What we want to say here is that any given pair of adjacent reacting and reporting nodes will have at least one commonly supported algorithm.
Proposal: It is proposed to replace the last line of the paragraph with:
   The adjacent reacting node on the path of the request.

Section 3.2, last two paragraphs:
Existing text:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent updates the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine the content of the modified  OC-
      Supported-Features AVP is out-of-scope for this specification and
      is left to implementation decisions.  Care must be taken not to
      introduce interoperability issues for downstream or upstream DOIC
      nodes.
Comment: It is perfectly ok (in this case) for the agent not to update and not to modify. 
Proposal: It is proposed to replace the two paragraphs with the following:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent can update the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine whether and if how to modify the
      content of the OC-Supported-Features AVP is out-of-scope for this
      specification and is left to implementation decisions.  Care must
      be taken not to introduce interoperability issues for downstream
      or upstream DOIC nodes.

Section 3.3, 4th and 5th paragraph:
Existing text:
   A report of type "HOST_REPORT" is sent to indicate the overload of a
   specific Diameter node for the application-id indicated in the
   transaction.  When receiving an OLR of type host, a reacting node
   applies overload abatement to what is referred to in this document as
   host-routed requests.  The reacting node applies overload abatement
   on those host-routed requests which the reacting node knows will be
   served by the server that matches the Origin-Host AVP of the received
   message that contained the received OLR of type host.

   A report of type "REALM_REPORT" applies to realm-routed requests for
   a specific realm as indicated in the Destination-Realm AVP.
Comment: While the 4th paragraph is all fine, the 5th paragraph should be aligned.
Proposal: It is proposed to replace the 5th paragraph with:
   A report of type "REALM_REPORT" is sent to indicate the overload of all
   Diameter nodes within a realm for the application-id indicated in the
   transaction.  When receiving an OLR of type realm, a reacting node
   applies overload abatement to what is referred to in this document as
   realm-routed requests.  The reacting node applies overload abatement
   on those realm-routed requests which contain  a Destination-Realm AVP
   that matches the Origin-Realm AVP of the received message that
   contained the received OLR of type realm.

Section 3.3, 8th paragraph:
Existing text:
   Reporting nodes are responsible for determining the need for a
   reduction of traffic.  The method for making this determination is
   implementation specific and depend on the type of overload report
   being generated.  A host-report, for instance, will generally be
   generated by tracking utilization of resources required by the host
   to handle transactions for the Diameter application.  A realm-report
   generally impacts the traffic sent to multiple hosts and, as such,
   requires tracking the capacity all servers for realm-routed requests
   for the application and realm.
Comment: Something is wrong with the last sentence.
Proposal: Replace the last sentence with:
                                                         A realm-report
   generally impacts the traffic sent to multiple hosts and, as such,
   requires tracking the capacity of all servers able to handle realm-
   routed requests for the application and realm.

Section 3.3, 12th paragraph:
Existing text:
   As the conditions that lead to the generation of the overload report
   change the reporting node can send new overload reports requesting
   greater reduction if the condition gets worse or less reduction if
   the condition improves.  The reporting node sends an overload report
   with a duration of zero to indicate that the overload condition has
   ended and need for use of the abatement algorithm to reduce traffic
   sent is no longer needed.
Comment: Bad style.
Proposal: Remove the words "need for" from the last sentence.

Section 4.1.2, 4th paragraph:
Existing text:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content of the OC-
   Feature-Vector AVP in the request message.
Comment: The Feature-Vector AVP may be absent. In this case knowledge cannot be based on the content.
Proposal: Replace the paragraph with:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content or absence of
   the OC-Feature-Vector AVP within the Supported-Features AVP in the
   request message.

Section 4.1.2, 8th paragraph:
Existing text:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs in answer
   messages.
Comment: As a result of an ongoing overload condition the reporting node is sending OC-OLR AVPs containing no validity duration or a validity duration different from zero in answer messages.
Proposal: Replace the paragraph with:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs
   containing no validity duration or a validity duration different
   from zero in answer messages.

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.
 
Section 4.1.3, 6th paragraph:
Existing text:
   As with a Diameter endpoint taking on reporting node behavior, a
   Diameter Agent MUST only include the OC-Supported-Features AVP in
   answer messages for transactions where the request message received
   by the Diameter Agent had an OC-Supported-Features AVP.
Comments: "MUST only do x for condition y" could mean:
a) "MUST do x for condition y and MUST NOT do x for conditions other than y", or
b) "MUST do x and nothing else for condition y, and nothing is specified for conditions other than y".
Proposal: Replace the paragraph with:
   As with a Diameter endpoint taking on reporting node behavior, a
   Diameter Agent MUST NOT include the OC-Supported-Features AVP in
   answer messages for transactions where the request message received
   by the Diameter Agent had no OC-Supported-Features AVP.

Section 4.1.3, last paragraph:
Existing text:
   When making changes to the OC-Supported-Features AVP the Diameter
   Agent needs to ensure that there is no ambiguity in DOIC behavior for
   both upstream and downstream DOIC nodes.
Comment: while that is true, in addition problems similar to those identified in the note in section 3.3 may result from making changes.
Proposal: Add the note:
      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.

Section 4.2.1.1, 3rd paragraph:
Existing text:
   A realm-type OCS entry is identified by the pair of application-d and
   realm.
Comment: a letter "i" is missing.
Proposal: replace the paragraph with:
   A realm-type OCS entry is identified by the pair of application-id and
   realm.

Section 4.2.1.3, 3rd paragraph:
Existing text:
   When receiving an answer message with multiple OLRs or different
   types, a reporting node MUST process each received OLR.
Comment: The "or" is probably meant to be an "of". Furthermore, OLRs with unsupported report types are not required to be processed.
Proposal: replace the paragraph with:
   When receiving an answer message with multiple OLRs of different
   supported report types, a reporting node MUST process each received OLR.

Section 4.2.1.3, 4th paragraph:
Existing text:
   When receiving an OC-OLR AVPs with unknown values, a reacting node
   SHOULD be silently discarded by reacting nodes and the event SHOULD
   be logged.
Comment: text is confusing. Maybe the intention was to say:
   When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
   SHOULD silently discarded the OC-OLR AVP and the event SHOULD
   be logged.
But even that is not correct.
Proposal: Remove the paragraph.

Section 4.2.2, 5th and 6th paragraph:
Existing text:
   If the request is a host-routed request then the reacting node SHOULD
   apply throttling abatement treatment to the request.
 
   If the request is a realm-routed request then the reacting node
   SHOULD apply diversion abatement treatment to the request.
Comment: I don't think so. If the reacting node selects the server and then detects that the selected server is overloaded and then detects that the request does not survive (i.e. is subject to abatement), then the reacting node SHOULD apply diversion treatment (i.e. select an alternative server if possible). If the reacting node does not select the server (either a. because the server was already selected by a downstream node, or b. because the server will be selected by an upstream node) then there is no point in applying diversion and the reacting node SHOULD apply throttling of requests that do not survive.
Proposal: replace the paragraphs with:
   If the reacting node does not select the server then it SHOULD apply
   throttling abatement to the request.

   If the reacting node selects the server then it SHOULD apply diversion
   abatement treatment (i.e. select an alternative server if possible) to
   the request.

Section 4.2.2, last paragraph:
Existing text:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires or has a
   validity duration of zero ("0"), meaning that the reporting node has
   explicitly signaled the end of the overload condition then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.
Comment: If no traffic is sent, no OLR will be received, hence you cannot come out of a 100% throttling by explicit indication.
Proposal: replace the paragraph with:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.

Section 4.3, 3rd paragraph:
Existing text:
   The extension MAY define new AVPs for use in DOIC Capability
   Announcement and for use in DOIC Overload reporting.  These new AVPs
   SHOULD be defined to be extensions to the OC-Supported-Features and
   OC-OLR AVPs defined in this document.
Comment: It is not necessary for a new AVP to be an extension to both the OC-Supported-Features AVP and the OC-OLR AVP.
Proposal: Replace the paragraph with:
   The extension MAY define new AVPs for use in DOIC Capability
   Announcement and for use in DOIC Overload reporting.  These new AVPs
   SHOULD be defined to be extensions to the OC-Supported-Features and/or
   OC-OLR AVPs defined in this document.

Section 5.1, 9th paragraph:
Existing text:
   4.  The reacting node determines if overload abatement treatment
       should be applied to the request.  One approach that could be
       taken for each request is to select a random number between 1 and
       100.  If the random number is less than the indicated reduction
       percentage then the request is given abatement treatment,
       otherwise the request is given normal routing treatment.
Comment:The maths is wrong.
Proposal: Replace the paragraph with:
   4.  The reacting node determines if overload abatement treatment
       should be applied to the request.  One approach that could be
       taken for each request is to select a random number between 1 and
       100.  If the random number is less than or equal to the indicated
       reduction percentage then the request is given abatement treatment,
       otherwise the request is given normal routing treatment.

Section 5.3, 4th paragraph:
Existing text:
   When applying overload abatement treatment for the load abatement
   algorithm, the reacting node MUST abate the requested percentage of
   requests that would have otherwise been sent to the reporting host or
   realm.
Comment: probably a typo.
Proposal: Replace the paragraph with:
   When applying overload abatement treatment for the loss abatement
   algorithm, the reacting node MUST abate the requested percentage of
   requests that would have otherwise been sent to the reporting host or
   realm.

Section 5.3, 6th paragraph:
Existing text:
   If the reacting node does not receive an OLR in messages sent to the
   formerly overloaded node then the reacting node SHOULD slowly
   increase the rate of traffic sent to the overloaded node.
Comment: confusing.
Proposal: Replace paragraph with:
   If the reacting node does not receive an OLR in response to messages
   sent to the formerly overloaded node then the reacting node SHOULD
   slowly increase the rate of traffic sent to the overloaded node.

Section 6.1, last paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: Absence of OC-Feature-Vector AVP indicates different things depending on the type of message (request / answer).
Proposal: Replace the paragraph with:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP in request
   messages indicates that only the default traffic abatement algorithm
   described in this specification is supported. The absence of the OC-
   Feature-Vector AVP in answer messages indicates that the default
   traffic abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.

Section 6.2, 2nd paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: seems to be misplaced as reference is given to 6.2.
Proposal: remove the paragraph.

Section 6.3, 1st paragraph:
Existing text:
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
   information necessary to convey an overload report on an overload
   condition at the reporting node.  The OC-OLR AVP does not explicitly
   contain all information needed by the reacting node to decide whether
   a subsequent request must undergo abatement using the received
   reduction percentage.  The value of the OC-Report-Type AVP within the
   OC-OLR AVP indicates which implicit information is relevant for this
   decision (see Section 6.6).  The application the OC-OLR AVP applies
   to is the same as the Application-Id found in the Diameter message
   header.  The host or realm the OC-OLR AVP concerns is determined from
   the Origin-Host AVP and/or Origin-Realm AVP found in the
   encapsulating Diameter command.  The OC-OLR AVP is intended to be
   sent only by a reporting node.
Comment: Reduction percentage may not be used by all future algorithms.
Proposal: Replace the paragraph with:
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
   information necessary to convey an overload report on an overload
   condition at the reporting node.  The OC-OLR AVP does not explicitly
   contain all information needed by the reacting node to decide whether
   a subsequent request must undergo abatement using the selected
   abatement algorithm.  The value of the OC-Report-Type AVP within the
   OC-OLR AVP indicates which implicit information is relevant for this
   decision (see Section 6.6).  The application the OC-OLR AVP applies
   to is the same as the Application-Id found in the Diameter message
   header.  The host or realm the OC-OLR AVP concerns is determined from
   the Origin-Host AVP and/or Origin-Realm AVP found in the
   encapsulating Diameter command.  The OC-OLR AVP is intended to be
   sent only by a reporting node.

Section 6.8, last character
Proposal: remove the "."

Section 8.2, last paragraph:
Existing text:
   See Section 6.2 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].
Comment: wrong reference.
Proposal: Replace the paragraph with:
   See Section 6.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, December 03, 2014 11:32 PM
To: [email-masked]
Subject: [Dime] WLGC #1 for draft-ietf-dime-ovli-05

Folks,

Lionel & Jouni

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime