Subject: Re: [Dime] Load Use Case justifying endpoint load reports

From: "Wiehe, Ulrich (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 6 May 2015 12:53:40 +0000

Hi Steve,
I'm not against your proposal, however,
it has been argued that (according to established routing principles)
in step 4) Destination-Host is not part of the information used to
determine the route.
Any reaction to this?

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Thursday, April 30, 2015 8:57 PM
To: [email-masked]
Subject: [Dime] Load Use Case justifying endpoint load reports

All,

There has been some offline discussion about whether or not the Diameter 
Load mechanism should include two types of Load reports.  I believe 
there is consensus that there is the need for a peer load report to 
support load balancing when routing requests to the next hop.

The question is whether or not we should also support an "endpoint" load 
report.  This load report would be the load of a server (or a client) 
and would be carried end-to-end.

The case for an endpoint load report can be supported by the following 
use case.

Assume a Diameter network for a Diameter application where the servers 
are partitioned across the user space.  For simplicity, assume that user 
identities starting with the numbers 0 through 4 are handled by 
partition 1 and that user identities starting with the numbers 5 through 
9 are handled by partition 2.

Also assume that each partition has three servers -- P1S1, P1S2 and P1S2 
in partition 1 and P2S1, P2S2 AND P2S3 in partition 2.

Next assume that there is a database that maps user identities to 
partitions.  This scenario assumes that the database is a standalone 
device that has some query mechanism for accessing the mapping.  
Different implementations are possible.  The query has the user identity 
as the key and a set of Diameter servers as the response.  This query 
does NOT return anything but the set of servers able to handle requests 
for the user id presented. Specifically, the query does not return the 
load of the servers.

Now, assume the following network topology:

    P1S1  P1S2  P1S3          P2S1  P2S2  P2S3
      \    |    /               \    |    /
        -------                   -------
       /       \                 /        \
   P1A1       P1A2              P2A1    P2A2
      |        |                 |       |
      -------------------------------------
                 |           |
         DB---- AA1         AA2-----DB
                   \       /
                       C

The lines are for convenience, they are not meant to imply anything 
physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2, 
for instance.

AA1 and AA2 are "access agents" and have access to the database that map 
user identities to sets of servers.

The flow of a request would be as follows:

1) C - Does realm routing using received peer load reports to load 
balance between AA1 and AA2.  Assume C routes to AA1.

2) AA1 queries the DB.  Assume the user identity starts with the number 
1.  The DB returns the set of servers including P1S1, P1S2 and P1S3.

3) AA1 then selects the server that is to handle the request from the 
set of servers returned.  AA1 uses endpoint load reports received from 
P1S1, P1S2 and P1S3 to makes its selection.  Assume in this case that 
AA1 selection P1S2.  As a result AA1 inserts the Destination-Host AVP 
into the request with a value of P1S2.

4) AA1 then determines the route for the request.  In this case the 
route would need to be determines based on the combination of the 
Destination-Realm, Application-ID and the Destination-Host in the 
request.  The routing tables would indicate that P1A1 and P1A2 are the 
candidate next hop servers for the request.  This requires AA1 to have a 
route defined for each of the servers.  AA1 then uses peer load 
information received from P1A1 and P1A2 to select the next hop.  Assume 
AA1 selects P1A1.

5) P1A1 determines that the request is targeted for P1S2 based on the 
Destination-Host AVP.  As a result it routes the request directly to 
P1S2.  P1A1 cannot use a peer report to load balance in this case as the 
request includes the destination in the Destination-Host AVP.

The endpoint load report is used in step 3 to select the server that 
will handle the request.  Peer load reports are used to select the next 
hop.

Regards,

Steve

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 May 2015 13:21:26 -0500

Ulrich,

Thanks for pointing out the argument against this use case.

I understand that the default set of information used for request 
routing is the Destination-Realm and application-id.  There is nothing, 
however, that says this is the only set of information that can be 
used.  In fact, the following from section 6.1.6. in RFC6733 affirms 
that there are cases when additional information will be used:

"  Realm names and Application Ids are the minimum supported routing
    criteria, additional information may be needed to support redirect
    semantics."

The case below suggests the use of Destination-Host.  There are 
scenarios where session-ID, for session based applications, can be 
used.  There is no reason that an agent couldn't use any AVP to make 
routing decisions.

In addition, Diameter is being used in ways that were not anticipated by 
the original authors.  That is a good thing.

I know of many Diameter networks that fit into this use case.  We need 
to take them into account when designing the load mechanism.

Regards,

Steve

---

From: "Wiehe, Ulrich (Nokia - DE/Munich)" <[email-masked]>
Date: Thu, 7 May 2015 06:49:04 +0000

Hi Steve,

thank you for the clarification.
As I said, I'm not against. I rather support your proposal.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2015 8:21 PM
To: Wiehe, Ulrich (Nokia - DE/Munich); [email-masked]
Subject: Re: [Dime] Load Use Case justifying endpoint load reports

Ulrich,

Regards,

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 12 May 2015 07:05:20 +0000

Hi Steve and all

This topic of the load control solution scope is not easy and I hereafter  give my views on the basis of the offline discussion on this topic and the use cases to address, in particular the partition use case that Steve presented. 
 
In the offline discussion we had, several use cases, including if I remember well partition use cases (in 3GPP a main partition case is the HSS one) were addressed. 

A) The important question in fact is the scope of a Load control standardization, 
- RFC 6733 specifies  a basic set of routing rules that I hereafter summarized:
    a) if the destination Host when present in the  request is in the peer table, the request is sent to this peer. 
    b) In other cases (destination host present or not in the request), the routing table gives the possible peers for a given realm /application entry     
 
- RFC 6733 allows to have additional routing criteria  as Steve indicated in 6.1.6, but they are not described and so out of the RFC 6733 scope.
- when considering load control, Lionel's position is that  the load control to be standardized is the one useful/needed for the above basic set of routing rules. Additional load control mechanisms that would  be useful when coupled to routing criteria out of 6733 scope are outside of the load control standardization scope. The reason is because we cannot define all the possible routing cases outside RFC6733 to see which load control would be needed; we can only specify a load control mechanism applicable to the  basic set of routing rules.

- when considering the load control for the basic set of routing rules
    - for a), there is no need to consider load information as the peer is selected from the peer table
    - for b), as there can be several peers, load info of the different peers is used to select the peer and achieve load balancing.  The load of end points (servers)  which are not peers cannot be used for this peer selection.

In conclusion, with the basic set of routing rules, only load info from the peers is needed for peer selection, no need for end point load info.       

Lionel, please  check if I have well summarized your position.

B) The above perimeter brings strong restrictions for the possible use cases to be in the scope. In particular the partition use cases as the  one described by Steve requires an additional routing  criteria (cf step 4) in Steve's mail) which makes this case out of the scope of the basic set of RFC 6733 routing rules, so also out of the scope of a standardized load control mechanis, although this partition use case is frequent in deployed networks (for HSS in 3GPP).
Does Dime do an exception to also include this use case in the scope of load control mechanism? 

C) In draft-campbell-dime-load-considerations-01, use cases  (which are not partition use cases) are described in 10.1 to 10.7 sections. Which ones are compliant with the basic set of RFC 6733 basic rules without requiring additional specific routing criteria 
- 10.1 No agent: compliant
- 10.2 Single agent: compliant
- 10.3 Multiple Agents: not compliant (for a request from C  with  a destination host)
- 10.4 Linked agent: partially compliant ( A1 has a routing table for the realm/application containing S1 , S3 ... and A2), this may drives to non optimal routing, especially when several agents).
- 10.5 Shared server pools: compliant
- 10.6 Agent chain: not compliant (as for 10.3 if A3 has not A2 in its routing table) or partially compliant (as for 10.4 if A3 has A2 in its routing table) 
- 10.7 Fully meshed layers: compliant. 

Note: for partially compliant cases, improvement can be done by giving a higher priority to peers that are servers (eg S1 , S3 in 10.4 for A1 routing table) than  to the peers that are agents(eg A2 in 10.4 for A1 routing table).  Such a priority is a specific additional routing criteria which is possible but out of the scope of the basic set of routing rules.      
  
In fact only the fully meshed cases allow a routing only based on the basic set of rules. Other cases imply additional specific rules not described in RFC 6733.

If we now consider the load control solution, the fully meshed cases (10.1, 10.2, 10.5, 10.7) only need peer load  info to achieve a right load balancing between servers and also between agents, as described in A). 
But existing deployments, especially large networks, are not in a fully meshed configuration, so they enter other use cases (10.3, 10.4, 10.6) for which the peer load info is not sufficient. I am not sure that the end-point load info (cf B)) is a good answer for these cases which  are different from the partition cases. Again, the question raises to do an exception to also include some of these use cases in the scope of load control solution? 

D) There are also the use cases with Redirect Agents. Here according to my understanding of RFC 6733, the Redirect Hosts returned to the node having requested the Redirect agent are peers (direct connection) of the node doing the redirect request (cf RFC 6733 2.8.3 and 6.1.8), and if several Redirect hosts are returned this enters the peer selection case achievable with the peer load info (cf A)), so not requiring e.g. an end-point load info.        

E) I would like you to check if I have not some errors/misunderstanding  in my above analysis, and then to have your position on the following:
- solution with peer load information  allows load control for routing cases using the basic set of RFC 6733 routing rules, as described in A). I think we all agree on A) and we can now start the writing of this solution in the draft.
- Redirect use cases also rely on the this peer load information solution     
- we have then to decide if we support some additional use cases outside the basic set of RFC 6733 routing rules, because they are important in existing deployments.  The one to consider first would be the partition case with end point load info which Steve presented and which corresponds to the 3GPP important HSS use case. Other presented use cases (cf C))can be left for possible future extension.

Thank you

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (Nokia - DE/Munich)
Envoyé : jeudi 7 mai 2015 08:49
À : ext Steve Donovan; [email-masked]
Objet : Re: [Dime] Load Use Case justifying endpoint load reports

Hi Steve,

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, May 06, 2015 8:21 PM
To: Wiehe, Ulrich (Nokia - DE/Munich); [email-masked]
Subject: Re: [Dime] Load Use Case justifying endpoint load reports

Ulrich,

I understand that the default set of information used for request routing is the Destination-Realm and application-id.  There is nothing, however, that says this is the only set of information that can be used.  In fact, the following from section 6.1.6. in RFC6733 affirms that there are cases when additional information will be used:

The case below suggests the use of Destination-Host.  There are scenarios where session-ID, for session based applications, can be used.  There is no reason that an agent couldn't use any AVP to make routing decisions.

In addition, Diameter is being used in ways that were not anticipated by the original authors.  That is a good thing.

I know of many Diameter networks that fit into this use case.  We need to take them into account when designing the load mechanism.

Regards,

Steve

On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote:
> Hi Steve,
> I'm not against your proposal, however, it has been argued that 
> (according to established routing principles) in step 4) 
> Destination-Host is not part of the information used to determine the 
> route.
> Any reaction to this?
> 
> Best regards
> Ulrich
>
> There has been some offline discussion about whether or not the 
> Diameter Load mechanism should include two types of Load reports.  I 
> believe there is consensus that there is the need for a peer load 
> report to support load balancing when routing requests to the next hop.
>
> The question is whether or not we should also support an "endpoint" 
> load report.  This load report would be the load of a server (or a 
> client) and would be carried end-to-end.
>
> are partitioned across the user space.  For simplicity, assume that 
> user identities starting with the numbers 0 through 4 are handled by 
> Also assume that each partition has three servers -- P1S1, P1S2 and 
> P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2.
>
> Different implementations are possible.  The query has the user 
> identity as the key and a set of Diameter servers as the response.  
> This query does NOT return anything but the set of servers able to 
> handle requests for the user id presented. Specifically, the query 
> does not return the load of the servers.
>
> AA1 and AA2 are "access agents" and have access to the database that 
> map user identities to sets of servers.
>
> 2) AA1 queries the DB.  Assume the user identity starts with the 
> number 1.  The DB returns the set of servers including P1S1, P1S2 and P1S3.
>
> candidate next hop servers for the request.  This requires AA1 to have 
> a route defined for each of the servers.  AA1 then uses peer load 
> P1S2.  P1A1 cannot use a peer report to load balance in this case as 
> the request includes the destination in the Destination-Host AVP.
>
> will handle the request.  Peer load reports are used to select the 
> next hop.
>
> Regards,
>
> Steve
>
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 12 May 2015 08:29:25 -0500

Jean-Jacques,

This was a good analysis, thanks.

It comes down to the question - Do we limit the solution to the routing 
rules defined twelve years ago or do we design a solution that addresses 
how Diameter is currently being used?

The use case I outlined is a common occurrence in today's Diameter 
networks.  We should design a solution that addresses the needs of all 
Diameter networks, including those that require routing on more than 
just Destination-Realm and Application-ID.

Regards,

Steve

---

From: <[email-masked]>
Date: Fri, 15 May 2015 09:01:51 +0000

Hi Steve,

The step 4 is simply against the routing rules defined in RFC6733. For example, you can refer to the following statement to understand that using the Destination-Host AVP for routing when the host Id is not part of the peer table is not so "standard":

   Note that an agent can only forward a request to a host described in
   the Destination-Host AVP if the host in question is included in its
   peer table (see Section 2.6).  Otherwise, the request is routed based
   on the Destination-Realm only (see Section 6.1.6).

It does not mean that additional routing criteria cannot be used for request routing purposes but there are considered as out of the base protocol and therefore application-specific.
For instance, the Cx interface defined a function performing user id to server id resolution but it is defined as a specific extension of the base protocol and therefore defined as part of a specific diameter application.

It is not preclude to work on a solution that could be used by application. However, I think that the basic solution defined as part of the standard process should only comply with the base protocol routing principle. Otherwise, there is no way to limit the type of information that could be part of the load information exchanged between Diameter nodes. Obviously, the baseline solution can be defined in a way that it could be possible to extend it for specific purposes. But I am against putting vendor-specific requirements in a solution defined as part of the standard stream (i.e. based on the RFC6733).

Regards,

Lionel

-----Message d'origine-----

Hi Steve,

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, May 06, 2015 8:21 PM
To: Wiehe, Ulrich (Nokia - DE/Munich); [email-masked]
Subject: Re: [Dime] Load Use Case justifying endpoint load reports

Ulrich,

Regards,

Steve

_________________________________________________________________________________________________________________________

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: Fri, 15 May 2015 16:18:04 +0000

Hi Steve, JJ,

Please see below.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 12 mai 2015 15:29
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : Re: [Dime] Load Use Case justifying endpoint load reports

Jean-Jacques,

It comes down to the question - Do we limit the solution to the routing rules defined twelve years ago or do we design a solution that addresses how Diameter is currently being used?
[LM] RFC6733 has been published in October 2012. Only 3 years ago after long, very long discussions. At this time, I didn't hear about any requirement for changing the routing principles given in the base protocol.

The use case I outlined is a common occurrence in today's Diameter networks.  We should design a solution that addresses the needs of all Diameter networks, including those that require routing on more than just Destination-Realm and Application-ID.
[LM] Designing a simple solution that can be enhanced to support any specific requirement without standard action is also a good solution from my point of view.

Regards,

Steve

On 5/12/15 2:05 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>      b) In other cases (destination host present or not in the 
> request), the routing table gives the possible peers for a given realm 
> /application entry
>   
> C) In draft-campbell-dime-load-considerations-01, use cases  (which 
> are not partition use cases) are described in 10.1 to 10.7 sections. 
> Which ones are compliant with the basic set of RFC 6733 basic rules 
> without requiring additional specific routing criteria
> - 10.6 Agent chain: not compliant (as for 10.3 if A3 has not A2 in its 
> routing table) or partially compliant (as for 10.4 if A3 has A2 in its 
> routing table)
> De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich 
> (Nokia - DE/Munich) Envoyé : jeudi 7 mai 2015 08:49 À : ext Steve 
> Donovan; [email-masked] Objet : Re: [Dime] Load Use Case justifying 
> endpoint load reports
>
> Hi Steve,
>
>> The case for an endpoint load report can be supported by the 
>> following use case.
>>
>> Assume a Diameter network for a Diameter application where the 
>> servers are partitioned across the user space.  For simplicity, 
>> assume that user identities starting with the numbers 0 through 4 are 
>> handled by partition 1 and that user identities starting with the 
>> numbers 5 through
>> set of servers returned.  AA1 uses endpoint load reports received 
>> from P1S1, P1S2 and P1S3 to makes its selection.  Assume in this case 
>> that
>> request.  The routing tables would indicate that P1A1 and P1A2 are 
>> the candidate next hop servers for the request.  This requires AA1 to 
>> have a route defined for each of the servers.  AA1 then uses peer 
>> load information received from P1A1 and P1A2 to select the next hop.
>> Assume
>> AA1 selects P1A1.
>>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 26 May 2015 11:58:33 -0500

> [LM] RFC6733 has been published in October 2012. Only 3 years ago after long, very long discussions. At this time, I didn't hear about any requirement for changing the routing principles given in t…
SRD> Ok, it was reviewed three years ago.  My point is still relevant.  
Things have changed since, or, more likely, were in the process of 
changing when 6733 was being worked on.
> [LM] Designing a simple solution that can be enhanced to support any specific requirement without standard action is also a good solution from my point of view.
SRD> I don't understand how it can be enhanced without standards action 
if multiple implementations are expected to interoperate.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 26 May 2015 12:05:41 -0500

>     on the Destination-Realm only (see Section 6.1.6).
SRD> Then I would assert that RFC6733 is on consistent.  See my 
reference below.
> It is not preclude to work on a solution that could be used by application. However, I think that the basic solution defined as part of the standard process should only comply with the base protocol routing principle. Otherwise, there is no way to limit the type of information that could be part of the load information exchanged between Diameter nodes.
SRD> I don't understand your point.  The proposal is to have the 
solution support two very specific load reports, one for endpoint load 
and one for peer load.  Each load report would contain very specific 
information, with the ability to extend the contents as is typical with 
Diameter solutions.
> Obviously, the baseline solution can be defined in a way that it could be possible to extend it for specific purposes. But I am against putting vendor-specific requirements in a solution defined as part of the standard stream (i.e. based on the RFC6733).
SRD> This is not a vendor specific requirement or solution. There have 
been multiple vendors supporting the inclusion of end-point load reports 
as part of this solution.  This is a proposal that addresses real world 
needs of existing Diameter networks in a way that lets Diameter nodes 
implemented by multiple vendors interoperate.  This is the reason 
standards exist.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 26 May 2015 22:27:57 +0000

We support what Steve's proposal.

Lionel, what is the "real" issue?

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Tuesday, May 26, 2015 1:06 PM
To: [email-masked]; Wiehe, Ulrich (Nokia - DE/Munich); [email-masked]
Subject: Re: [Dime] Load Use Case justifying endpoint load reports

SRD> I don't understand your point.  The proposal is to have the
solution support two very specific load reports, one for endpoint load and one for peer load.  Each load report would contain very specific information, with the ability to extend the contents as is typical with Diameter solutions.
SRD> This is not a vendor specific requirement or solution. There have
been multiple vendors supporting the inclusion of end-point load reports as part of this solution.  This is a proposal that addresses real world needs of existing Diameter networks in a way that lets Diameter nodes implemented by multiple vendors interoperate.  This is the reason standards exist.
> ______________________________________________________________________
> ___________________________________________________
>
> 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.