Subject: Re: [Dime] Proposed resolutions of LOAD discussion

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 2 Sep 2016 09:56:36 +0000

Hello Steve,

Thanks for the proposal.
I still think the text is a bit misleading:

"The calculated LOAD value MUST reflect the sending Diameter nodes 
capacity relative to the maximum available capacity for the sending 
Diameter node."

I think it should be:
"The calculated LOAD value MUST reflect the sending Diameter node 
capacity relative to the maximum available capacity for a sending 
Diameter node."

Reasoning: a node may have a very limited maximum capacity, but the key point is precisely to provide a LOAD value relative to the maximum value A node may have. 

I hope this clarifies
Thanks
/MCruz

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: martes, 30 de agosto de 2016 5:59
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Proposed resolutions of LOAD discussion

Maria Cruz,

Thanks for your comments.  See my replies inline.

Regards,

Steve

On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote:
> Hello Steve,
>
> Thanks for the proposals, see below
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
> Sent: martes, 16 de agosto de 2016 16:50
> To: [email-masked]
> Subject: [Dime] Proposed resolutions of LOAD discussion
>
> All,
>
> I have outlined proposed solutions for the issues raised in the discussion around the Diameter Load draft.
>
> Please let me know if I've missed anything from the discussion.
>
> Regards,
>
> Steve
>
> Primary Issues:
>
> 1) Use of DNS SRV weighted value as format for LOAD value.
>
> This was discussed and agreed to early in the process.  It has the advantage that Diameter nodes can use a combination of values received via the DNS SRV interface and dynamic values received through the Diameter LOAD interface.  While I agree that it isn't as intuitive as a straight percentage value, I don't see this as compelling enough of a reason to change a decision the working group has already made.
> [MCruz] I still think using SRV values is error prone and anti-intuitive, but I can live with this if you really think it is not possible to re-evaluate this now.
SRD> I haven't seen any argument that using the SRV values doesn't 
work.  As such, I prefer to not change this at this stage of the process.
>
> 2) Need to add wording that the calculated LOAD value needs to be based on overall available capacity.
>
> I agree with Maria Cruz's comment that we need to add wording indicating that the calculated LOAD value needs to reflect available capacity.  To this end, I propose adding the following to section 6.1 (this is based on wording proposed by Maria Cruz):
>
> The calculated LOAD value MUST reflect the Diameter nodes capacity relative to the total available capacity across the Diameter nodes to which requests can be routed.  This could be either a set of Diameter endpoints or a set of Diameter agents, depending on the type of the LOAD report.  The method for determining the total available capacity is outside of the scope of this document.
>
>      Note: The LOAD value should be calculated in a way that reflects the available load independently of the weight of each
>      server.  This allows the Diameter node that routes a request, including nodes doing server selection and agents routing
>      requests, to accurately compare values from different nodes.  Any specific LOAD value needs to identify  the same
>      amount of available capacity, regardless the Diameter node that calculates the value.
>
> The mechanism used to calculate the LOAD value that fulfills this requirement is an implementation decision.
>
>
> [MCruz] Some comments to proposed text:
> " The calculated LOAD value MUST reflect the Diameter nodes capacity relative to the total available capacity across the Diameter nodes to which requests can be routed. ": I think it may be misleading what is the "total available capacity across nodes".
> See proposal:
> " The calculated LOAD value MUST reflect each Diameter node capacity relative to the maximum available capacity for a Diameter node to which requests can be routed."
SRD> This wording could imply that the LOAD value carries load 
information for multiple Diameter nodes.  How about the following:

"The calculated LOAD value MUST reflect the sending Diameter nodes 
capacity relative to the maximum available capacity for the sending 
Diameter node."

>
> 3) Wording in Appendix A.
>
> Before we reword Appendix A, we need to decide if it is still needed.
> It was valuable in helping to generate the solution but I'm not convinced it is still needed in the document.  Is there objection to removing this section?
>
> [MCruz] I prefer this to remain, it provides some hints that may be valuable for first time readers.
SRD> I'd like to hear other opinions on this as there is work required 
to make the section consistent with the mechanism defined. Implementors 
will still have access to this information by reviewing the history of 
the process of writing the specification.

SRD> Are there schedule pressures in 3GPP to get this to RFC state?  If 
so, it will be faster to just remove this section.
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Mon, 19 Sep 2016 12:01:51 -0500

Maria Cruz,

I think we are saying the same thing.  My original has an unfortunate 
typo and should have read as follows:

"The calculated LOAD value MUST reflect the sending Diameter node's 
capacity relative to the maximum available capacity for the sending 
Diameter node."

In thinking about this, the word sending might also not be clear 
enough.  We might want to use the reporting node instead.  This would 
change it to the following:

"The calculated LOAD value MUST reflect the reporting Diameter node's 
capacity relative to the maximum available capacity for the reporting 
Diameter node."

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 19 Sep 2016 17:11:46 +0000

Hello Steve,

Thanks for the clarification
I still think the last part of the sentence is misleading: "... relative to the maximum available capacity for the reporting Diameter node ".

It should be "... relative to the maximum available capacity for a reporting Diameter node".

The reasoning is that it should be relative to the maximum capacity not of that particular reporting node, but any of the nodes. That is, if we use SRV to provide the load value, the maximum load is 65535, but a particular node may just have a maximum capacity of e.g. 4000. Then the load value of this reporting node should be relative not to 4000 but to 65535, and it should be done the same for all nodes, in a way that the load is then comparable by the reacting node.
Is my point clearer now?
The NOTE you wrote clarified that point in fact.

Best regards
/MCruz

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: lunes, 19 de septiembre de 2016 19:02
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Proposed resolutions of LOAD discussion

Maria Cruz,

I think we are saying the same thing.  My original has an unfortunate typo and should have read as follows:

"The calculated LOAD value MUST reflect the sending Diameter node's capacity relative to the maximum available capacity for the sending Diameter node."

In thinking about this, the word sending might also not be clear enough.  We might want to use the reporting node instead.  This would change it to the following:

"The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum available capacity for the reporting Diameter node."

Regards,

Steve

On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote:
> to make the section consistent with the mechanism defined. 
> Implementors will still have access to this information by reviewing 
> the history of the process of writing the specification.
>
> SRD> Are there schedule pressures in 3GPP to get this to RFC state?  
> SRD> If

---

From: Steve Donovan <[email-masked]>
Date: Mon, 19 Sep 2016 13:34:37 -0500

Actually, looking at it again, I think the following wording is needed:

"The calculated LOAD value MUST reflect the reporting Diameter node's 
capacity relative to the maximum available capacity for the set of 
Diameter nodes that are potential receiving nodes for the future 
messages covered by the LOAD report."

We probably need some words on what the set of Diameter nodes comprises, 
as it is different for HOST reports and PEER reports.

Does this work?

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 19 Sep 2016 18:45:06 +0000

Hello Steve,

See proposal:

"The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum capacity for a Diameter node in the group of nodes the messages are load balanced".

I removed "available" because it may be misinterpreted as "available at a moment in time", what is not right, it is just the maximum capacity it is offered, it can be reached.
"for a Diameter node": in order to indicate that it is the maximum capacity of "any" of the Diameter nodes, what a Diameter node is normally offering. 
But we can limit that to the group of nodes that are receivers of messages, i.e. the load-balancing group.

Does it make sense to you?
Thanks Steve

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: lunes, 19 de septiembre de 2016 20:35
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Proposed resolutions of LOAD discussion

"The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum available capacity for the set of Diameter nodes that are potential receiving nodes for the future messages covered by the LOAD report."

We probably need some words on what the set of Diameter nodes comprises, as it is different for HOST reports and PEER reports.

Does this work?

Steve

On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote:
>> SRD> I'd like to hear other opinions on this as there is work 
>> SRD> required

---

From: <[email-masked]>
Date: Mon, 19 Sep 2016 22:00:54 +0000

Hi,

I was wondering if we could simplify in a way that would be understandable for anyone outside the current discussion.

Is something missing in the following text?

"The calculated LOAD value MUST indicate the relative capacity of a Diameter node to process or forward subsequent request messages. The method for determining the total available capacity is outside of the scope of this document.

NOTE: When the reporting node is not a server, the LOAD value reflects not only the capacity of the reporting node but also the total capacity of the Diameter nodes to which requests can be forwarded."

Lionel

> -----Message d'origine-----
> De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
> Envoyé : lundi 19 septembre 2016 20:45
> À : Steve Donovan; [email-masked]
> Objet : Re: [Dime] Proposed resolutions of LOAD discussion
> 
> Hello Steve,
> 
> See proposal:
> 
> capacity relative to the maximum capacity for a Diameter node in the group of
> nodes the messages are load balanced".
> 
> I removed "available" because it may be misinterpreted as "available at a
> moment in time", what is not right, it is just the maximum capacity it is offered,
> it can be reached.
> "for a Diameter node": in order to indicate that it is the maximum capacity of
> "any" of the Diameter nodes, what a Diameter node is normally offering.
> capacity relative to the maximum available capacity for the set of Diameter
> nodes that are potential receiving nodes for the future messages covered by the
> LOAD report."
> 
> We probably need some words on what the set of Diameter nodes comprises, as
> it is different for HOST reports and PEER reports.
> 
> Does this work?
> 
> Steve
> 
> > I still think the last part of the sentence is misleading: "... relative to the
> maximum available capacity for the reporting Diameter node ".
> >
> > The reasoning is that it should be relative to the maximum capacity not of that
> particular reporting node, but any of the nodes. That is, if we use SRV to provide
> the load value, the maximum load is 65535, but a particular node may just have
> a maximum capacity of e.g. 4000. Then the load value of this reporting node
> should be relative not to 4000 but to 65535, and it should be done the same for
> all nodes, in a way that the load is then comparable by the reacting node.
> > Is my point clearer now?
> capacity relative to the maximum available capacity for the sending Diameter
> node."
> >
> > In thinking about this, the word sending might also not be clear enough.  We
> might want to use the reporting node instead.  This would change it to the
> following:
> >
> capacity relative to the maximum available capacity for the reporting Diameter
> node."
> >
> > Regards,
> >
> > Steve
> >
> >> Reasoning: a node may have a very limited maximum capacity, but the key
> point is precisely to provide a LOAD value relative to the maximum value A node
> may have.
> >>
> >> I hope this clarifies
> >> Thanks
> >> /MCruz
> >>
> >>> This was discussed and agreed to early in the process.  It has the advantage
> that Diameter nodes can use a combination of values received via the DNS SRV
> interface and dynamic values received through the Diameter LOAD interface.
> While I agree that it isn't as intuitive as a straight percentage value, I don't see
> this as compelling enough of a reason to change a decision the working group
> has already made.
> >>> [MCruz] I still think using SRV values is error prone and anti-intuitive, but I
> can live with this if you really think it is not possible to re-evaluate this now.
> >>> I agree with Maria Cruz's comment that we need to add wording indicating
> that the calculated LOAD value needs to reflect available capacity.  To this end, I
> propose adding the following to section 6.1 (this is based on wording proposed
> by Maria Cruz):
> >>>
> >>> The calculated LOAD value MUST reflect the Diameter nodes capacity
> relative to the total available capacity across the Diameter nodes to which
> requests can be routed.  This could be either a set of Diameter endpoints or a set
> of Diameter agents, depending on the type of the LOAD report.  The method for
> determining the total available capacity is outside of the scope of this
> document.
> >>>
> >>>        Note: The LOAD value should be calculated in a way that reflects the
> available load independently of the weight of each
> >>>        server.  This allows the Diameter node that routes a request, including
> nodes doing server selection and agents routing
> >>>        requests, to accurately compare values from different nodes.  Any
> specific LOAD value needs to identify  the same
> >>> The mechanism used to calculate the LOAD value that fulfills this
> requirement is an implementation decision.
> >>>
> >>>
> >>> " The calculated LOAD value MUST reflect the Diameter nodes capacity
> relative to the total available capacity across the Diameter nodes to which
> requests can be routed. ": I think it may be misleading what is the "total
> available capacity across nodes".
> >>> See proposal:
> >>> " The calculated LOAD value MUST reflect each Diameter node capacity
> relative to the maximum available capacity for a Diameter node to which
> requests can be routed."
> >>> It was valuable in helping to generate the solution but I'm not convinced it is
> still needed in the document.  Is there objection to removing this section?
> >>>

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Mon, 19 Sep 2016 22:07:11 +0000

> This was discussed and agreed to early in the process.  It has the advantage that
> Diameter nodes can use a combination of values received via the DNS SRV

[LM] ok to keep DNS SRV weighted value type.

> I agree with Maria Cruz's comment that we need to add wording indicating that
> the calculated LOAD value needs to reflect available capacity.  To this end, I
> The calculated LOAD value MUST reflect the Diameter nodes capacity relative to
> the total available capacity across the Diameter nodes to which requests can be
> routed.  This could be either a set of Diameter endpoints or a set of Diameter
> agents, depending on the type of the LOAD report.  The method for determining
> the total available capacity is outside of the scope of this document.
> 
>     server.  This allows the Diameter node that routes a request, including nodes
> doing server selection and agents routing

[LM] see other email.

> It was valuable in helping to generate the solution but I'm not convinced it is still
> needed in the document.  Is there objection to removing this section?

[LM] if it is only for information, we can just remove them. If someone identifies important aspects that need to be kept, it would mean that the body is not self-consistent. If we keep it, we will have to ensure that the content is correct, even if informative, as the appendix is reviewed during IETF LC as any other part of the document and it would be painful to trigger useless discussions on a pure informative part.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 20 Sep 2016 07:32:25 +0000

Hello Lionel,

We need to clarify "relative to what". This is the part we are rephrasing.

Anyway, I will keep NOTE by Steve:

Note: The LOAD value should be calculated in a way that reflects the
 available load independently of the weight of each
server.  This allows the Diameter node that routes a request, including
nodes doing server selection and agents routing
requests, to accurately compare values from different nodes.  Any
specific LOAD value needs to identify  the same
amount of available capacity, regardless the Diameter node that
calculates the value.
The mechanism used to calculate the LOAD value that fulfils this
requirement is an implementation decision.

Cheers
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: martes, 20 de septiembre de 2016 0:01
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]
Subject: RE: [Dime] Proposed resolutions of LOAD discussion

Hi,

Lionel

---

From: <[email-masked]>
Date: Wed, 21 Sep 2016 20:29:02 +0000

Hi Maria Cruz,

"Relative" could also be simply understood as the fact that it is not an absolute value but a value defined in comparison of arbitrary values fixing a finite range ("0-65535"). At least it is how I have interpreted so far.

And I thought that the remaining point was on how to calculate to determine this value.
I think that the clarification could be that this value reflects either the capacity of the reporting node (when processing the request and generating the answer e.g. server) or its forwarding capacity (when acting as an relay/proxy). And the forwarding case obviously depends on the upstream load capacity.

And this this what I have tried to summarize in:

> De : Maria Cruz Bartolome [mailto:[email-masked]]
> Envoyé : mardi 20 septembre 2016 09:32
> À : MORAND Lionel IMT/OLN; Steve Donovan; [email-masked]
> Objet : RE: [Dime] Proposed resolutions of LOAD discussion
> 
> Hello Lionel,
> 
> Note: The LOAD value should be calculated in a way that reflects the  available
> load independently of the weight of each server.  This allows the Diameter node
> that routes a request, including nodes doing server selection and agents routing
> requests, to accurately compare values from different nodes.  Any specific LOAD
> value needs to identify  the same amount of available capacity, regardless the
> Diameter node that calculates the value.
> The mechanism used to calculate the LOAD value that fulfils this requirement is
> an implementation decision.
> 
> 
> Cheers
> /MCruz
> 
> "The calculated LOAD value MUST indicate the relative capacity of a Diameter
> node to process or forward subsequent request messages. The method for
> NOTE: When the reporting node is not a server, the LOAD value reflects not only
> the capacity of the reporting node but also the total capacity of the Diameter
> nodes to which requests can be forwarded."
> 
> Lionel
> 
> > De : DiME [mailto:[email-masked]] De la part de Maria Cruz
> > Bartolome Envoyé : lundi 19 septembre 2016 20:45 À : Steve Donovan;
> > [email-masked] Objet : Re: [Dime] Proposed resolutions of LOAD
> > discussion
> >
> > Hello Steve,
> >
> > See proposal:
> >
> > capacity relative to the maximum capacity for a Diameter node in the
> > group of nodes the messages are load balanced".
> >
> > I removed "available" because it may be misinterpreted as "available
> > at a moment in time", what is not right, it is just the maximum
> > capacity it is offered, it can be reached.
> > "for a Diameter node": in order to indicate that it is the maximum
> > capacity of "any" of the Diameter nodes, what a Diameter node is normally
> offering.
> > We probably need some words on what the set of Diameter nodes
> > comprises, as it is different for HOST reports and PEER reports.
> >
> > Does this work?
> >
> > Steve
> >
> > > It should be "... relative to the maximum available capacity for a
> > > reporting
> > Diameter node".
> > >
> > particular reporting node, but any of the nodes. That is, if we use
> > SRV to provide the load value, the maximum load is 65535, but a
> > particular node may just have a maximum capacity of e.g. 4000. Then
> > the load value of this reporting node should be relative not to 4000
> > but to 65535, and it should be done the same for all nodes, in a way that the
> load is then comparable by the reacting node.
> > > Is my point clearer now?
> > > I think we are saying the same thing.  My original has an
> > > unfortunate typo and
> > should have read as follows:
> > >
> > > enough.  We
> > point is precisely to provide a LOAD value relative to the maximum
> > value A node may have.
> > >>
> > >> I hope this clarifies
> > >> Thanks
> > >> /MCruz
> > >>
> > >>> Thanks for the proposals, see below Best regards /MCruz
> > >>>
> > >>> I have outlined proposed solutions for the issues raised in the
> > >>> discussion
> > around the Diameter Load draft.
> > >>>
> > that Diameter nodes can use a combination of values received via the
> > DNS SRV interface and dynamic values received through the Diameter LOAD
> interface.
> > While I agree that it isn't as intuitive as a straight percentage
> > value, I don't see this as compelling enough of a reason to change a
> > decision the working group has already made.
> > >>> 2) Need to add wording that the calculated LOAD value needs to be
> > >>> based
> > on overall available capacity.
> > >>>
> > that the calculated LOAD value needs to reflect available capacity.
> > To this end, I propose adding the following to section 6.1 (this is
> > based on wording proposed by Maria Cruz):
> > >>>
> > relative to the total available capacity across the Diameter nodes to
> > which requests can be routed.  This could be either a set of Diameter
> > endpoints or a set of Diameter agents, depending on the type of the
> > LOAD report.  The method for determining the total available capacity
> > is outside of the scope of this document.
> > >>>
> > relative to the total available capacity across the Diameter nodes to
> > which requests can be routed. ": I think it may be misleading what is
> > the "total available capacity across nodes".
> > >>> See proposal:
> > relative to the maximum available capacity for a Diameter node to
> > which requests can be routed."
> > >>> [MCruz] I prefer this to remain, it provides some hints that may
> > >>> be valuable
> > for first time readers.
> > >> Implementors will still have access to this information by
> > >> reviewing the history of the process of writing the specification.
> > >>
> _________________________________________________________________
> ________________________________________________________
> 
> 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.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 21 Sep 2016 17:34:54 -0500

Lionel,

I'm not okay with the note.  It should also just be the capacity of the 
agent in that specific case.

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 23 Sep 2016 12:32:54 +0000

Hello all,

The importance of the "relative" value is not only to provide a value in a range from 0-65535, but that this value is coordinated with the different nodes among which the request could be load-balanced.
The 0-65535 could identify a capacity value for a single Diameter node, but if it does not take into account rest of nodes it will be useless.
As we explained, for an small node, its maximum of capacity (i.e. 65535) could mean a very little capacity compared to a "big" server, even when that server indicates an e.g. low capacity value (e.g. 1000). 
Then, it is key to explain that, and it was what we agreed to include in the doc.

Then, my proposal would be the following:

"The calculated LOAD value MUST reflect the reporting Diameter 
node's capacity relative to the maximum capacity of a Diameter node 
in the group of nodes the messages are load balanced.

Note: The LOAD value should be calculated in a way that reflects the  
available load independently of the weight of each server.  This 
allows the Diameter node that routes a request, including nodes doing 
server selection and agents routing requests, to accurately compare 
values from different nodes.  Any specific LOAD value needs to 
identify  the same amount of available capacity, regardless the Diameter node that calculates the value.

The mechanism used to calculate the LOAD value that fulfils this  requirement is an implementation decision."

I hope this could get agreeable.
Best regards
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: miércoles, 21 de septiembre de 2016 22:29
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]
Subject: RE: [Dime] Proposed resolutions of LOAD discussion

Hi Maria Cruz,

> Envoyé : mardi 20 septembre 2016 09:32 À : MORAND Lionel IMT/OLN; 
> Steve Donovan; [email-masked] Objet : RE: [Dime] Proposed resolutions 
> of LOAD discussion
> 
> Hello Lionel,
> 
> available load independently of the weight of each server.  This 
> allows the Diameter node that routes a request, including nodes doing 
> server selection and agents routing requests, to accurately compare 
> values from different nodes.  Any specific LOAD value needs to 
> identify  the same amount of available capacity, regardless the Diameter node that calculates the value.
> I was wondering if we could simplify in a way that would be 
> understandable for anyone outside the current discussion.
> 
> "The calculated LOAD value MUST indicate the relative capacity of a 
> Diameter node to process or forward subsequent request messages. The 
> method for determining the total available capacity is outside of the 
> scope of this document.
> 
> NOTE: When the reporting node is not a server, the LOAD value reflects 
> not only the capacity of the reporting node but also the total 
> capacity of the Diameter nodes to which requests can be forwarded."
> 
> Lionel
> 
> > "The calculated LOAD value MUST reflect the reporting Diameter 
> > node's capacity relative to the maximum capacity for a Diameter node 
> > in the group of nodes the messages are load balanced".
> >
> > "The calculated LOAD value MUST reflect the reporting Diameter 
> > node's capacity relative to the maximum available capacity for the 
> > set of Diameter nodes that are potential receiving nodes for the 
> > future messages covered by the LOAD report."
> >
> > capacity relative to the maximum available capacity for the 
> > reporting Diameter node."
> > >
> > > Regards,
> > >
> > > Steve
> > >
> > >> "The calculated LOAD value MUST reflect the sending Diameter 
> > >> nodes capacity relative to the maximum available capacity for the 
> > >> sending Diameter node."
> > >>
> > >> I think it should be:
> > >> SRD> I haven't seen any argument that using the SRV values 
> > >> SRD> doesn't
> > >>> 2) Need to add wording that the calculated LOAD value needs to 
> > >>> be based
> > relative to the total available capacity across the Diameter nodes 
> > to which requests can be routed.  This could be either a set of 
> > Diameter endpoints or a set of Diameter agents, depending on the 
> > type of the LOAD report.  The method for determining the total 
> > available capacity is outside of the scope of this document.
> > >>>
> > relative to the total available capacity across the Diameter nodes 
> > to which requests can be routed. ": I think it may be misleading 
> > what is the "total available capacity across nodes".
> > >>> See proposal:
> > >> "The calculated LOAD value MUST reflect the sending Diameter 
> > >> nodes capacity relative to the maximum available capacity for the 
> > >> sending Diameter node."
> > >>
> 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.

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.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 23 Sep 2016 09:39:07 -0500

Maria Cruz,

I'm mostly okay with your proposal.  My concern is that all nodes in the 
group of Diameter nodes need to express their load using the maximum 
capacity of the SAME node in the group.  Your wording implies that 
individual nodes in the group could choose different nodes maximum 
capacity in its calculations.

I also think it works if the maximum total capacity of the group is used.

One other option would be to base this on transactions per second rather 
than capacity.  It might be late to consider this, but we could base it 
on the TPS a node is currently able to handle.  The primary issue with 
this approach is that not all transactions consume the same resources.

Assuming we don't want to switch over to TPS, I propose the following 
modification of Maria Cruz's wording:

"The calculated LOAD value MUST reflect the reporting Diameter
node's capacity relative to the maximum capacity of a Diameter node
in the group of nodes the messages are load balanced.  All nodes
in the group MUST use the same nodes maximum capacity when
calculating it's own LOAD value.

identify  the same amount of available capacity, regardless the Diameter node that calculates the value."

Regards,

Steve

On 9/23/16 7:32 AM, Maria Cruz Bartolome wrote:
>>>> node's
>>>> node's

---

From: <[email-masked]>
Date: Fri, 23 Sep 2016 16:01:43 +0000

Hi,

I have to admit that I'm lost. Maybe not the last time.
And I really have some doubts that people reading the proposed text will be able to understand something.

First of all, it is not only about "loadbalance". You may have a single agent in front of a single server and the load value reported by the agent needs to reflect the capacity to process incoming requests as well as the agent capacity to forward the requests towards the server. And the last one depends on the server capacity. If there is more than one server, the "forwarding capacity" depends on the whole capacity of the server farm.
Is the above summary correct? Is there something missing?

Now, I don't understand the following assertion: "all nodes in the group of Diameter nodes need to express their load using the maximum capacity of the SAME node in the group."
Could you please clarify?

regards,

Lionel

> De : Steve Donovan [mailto:[email-masked]]
> Envoyé : vendredi 23 septembre 2016 16:39
> À : Maria Cruz Bartolome; MORAND Lionel IMT/OLN; [email-masked]
> I'm mostly okay with your proposal.  My concern is that all nodes in the group of
> Diameter nodes need to express their load using the maximum capacity of the
> SAME node in the group.  Your wording implies that individual nodes in the group
> could choose different nodes maximum capacity in its calculations.
> 
> One other option would be to base this on transactions per second rather than
> capacity.  It might be late to consider this, but we could base it on the TPS a
> node is currently able to handle.  The primary issue with this approach is that not
> all transactions consume the same resources.
> 
> capacity relative to the maximum capacity of a Diameter node in the group of
> nodes the messages are load balanced.  All nodes in the group MUST use the
> same nodes maximum capacity when calculating it's own LOAD value.
> 
> Diameter node that calculates the value."
> 
> 
> Regards,
> 
> Steve
> 
> > The importance of the "relative" value is not only to provide a value in a range
> from 0-65535, but that this value is coordinated with the different nodes among
> which the request could be load-balanced.
> > The 0-65535 could identify a capacity value for a single Diameter node, but if it
> does not take into account rest of nodes it will be useless.
> > As we explained, for an small node, its maximum of capacity (i.e. 65535) could
> mean a very little capacity compared to a "big" server, even when that server
> indicates an e.g. low capacity value (e.g. 1000).
> > capacity relative to the maximum capacity of a Diameter node in the
> > group of nodes the messages are load balanced.
> >
> > "Relative" could also be simply understood as the fact that it is not an absolute
> value but a value defined in comparison of arbitrary values fixing a finite range
> ("0-65535"). At least it is how I have interpreted so far.
> >
> > I think that the clarification could be that this value reflects either the capacity
> of the reporting node (when processing the request and generating the answer
> e.g. server) or its forwarding capacity (when acting as an relay/proxy). And the
> forwarding case obviously depends on the upstream load capacity.
> >
> > NOTE: When the reporting node is not a server, the LOAD value reflects not
> only the capacity of the reporting node but also the total capacity of the
> Diameter nodes to which requests can be forwarded."
> >
> >> NOTE: When the reporting node is not a server, the LOAD value
> >> reflects not only the capacity of the reporting node but also the
> >> total capacity of the Diameter nodes to which requests can be forwarded."
> >>
> >> Lionel
> >>
> >>> But we can limit that to the group of nodes that are receivers of messages,
> i.e.
> >>> the load-balancing group.
> >>>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 26 Sep 2016 07:01:12 +0000

Hello,

I think we could simplify a bit the text, and keep what I think is key:

"The LOAD value should be calculated in a way that reflects the available load independently of the weight of each server, in order to accurately compare LOAD values from different nodes. Any specific LOAD value needs to identify  the same amount of available capacity, regardless the Diameter node that calculates the value."

I think this cover our concerns. 
And add the following sentence:

"The mechanism used to calculate the LOAD value that fulfils this  requirement is an implementation decision."

Let me know your views
Best regards
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: viernes, 23 de septiembre de 2016 18:02
To: Steve Donovan; Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] Proposed resolutions of LOAD discussion

Hi,

regards,

Lionel

> De : Steve Donovan [mailto:[email-masked]] Envoyé : vendredi 
> 23 septembre 2016 16:39 À : Maria Cruz Bartolome; MORAND Lionel 
> IMT/OLN; [email-masked] Objet : Re: [Dime] Proposed resolutions of LOAD 
> discussion
> 
> Maria Cruz,
> 
> I'm mostly okay with your proposal.  My concern is that all nodes in 
> the group of Diameter nodes need to express their load using the 
> maximum capacity of the SAME node in the group.  Your wording implies 
> that individual nodes in the group could choose different nodes maximum capacity in its calculations.
> 
> One other option would be to base this on transactions per second 
> rather than capacity.  It might be late to consider this, but we could 
> base it on the TPS a node is currently able to handle.  The primary 
> issue with this approach is that not all transactions consume the same resources.
> 
> group of nodes the messages are load balanced.  All nodes in the group 
> MUST use the same nodes maximum capacity when calculating it's own LOAD value.
> 
> from 0-65535, but that this value is coordinated with the different 
> nodes among which the request could be load-balanced.
> mean a very little capacity compared to a "big" server, even when that 
> server indicates an e.g. low capacity value (e.g. 1000).
> > allows the Diameter node that routes a request, including nodes 
> > doing server selection and agents routing requests, to accurately 
> > compare values from different nodes.  Any specific LOAD value needs 
> > to identify  the same amount of available capacity, regardless the 
> > Diameter node
> value but a value defined in comparison of arbitrary values fixing a 
> finite range ("0-65535"). At least it is how I have interpreted so far.
> >
> > And I thought that the remaining point was on how to calculate to 
> > determine
> this value.
> of the reporting node (when processing the request and generating the 
> answer e.g. server) or its forwarding capacity (when acting as an 
> relay/proxy). And the forwarding case obviously depends on the upstream load capacity.
> >
> > Diameter
> determining the total available capacity is outside of the scope of 
> this document.
> >
> > reflects not
> only the capacity of the reporting node but also the total capacity of 
> the Diameter nodes to which requests can be forwarded."
> >
> >> De : Maria Cruz Bartolome 
> >> [mailto:[email-masked]]
> >> Steve Donovan; [email-masked] Objet : RE: [Dime] Proposed 
> >> resolutions of LOAD discussion
> >>
> >> Hello Lionel,
> >>
> >> Note: The LOAD value should be calculated in a way that reflects 
> >> the available load independently of the weight of each server.  
> >> This allows the Diameter node that routes a request, including 
> >> nodes doing server selection and agents routing requests, to 
> >> accurately compare values from different nodes.  Any specific LOAD 
> >> value needs to identify  the same amount of available capacity, 
> >> regardless the Diameter
> node that calculates the value.
> >> Diameter node to process or forward subsequent request messages. 
> >> The method for determining the total available capacity is outside 
> >> of the scope of this document.
> >>
> >>> Bartolome Envoyé : lundi 19 septembre 2016 20:45 À : Steve 
> >>> Donovan; [email-masked] Objet : Re: [Dime] Proposed resolutions of 
> >>> LOAD discussion
> >>>
> >>> Hello Steve,
> >>>
> >>> See proposal:
> >>>
> >>> node's capacity relative to the maximum capacity for a Diameter 
> >>> node in the group of nodes the messages are load balanced".
> >>>
> >>> I removed "available" because it may be misinterpreted as 
> >>> "available at a moment in time", what is not right, it is just the 
> >>> maximum capacity it is offered, it can be reached.
> >>>> It should be "... relative to the maximum available capacity for 
> >>>> a reporting
> >>> Diameter node".
> >>> particular reporting node, but any of the nodes. That is, if we 
> >>> use SRV to provide the load value, the maximum load is 65535, but 
> >>> a particular node may just have a maximum capacity of e.g. 4000. 
> >>> Then the load value of this reporting node should be relative not 
> >>> to 4000 but to 65535, and it should be done the same for all 
> >>> nodes, in a way that the
> >>>>> nodes capacity relative to the maximum available capacity for 
> >>>>> the sending Diameter node."
> >>>>>
> >>>>> I think it should be:
> >>>>> node capacity relative to the maximum available capacity for a 
> >>>>> sending Diameter node."
> >>>>>
> >>> that Diameter nodes can use a combination of values received via 
> >>> the DNS SRV interface and dynamic values received through the 
> >>> Diameter LOAD
> >> interface.
> >>> value, I don't see this as compelling enough of a reason to change 
> >>> a decision the working group has already made.
> >>> To this end, I propose adding the following to section 6.1 (this 
> >>> is based on wording proposed by Maria Cruz):
> >>>>> nodes capacity relative to the maximum available capacity for 
> >>>>> the sending Diameter node."
> >>>>>
> >>>>>> [MCruz] I prefer this to remain, it provides some hints that 
> >>>>>> may be valuable
> >>> for first time readers.
> >> 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 
> >> 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.
> >
> >
> > 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.
> >