Re: [Dime] Ongoing Throttling Information in request messages

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

Nirav,

thank you for the explanation. This may be  a solution which adds more complexity to the reporting node: The reporting node must remember the maximum not yet expired fraction of duration values it sent when leaving the overload state and must continue reporting "end of overload condition" until expiry. (there is no corresponding complexity at the reacting node in my proposal)

Another question: While doing a throttling, what is the expected behaviour of the reacting node when receiving an answer message without OC-OLR AVP? (stop/continue throttling?) (there is no corresponding question in my proposal since not sending of OC-Ongoing-Throttling-Information clearly means that throttling is not in place)

Another question is for the reacting node: What is the expected behaviour when receiving lots of redundant OC-OLR AVPs in answer messages? The reacting node needs to check every single OC-OLR AVP in order to find out whether it contains an update. Is that the correct understanding? (this seems to be equivalent to checking for redundant OC-Ongoing-Throttling-Information AVPs in every request by the reporting node in my proposal)


Adding dime-list again.

Ulrich


From: ext Nirav Salot (nsalot) [mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 4:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

During "no overload condition", why should reporting node include overload-information in all the answer messages?
e.g. if the reporting node has advertised overload-report with period-of-validity=10 sec., it knows that after that period all the reacting node will automatically stop applying any overload mitigation action. And hence it does not need to explicitly send any overload-report indicating "no overload condition".

In general, I assume that overload period of would be much shorter as compared to "no overload" period. And hence I do not see reason to always include overload-report.

Regards,
Nirav.

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 9:12 PM
To: Nirav Salot (nsalot); [e-mail]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

"During the overload" yes I agree, but "when no longer in overload" all answer messages would contain the information "no longer in overload" while only few request messages would contain the Ongoing-Throttling-Information.

Removing dime-list which bounces.

Best regards
Ulrich
From: ext Nirav Salot (nsalot) [mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 4:02 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]; [e-mail]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

I might be missing something here so please bear with me.

Number of answer messages sent by server = number of request messages received by the server.
During the overload, the server would receive only those requests which survived throttling.
And then the server would send answer messages to only those request messages.
So "every" and "some" are actually equal in the below equation. No?

Regards,
Nirav.

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 8:24 PM
To: Nirav Salot (nsalot); [e-mail]; [e-mail]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Not quite.

The question is:
"is sending an overload-report in every answer message that corresponds to request with OC-Feature-Vector present more resource consuming than receiving Ongoing-Throttling-Information in some request messages (only those that survived a throttling)?"

Best regards
Ulrich



From: ext Nirav Salot (nsalot) [mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 3:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]; [e-mail]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Thanks for clarification.

Then the question would be 
"is sending overload-report in every answer message is more resource consuming than the solution below - i.e. receiving OC-Ongoing-Throttling-Information in all request message and analyzing the timestamp and then deciding if the overload-report should be included or not."
I am not sure.

Regards,
Nirav.

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 7:08 PM
To: Nirav Salot (nsalot); [e-mail]; [e-mail]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,
thank you for your comments.

The comparism is between:
Current way: "send OC specific information (Feature-Vector) in every request message and in every corresponding answer message"
My proposal: "send OC specific information (Feature-Vector and in some cases Ongoing-Throttling-Info) in every request message and in corresponding answer messages only when required".

Sending OC specific information  is regarded a resource consuming action and we should not put this action to the (overloaded) server where avoidable. See REQ 13.

Best regards
Ulrich




From: ext Nirav Salot (nsalot) [mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]; [e-mail]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Thanks for the detail explanation of your proposal.

Just to verify my understanding,
Your proposal would allow the reporting node to avoid inclusion of the "same" overload-report in the answer message since the request message indicates that the path contains at least one reacting node which already has the latest overload-report.
In other words, the reporting node need not include overload-report in every message, blindly.

To achieve the above objective, the solution below suggest the reacting node to include new AVP OC-Ongoing-Throttling-Information in every request message, which survives throttling.
So the net result is that, the inclusion of the overload-report is prevented in every answer message since the OC-Ongoing-Throttling-Information is included in every request message.
[Wiehe, Ulrich (NSN - DE/Munich)] no.  .in every request message that survived a throttling.
And hence I am not sure if the solution has sound benefit from the inclusion of redundant information point of view.

In summary, I think the solution suggested below works as explained.
But I fail to see the benefit of using this solution compare to a solution in which the reporting node includes overload-report in every answer message.

Regards,
Nirav.

From: [e-mail] [mailto:[e-mail]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: [e-mail]; [e-mail]
Subject: [doc-dt] Ongoing Throttling Information in request messages

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