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

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:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
Envoyé : vendredi 21 février 2014 18:33
À : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

+1 (including Steve comment)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : vendredi 21 février 2014 16:37
À : dime@ietf.org<mailto:dime@ietf.org>
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

DiME@ietf.org<mailto:DiME@ietf.org>

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.