Re: [Dime] Ongoing Throttling Information in request messages

[<[e-mail]>]

Hi,

Not so sure that the optimization proposed below is deemed required for the basic solution.
And I don't see anything in the basic proposed solution that would prevent such optimization in a later stage if finally needed.

Lionel

De : [e-mail] [mailto:[e-mail]] De la part de Steve Donovan
Envoyé : mercredi 6 novembre 2013 17:22
À : [e-mail]
Objet : Re: [Dime] Ongoing Throttling Information in request messages

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]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dime


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.