Subject: [Dime] Ongoing Throttling Information in request messages

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 5 Nov 2013 16:06:26 +0000

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Nov 2013 13:37:49 +0000

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:[email-masked]]
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [doc-dt] Ongoing Throttling Information in request messages

Hi,
draft-docdt-dime-ovli-01

Architecture:

                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.

Best regards
Ulrich

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 6 Nov 2013 11:04:21 +0000

Ulrich,

Regards,
Nirav.

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

Hi,
draft-docdt-dime-ovli-01

Architecture:

                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.

Best regards
Ulrich

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 6 Nov 2013 14:14:49 +0000

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:[email-masked]]
Sent: Wednesday, November 06, 2013 7:08 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Best regards
Ulrich

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

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

Architecture:

                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.

Best regards
Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Nov 2013 14:53:38 +0000

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:[email-masked]]
Sent: Wednesday, November 06, 2013 3:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

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

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

Architecture:

                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.

Best regards
Ulrich

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 6 Nov 2013 15:02:26 +0000

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:[email-masked]]
Sent: Wednesday, November 06, 2013 8:24 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

Architecture:

                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.

Best regards
Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Nov 2013 09:00:57 -0800

Resending with most of the message trimmed.  My first attempt to send 
this got a response that the message is awaiting moderator approval 
because it was bigger than 50k bytes.

Steve

-------- Original Message --------
Subject: 	Re: [Dime] Ongoing Throttling Information in request messages
Date: 	Wed, 06 Nov 2013 08:21:31 -0800
From: 	Steve Donovan <[email-masked]>
To: 	[email-masked]

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

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 6 Nov 2013 19:03:17 +0200

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)" <[email-masked]> wrote:

>         …. Another way
> 	• 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Nov 2013 08:21:31 -0800

Nirav,

Steve

On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote:
> *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
> *Sent:* Wednesday, November 06, 2013 8:24 PM
> *To:* Nirav Salot (nsalot); [email-masked]; [email-masked]
> *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:[email-masked]]
> *Sent:* Wednesday, November 06, 2013 3:15 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Ongoing Throttling Information in request messages
>
> Ulrich,
>
> "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:[email-masked]]
> *Sent:* Wednesday, November 06, 2013 7:08 PM
> *To:* Nirav Salot (nsalot); [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Ongoing Throttling Information in request messages
>
> Nirav,
>
> 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:[email-masked]]
> *Sent:* Wednesday, November 06, 2013 12:04 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Ongoing Throttling Information in request messages
>
> Ulrich,
>
> 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.
>
> 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.
>
> 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:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Wiehe, Ulrich (NSN - 
> DE/Munich)
> *Sent:* Tuesday, November 05, 2013 9:36 PM
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* [doc-dt] Ongoing Throttling Information in request messages
>
> Hi,
>
> *draft-docdt-dime-ovli-01 *
>
> 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.
>
> 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).
>
> 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
>
>
>

---

From: <[email-masked]>
Date: Thu, 7 Nov 2013 00:33:07 +0000

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 : [email-masked] [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 6 novembre 2013 17:22
À : [email-masked]
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

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

Architecture:

                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.

Best regards
Ulrich

DiME mailing list

[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Nov 2013 08:24:17 +0000

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:[email-masked]] 
Sent: Wednesday, November 06, 2013 4:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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:[email-masked]] 
Sent: Wednesday, November 06, 2013 9:12 PM
To: Nirav Salot (nsalot); [email-masked]
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:[email-masked]] 
Sent: Wednesday, November 06, 2013 4:02 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

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.

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01 
        .. Another way

 

 
Architecture:
 
                       +----------------+
                       | supporting     |
                      /| agent A1       |\    

Comments are welcome.
 
Best regards
Ulrich

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 7 Nov 2013 09:14:30 +0000

Ulrich,

Please read my responses inline.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 1:54 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

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)
[Nirav] This is not always true, e.g. as I had indicated if the node has advertised 10% reduction-percentage for 10 sec., it need not bother to advertise no-overload condition since the validity-period was very small.

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)
[Nirav] The reacting node should continue to apply the earlier received OC-OLR. 
" (Note: We seem to
   have consensus that a server MAY repeat OLRs in subsequent messages,
   but is not required to do so, based on local policy.)"

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)
[Nirav] Please refer to Timestamp AVP within OC-OLR.
The TimeStamp AVP indicates when the original OC-OLR AVP with the
   current content was created.  It is possible to replay the same OC-
   OLR AVP multiple times between the overload endpoints, however, when
   the OC-OLR AVP content changes or the other information sending
   endpoint wants the receiving endpoint to update its overload control
   information, then the TimeStamp AVP MUST contain a new value.

Adding dime-list again.

Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

 

 
Architecture:
 
                       +----------------+
                       | supporting     |
                      /| agent A1       |\
 
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.

Comments are welcome.
 
Best regards
Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Nov 2013 10:23:28 +0000

Nirav,

please see inline.

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 10:15 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 1:54 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

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)
[Nirav] This is not always true, e.g. as I had indicated if the node has advertised 10% reduction-percentage for 10 sec., it need not bother to advertise no-overload condition since the validity-period was very small.
[Ulrich] Also not always true, e.g. if the reporting node has requested at 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to request a 10% reduction for 10 sec. Although the validity-period is small (10 sec) there may still be a reacting node that did not get the update and keeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to take REQ 10 seriously. My understanding was that timeout is last resort, not the normal way.

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)
[Nirav] The reacting node should continue to apply the earlier received OC-OLR. 
" (Note: We seem to
   have consensus that a server MAY repeat OLRs in subsequent messages,
   but is not required to do so, based on local policy.)"
[Ulrich] This needs to be reconsidered. See the following example:
Non supporting client C1 sends a request via supporting agent A1 to Server S.
S returns a 10% throttling request. 
C sends an new request via supporting agent A2 to S. 
S decides not to repeat the 10% throttling request (hence A2 is not aware of the throttling request). 
C1 sends a new request via A1. 
S decides to repeat the throttling request (redundant). 
Supporting client C2 sends a request via A2 to S.
S decides not to repeat....
To avoid this mess we either need to mandate sending OC-OLR in every answer (while in overload) or let the Server keep track which agent and which client is updated with the newest info. (or consider my proposal).

[Ulrich] This does not explicitly say that the reacting node must check every TimeStamp received within OC-OLR AVPs. But I guess this is the consequence. Can you please confirm.

Adding dime-list again.

Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

 

 
Architecture:
 
                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.
 
Best regards
Ulrich

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:28:45 +0000

Ulrich,

Not sure the significance of REQ 10 here but I do not agree to enforce the server to include overload-report (indicating non-zero or zero overload condition) in every message.
Even in your example, the overload condition will end sometime - e.g. after 1000 sec. and then the server can stop including the overload-report.
Besides, I am still not convince that "during the overload condition, using some logic to avoid inclusion of overload-report is less resource consuming than simply including the same overload-report".

Yes, the reason behind defining timestamp is to allow the reacting node to discard the overload-report if the same was already received from the reporting node.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 3:53 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

please see inline.

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 10:15 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 1:54 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

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) [Nirav] This is not always true, e.g. as I had indicated if the node has advertised 10% reduction-percentage for 10 sec., it need not bother to advertise no-overload condition since the validity-period was very small.
[Ulrich] Also not always true, e.g. if the reporting node has requested at 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to request a 10% reduction for 10 sec. Although the validity-period is small (10 sec) there may still be a reacting node that did not get the update and keeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to take REQ 10 seriously. My understanding was that timeout is last resort, not the normal way.

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) [Nirav] The reacting node should continue to apply the earlier received OC-OLR. 
" (Note: We seem to

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) [Nirav] Please refer to Timestamp AVP within OC-OLR.

Adding dime-list again.

Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

 

 
Architecture:
 
                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.
 
Best regards
Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Nov 2013 15:33:21 +0000

Nirav,

in summary it seems that we have two valid options:

Option A: 
A1: the server (or reporting node), while overloaded must insert the load OC-OLR AVP in every answer message.
A2: the server (or reporting node) after leaving the overload state must continue inserting the OC-OLR AVP (indicating end of throttling request) for some time (how long needs to be calculated by the server) or the server must rely on expiry of outdated overload reports.
A3: the reacting node must/should check the timeStamp in every OC-OLR AVP received in answer messages in order not to miss an update.

Option B:
B1: the reacting node, while performing throttling, must insert the OC-Ongoing-Throttling-Information in every request message.
B2: void (the reacting node , while no longer throttling, simply does not insert OC-Ongoing-Throttling-Information)
B3: the reporting node must/should check OC-Ongoing-Throttling-Information received in a request in order to decide whether or not OC-OLR must be sent back. 

Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 5:29 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 3:53 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

please see inline.

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 10:15 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 1:54 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Adding dime-list again.

Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

 

 
Architecture:
 
                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.
 
Best regards
Ulrich

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 14 Nov 2013 14:53:32 +0000

Ulrich,

I confirm the summary below of having two valid options.

Just wanted to highlight one aspect, in general.
Current definition of the OC-OLR AVP suggest the inclusion of TimeStamp and ValidityDuration AVPs. And these AVPs are applicable/valid/needed in both the options below.
Additionally, if we decide to go for option B, we would need to define new AVP OC-Ongoing-Throttling-Information AVP.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 9:03 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Option A: 

Option B:

Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 5:29 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 3:53 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

please see inline.

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 10:15 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 1:54 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Adding dime-list again.

Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

 

 
Architecture:
 
                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.
 
Best regards
Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 20 Nov 2013 15:24:48 +0000

Nirav,

thank you for your confirmation.
In order to select the best solution let me try to start a comparism:

1) A1 can be compared with B1 as both require to insert an AVP in every message (answer/request, while overloaded/while performing throttling): A1 adds (resource consuming) functionality to the (overloaded) server/reporting node while B1 adds to the client/reacting node. Furthermore, the AVP to be inserted in A1 (OC-OLR) is the only OC-specific AVP to be inserted to the answer whereas the AVP to be inserted in B1 (OC-Ongoing-Throttling-Information) would be in addition to the OC-Feature-Vector which anyway needs to be added to every request (inserting OC specific info to requests is needed anyway). Furthermore A1 seems to violate REQ 13 from RFC 7068 while B1 does not. All this clearly is a pro for option B.

2) A2 can be compared with B2: A2 either requires additional processing at the server/reporting node or relies on timouts (violating REQ 10) while B2 does not require any corresponding functionality. This is also a pro for Option B.

3) A3 can be compared with B3 as both recommend to check the presence of new OC-specific info in all received messages: A3 adds the recommended functionality to the (overloaded) server/reporting node while B3 adds to the client/reacting node. This is a pro for option A.

4) Option B adds a feedback channel from client to server making the solution more robust. It also allows the server to give some priority to already throttled traffic (see REQ 18) and it allows agents to ensure that already throttled traffic (by a downstream node) is not throttled again. This is a pro for option B.

5) In Option A it is not clear how the client/reacting node should behave when it receives an answer without OC-OLR AVP while performing throttling. This is a con for option A.

In summary my preference is for option B.

Comments are welcome.

Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Thursday, November 14, 2013 3:54 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 9:03 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Option A: 

Option B:

Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 5:29 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 3:53 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

please see inline.

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 10:15 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 1:54 PM
To: Nirav Salot (nsalot); [email-masked]; [email-masked]
Subject: RE: Ongoing Throttling Information in request messages

Nirav,

Adding dime-list again.

Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Not quite.

The question is:

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Nirav,

Best regards
Ulrich

Ulrich,

Regards,
Nirav.

Hi,
draft-docdt-dime-ovli-01

 

 
Architecture:
 
                       +----------------+
                       | supporting     |
                      /| agent A1       |\

Comments are welcome.
 
Best regards
Ulrich

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 Nov 2013 13:56:45 -0600

On Nov 7, 2013, at 4:23 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> Furthermore you seem not to take REQ 10 seriously. My understanding was that timeout is last resort, not the normal way.

I disagree with that conclusion.

Quoting RFC 7068:

> Consumers of overload information MUST be able to determine
>            when the overload condition improves or ends.

That text does not contemplate any particular mechanism, e.g. timeouts vs explicit notification. It merely requires that a mechanism exists.  The solution draft actually has _two_ mechanism for this (i.e. timeouts and explicit notification.) It's up to the implementation to figure out the exact details. Sure, it would be bad form for a node to declare an hour long overload period, have it resolve in a few seconds, and then leave the reacting nodes hanging for the rest of the hour.

 OTOH, I see nothing wrong at the protocol level with Nirav's case of having a short timeout, and just letting it expire. Whether it's the most efficient approach is another issue. We might offer guidance on that, but I would expect such guidance to be non-normative advice.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 Nov 2013 16:33:30 -0600

Hi,

I do not object to marking requests that survived throttling in general, although I think we might need some simulations to see if it really helps. However, I have reservations about the use of the timestamp.

Your argument for the timestamp seems to be based on an assumption that it is expensive to resend an existing OLR, or at least that it is more expensive to resend it than to check timestamps to determine if you need to send it. I note that Nirav and Steve both questioned that assumption. So do I.

I think in most cases, the execution of logic to determine if a node needs to resend an OLR is likely to be more expensive than just sending it.

We're talking about a reporting node that's already in overload. That means it already has insufficient resources to handle the offered load. There's a fair chance that one of those constrained resources is CPU cycles. It's _not_ particularly likely that the constrained resource is the network link between the reporting nodes and its reacting nodes. If those links were overloaded, the reporting node would probably be seeing less traffic in the first place. Inserting an already (or mostly already) constructed OLR into a Diameter answer.

Again, this is probably something better tested in simulation than just assumed--I'm just going on my own instincts and experience.

One approach to this would be to _allow_ a reporting node to use the timestamp to avoid sending extra copies of an OLR, but not _require_ it. That is, treat it like an hint to the server that the server can apply if it helps it to do so.

Thanks!

Ben.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 27 Nov 2013 11:21:09 +0000

Ben,

I disagree.

The requirement is not to "...determine _whether or not _ the overload condition improved or ended".
The word "when" has a strong reference to "point in time". 
The timeout mechanism does not allow the consumer of overload information to detect the point in time at which the overload condition ends.

Also: REQ 8 is not addressed by the timeout mechanism as overload information may become stale before expiry.

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 27 Nov 2013 11:21:20 +0000

Ben,

thank you for not objecting to marking requests that survived a throttling. From here it is only a small step to additionally indicate which type of throttling (10% or 80% or.... identified by timestamp) the request survived.

Open issue is to assess whether

a) executing some logic (timestamp check) always + sending OLR only in the very few cases where it is needed
is more expensive (in terms or resource consumption contributing to overload) than
b) sending OLR always

One approach could be to 
- mandate sending of Ongoing-Throttling-Information(TimeStamp) in request messages by acting nodes while performing throttling
- reporting nodes that are in overload may either do a) or b) whatever is regarded less resource consuming by the implementation
- reporting nodes that are not (no longer) overloaded must do a)

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, November 26, 2013 11:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] Ongoing Throttling Information in request messages

Hi,

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Nov 2013 09:30:24 -0600

On Nov 27, 2013, at 5:21 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> Ben,
> 
> thank you for not objecting to marking requests that survived a throttling.

To be clear, by "not objecting" I mean that I think it might be a worthwhile extension to pursue, but I'm not convinced it needs to go in the base spec.

> From here it is only a small step to additionally indicate which type of throttling (10% or 80% or.... identified by timestamp) the request survived.

I'm not sure what the purpose of that would be.

> is more expensive (in terms or resource consumption contributing to overload) than

Agreed, but with the caveat that we still have c) reporting node resends when it wants to.

> - reporting nodes that are not (no longer) overloaded must do a)

Why the last point? I'd leave it as a MAY for both cases.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 27 Nov 2013 16:48:06 +0000

Ben,

Please see inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 4:30 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] Ongoing Throttling Information in request messages

I'm not sure what the purpose of that would be.
[Wiehe, Ulrich (NSN - DE/Munich)] This is to allow the reporting node to detect whether the reacting node is already doing the correct throttling or whether it is still doing a throttling based on stale information and therefore needs to be updated with the latest OLR.

Agreed, but with the caveat that we still have c) reporting node resends when it wants to.
[Wiehe, Ulrich (NSN - DE/Munich)] no. It's either "send OLR when needed and when not needed" (i.e. always see b)) or "send OLR when needed and don't send OLR when not needed (see a)). "do what you want" would allow not sending OLR although needed.

Why the last point? I'd leave it as a MAY for both cases.
[Wiehe, Ulrich (NSN - DE/Munich)] because non-overloaded reporting nodes do not do b)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Nov 2013 14:39:02 -0600

> [Wiehe, Ulrich (NSN - DE/Munich)] This is to allow the reporting node to detect whether the reacting node is already doing the correct throttling or whether it is still doing a throttling based on…

This seems like premature optimization. It adds quite a bit of complexity, and I don't think the returns are going to be worth it. 

> [Wiehe, Ulrich (NSN - DE/Munich)] no. It's either "send OLR when needed and when not needed" (i.e. always see b)) or "send OLR when needed and don't send OLR when not needed (see a)). "do what you…

By "do what you want" I mean that you follow local policy to determine when it's needed. We don't need the protocol to normatively define that.

> [Wiehe, Ulrich (NSN - DE/Munich)] because non-overloaded reporting nodes do not do b)

Your last bullet said "reporting nodes that are not (no longer) overloaded must do a)" That's not a "may".

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Nov 2013 08:02:14 +0000

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 9:39 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] Ongoing Throttling Information in request messages

> [Wiehe, Ulrich (NSN - DE/Munich)] This is to allow the reporting node to detect whether the reacting node is already doing the correct throttling or whether it is still doing a throttling based on…

This seems like premature optimization. 

[Wiehe, Ulrich (NSN - DE/Munich)] no, unless we say "doing the wrong throttling is good - doing the correct throttling is an optimization"
It adds quite a bit of complexity, and I don't think the returns are going to be worth it. 
[Wiehe, Ulrich (NSN - DE/Munich)] I do not agree

[Wiehe, Ulrich (NSN - DE/Munich)] how would the local policy be able to determine the right thing to do?

Your last bullet said "reporting nodes that are not (no longer) overloaded must do a)" That's not a "may".
[Wiehe, Ulrich (NSN - DE/Munich)] I agree, it's not a "may", it is a "must".