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

OK

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 13 février 2014 13:55
À : dime@ietf.org
Objet : Re: [Dime] [dime] #52: Throttling not needed to be based on previous history

+1
On 2/12/14 7:34 AM, Maria Cruz Bartolome wrote:

Thanks Jouni, I didn't realize.

One more correction added

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.

-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: miércoles, 12 de febrero de 2014 10:36

To: Maria Cruz Bartolome

Cc: dime@ietf.org<mailto:dime@ietf.org>

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

Fine by me.. though you then need to apply the same change to the rest of this paragraph, not only the first one.

Also, please update this additional concern into the issue tracker issue #52.

- Jouni

On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com><mailto:maria.cruz.bartolome@ericsson.com> wrote:

Same comment also applies to following paragraph in 5.5.2

Now:

  0 < value < 100

     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 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.

We should not specify a rates for the simple loss algorithm. It's up to the implementation how to reduce, but no time unit has to be specified.

-----Original Message-----

From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Sent: miércoles, 12 de febrero de 2014 9:13

To: Maria Cruz Bartolome

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: [dime] #52: Throttling not needed to be based on previous

history

#52: Throttling not needed to be based on previous history

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.

The intention is to avoid that anyone may interpret reacting node is  required to consider history of sent information when throttling.

--

-----------------------------------------------+----------------------

-----------------------------------------------+--

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com<mailto:maria.cruz.bartolome@ericsson.com>  |      Owner:  MCruz

    Type:  defect                             |  Bartolomé

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                              |   Keywords:

-----------------------------------------------+----------------------

-----------------------------------------------+--

-----------------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/52><http://trac.tools.ietf.org/wg/dime/trac/ticket/52>

dime <http://tools.ietf.org/wg/dime/><http://tools.ietf.org/wg/dime/>

_______________________________________________

DiME mailing list

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

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

_______________________________________________

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.