DOC Use Case Analysis Client to server use cases 1

Contents This contains a high level analysis of the DOC use cases dealing with the direct connections between clients and servers. 2

Methodology This is the first part of an incremental analysis of DOC use cases. The scenarios are additive. Everything from previous scenarios apply unless explicitly called out as different. Any conclusions make in these use cases are preliminary. 3

Methodology The goal is to incrementally define the following: – Impacts to the on the wire Diameter protocol – Protocol significant behavior for Diameter nodes, including Client, Agents and Servers 4

UC CS1: CS, SL, DH, 1S, NP, 1A Client Server xxR xxA OLR (R=10%) 5 Client Server Architecture Example Message Flow Server becomes overloaded Client Throttles traffic to server xxR xxA xxR Server overload level unchanged Thus no overload report sent Throttle 10% Overload report contains Requested reduction CS – Direct connections from client to server SL – Session-less application DH – Destination Host routed 1S – Single server NP – No server partitioning 1A – Single application......

UC1 – Sub cases No server overload – normal operation Server becomes overloaded Server handling of requests after overload report sent Server overload level changes Overload report duration period ends – Server still overloaded – Server no longer overloaded Server overload ends Mixed client support of DOC 6

UC CS1 – 1 Server Overload and Overload report refresh Client Server xxR xxA OLR (R=10%) Server becomes overloaded Client throttles traffic to server xxR xxA xxR Server overload level unchanged Thus no overload report sent Throttle 10% Overload report contains Requested reduction and time period 7 xxR xxA OLR (R=10%) Server periodically refreshes overload report Mcruz: Refresh may not be needed.

UC CS1 – 2 – Server overload level changes Client Server Server overload level changes xxA OLR (R=50%) Overload report contains Requested reduction Client adjusts throttle rate xxR Throttle 50% xxR 8

UC CS1 – 3 Overload report duration expires Client Server xxR xxA OLR (R=10%) Overload period ends Server still overloaded Client Throttles traffic to server xxR Throttle 10% Overload report contains Requested reduction xxA No overload report Client stops throttling Overload period ends Server no longer overloaded Client stops throttling xxR 9 Mcruz: I presume that in this proposal you consider the server has a timer per client&application. I presume that since a report is sent when the timer is expired. However, I think that we can avoid keep timers in the server, and just report overload in the two situations proposed in previous slides: -overload level is modified -Periodically (at least) while overload level is maintained.

UC CS1 – 4 Server reported end of overload condition Client Server xxR xxA OLR (R=10%) Server becomes overloaded Client Throttles traffic to server xxR Throttle 10% Overload report contains Requested reduction Server overload ends xxA OLR (R=0%) Overload report contains Indication that overload has ended xxR xxA No overload report Client stops throttling xxR 10 Mcruz: Fine, but in fact this is just another case of overload level modification.

UC CS1 – 5 Mixed client support of DOC Client Server xxR xxA OLR (R=10%) Server becomes overloaded DOC Client Throttles traffic to server xxR Throttle 10% Overload report contains Requested reduction Client xxR xxA OLR (R=10%) No DOC Support DOC Support Server includes Overload report in answers to all clients (server doesn’t know which clients support DOC) xxR xxA Non DOC Client continues sending traffic without throttling 11 Mcruz: the assumption is that a server does not know which clients support DOC, but this may not be true depending on whether we finally require some negotiation (or advertisement capabilities), at least for deciding which mitigation algorithm to use. This is still under discussion.

Initial recommendations “Loss” is initial defined abatement algorithm – Other abatement algorithms require extensions Overload report contents: – Traffic reduction request New session requests (not for this scenario but anticipating session scenarios) – Set to zero for session-less applications Mid session requests – Report duration Client: – Client must support “loss” abatement algorithm – Client must stop abatement when duration of the overload report expires Server: – Server sends report when overload level changes – Server periodically refreshes overload report – Server sends reports to all clients (no capabilities negotiation) 12 Mcruz: whether a default algorithm is needed or which one we should use is under analysis. Mcruz: decision to have two reduction-requests may depend on: -Whether we use scope (to cover CAS use cases) -Whether we really consider to reduce traffic based on server resource usage. This may not be our most prioritized intention. Report duration may be not required if you decide to have a default that should be enforced by client. It could be optional.

UC CS2: CS, SL, DH, 1S, NP, >1A Client Server xxR(ap1) xxA (ap1) OLR (R=10%) 13 Client Server Architecture Example Message Flow Server becomes overloaded for ap1 Client throttles ap1 traffic to server xxR(ap1) xxA(ap1) xxR(ap1) Server overload level unchanged Thus no overload report sent Throttle 10% Overload report contains Requested reduction CS – Direct connections from client to server SL – Session-less application DH – Destination Host routed 1S – Single server NP – No server partitioning >1A – Multiple applications xxA(ap2) xxR (ap2) No overload report for ap Mcruz: if we are piggybacking overload reports in applications messages this use case is simple and straight forward.

UC CS2 - Subcases Server overload of single application Server overload of multiple applications ?Server overload of all applications? 14

UC CS2-1: Single application overloaded Client Server xxR(ap1) xxA (ap1) OLR (R=10%) 15 Server becomes overloaded for ap1 Client throttles ap1 traffic to server xxR(ap1) Throttle 10% Overload report contains Requested reduction xxA(ap2 ) xxR (ap2) xxA(ap2 ) xxR (ap2) No overload report for ap2 No client throttling of ap2 traffic to server

UC CS2-2: Multiple applications overloaded 16 Client Server xxR(ap2) xxA (ap2) OLR (R=50%) Server is overloaded for ap1 (10%) Server becomes overloaded for ap2 (50%) Client continues to throttles ap1 traffic by 10% xxR(ap1) Throttle 10% Overload report contains Requested reduction xxR(ap2) Throttle 50% Client Throttles ap2 traffic by 50%

UC CS2-2: One application’s overload report expires 17 Client Server Server is overloaded for ap1 (10%) and ap2 (50%) xxR(ap1) xxA(ap1 ) Client stops throttling ap1 xxR(ap2) Throttle 50% Ap1 overload report expires Client continues throttling ap2

UC CS2 - Questions Does overload report include indication of the application(s) currently overloaded? – If multiple applications overloaded, does server include multiple overload reports or one report per application? 18

UC CS2-2 Recommendations Overload Report Contents – TBD – Include application id in report? – TBD – Multiple applications in single report? – The separate application traffic reduction requests must be allowed to have different reduction levels and durations Clients must maintain per application reduction and overload report duration state Servers must be able to report overload level for separate applications independently 19

UC CS3: CS, SL, DH, >1S, NP, 1A Client Server 1 xxR(ap1) xxA (ap1) OLR (R=10%) 20 Client Server Architecture Example Message Flow Server1 becomes overloaded for ap1 Server2 is not overloaded for any ap Client Throttles ap1 traffic to server1 xxR(ap1) xxA(ap1) xxR(ap1) Client does not throttle ap1 traffic to server2 Throttle 10% Overload report contains Requested reduction CS – Direct connections from client to server SL – Session-less application DH – Destination Host routed >1S – Single server NP – No server partitioning >1A – Multiple applications xxA(ap1 ) xxR (ap1) No overload report from server2 Server 2 Server......

UC CS3 - Scenarios Mix of overload states between servers and applications – For n servers and m application, n*m overload states must be maintained by the application 21

UC CS3 - Questions Does overload report include indication of the server that generated the report? – This scenario does not mandate it – Future agent based scenarios might 22

UC CS3 Recommendations Overload report contents – TDB – Indication of the server that generated the report Clients must support maintaining overload state for each server, application-id pair – Client can use capabilities exchange to determine the applications supported by the server This is no longer the case in agent scenarios – Overload state includes reduction percentage and duration No change in server behavior introduced by this scenario 23 Mcruz: “use capabilities exchange”? Nothing extra is needed for 3GPP applications here.

UC CS4: CS, SB, DH, 1S, NP, >1A Client Server xxR xxA OLR (NSR=10%) 24 Client Server Architecture Example Message Flow Server becomes overloaded for new sessions Client throttles new session traffic to server xxR (MS) xxA xxR (NS) Mid session requests are not throttled Throttle 10% Overload report contains requested reduction CS – Direct connections from client to server SB – Session-based application DH – Destination Host routed 1S – Single server NP – No server partitioning >1A – Multiple applications Key: xxR(NS) – New Session Request xxR (MS) – Mid Session Request NSR – New Session Requests MSR – Mid Session Requests

UC CS4 Scenarios Single application becomes overloaded for new sessions Single application becomes overloaded for mid session requests Mix of overload state for each application and request type 25 Mcruz: decision to have two reduction-requests may depend on (for the CS use cases ) whether we really consider to reduce traffic based on server resource usage. This may not be our most prioritized intention..

UC CS4 Recommendations Overload report contents: – The overload report must support the ability to request a reduction in new session requests, a reduction in midsession requests or both. – The requested reduction must be able to be different values for new session requests and mid session requests. Clients of session-based applications: – Clients must support the ability to differentiate reduction requests for new session requests from reduction requests for mid session requests. Servers of session-based applications: – Servers must support the ability to generate separate reduction requests for new session requests and mid session requests. If the server doesn’t require this functionality then the server must include the same reduction request for both new session requests and mid session requests. 26

UC CS5: CS, SB, DH, >1S, NP, >1A 27 Client Server Architecture CS – Direct connections from client to server SL – Session-less application DH – Destination Host routed >1S – Multiple servers NP – No server partitioning >1A – Multiple applications Client Server 1 xxR(ap1) xxA (ap1, NS) OLR (MSR=10%) Example Message Flow Server1 becomes overloaded for mid-session requests for ap1 Server2 is not overloaded for any ap Client throttles mid session ap1 traffic to server1 xxR(ap1) xxA(ap1) xxR(ap1, MS) Client does not throttle ap1 traffic to server2 Throttle 10% Overload report contains requested reduction xxA(ap1 ) xxR (ap1) No overload report from server2 Server 2 xxR(ap1,NS) xxA (ap1, NS) Client does not throttles new session ap1 traffic to server1

UC CS5 Scenarios Same as UC4 but for multiple servers 28

UC CS5 Recommendations Overload report contents – Nothing new identified Client – Nothing new identified Server – Nothing new identified 29