Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

From: Janet P Gunn <[email-masked]>
Date: Mon, 3 Mar 2014 13:08:14 -0500

It seems to me this begs the question:
What does "normally sends 100 packets" actually MEAN?  How is the number 
of packets it "normally sends" calculated?

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   <[email-masked]>
To:     Jouni Korhonen <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:   02/28/2014 08:59 AM
Subject:        Re: [Dime] #52: Throttling not needed to be based on 
previous history - conclusion
Sent by:        "DiME" <[email-masked]>

Jouni, I'm assuming that you are OK with the conclusion given here too, 
right? J 
 
De : DiME [mailto:[email-masked]] De la part de Maria Cruz 
Bartolome
Envoyé : mercredi 26 février 2014 13:56
À : [email-masked]
Objet : Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
Fine
 
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, 
JEAN-JACQUES (JEAN-JACQUES)
Sent: miércoles, 26 de febrero de 2014 8:43
To: [email-masked]
Subject: Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
Hi
 
Remove “from now on” is acceptable for me, but  I have a preference for 
the reverse wording Lionel proposes, which is shorter and brings the 
clarification I was looking for,:
For example if an OC-Reduction-Percentage value of 
 10 has been received, the reacting node which 
 would normally send 100 packets MUST only send 90 
 packets to the reporting node.

Best regards 
 
JJacques 

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 24 février 2014 17:00
À : [email-masked]
Objet : Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
I'm with Lionel.  I don't understand why the proposed wording is 
confusing.  Reacting nodes always only apply the reduction percentage for 
the period of time that the specific overload report is active.  That 
period either ends when a new overload report is received or when the 
overload report expires.

That said, I'm happy with just removing the words "from no on" as proposed 
by Lionel below.

Steve
 
On 2/24/14 7:26 AM, [email-masked] wrote:
I don't see the issue, as explained in my mail but OK to remove it. 
 
If "for now" is removed, the resulting text would be:
 
  For example if the reacting node has been sending
  100 packets per second to the reporting node, then
  a reception of OC-Reduction-Percentage value of 10
  would mean that from now on the reacting node MUST
  only send 90 packets per second.
 
Maybe it would be even easier to reverse the sentence as follow:
 
 For example if an OC-Reduction-Percentage value of 
 10 has been received, the reacting node which 
 would normally send 100 packets MUST only send 90 
 packets to the reporting node.

But I'm fine if the initial proposed revised text is kept.
 
Lionel
 
De : DiME [mailto:[email-masked]] De la part de Maria Cruz 
Bartolome
Envoyé : lundi 24 février 2014 14:13
À : [email-masked]
Objet : Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
Hello,
 
I agree with Ulrich's proposal
Cheers
/MCruz
 
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN 
- DE/Munich)
Sent: lunes, 24 de febrero de 2014 10:46
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Subject: Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
I share JJacques concern. Replacing "from now on" with "for the period 
that the overload report is active"
is misleading. May be its better to simply remove "from now on".
 
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, 
JEAN-JACQUES (JEAN-JACQUES)
Sent: Friday, February 21, 2014 7:11 PM
To: [email-masked]
Subject: Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
Hi MCruz, Steve
 
I also agree on the "would send " instead of the "would have sent"  for 
sure.  But I have  a small concern/ clarification  about the Steve comment 
on   "for the period that the overload report is active" and the example 
to which it refers.
 
During the time the OLR is active, which may be rather long,  the traffic 
the reacting node would send may be 100 packet  when it has just received 
the OLR. A bit later, the traffic it would send could be 120 (or 80), and 
from the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on 
which I agree. This is in line  with the every 10th packet dropping  on 
which I also agree. 
 
As the text   would  be written with the Steve modification , we may 
understand it is  80 Packet during all the time  the OLR is active. Not 
yet think to an alternative text, but first to see if you agree with my 
remark.
 
JJacques 

De : DiME [mailto:[email-masked]] De la part de 
[email-masked]
Envoyé : vendredi 21 février 2014 18:33
À : Steve Donovan; [email-masked]
Objet : Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
+1 (including Steve comment)
 
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : vendredi 21 février 2014 16:37
À : [email-masked]
Objet : Re: [Dime] #52: Throttling not needed to be based on previous 
history - conclusion
 
Maria Cruz,
 
I support your suggested changes.  I have one further suggested change 
below.
 
Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history
 
Following agreement is reached:
 
 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.
 
 Proposal:
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 
   and describes the percentage of the traffic that the sender is 
   requested to reduce, compared to what it otherwise would send.  <----

 Now (chapter 5.5.2):
      Indicates that the reporting node urges the reacting node to
      reduce its traffic by a given percentage.  For example if the
      reacting node has been sending 100 packets per second to the
      reporting node, then a reception of OC-Reduction-Percentage value
      of 10 would mean that from now on the reacting node MUST only send
      90 packets per second.  How the reacting node achieves the "true
      reduction" transactions leading to the sent request messages is up
      to the implementation.  The reacting node MAY simply drop every
      10th packet from its output queue and let the generic application
      logic try to recover from it.0 < value < 100
 
  Proposal:
 Indicates that the reporting node urges the reacting node to reduce 
 its traffic by a given percentage. For example if the
 reacting node would send 100 packets to the                          <---
 reporting node, then a reception of OC-Reduction-Percentage value of 
 10 would mean that from now on the reacting node MUST only send
 90 packets instead of 100. How the reacting node achieves the "true <---
 reduction" transactions leading to the sent request messages is up to 
 the implementation. The reacting node MAY simply drop every 10th 
 packet from its output queue and let the generic application logic try 
 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the 
overload report is active"

 
 
_______________________________________________
DiME mailing list
[email-masked]
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.
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
DiME mailing list
[email-masked]
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.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Mon, 03 Mar 2014 18:52:32 +0000

Janet,

I'm not sure why we use the word packets.  It should be requests
instead.  Throttling does not impact packets carrying answer messages,
for instance.

What is meant is that if normal handling would have resulted in 100
request messages being sent then an overload report requesting a
reduction of 10% would result in 90 request messages being sent and 10
request messages being throttled.  The loss algorithm is intentionally
simple and stateless.  The proposed implementation being to drop 1 in X
messages where X is calculated based on the requested percentage
reduction received in the overload report.  This is meant to be
independent of any hysteresis and independent of the arrival rate of
service requests.

Steve

On 3/3/14 6:08 PM, Janet P Gunn wrote:
> What does "normally sends 100 packets" actually MEAN?  How is the
> number of packets it "normally sends" calculated?
>
> Janet
>
> This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery. NOTE: Regardless of content, this e-mail shall
> not operate to bind CSC to any order or other contract unless pursuant
> to explicit written agreement or government initiative expressly
> permitting the use of e-mail for such purpose.
>
>
>
> ------------------------------------------------------------------------
>
>
>
> Jouni, I'm assuming that you are OK with the conclusion given here
> too, right? J
>  
> *De :* DiME [mailto:[email-masked]] *De la part de* Maria Cruz
> Bartolome*
> Envoyé :* mercredi 26 février 2014 13:56*
> À :* [email-masked]*
> Objet :* Re: [Dime] #52: Throttling not needed to be based on previous
> history - conclusion
>  
> Fine
>  
> *From:* DiME [mailto:[email-masked]] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)*
> Sent:* miércoles, 26 de febrero de 2014 8:43*
> To:* [email-masked]*
> Subject:* Re: [Dime] #52: Throttling not needed to be based on
> Remove "from now on" is acceptable for me, but  I have a preference
> for the reverse wording Lionel proposes, which is shorter and brings
> the clarification I was looking for,:
> *De :* DiME [_mailto:[email-masked]] *De la part de* Steve
> Donovan*
> Envoyé :* lundi 24 février 2014 17:00*
> À :* [email-masked] <mailto:[email-masked]>*
> Objet :* Re: [Dime] #52: Throttling not needed to be based on previous
> history - conclusion
>  
> confusing.  Reacting nodes always only apply the reduction percentage
> for the period of time that the specific overload report is active.
>  That period either ends when a new overload report is received or
> when the overload report expires.
>
> That said, I'm happy with just removing the words "from no on" as
> proposed by Lionel below.
>
> Steve
>
> On 2/24/14 7:26 AM, [email-masked]
> <mailto:[email-masked]>wrote:
> De : DiME [_mailto:[email-masked]] De la part de Maria Cruz
> Bartolome
> À : [email-masked] <mailto:[email-masked]>
> From: DiME [_mailto:[email-masked]] On Behalf Of Wiehe, Ulrich
> (NSN - DE/Munich)
> To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
> <mailto:[email-masked]>
> From: DiME [_mailto:[email-masked]] On Behalf Of ext TROTTIN,
> To: [email-masked] <mailto:[email-masked]>
> I also agree on the "would send " instead of the "would have sent"
>  for sure.  But I have  a small concern/ clarification  about the
> Steve comment on   "for the period that the overload report is active"
> and the example to which it refers.
>  
> During the time the OLR is active, which may be rather long,  the
> traffic the reacting node would send may be 100 packet  when it has
> just received the OLR. A bit later, the traffic it would send could be
> 120 (or 80), and from the OLR definition,   it would send 120x0,9 (or
> 80* 0,9) packets, on  which I agree. This is in line  with the every
> 10th packet dropping  on which I also agree.
>  
> understand it is  80 Packet during all the time  the OLR is active.
> Not yet think to an alternative text, but first to see if you agree
> with my remark.
>  
> JJacques
>  
>  
> De : DiME [_mailto:[email-masked]] De la part de
> [email-masked] <mailto:[email-masked]>
> À : Steve Donovan; [email-masked] <mailto:[email-masked]>
> De : DiME [_mailto:[email-masked]] De la part de Steve Donovan
> À : [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/dime_
>  
>  
> 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;
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.
>  
> 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;
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.
>  
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/dime_
>  
>  
> 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;
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 3 Mar 2014 15:08:04 -0500

OK, I admit to being confused.

Independent of the packets vs requests distinction-

Assuming a node receives a message requiring 10% reduction, does this mean

A - The node will drop one out of every 10 requests it "wants" to send , 
whether it "wants" to send 10 requests or 1000 requests per unit time.

or 

B- If it "normally" sends 100 messages per unit time, it will restrict 
itself to 90 messages per unit time, regardless of whether it "wants" to 
send 10 or 1000
?

"A" makes more sense to me, but the proposed text (repeated below) seems 
to imply "B" (90 packets per second based on what it "has been sending" or 
"would normally send" independent of the number the node "wants" to 
send").

If "A" is intended, I suggest rewording the text to make it clearer

<quoted from below>

</quoted from below>

It is possible that your "would normally send" is the same as my "wants to 
send", but that isn't the way it reads, at least to me.

Thanks,

Janet

From:   Steve Donovan <[email-masked]>
To:     [email-masked]
Date:   03/03/2014 01:52 PM
Subject:        Re: [Dime] #52: Throttling not needed to be based on 
previous history - conclusion
Sent by:        "DiME" <[email-masked]>

Janet,

I'm not sure why we use the word packets.  It should be requests instead. 
Throttling does not impact packets carrying answer messages, for instance.

What is meant is that if normal handling would have resulted in 100 
request messages being sent then an overload report requesting a reduction 
of 10% would result in 90 request messages being sent and 10 request 
messages being throttled.  The loss algorithm is intentionally simple and 
stateless.  The proposed implementation being to drop 1 in X messages 
where X is calculated based on the requested percentage reduction received 
in the overload report.  This is meant to be independent of any hysteresis 
and independent of the arrival rate of service requests. 

Steve

Janet

  
  
Fine 

Hi 

Best regards 
  
JJacques 

Steve

  

  
Lionel 

Hello, 

  
  
Ulrich 

  
Hi MCruz, Steve 

 
  
JJacques 

  
  
Maria Cruz, 

Steve 

 Now (chapter 4.7): 
  
 Proposal: 

 Now (chapter 5.5.2): 
  
  Proposal:

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 3 Mar 2014 23:03:35 +0000

Hello Janet, all,

The pre-agreed proposal is the following:

Now (chapter 4.7):

Proposal:
  The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
  and describes the percentage of the traffic that the sender is
  requested to reduce, compared to what it otherwise would send.

Now (chapter 5.5.2):

    logic try to recover from it.

Proposal:

    reduce its traffic by a given percentage. For example if an

    OC-Reduction-Percentage value of  10 has been received,

    the reacting node which  would normally send 100 requests

    MUST only send 90 requests to the reporting node.

    How the reacting node achieves the "true

    to the implementation. The reacting node MAY simply drop every 10th

   request from its output queue and let the generic application logic

   try to recover from it.

Let me know if this text covers your concerns.
I took profit to replace packet by request.

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: lunes, 03 de marzo de 2014 21:08
To: Steve Donovan
Cc: DiME; [email-masked]
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

A - The node will drop one out of every 10 requests it "wants" to send , whether it "wants" to send 10 requests or 1000 requests per unit time.

or

B- If it "normally" sends 100 messages per unit time, it will restrict itself to 90 messages per unit time, regardless of whether it "wants" to send 10 or 1000
?

"A" makes more sense to me, but the proposed text (repeated below) seems to imply "B" (90 packets per second based on what it "has been sending" or "would normally send" independent of the number the node "wants" to send").

<quoted from below>

It is possible that your "would normally send" is the same as my "wants to send", but that isn't the way it reads, at least to me.

Thanks,

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

From:        Steve Donovan <[email-masked]>
To:        [email-masked]
Date:        03/03/2014 01:52 PM
Subject:        Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Sent by:        "DiME" <[email-masked]>
________________________________

Janet,

I'm not sure why we use the word packets.  It should be requests instead.  Throttling does not impact packets carrying answer messages, for instance.

What is meant is that if normal handling would have resulted in 100 request messages being sent then an overload report requesting a reduction of 10% would result in 90 request messages being sent and 10 request messages being throttled.  The loss algorithm is intentionally simple and stateless.  The proposed implementation being to drop 1 in X messages where X is calculated based on the requested percentage reduction received in the overload report.  This is meant to be independent of any hysteresis and independent of the arrival rate of service requests.

Steve

On 3/3/14 6:08 PM, Janet P Gunn wrote:
It seems to me this begs the question:
What does "normally sends 100 packets" actually MEAN?  How is the number of packets it "normally sends" calculated?

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

From:        <[email-masked]><mailto:[email-masked]>
To:        Jouni Korhonen <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Date:        02/28/2014 08:59 AM
Subject:        Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Sent by:        "DiME" <[email-masked]><mailto:[email-masked]>
________________________________

Jouni, I'm assuming that you are OK with the conclusion given here too, right? ☺

De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mercredi 26 février 2014 13:56
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Fine

From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: miércoles, 26 de febrero de 2014 8:43
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Hi

Remove “from now on” is acceptable for me, but  I have a preference for the reverse wording Lionel proposes, which is shorter and brings the clarification I was looking for,:

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 24 février 2014 17:00
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

I'm with Lionel.  I don't understand why the proposed wording is confusing.  Reacting nodes always only apply the reduction percentage for the period of time that the specific overload report is active.  That period either ends when a new overload report is received or when the overload report expires.

That said, I'm happy with just removing the words "from no on" as proposed by Lionel below.

Steve

On 2/24/14 7:26 AM, [email-masked]<mailto:[email-masked]> wrote:
I don't see the issue, as explained in my mail but OK to remove it.

Lionel

De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : lundi 24 février 2014 14:13
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Hello,

From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 10:46
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

I share JJacques concern. Replacing "from now on" with "for the period that the overload report is active"
is misleading. May be its better to simply remove "from now on".

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Friday, February 21, 2014 7:11 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Hi MCruz, Steve

I also agree on the "would send " instead of the "would have sent"  for sure.  But I have  a small concern/ clarification  about the Steve comment on   "for the period that the overload report is active" and the example to which it refers.

During the time the OLR is active, which may be rather long,  the traffic the reacting node would send may be 100 packet  when it has just received the OLR. A bit later, the traffic it would send could be 120 (or 80), and from the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  which I agree. This is in line  with the every 10th packet dropping  on which I also agree.

As the text   would  be written with the Steve modification , we may understand it is  80 Packet during all the time  the OLR is active. Not yet think to an alternative text, but first to see if you agree with my remark.

JJacques

De : DiME [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : vendredi 21 février 2014 18:33
À : Steve Donovan; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : vendredi 21 février 2014 16:37
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Maria Cruz,

I support your suggested changes.  I have one further suggested change below.

Steve

Now (chapter 4.7):

Proposal:

Now (chapter 5.5.2):

 Proposal:
SRD> Replace "from now on" in the above with "for the period that the overload report is active"

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
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.

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.

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
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.
_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 4 Mar 2014 12:45:08 -0500

I think the intent, in changing from "has been sending  100 requests per 
second" to "would normally send 100 requests" was to get rid of the 
reference to a  "historical  transmission rate".

The phrase, "would normally send" still has the connotation (for me 
anyway) of a "historical  transmission rate".

Possible suggestions are 
"would, without overload control, send 100 requests"
or 
"would otherwise send 100 requests" (which is consistent with the wording 
in 4.7).

Just trying to make it clearer to future readers.

Thanks

Janet

From:   Maria Cruz Bartolome <[email-masked]>
To:     Janet P Gunn/USA/CSC@CSC, Steve Donovan <[email-masked]>
Cc:     DiME <[email-masked]>, "[email-masked]" <[email-masked]>
Date:   03/03/2014 06:03 PM
Subject:        RE: [Dime] #52: Throttling not needed to be based on 
previous history - conclusion

Hello Janet, all,

Now (chapter 4.7): 
 
Proposal: 

Now (chapter 5.5.2):
 
Proposal:

Best regards
/MCruz

or 

<quoted from below>

Thanks, 

Janet

Janet,

Steve

Janet

 
 
Fine 

Hi 

Best regards 
 
JJacques 

Steve

 

 
Lionel 

Hello, 

 
 
Ulrich 

 
Hi MCruz, Steve 

 
 
JJacques 

 
 
Maria Cruz, 

Steve 

Now (chapter 4.7): 
 
Proposal: 

Now (chapter 5.5.2): 
 
 Proposal:

---

From: <[email-masked]>
Date: Tue, 4 Mar 2014 18:02:03 +0000

I'm ok with both. Pick one! :)

Lionel

De : Janet P Gunn [mailto:[email-masked]] 
Envoyé : mardi 4 mars 2014 18:45
À : Maria Cruz Bartolome
Cc : [email-masked]; DiME; Steve Donovan
Objet : RE: [Dime] #52: Throttling not needed to be based on previous history - conclusion

I think the intent, in changing from "has been sending  100 requests per second" to "would normally send 100 requests" was to get rid of the reference to a  "historical  transmission rate". 

The phrase, "would normally send" still has the connotation (for me anyway) of a "historical  transmission rate". 

Possible suggestions are 
"would, without overload control, send 100 requests" 
or 
"would otherwise send 100 requests" (which is consistent with the wording in 4.7). 

Thanks 

Janet

From:        Maria Cruz Bartolome <[email-masked]> 
To:        Janet P Gunn/USA/CSC@CSC, Steve Donovan <[email-masked]> 
Cc:        DiME <[email-masked]>, "[email-masked]" <[email-masked]> 
Date:        03/03/2014 06:03 PM 
Subject:        RE: [Dime] #52: Throttling not needed to be based on previous history - conclusion 
________________________________________

Hello Janet, all, 

Now (chapter 4.7): 

Proposal: 

Now (chapter 5.5.2): 
  
Proposal: 

Best regards 
/MCruz 

or 

<quoted from below>

Thanks, 

Janet

________________________________________

Janet,

Steve

Janet

To:        Jouni Korhonen <[email-masked]>, "[email-masked]" <[email-masked]> 

________________________________________

Fine 

Hi 

Best regards 

JJacques 

Steve

Lionel 

Hello, 

Ulrich 

Hi MCruz, Steve 

JJacques 

De : DiME [mailto:[email-masked]] De la part de [email-masked] 
Envoyé : vendredi 21 février 2014 18:33 
À : Steve Donovan; [email-masked] 
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion 

Maria Cruz, 

Steve 

Now (chapter 4.7): 

Proposal: 

Now (chapter 5.5.2): 

Proposal: