Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 6 Jun 2016 16:06:27 -0500

Hi Steve,

Thanks for the doc. I found only nits:

Section 2.  Remove "Routing Information - " from the beginning of the 
Routing Information definition.

Section 5 Para 7.      s/next hop/next-hop

Section 5 Para 7.      s/do not have/does not have

Section 5 Para 10.     s/goal is make/goal is to make

Section 5 last para.   s/nodes load/node's load

Section 5.1 Para 5.    s/it's own/its own

Section 6.1.1 Para 2.  s/it's own/its own

Section 6.1.1 Para 2.  s/Source-ID/SourceID

Section 6.1.1 Para 4.  s/Value AVP/Load-Value AVP

Section 6.1.1 Para 7.  s/endpoints peer/endpoint's peer (2 occurrences)

Section 6.1.2 Para 2.  s/it's own/its own

Section 6.1.2 Para 2.  s/Source-ID/SourceID

Section 6.1.2 Para 4.  s/Value AVP/Load-Value AVP

Section 6.2 Para 5.    s/Value AVP/Load-Value AVP

Section 6.2 Para 6.    s/Source-ID/SourceID

Jean

On 5/24/16 10:30 AM, Jouni Korhonen wrote:
> Folks,
>
> This email starts the WGLC #1 for draft-ietf-dime-load-02. Please,
> review the document, post your comments to the mailing list and also
> insert them into the Issue Tracker with your proposed resolution.
>
> WGLC starts: 5/24/2016
>        ends: 6/7/2016 EOB PDT
>
> - Jouni & Lionel
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Thu, 9 Jun 2016 20:03:07 -0500

Jean,

Thanks for the detailed review.  I have made all of the changed 
suggested below.

Regards,

Steve

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Fri, 10 Jun 2016 10:23:39 -0500

> Thanks for the detailed review.  I have made all of the changed

Thanks!

Jean

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 17 Jun 2016 16:30:17 -0700

Ok. No too many review received but I think we can still conclude the 
WGLC successfully. The chairs look forward advancing the draft out of 
the WG..

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 17 Jun 2016 16:37:07 -0700

Having said this please submit the revised version.

- JOuni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 20 Jun 2016 09:13:38 +0000

Hello all,

I would like to provide some questions, proposed changes and typos, see in different sections to ease reading.
Best regards
/MCruz

===========  SOME QUESTIONS ===========:

Appendix A.  Topology Scenarios
Does it really make sense to keep an appendix that states: 
   "Nothing in this section should be construed to mean that a given
   scenario is in scope for this effort, or even a good idea."

I think we need to keep only the scenarios that are "in scope of this effort", what I understand as "suitable for load conveyance as stated in this draft".
If some of them are not considered suitable by any reasons, I presume they should be removed.

A.10.  Addition and removal of Nodes
Shouldn't this part of the annex be in the regular body of the draft?

=========== PROPOSED CHANGES ===========:

Abstract:

Now:
   This document defines a mechanism for *sharing*  of Diameter load
   information.  
Proposed:
   This document defines a mechanism for *conveying* Diameter load
   information.  

Reasoning:
*Sharing" may be a bit misleading.

1. Introduction:
Now:
  In particular, DOIC does not fulfill Req 24, which requires a
   mechanism where Diameter nodes can indicate their *current load* , even
   if they are not currently overloaded.  DOIC also does not fulfill Req
   23, which requires that *nodes that divert traffic*  away from
   overloaded nodes be provided with sufficient information to select
   targets that are most likely to have sufficient capacity.

Proposal:
I think we need to include the exact requirement text from RFC7068, since the description you use does not keep the exact meaning.
E.g. *current load* should be replaced by *load levels", *nodes that divert traffic*, in fact is *nodes with traffic diversion capability*.
Better, just list requirements. If an interpretation is required, this is fine, but the original text is important to be kept:
REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them.
REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring.
 
1. Introduction

Now:
  There are several other requirements in [RFC7068] that mention both
   overload and load information that are only partially fulfilled by
   DOIC.
  [....]
   This document defines a mechanism that addresses the load-related
   requirements from RFC 7068.

Proposal
We need to list the requirements we refer to. They are not listed anywhere, right? 
I think we refer to following Requirements:

REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. 
REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3. 
REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small- scale failure from becoming a widespread outage. 
REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution.

2. Terminology and abbreviations
 
Now: 
Load
      The *relative  capacity of a Diameter node*.  A low load level
      indicates that the Diameter node is under utilized.  A high load
      level indicates that the node is closer to being fully utilized.

Proposed:
Load
      The* Diameter message processing  capacity of a node*.  A low load level
      indicates that the Diameter node is under utilized.  A high load
      level indicates that the node is closer to being fully utilized.

Reasoning:
I think using "relative" is misleading.

4.1
Now:
   Second, Overload information, in the form of a DOIC Overload Report
   (OLR) [RFC7683] indicates an explicit request for action on the part
   of the reacting node.  That is, the OLR requests that the reacting
   node reduce the offered load -- the actual traffic sent to the
   reporting node after overload abatement and routing decisions are
   made -- by an indicated amount *or to an indicated level *.

Proposed:
   Second, Overload information, in the form of a DOIC Overload Report
   (OLR) [RFC7683] indicates an explicit request for action on the part
   of the reacting node.  That is, the OLR requests that the reacting
   node reduce the offered load -- the actual traffic sent to the
   reporting node after overload abatement and routing decisions are
   made -- by an indicated amount *(by default, or other optional abatement algorithms).*

  - Or remove everything after "amount".

4.1
Now:
   None of this prevents a Diameter node from deciding to reduce the
   offered load based on load information.   .  

Proposed
  (remove)

Reasoning:
This sentence is not properly linked to previous paragraph and it is covered by previous paragraph already

4.2
Now:
   Req 24 discusses how Diameter load information might be used when no
   overload condition currently exists.  Diameter nodes can use the load
   information to make decisions to try to avoid overload conditions in
   the first place.  Normal load-balancing falls into this category.  A
   node might also take other proactive steps to reduce offered load
   based on load information, so that the loaded node never goes into
   overload in the first place.

Proposed:
   Req 24 discusses how Diameter load information might be used when no
   overload condition currently exists.  Diameter nodes can use the load
   information to make decisions to try to avoid overload conditions in
   the first place.  Normal load-balancing falls into this category, but 
   the diameter node can  take other proactive steps as well.

4.2
Now
   If the loaded nodes are Diameter servers (or clients in the case of
   server-to-client transactions), both of these uses are most
   effectively accomplished  by a Diameter node that performs server
   selection.  

Proposed:
   If the loaded nodes are Diameter servers (or clients in the case of
   server-to-client transactions), both of these *load information* uses *should
   be*  accomplished  by a Diameter node that performs server
   selection.  

Reasoning:
  Diverting traffic can only be performed by a node that performs server selection, or?

5.
Now
   The second big difference between DOIC and Load is visibility of the
   DOIC or Load information within a Diameter network.  DOIC information
   is sent end-to-end resulting in the ability of all nodes in the path
   of the answer message that carries the OC-OLR AVP to act on the
   information.  The DOIC overload reports much remain in the message
   all the way from the reporting node to the node that is the target
   for the answer message. 

   For the Load mechanism there are two types of load reports.

   The first is the load of the endpoint sending the answer message.
   This load report is carried end-to-end to enable any nodes that make
   server selection decisions to use the load status of the sending
   endpoint as part of  the server selection decision.

   The second type of load report is a peer report.  This report is used
   by Diameter nodes as part of the logic to select the next hop
   Diameter node and, as such, do not have significance beyond the peer
   node.  These load reports are removed by the first supporting
   Diameter node to receive the report.

Proposed:
   The second big difference between DOIC and Load is visibility of the
   DOIC or Load information within a Diameter network.  DOIC information
   is sent end-to-end resulting in the ability of all nodes in the path
   of the answer message that carries the OC-OLR AVP to act on the
   information, *although only one node can actually consume the report*.  The DOIC overload reports much remain in the message
   all the way from the reporting node to the node that is the target
   for the answer message. 

   *However,* for the Load mechanism there are two types of load reports *and only the 
    first one is transmitted end-to-end*.

   The first is the load of the endpoint sending the answer message.
   This load report is carried end-to-end to enable any nodes that make
   server selection decisions to use the load status of the sending
   endpoint as part of  the server selection decision. *More than one node may make use of the load information received*

   The second type of load report is a peer report.  This report is used
   by Diameter nodes as part of the logic to select the next hop
   Diameter node and, as such, do not have significance beyond the peer
   node.  These load reports are removed by the first supporting
   Diameter node to receive the report.

5.
Now
  The goal is make it possible to use both the load values received as
   a part of the Diameter Load mechanism and weight values received as a
   result of a DNS SRV query.  As a result, the Diameter load value has
   a range of 0-65535.  This value and DNS SRV weight values are then
   used in a distribution algorithm similar to that specified in
   [RFC2782].

Comments:
In order to have an efficient load balancing algorithm, it is not enough for the reacting node (for the node in charge of load balancing) to know the Load of each server, but it needs to know the load in relation to each server capacity. Unless we do so, the Load value of a server can't be compared with the Load of a Server with a different weight. 
Then, in my opinion, we need to find a way to provide a Load value that is in fact comparable with the rest of the Load values of the servers in the group.
Reflecting a bit longer on this, I think we need then to define a group of servers in the load-balancing group, like a load-balancing context, and then, for all servers in such a group we need to provide a relative value of dynamic Load.

5.
Now
   The load report includes the relative load of the sending node.  This
   relative load is specified in a manner consistent with that defined
   for DNS SRV [RFC2782].

Proposed:
   The load report includes a value to identify the load of the sending node, 
  specified in a manner consistent with that defined
   for DNS SRV [RFC2782].

5.
Now:
The distribution algorithm used by Diameter nodes supporting the
   Diameter Load mechanism is an implementation decision but it needs to
   result in similar behavior as the algorithm specified in [RFC2782].

Proposed:
The distribution algorithm used by Diameter nodes supporting the
   Diameter Load mechanism is an implementation decision but it needs to
   result in similar behavior as the algorithm *described
   for the use of weigth values in* [RFC2782].

5.1
Now:
  If Agent A4 supports the Load mechanism then it will verify that the
   load information received is valid.  For a HOST load report this is
   achieved by matching the identity included in the load information
   with the identity of the host node from which the answer message was
   received.

Comments:
A4 behaviour should be defined generically. In the example, we know S[n] is a peer of A4, but generically A4 will not know it when receiving a HOST report.
Then, for an AgentX the HOST load report is valid as long as it is responsible for server selection, as explained for A1 below:
A1's actions depend on whether A1 is
   responsible for doing server selection.  If A1 is not doing server
   selection then A1 ignores the HOST load report.  If A1 is responsible
   for doing server selection then it stores the load information for
   S[n] in its routing information for the handling of subsequent
   request messages.  In both cases A1 leaves the HOST report in the
   message

6.1.1
Now: 
   The method for determining the load value included in the load report
   is an implementation decision.

Comments:
In line to comment above, I agree it should be implementation specific, but we need to provide some guidance to be able to provide a value that could be used to achieve a successful load balancing.

6.2
Now:
   If the Diameter node is responsible for doing server selection then
   it SHOULD save the load value included in the Value AVP included in
   the Load AVP of type HOST in its routing information.

Proposed:
   If the Diameter node is responsible for doing server selection then
   it SHOULD save the load value included in the Value AVP included in
   the Load AVP of type HOST.

Reasoning:
It is a bit misleading to state that is should be stored "in its routing information". It has to be used for server selection, regardless "how" and "where" it is stored.

7.3
Now:
   The Load-Value AVP (AVP code TBD3) is of type Unsigned64.  It is used
   to convey relative load information about the sender of the load
   report.

Comments:
*Relative load* 
It seems it refers to what I commented before, about the "relative dynamic load", in that comment it is relative to the weight. 
But as the draft is now, I think it is misleading, since it is not clear to what it refers.

7.3
Now:
   The Load-Value AVP is specified in a manner similar to the weight
   value in DNS SRV ([RFC2782]).

   The Load-Value has a range of 0-65535.

   A higher value indicates a lower load on the sending node.  A lower
   value indicates that the sending node is heavily loaded.

      Stated another way, a node that has zero load would have a load
      value of 65535.  A node that is 100% loaded would have a load
      value of 0.

Comments:
I think it could be easier to use a %. It is more straight forward to figure out what it means.

=========== TYPOS========:

2. Terminology and abbreviations

   Routing Information

      Routing Information - Routing information referred to in this
      document can include the Routing and Peer tables defined in RFC
      6733.  It can also include other implementation specific tables
      used to store load information.  This document does not define the
      structure of such tables.

Remove *Routing information* duplicated sentence.

4.1
At any given time that load *maybe*  effectively
   zero
*May be*

5.1
Because the load report is *an* HOST load report, A4 leaves the load
   report in the message it relays.

5.1
   A1 then calculates its own load information and inserts load
   information AVPs of type PEER in the message before sending the
   message to *A1*

  *A1* should be C

6.1.1
      For instance, if the only consumer of the load reports is the
     * endpoints peer* then the endpoint can choose to only include a load
      report when the load of the endpoint has changed by a meaningful
      percentage.  If there are consumers of the endpoint load report
      other *thaen* the *endpoints peer* (this will be the case if other
      nodes are responsible for server selection) then the endpoint
      might choose to include load reports in all answer messages as a
      way of ensuring that all nodes doing server selection get accurate
      load information.

     *endpoint's peer*

6.2
A Diameter node MUST be prepared to process load reports of type HOST
   *and* of type PEER

6.2
      Note that the node needs to be able to handle messages with no
      load reports, messages with just a PEER load report, messages with
      just *an* HOST load report and messages with both types of load
      reports.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: martes, 24 de mayo de 2016 17:30
To: [email-masked]
Subject: [Dime] WGLC #1 for draft-ietf-dime-load-02

Folks,

This email starts the WGLC #1 for draft-ietf-dime-load-02. Please, review the document, post your comments to the mailing list and also insert them into the Issue Tracker with your proposed resolution.

WGLC starts: 5/24/2016
        ends: 6/7/2016 EOB PDT

- Jouni & Lionel

---

From: "Gunn, Janet P" <[email-masked]>
Date: Tue, 21 Jun 2016 16:16:00 +0000

Comments in line <JPG>

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Monday, June 20, 2016 5:14 AM
To: [email-masked]; [email-masked]
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello all,

I think we need to keep only the scenarios that are "in scope of this effort", what I understand as "suitable for load conveyance as stated in this draft".
If some of them are not considered suitable by any reasons, I presume they should be removed.
<JPG> Or note as (counter) examples of scenarios NOT suitable.</JPG>

Abstract:

Now:

Reasoning:

<JPG> Agree. Conveying is better. </JPG>

1. Introduction:
Now:

Proposal:

<JPG> Agree.  Itt would make sense to have a section, or even an appendix, which lists the requirements, and notes whichare/are not met. </JPG>

1. Introduction

Now:

Proposal

<JPG> Agree. See above comment. </JPG>

Now:
Load

Proposed:
Load

Reasoning:

<JPG> I do not like either. "Capacity" is what the node can do.

 "Available capacity" is actually HIGH when there is a low load level, and LOW when there is a high laod level.

If you want to avoid "Utilization", which implies an explicit calculation, you could say "the relative usage of the Daimeter message processing capacity'" </JPG>

4.1
Now:

Proposed:

<JPG> RFC7683 is clear that the Overload Report may be used to trigger EITHER a loss based algorithm, or a different (e.g. rate based) algorthm.  So the summary here should not be restricted to a loss-based description.  Perhaps "--by an indicated amount (by default), or as prescribed by the selected abatement algorithm." </JPG>

4.1
Now:

Proposed
  (remove)

Reasoning:

<JPG> OK with this, though not sure it is necessary to delete.</JPG>

4.2
Now:

Proposed:

<JPG> Agree </JPG>

4.2
Now

Proposed:

Reasoning:

<JPG> Agree in principle, but I think that "..both of these uses of laod information should be ..." reads better than  "... both of these load information uses should be ...". </JPG>

5.
Now

Proposed:

<JPG> Slightly different comment.  I think the phrase " The DOIC overload reports much remain in the message..." is a typo and should be " The DOIC overload reports must (or MUST?) remain in the message.."  <?JPG>

5.
Now

Comments:

<JPG> Agree with the thought- if "Little Server" is 30% utilized and "Big Server" is 50% utilized, it still makes sense to send more traffic to Big Server.  But I am not sure if that is withn the scope of this document. </JPG>

5.
Now

Proposed:

<JPG> Agree. </JPG>

5.
Now:

Proposed:

<JPG> Agree in principle. NIT- replace "similar behavior as" with "similar behavior to", and repalce "weigth" with "weight". </JPG> (End of my comments)

5.1
Now:

Comments:

6.1.1
Now:

Comments:

6.2
Now:

Proposed:

Reasoning:

7.3
Now:

Comments:
*Relative load*

7.3
Now:

Comments:

   Routing Information

4.1

5.1

5.1

  *A1* should be C

6.1.1

     *endpoint's peer*

6.2

6.2

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: martes, 24 de mayo de 2016 17:30
To: [email-masked]
Subject: [Dime] WGLC #1 for draft-ietf-dime-load-02

Folks,

WGLC starts: 5/24/2016
        ends: 6/7/2016 EOB PDT

- Jouni & Lionel

This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 22 Jun 2016 09:50:38 -0500

I'll respond to both Maria Cruz and Janet's comments using Janet's email.

Regards,

Steve

> <JPG> Or note as (counter) examples of scenarios NOT suitable.</JPG>
SRD> I propose that we take out the above sentence.  It looks to me like 
all of the scenarios are perfectly valid.
> Shouldn't this part of the annex be in the regular body of the draft?
SRD> I agree this would be good in the body of the draft.  I'll move it 
to the end of section 6.
> <JPG> Agree. Conveying is better. </JPG>
SRD> Agreed
> <JPG> Agree.  Itt would make sense to have a section, or even an appendix, which lists the requirements, and notes whichare/are not met. </JPG>
SRD> I'm okay with Maria Cruz's suggestion that we copy the requirements 
text for 23 and 24 into the document and have made this change.  I'm not 
sure there is benefit to include a detailed, requirement by requirement 
analysis for the Load mechanism but I'm open to this if there is 
consensus that it is needed.  I would prefer that specific shortcomings 
based on unaddressed requirements are  brought forward.
> <JPG> Agree. See above comment. </JPG>
SRD> See my comment above.  The introduction is giving motivation for 
why this mechanism is being defined.  I  think listing Req 23 and Req 24 
is strong enough motivation.  Having a mention that there are other 
requirements that mention the need for load adds to that motivation.  I 
don't see the need to list those requirements in this document.  A 
reader can go to the requirements document to find then if needed.
> If you want to avoid "Utilization", which implies an explicit calculation, you could say "the relative usage of the Daimeter message processing capacity'" </JPG>
SRD> I'm good with Janet's suggestion.
> <JPG> RFC7683 is clear that the Overload Report may be used to trigger EITHER a loss based algorithm, or a different (e.g. rate based) algorthm.  So the summary here should not be restricted to a l…
SRD> I've updated this based on Janet's suggestion.
> <JPG> OK with this, though not sure it is necessary to delete.</JPG>
SRD> This sentence adds emphasis to the point that a similar result can 
happen between load and overload, leading into the next sentence 
outlining the fundamental difference between the two.  I don't see the 
harm in leaving it, even if what is says is implied by the previous 
paragraph.
>     the diameter node can  take other proactive steps as well.
SRD> Agreed.
> <JPG> Agree in principle, but I think that "..both of these uses of laod information should be ..." reads better than  "... both of these load information uses should be ...". </JPG>
SRD> Changed to:

         both of these uses of load information should
         be accomplished by a Diameter node that performs server selection.

>     all the way from the reporting node to the node that is the target
SRD> How about "although only one node actually reacts to the report", 
changing consume to react.
>      first one is transmitted end-to-end*.
SRD> This is covered in the following paragraphs.
>     endpoint as part of  the server selection decision. *More than one node may make use of the load information received*
SRD> How about:

    Unlike with DOIC, more than one node may make use of the load 
information received.
> <JPG> Slightly different comment.  I think the phrase " The DOIC overload reports much remain in the message..." is a typo and should be " The DOIC overload reports must (or MUST?) remain in the me…
SRD> Yes, it was meant to be must but I think it is better to remove the 
word altogether, leaving:

       The DOIC overload reports remain in the message all the way from the
       reporting node to the node that is the target for the answer message.
> <JPG> Agree with the thought- if "Little Server" is 30% utilized and "Big Server" is 50% utilized, it still makes sense to send more traffic to Big Server.  But I am not sure if that is withn the s…
SRD> I don't understand the concern.  The load values supplied will be 
input into the route selection algorithm as specified in RFC2782.  If a 
node isn't getting enough traffic it will change its load value to a 
lower value and will start getting more traffic.

>    specified in a manner consistent with that defined
SRD> I don't understand the need for this change.
> <JPG> Agree in principle. NIT- replace "similar behavior as" with "similar behavior to", and repalce "weigth" with "weight". </JPG> (End of my comments)
SRD> Agreed.
>     request messages.  In both cases A1 leaves the HOST report in the
SRD> Agreed.  The section now looks as follows:

    If Agent A4 supports the Load mechanism then A4's actions depend on
    whether A4 is responsible for doing server selection.  If A4 is not
    doing server selection then A4 ignores the HOST load report.  If A4
    is responsible for doing server selection then it stores the load
    information for S[n] in its routing information for the handling of
    subsequent request messages.  In both cases A4 leaves the HOST report
    in the message.

       Note: If A4 does not support the Load mechanism then it will relay
       the answer message without doing any processing on the load
       information.  In this case the load information AVPs will be
       relayed without change.

    A4 then calculates its own load information and inserts load
    information AVPs of type PEER in the message before sending the
    message to A1.

> In line to comment above, I agree it should be implementation specific, but we need to provide some guidance to be able to provide a value that could be used to achieve a successful load balancing.
SRD> See my comment above about DNS SRV algorithm.
> It is a bit misleading to state that is should be stored "in its routing information". It has to be used for server selection, regardless "how" and "where" it is stored.
SRD> This is based on the definition of routing information in section 2.
> I think it could be easier to use a %. It is more straight forward to figure out what it means.
SRD> Percentage can be mapped to the range 0-65535 if that is the 
internal implementation decision.  The goal here is to be consistent 
with RFC2782.
> Remove *Routing information* duplicated sentence.
SRD> I think it reads better as is.
> At any given time that load *maybe*  effectively
SRD> Agreed.
>     report in the message it relays.
SRD> This was addressed by the change to A4 wording above.
>     information AVPs of type PEER in the message before sending the
SRD> Agreed.
>        way of ensuring that all nodes doing server selection get accurate
SRD> Agreed.
> A Diameter node MUST be prepared to process load reports of type HOST
SRD> Agreed.
>        just *an* HOST load report and messages with both types of load
SRD> Agreed.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 27 Jun 2016 07:18:46 +0000

Hello Steve, Janet,
See my comments below.
Thanks
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: miércoles, 22 de junio de 2016 16:51
To: [email-masked]
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Regards,

Steve

MCRUZ> Fine

MCRUZ> Fine

> <JPG> Agree. Conveying is better. </JPG>
SRD> Agreed
MCRUZ> Fine

> <JPG> Agree.  Itt would make sense to have a section, or even an 
> appendix, which lists the requirements, and notes whichare/are not 
> met. </JPG>
SRD> I'm okay with Maria Cruz's suggestion that we copy the requirements
text for 23 and 24 into the document and have made this change.  I'm not sure there is benefit to include a detailed, requirement by requirement analysis for the Load mechanism but I'm open to this if there is consensus that it is needed.  I would prefer that specific shortcomings based on unaddressed requirements are  brought forward.
MCRUZ> Fine

SRD> See my comment above.  The introduction is giving motivation for
why this mechanism is being defined.  I  think listing Req 23 and Req 24 is strong enough motivation.  Having a mention that there are other requirements that mention the need for load adds to that motivation.  I don't see the need to list those requirements in this document.  A reader can go to the requirements document to find then if needed.
MCRUZ> Fine

> If you want to avoid "Utilization", which implies an explicit 
> calculation, you could say "the relative usage of the Daimeter message 
> processing capacity'" </JPG>

> <JPG> RFC7683 is clear that the Overload Report may be used to trigger 
> EITHER a loss based algorithm, or a different (e.g. rate based) 
> algorthm.  So the summary here should not be restricted to a 
> loss-based description.  Perhaps "--by an indicated amount (by 
> default), or as prescribed by the selected abatement algorithm." 
> </JPG>
MCRUZ> Fine

SRD> This sentence adds emphasis to the point that a similar result can
happen between load and overload, leading into the next sentence outlining the fundamental difference between the two.  I don't see the harm in leaving it, even if what is says is implied by the previous paragraph.
MCRUZ> My problem with the sentence is that it is not straight forward to what refers "none of this". The reader will look above to check what it refers to... and it seems to be the whole paragraph, i.e. the differences between load and overload. But this sentence refers again to something that is mentioned above. Then, I think the sentence, as it is, is misleading that turns reading a bit unease. 

>     the diameter node can  take other proactive steps as well.
SRD> Agreed.
MCRUZ> Fine

> <JPG> Agree in principle, but I think that "..both of these uses of 
> laod information should be ..." reads better than  "... both of these 
> load information uses should be ...". </JPG>
SRD> Changed to:

MCRUZ> Fine

SRD> How about "although only one node actually reacts to the report",
changing consume to react.
MCRUZ> I think "consume" is better since it implies that from then on the report is removed.

SRD> This is covered in the following paragraphs.
MCRUZ> Yes, but I think we need an introduction for the analysis below, in order to understand we are going to compare. Trying to ease reading.

>     endpoint as part of  the server selection decision. *More than one 
> node may make use of the load information received*
SRD> How about:

    Unlike with DOIC, more than one node may make use of the load information received.
MCRUZ> Fine.

> <JPG> Slightly different comment.  I think the phrase " The DOIC 
> overload reports much remain in the message..." is a typo and should 
> be " The DOIC overload reports must (or MUST?) remain in the 
> message.."  <?JPG>

MCRUZ> Fine

SRD> I don't understand the concern.  The load values supplied will be 
input into the route selection algorithm as specified in RFC2782.  If a 
node isn't getting enough traffic it will change its load value to a 
lower value and will start getting more traffic.
MCRUZ> Unless the LOAD info provided is in fact a value that represents the available capacity, then the load balancing will not select the less loaded server. Being able to select the less loaded server is the whole purpose of this mechanism, then we need to find a way to provide a LOAD value from different servers that we are able to compare, i.e. the value provide must indicate the available capacity regardless the static capacity of each server. 
Providing an example, let me use dynamic Load (say DL) in % (100% is totally loaded) that I found it easier for calculation:
- Server1: weight=1500; DL= 2%
- Server2: weight=55000; DL= 70%
Then, if we only use DL in the LB algorithm, obviously Server 1 seems to be clearly less loaded, but however, taking into account its weight is much smaller it may be the other way around. In fact, if traffic is redirected to this server, it may get overloaded rapidly (due to its small capacity).
One possible way to calculate the relative DL is  to divide it by the weight, then for this example:
- Server1 RDL= 10000 * (2/1500) = 13.33
- Server2 RDL= 10000 * (70/55000) = 12.73
(I multiplied by 10000 simply to get rid of the decimals for our discussion).
Then, we actually find out that available load for both servers is pretty similar. In fact, in this case, a correct load balancing should select Server2 as the less loaded server instead of server1.
My proposal is to consider this reflection in the draft, and then make a clear distinction between dynamic load (DL) and RELATIVE DL. We need to provide the RDL in the message, not DL.

SRD> I don't understand the need for this change.
MCRUZ> Using "relative" is misleading unless we clarify "relative to what".

> <JPG> Agree in principle. NIT- replace "similar behavior as" with "similar behavior to", and repalce "weigth" with "weight". </JPG> (End of my comments)
SRD> Agreed.
MCRUZ> Fine

MCRUZ> Fine

SRD> See my comment above about DNS SRV algorithm.
MCRUZ> This is related to my comment above to 5, but to the part related to a way to provide a LOAD value that represents the available capacity of a server, taking into account its static capacity.

SRD> Percentage can be mapped to the range 0-65535 if that is the 
internal implementation decision.  The goal here is to be consistent 
with RFC2782.
MCRUZ> Why do we need to keep consistency to that RFC? I think it is clearer to use a percentage, it is more straight forward to identify the available load we refer to.
E.g. 50% loaded, using SRV is 32767,5;  25% is 49151,25;  and so on.  
In the mechanism we are defining we do not have the need to keep using a complex value like this one, when we can simply use 0 to 100%, 0 (totally available), 100 (totally loaded).
In fact, this is in line to the definition in the doc:

Load
        The* Diameter message processing  available capacity of a node*.  A low load level
        indicates that the Diameter node is under utilized.  A high load
        level indicates that the node is closer to being fully utilized.

SRD> Agreed.
SRD> Agreed.
SRD> Agreed.
SRD> Agreed.
SRD> Agreed.

---

From: "Gunn, Janet P" <[email-masked]>
Date: Mon, 27 Jun 2016 15:54:52 +0000

I am OK with the responses to my comments. 

 In cases where there is still a differnec of opinion, I do not have  a strong opinion either way.

Janet

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Monday, June 27, 2016 3:19 AM
To: Steve Donovan <[email-masked]>; [email-masked]
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello Steve, Janet,
See my comments below.
Thanks
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: miércoles, 22 de junio de 2016 16:51
To: [email-masked]
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Regards,

Steve

SRD> Agreed
MCRUZ> Fine

SRD> Agreed.
MCRUZ> Fine

SRD> Changed to:

SRD> How about:

> <JPG> Agree with the thought- if "Little Server" is 30% utilized and 
> "Big Server" is 50% utilized, it still makes sense to send more 
> traffic to Big Server.  But I am not sure if that is withn the scope 
> of this document. </JPG>
input into the route selection algorithm as specified in RFC2782.  If a node isn't getting enough traffic it will change its load value to a lower value and will start getting more traffic.
- Server2 RDL= 10000 * (70/55000) = 12.73 (I multiplied by 10000 simply to get rid of the decimals for our discussion).

> <JPG> Agree in principle. NIT- replace "similar behavior as" with 
> "similar behavior to", and repalce "weigth" with "weight". </JPG> (End 
> of my comments)
SRD> Agreed.
MCRUZ> Fine

MCRUZ> Fine

internal implementation decision.  The goal here is to be consistent with RFC2782.

Load

SRD> Agreed.
SRD> Agreed.
SRD> Agreed.
SRD> Agreed.
SRD> Agreed.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 29 Jun 2016 09:19:16 -0500

I've removed the items that we have agreement on.

More comments below.

Steve

> MCRUZ> My problem with the sentence is that it is not straight forward to what refers "none of this". The reader will look above to check what it refers to... and it seems to be the whole paragraph…
SRD> How about: "A Diameter node can, however, decide to reduce offered 
load based on load information."

...
> MCRUZ> I think "consume" is better since it implies that from then on the report is removed.
SRD> How about consume and react?  "although only one node actually 
consumes and reacts to the report"
> MCRUZ> Yes, but I think we need an introduction for the analysis below, in order to understand we are going to compare. Trying to ease reading.
SRD> Okay.
...
> MCRUZ> Unless the LOAD info provided is in fact a value that represents the available capacity, then the load balancing will not select the less loaded server. Being able to select the less loaded…
SRD> I view the goal of this a little differently.  The goal is to make 
sure that requests are delivered to nodes with available capacity.  It 
is not strictly necessary that every request goes to the least loaded node.
> My proposal is to consider this reflection in the draft, and then make a clear distinction between dynamic load (DL) and RELATIVE DL. We need to provide the RDL in the message, not DL.
SRD> This is about how the load value is calculated which is explicitly 
stated as being an implementation decision.
> MCRUZ> Using "relative" is misleading unless we clarify "relative to what".
SRD> Okay.  How about a small change to: "The load report includes a 
value **indicating** the load of the sending node..."
...
> MCRUZ> This is related to my comment above to 5, but to the part related to a way to provide a LOAD value that represents the available capacity of a server, taking into account its static capacity.
SRD> Okay, I'll propose some text, based on your example, in the next 
version of the draft.  This would be a non normative example of how 
someone might compute the load value.
...
> MCRUZ> Why do we need to keep consistency to that RFC? I think it is clearer to use a percentage, it is more straight forward to identify the available load we refer to.
SRD> This was discussed and agreed to early in the process of writing 
this mechanism.  There a a couple of reasons, first, its an algorithm 
that has already been specified and implemented.  Second, it  allows 
someone who has already implemented the DNS SRV algorithm to reuse it.  
Third, while RFC6733 doesn't directly address load 
balancing/distribution, it does reference use of DNS SRV for handling 
dynamic connections.  It is not unreasonable to expect that there are 
implementations would use the DNS SRV value for nodes that don't support 
load, along with load values received.
> In fact, this is in line to the definition in the doc:
SRD> I really don't want to revisit this decision this late in the 
game.  While not as intuitive to a casual reader of the specification as 
a percentage value might be, Using the DNS SRV value works.
...

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 29 Jun 2016 17:18:49 +0000

Hello Steve,
Thanks for the responses, see some more comments below
Best regards
/MCruz

On 6/27/16 2:18 AM, Maria Cruz Bartolome wrote:
> SRD> This sentence adds emphasis to the point that a similar result 
> SRD> can

SRD> Okay.
...
SRD> I view the goal of this a little differently.  The goal is to make 
sure that requests are delivered to nodes with available capacity.  It 
is not strictly necessary that every request goes to the least loaded node.
MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to be able to choose a node with available  load (I agree), but among the node with available load we need to choose the least loaded (or one of the least loaded). It does not make sense, in my opinion, to simply select a node with available load, when we are providing info about load. The information provided should be valid to be able to select the least (or close to) loaded.

SRD> This is about how the load value is calculated which is explicitly 
stated as being an implementation decision.
MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided should be the relative available load, taking into account the static weight. This is the only way we are providing a load value that can possibly be used by a client to LOAD-balance. 
I could accept that we leave the way to do so up to implementations.
Proposal: "LOAD should be calculated in a way that reflects the available load independently of the weight of each server, in order to allow the Diameter node that performs server selection to accurateraly compare values from different servers, i.e. LOAD value identifies the same amount of available capacity, regardless the server that has calculate it. "

...
SRD> Okay, I'll propose some text, based on your example, in the next 
version of the draft.  This would be a non normative example of how 
someone might compute the load value.
MCRUZ> Including the example is fine. Although above I proposed some normative text as well that I think we need to consider.

...
SRD> This was discussed and agreed to early in the process of writing 
this mechanism.  There a a couple of reasons, first, its an algorithm 
that has already been specified and implemented.  Second, it  allows 
someone who has already implemented the DNS SRV algorithm to reuse it.  
Third, while RFC6733 doesn't directly address load 
balancing/distribution, it does reference use of DNS SRV for handling 
dynamic connections.  It is not unreasonable to expect that there are 
implementations would use the DNS SRV value for nodes that don't support 
load, along with load values received.
MCRUZ> I do not remember a discussion about this, sorry. I had the impression it was incorporated without much discussion.
However, I do not see that it helps reusing DNS SRV. Does an implementation take profit of anything previously implemented for DNS SRV when deciding what load value include in the AVP? I think the server will calculate the LOAD, and then it needs to reflect a value from totally-available to totally-loaded. It is more straight forward and more intuitive to simply use 0-100 as you agreed below.
I did not consider the comment before, sorry, but I think now it can be easily changed and simplify all the implementations and interpretation of LOAD value, don't you think?

---

From: "Trottin, Jean-Jacques (Nokia - FR)" <[email-masked]>
Date: Thu, 30 Jun 2016 10:59:32 +0000

Dear all
 
About discussion regarding draft-ietf-dime-load-02, I was in line with the new 02 version Steve distributed some time ago. I here reviewed Maria Cruz comments and Steve's reactions.
 
Globally I remain in line with the Steve's hereafter comments. My main comment is on .5 about server capacity. The other updates have for me no protocol impact and were mainly wording enhancements  and  are worthwhile for me .
Please see my few comments in line (with JJ>). Main one is in 5. about the capacity topic
 
I would also take this opportunity to indicate that due to my job evolution, my colleague Balint Uveges will follow the load/overload dime aspects in IETF.

Best regards
 
JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mercredi 29 juin 2016 19:19
À : Steve Donovan; [email-masked]
Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello Steve,
Thanks for the responses, see some more comments below Best regards /MCruz

SRD> How about consume and react?  "although only one node actually
consumes and reacts to the report"
MCRUZ> Fine
JJ> this would be the only place (here and I also think in DOIC RFC) where "consume" word is used and raising the question what "consume" means, in particular this does not imply to remove the report. "react" was OK for me but no opposition to "consume and react".  

SRD> Okay.
...
> input into the route selection algorithm as specified in RFC2782.  If 
> a node isn't getting enough traffic it will change its load value to a 
SRD> I view the goal of this a little differently.  The goal is to make
sure that requests are delivered to nodes with available capacity.  It is not strictly necessary that every request goes to the least loaded node.
MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to be able to choose a node with available  load (I agree), but among the node with available load we need to choose the least loaded (or one of the least loaded). It does not make sense, in my opinion, to simply select a node with available load, when we are providing info about load. The information provided should be valid to be able to select the least (or close to) loaded.

JJ> I think we can remain with only the relative load information  proposed in the draft even when servers have different capacity. If a small capacity node sees its incoming traffic increasing it will quickly react by sending a higher load value, which, when received by a sending node, will become higher than the values  received from other nodes with higher capacity. Sending node will then reduce the traffic towards this node to ensure load balancing and will continue to adjust according to the load values received. This seems a simple loopback mechanism ensuring a right load balancing.
Do you think it is not sufficient? To add capacity value (weight, group of servers) ..)increases the increases the complexity given this capacity may vary over time (eg a partial failure) so possibly requiring to be dynamically updated. 
More sophisticated behaviors can be introduced (implementation specific) without impacting the protocol and AVPs specified in the draft. If justified requirements drive to new AVPs, this could be part of future evolution, out of the scope of the present draft .

JJ> "relative" also used in the proposed update definition of "load" in section 2, which is consistent with the definition of the Load-Value AVP in 7.3., so for me relative is not misleading.     
...

JJ> see my above comments to 5. The sender adjusts its traffic according the evolution of the received load values.  

...

JJ> Preliminary version of the draft started with %, then Steve proposed to use the same definition as with SRV which didn't raise comments, I am OK to remain on Steve proposal.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 30 Jun 2016 12:50:11 +0000

Hello JJ,

Nice to listening from you again.
See comments below
/MCruz

-----Original Message-----
From: Trottin, Jean-Jacques (Nokia - FR) [mailto:[email-masked]] 
Sent: jueves, 30 de junio de 2016 13:00
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]
Cc: Uveges, Balint (Nokia - HU/Budapest); Wiehe, Ulrich (Nokia - DE/Munich)
Subject: RE: [Dime] WGLC #1 for draft-ietf-dime-load-02

Dear all

 

Best regards
 
JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : mercredi 29 juin 2016 19:19 À : Steve Donovan; [email-masked] Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello Steve,

SRD> Okay.
...

> - Server2 RDL= 10000 * (70/55000) = 12.73 (I multiplied by 10000 
> simply to get rid of the decimals for our discussion).

JJ> I think we can remain with only the relative load information  proposed in the draft even when servers have different capacity. If a small capacity node sees its incoming traffic increasing it will quickly react by sending a higher load value, which, when received by a sending node, will become higher than the values  received from other nodes with higher capacity. Sending node will then reduce the traffic towards this node to ensure load balancing and will continue to adjust according to the load values received. This seems a simple loopback mechanism ensuring a right load balancing.
MCRUZ> This does not assure a proper load-balancing, because the client does not have information it can compare, then it does not know which server is less loaded, not even approximately. Obviously, when a server gets more loaded it will provide the information, but this will cause oscillations, that could even be critical for a server. For example, if one server has a very small weight, compared to the rest, it may be selected as the destination of requests but it would get easily loaded, and again, it needs to react. 
Moreover, the servers in the pool with higher capacity will be normally underutilized. In general, resources are not efficiently use (bigger server tend to be underutilized), the load fluctuates a lot (specially for the small servers), and some servers may be overloaded with peaks of traffic (small servers).
Then, my proposal is to include a normative sentence, as above, although the way to specifically do it may be operator specific. Then, on top of that, the example I provided is useful to understand the situation and I think should be in the draft as well.

JJ> "relative" also used in the proposed update definition of "load" in section 2, which is consistent with the definition of the Load-Value AVP in 7.3., so for me relative is not misleading.
MCRUZ> I made same comment to that section. I think Steve's proposal is fine and more accurate.

...
SRD> Okay, I'll propose some text, based on your example, in the next
version of the draft.  This would be a non normative example of how someone might compute the load value.
MCRUZ> Including the example is fine. Although above I proposed some normative text as well that I think we need to consider.

JJ> see my above comments to 5. The sender adjusts its traffic according the evolution of the received load values.  
MCRUZ> See my comments above. This causes a bunch of problems.

...

MCRUZ> There is no reason to keep it unless we think it has some advantages, which as I explained above, I do not think there are. Let me know if you see any advantages.