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

[Steve Donovan <[e-mail]>]

On 5/15/15 11:18 AM, [e-mail] wrote:
> Hi Steve, JJ,
>
> Please see below.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:[e-mail]] De la part de Steve Donovan
> Envoyé : mardi 12 mai 2015 15:29
> À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [e-mail]
> Objet : Re: [Dime] Load Use Case justifying endpoint load reports
>
> 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?
> [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.
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.
>
> 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.
SRD> I don't understand how it can be enhanced without standards action 
if multiple implementations are expected to interoperate.
>
>
> Regards,
>
> Steve
>
> On 5/12/15 2:05 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>> 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:[e-mail]] De la part de Wiehe, Ulrich
>> (Nokia - DE/Munich) Envoyé : jeudi 7 mai 2015 08:49 À : ext Steve
>> Donovan; [e-mail] Objet : Re: [Dime] Load Use Case justifying
>> endpoint load reports
>>
>> 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:[e-mail]]
>> Sent: Wednesday, May 06, 2015 8:21 PM
>> To: Wiehe, Ulrich (Nokia - DE/Munich); [e-mail]
>> Subject: Re: [Dime] Load Use Case justifying endpoint load reports
>>
>> 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
>>
>> 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
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:[e-mail]] On Behalf Of ext Steve
>>> Donovan
>>> Sent: Thursday, April 30, 2015 8:57 PM
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>