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

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 13:56:55 -0500

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