Re: [Dime] Ongoing Throttling Information in request messages

[Steve Donovan <[e-mail]>]

Nirav,

One qualification of your point below -- The server would only receive 
requests that survived throttling from clients that support DOIC.  The 
server will also receive requests from clients that do not support 
DOIC.  One of the benefits of Ulrich's proposal is that it tells the 
server when a request has not gone through throttling. The server can 
then choose to do something different with that set of requests.

As to the question of which is more work for the server, which is the 
important question, that isn't yet clear to me.

Steve

On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote:
>
> 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] 
> <mailto:[e-mail]>; [e-mail] <mailto:[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] <mailto:[e-mail]>; 
> [e-mail] <mailto:[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] 
> <mailto:[e-mail]>; [e-mail] <mailto:[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]> 
> [mailto:[e-mail]] *On Behalf Of *Wiehe, Ulrich (NSN - 
> DE/Munich)
> *Sent:* Tuesday, November 05, 2013 9:36 PM
> *To:* [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[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
>
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime