Re: [Dime] Ongoing Throttling Information in request messages

Just a reminder. Please avoid using HTML emails ;-) This innocent 13KB blob of text expanded into ~80KB of HTML goodness after few iterations, which our email list reflector holds until the moderator accepts it manually. I'll check if I can raise the maximum message size in a meanwhile.

- JOuni

On Nov 5, 2013, at 6:06 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

> 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      |
>                       +----------------+      +------------+    +---------+
>  
> 	• 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.
> 	• 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.
> 	• A3 stores the 10% throttling request.
> 	• 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.
> 	• S recognizes that correct throttling (correct time stamp) is in place and therefore does not return OC-OLR in the answer.
> 	• 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.
> 	• 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.
> 	• A1 stores the 10% throttling request.
> 	• 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.
> 	• S recognizes that correct throttling (correct time stamp) is in place and therefore does not return OC-OLR in the answer.
> 	• 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.
> 	• Overload situation in S for some reason gets worse, S decides to request 20 % reduction.
> 	• 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.
> 	• 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.
> 	• A3 (not taking the role of the reactingt node)may, A1 must store the 20% throttling request (replacing the 10% request).
> 	• 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)
> 	• 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.
> 	• A3 stores the 20% throttling request (replacing the 10% request).
> 	• 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
>  
>  
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime