[Dime] Ongoing Throttling Information in request messages

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

Hi,

draft-docdt-dime-ovli-01
in Appendix B, Table 1, REQ 13 says:
        .... Another way
        is to let the request sender (reacting node) insert
        information in the request to say whether a
        throttling is actually performed.  The reporting node
        then can base its decision on information received in
        the request; no need for keeping state to record who
  has received overload reports.

And in Appendix B, Table 1, REQ 18:
        There has been a proposal to mark
        messages that survived overload throttling as one
        method for an overloaded node to address fairness but
        this proposal is not yet part of the solution.

I would like to come back to this proposal.
A new AVP OC-Ongoing-Throttling-Information inserted in request messages would indicate that the request message survived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR AVP, according to which the ongoing throttling (which was survived) is performed.

OC-Ongoing-Throttling-Information ::= < AVP Header: TBD9 >
              < TimeStamp >
            * [ AVP ]

Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP  into request messages that survived a throttling performed at that client.
Supporting Agents when receiving a request message that contains an OC-Ongoing-Throttling-Information AVP would not perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, when receiving a request that does not contain OC-Ongoing-Throttling-Information AVP would perform throttling (on behalf of the client) according to a previously received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-Throttling-Information AVP in the request before sending it further upstream.
Servers (or in general reporting nodes) would check presence and content of the OC-Ongoing-Throttling-Information AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whether inserting an OC-OLR AVP in the corresponding answer message is needed in order to update the reacting node with a new OC-OLR).

This proposal especially addresses use cases like the following:

Architecture:

                       +----------------+
                       | supporting     |
                      /| agent A1       |\
  +----------------+ / +----------------+ \
  | non supporting |/                      \
  | client C       |\                       \
  +----------------+ \ +----------------+    \ +------------+    +---------+
                      \| non supporting |     \| supporting |    | Server  |
                       |  agent A2      |------| agent A3   |----|  S      |
                       +----------------+      +------------+    +---------+

1.      A request is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has no valid OLR from S stored and therefore does not perform throttling and does not insert an OC-Throttling-Information AVP.
2.      S recognizes that there is a reacting node downstream which is actually not performing a throttling. S returns a 10% throttling request (TimeStamp=t1, duration=d) within OC-OLR in the answer which goes back via A3 and A2 to C.
3.      A3 stores the 10% throttling request.
4.      A new request is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has  valid OLR from S stored and performs a 10% throttling. The request survives and A3 inserts an OC-Throttling-Information AVP with timeStamp=t1.
5.      S recognizes that correct throttling (correct time stamp) is in place and therefore does not return OC-OLR in the answer.
6.      A new request is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has no valid OLR from S stored and therefore does not perform throttling and does not insert an OC-Throttling-Information AVP. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.
7.      S recognizes that there is a reacting node downstream which is actually not performing a throttling. S returns a 10% throttling request (TimeStamp=t1, duration=d) within OC-OLR in the answer which goes back via A3 and A1 to C.
8.      A1 stores the 10% throttling request.
9.      A new request is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  valid OLR from S stored and therefore performs a 10% throttling. The request survives and A1 inserts an OC-Throttling-Information AVP with timeStamp=t1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.
10.     S recognizes that correct throttling (correct time stamp) is in place and therefore does not return OC-OLR in the answer.
11.     Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3.
12.     Overload situation in S for some reason gets worse, S decides to request 20 % reduction.
13.     A new request is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  valid OLR from S stored and therefore performs a 10% throttling. The request survives and A1 inserts an OC-Throttling-Information AVP with timeStamp=t1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.
14.     S recognizes that incorrect throttling (wrong time stamp) is in place and therefore S returns a 20% throttling request (TimeStamp=t2, duration=x) within OC-OLR in the answer which goes back via A3 and A1 to C.
15.     A3 (not taking the role of the reactingt node)may, A1 must store the 20% throttling request (replacing the 10% request).
16.     A new request is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has  valid OLR from S stored and performs a 10% throttling. The request survives and A3 inserts an OC-Throttling-Information AVP with timeStamp=t1. (assuming A3 did not store the 20% request at step 14)
17.     S recognizes that incorrect throttling (wrong time stamp) is in place and therefore S returns a 20% throttling request (TimeStamp=t2, duration=x) within OC-OLR in the answer which goes back via A3 and A2 to C.
18.     A3 stores the 20% throttling request (replacing the 10% request).
19.     Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3.


Comments are welcome.

Best regards
Ulrich