Subject: [Dime] draft-ietf-dime-ovli - New suggestion for default algorithm

From: Dave Dolson <[email-masked]>
Date: Thu, 6 Mar 2014 00:59:15 +0000

Jouni et all,

I'm reading this draft for the first time, so apologies if I've totally misunderstood...

As I understand the control signal, the reporting node says "reduce current demand by x %"
- I think this would be implemented in the reacting node by turning away x% of requests.

But then there can be an updated message (with a later sequence number), "reduce current demand by y%",
- I think this would be implemented in the reacting node by turning away (100 - (1-x/100)*(1-y/100)*100) % of traffic.
- E.g., x=20%, y=10% --> 28%

There are also complexities in the protocol (sequence checking) to ensure that it doesn't see the 'x' message twice and apply the 'x' reduction twice.
E.g., reduce by 10%, reduce by 10% (oops) --> 19%
Or what if a message is missed? The reacting node might not be doing what the reporting node thinks it is.

Also, there is no way for the reporting node to reduce the drop by a small percent. E.g., to reduce the drop level back down to 10% from 28%. The only mechanism in the protocol completely removes all control.

So, I think it would be a lot simpler for the reporting node to indicate an absolute percentage to turn away vs. the amount to reduce the previous value by.

In the example above, the reporting node says "shed 10% of demand".
And later it says "shed 28% of demand".
It can also back off a bit by saying "shed 15% of demand"
And it can remove all controls by saying, "shed 0% of demand"
Duplicate commands cause no harm. And if commands are lost we still have eventual consistency when the next message is received.

When conditions are consistently overloaded, the job of the reporting node is to hunt for the best steady-state drop numbers. A good control system cannot be done with all-on/all-off levers.

This protocol change would remove the need for the sequence number (no race conditions to resolve), and rename the OC-Reduction-Percentage to perhaps OC-Discard-Percentage.

Thoughts?

David Dolson
Senior Software Architect
Sandvine

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 6 Mar 2014 07:17:26 +0000

Hi Dave

Thanks for your analysis that I share.
The text of the IETF draft was written  according to your hereafter proposal with   the "absolute percentage" in mind
" I think it would be a lot simpler for the reporting node to indicate an absolute percentage to turn away vs. the amount to reduce the previous value by."
This is the way I read the IETF draft.

Your remark indicates that the current  text in the draft  can be interpreted according to the other way that we must avoid. So I think we have to  carefully review the wording so that there is no more this difference of interpretation.

Best regards

Jean-Jacques

De : DiME [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : jeudi 6 mars 2014 01:59
À : [email-masked]
Cc : [email-masked]
Objet : [Dime] draft-ietf-dime-ovli - New suggestion for default algorithm

Jouni et all,

Thoughts?

David Dolson

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Mar 2014 08:40:27 +0000

On Mar 6, 2014, at 7:17 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <[email-masked]> wrote:

> The text of the IETF draft was written  according to your hereafter proposal with   the “absolute percentage” in mind
> ” I think it would be a lot simpler for the reporting node to indicate an absolute percentage to turn away vs. the amount to reduce the previous value by.”

Agreed. We didn't mean for the percentages to "stack". It would probably be better to describe the percentage reduction as a reduction against what you would have sent if no overload conditions had been reported. If a second overload report contains a smaller reduction percentage, we expect the traffic to increase, not decrease by the additional amount.

> Your remark indicates that the current  text in the draft  can be interpreted according to the other way that we must avoid. So I think we have to  carefully review the wording so that there is no…

Also agreed.

> I’m reading this draft for the first time, so apologies if I’ve totally misunderstood…
>  
> As I understand the control signal, the reporting node says “reduce current demand by x %”
> But then there can be an updated message (with a later sequence number), “reduce current demand by y%”,
> - E.g., x=20%, y=10% à 28%
>  
> There are also complexities in the protocol (sequence checking) to ensure that it doesn’t see the ‘x’ message twice and apply the ‘x’ reduction twice.
> E.g., reduce by 10%, reduce by 10% (oops) à 19%
> In the example above, the reporting node says “shed 10% of demand”.
> And later it says “shed 28% of demand”.
> It can also back off a bit by saying “shed 15% of demand”
> And it can remove all controls by saying, “shed 0% of demand”

---

From: Dave Dolson <[email-masked]>
Date: Thu, 6 Mar 2014 14:24:39 +0000

I think the relevant language is in section 4.7:

"... describes the percentage the sender is requested to reduce, compared to what it otherwise would have sent."

How about:

"... prescribes the absolute percentage of application requests the sender is requested to suppress, compared to what it would have sent without suppression."

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, March 06, 2014 8:40 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc: Dave Dolson; [email-masked]; [email-masked]
Subject: Re: draft-ietf-dime-ovli - New suggestion for default algorithm

Also agreed.

> I'm reading this draft for the first time, so apologies if I've totally misunderstood.
>