Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages

From: "dime issue tracker" <[email-masked]>
Date: Fri, 21 Mar 2014 13:32:57 -0000

#30: OC-Supported-Features AVP in answer messages

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 We reached the tentative agreement in the DIME meeting on the following:

 OC-Supported-Features handling:

 Agreed: OC-Supported-Features AVP MUST be included in all answer messages
 (we had already agreed that it must be included in all request messages).
 Agreed: Reacting node advertises all supported algorithms;
 Agreed: Reporting node responds with the single algorithm it will be
 using;
 Agreed: Handling of other feature bits is defined in the extension drafts

 Based on this I believe we need the text changes outlined below.

 Let me know if I have missed any.

 If we agree on the text changes then we can close the issue and I'll
 update the document accordingly.

 Regards,

 Steve

 -----

 Section 5.3.2, paragraph 1:

 Change:

 The answer message
    initiating endpoint MAY announce as many supported capabilities as it
    has (the announced set is a subject to local policy and
    configuration). However, at least one of the announced capabilities
    MUST be the same as received in the request message.

 To:

 The reporting node MUST include the OC-Supported-Features AVP in all
 response messages for transactions where the request message included the
 OC-Supported-Features AVP.  The reporting node MUST announce support of
 the single algorithm that the reporting node will request the reacting
 node to use to mitigate overload instances.  The reporting node MUST NOT
 change the selected algorithm during a period of time that it is in an
 overload state and, as a result, is sending OC-OLR AVPs in answer
 messages.

     Note: There will always be at least one algorithm supported by both
 the reacting and reporting nodes as all nodes that support DOIC must
 support the loss algorithm defined in this document.

 The handling of feature bits in the OC-Feature-Vector AVP that are not
 associated with overload abatement algorithms MUST be specified by the
 extension that defines the feature.

 Paragraph 2:

 Change:

 The answer message initiating endpoint MUST NOT include any overload
    control solution defined AVPs into its answer messages if the request
    message initiating endpoint has not indicated support at the
    beginning of the created session (or transaction in a case of non-
    session state maintaining applications). The same also applies if
    none of the announced capabilities match between the two endpoints.

 To:

 The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR
 AVP or any other overload control AVPs defined in extension drafts in
 response messages for transaction where the request message does not
 include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features
 AVP in the request message indicates that the sender of the request
 message does not support DOIC.

 Section 5.5.2, Paragraph 1:

 Change:

    Once a reacting node receives an OC-OLR AVP from a reporting node, it
    applies the traffic abatement based on the commonly supported
    algorithm with the reporting node and the current overload condition.
    The reacting node learns the reporting node supported abatement
    algorithms directly from the received answer message containing the
    OC-Supported-Features AVP or indirectly remembering the previously
    used traffic abatement algorithm with the given reporting node.

 To: (removing the last portion of the last sentence)

    Once a reacting node receives an OC-OLR AVP from a reporting node, it
    applies the traffic abatement based on the commonly supported
    algorithm with the reporting node and the current overload condition.
    The reacting node learns the reporting node supported abatement
    algorithms directly from the received answer message containing the
    OC-Supported-Features AVP.

 -----

 +1, with a minor suggested edit:

 On Mar 17, 2014, at 2:03 PM, Steve Donovan <[email-masked]>
 wrote:

 > Change:
 >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
 >    applies the traffic abatement based on the commonly supported
 >    algorithm with the reporting node and the current overload condition.
 >    The reacting node learns the reporting node supported abatement
 >    algorithms directly from the received answer message containing the
 >    OC-Supported-Features AVP or indirectly remembering the previously
 >    used traffic abatement algorithm with the given reporting node.

 > To: (removing the last portion of the last sentence)
 >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
 >    applies the traffic abatement based on the commonly supported

 s/"commonly supported"/selected

 "Commonly supported" is no longer descriptive. There may be several
 commonly supported algorithm, but the reporting node selects just one.

 >    algorithm with the reporting node and the current overload condition.
 >    The reacting node learns the reporting node supported abatement
 >    algorithms directly from the received answer message containing the
 >    OC-Supported-Features AVP.
 >

-- 
--------------------------------------+---------------------------
 Reporter:  [email-masked]  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/30#comment:1>
dime <http://tools.ietf.org/wg/dime/>

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 21 Mar 2014 17:10:14 -0400

Just a question.

In the phrase " it
    applies the traffic abatement based on the commonly supported/selected
    algorithm with the reporting node and the current overload condition."

Is it really the "current overload CONDITION", or the "current abatement 
REQUESTED"?

If the message is asking for a 10% reduction in traffic, that does not 
actually identify the "current overload condition".

Janet

From:   "dime issue tracker" <[email-masked]>
To:     [email-masked]
Cc:     [email-masked]
Date:   03/21/2014 09:33 AM
Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): 
OC-Supported-Features AVP in answer messages
Sent by:        "DiME" <[email-masked]>

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Regards,

 Steve

 -----

 Change:

 The answer message

 To:

 Paragraph 2:

 Change:

 To:

 Change:

 -----

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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 08:42:06 -0500

Janet,

Well, in the sense that the current overload condition caused the
current abatement request, the wording is mostly correct.  I agree it
can be made more clear.  It might be better if we changed the word
condition to report.

Steve

On 3/21/14 4:10 PM, Janet P Gunn wrote:
> In the phrase "it
> Is it really the "current overload CONDITION", or the "current
> abatement REQUESTED"?
>
> ------------------------------------------------------------------------
>
>
>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 24 Mar 2014 10:11:55 -0400

Fine with me

Janet

"DiME" <[email-masked]> wrote on 03/24/2014 09:42:06 AM:

> From: Steve Donovan <[email-masked]>
> To: [email-masked]
> Date: 03/24/2014 09:42 AM
> Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages
> current abatement request, the wording is mostly correct.  I agree 
> it can be made more clear.  It might be better if we changed the 
> word condition to report.
> 
> Steve

> If the message is asking for a 10% reduction in traffic, that does 
> not actually identify the "current overload condition". 
> 
> 
> Janet 
> 
> 
> 
> 
> Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Mar 2014 14:36:51 +0000

Hi Steve

I am ok with the changes you proposed including  your modification  coming from  the Janet's remark.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Janet P Gunn
Envoyé : lundi 24 mars 2014 15:12
À : Steve Donovan
Cc : DiME; [email-masked]
Objet : Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages

Fine with me

Janet

"DiME" <[email-masked]<mailto:[email-masked]>> wrote on 03/24/2014 09:42:06 AM:

> From: Steve Donovan <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>
> Sent by: "DiME" <[email-masked]<mailto:[email-masked]>>
>
> Janet,
>

> From:        "dime issue tracker" <[email-masked]<mailto:[email-masked]>>
> To:        [email-masked]<mailto:[email-masked]>
> Cc:        [email-masked]<mailto:[email-masked]>
> Sent by:        "DiME" <[email-masked]<mailto:[email-masked]>>
>
>
>
> Changes (by [email-masked]<mailto:[email-masked]>):
>
> * status:  new => closed
> * resolution:   => fixed
>
>
> Comment:
>
> On Mar 17, 2014, at 2:03 PM, Steve Donovan <[email-masked]<mailto:[email-masked]>>
> wrote:
>
> > Change:
> Reporter:  [email-masked]<mailto:[email-masked]>  |       Owner:  Ulrich Wiehe
> [email-masked]<mailto:[email-masked]>

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

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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 14:07:25 -0500

I didn't get this into the current snapshot but have it marked to put
into the next -02 snapshot.

Steve