Re: [Dime] Issue#30 status

See inline.

Steve
On 2/26/14 7:27 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> I did not say that the server MUST do so.
>
SRD> I assumed a MUST if this was to be used as a way to communicate
support for DOIC. 
>
>  
>
> For my clarification: what is the proposal for OC-Supported-Features
> in answer messages? Is it  a MUST in all answer messages that
> correspond to requests that indicated DOIC support? If so, why is it
> better
>
> a) to always say "yes I support DOIC" rather than
>
> b) to always say "current overload is xx"  
>
> where xx includes the possibility to say "no overload" and of course
> b) implicitly indicates "yes I support DOIC"
>
SRD> One is capability advertisement the other is overload reporting. 
We should not mix the semantics of the two.

SRD> We don't have consensus yet, but if we agree on the need for
reacting nodes to know whether there is support for DOIC in the Diameter
network then I think the requirement would be similar to how we are
handling overload reports.  The reporting node MUST ensure that all
reacting nodes receive the OC-Supported-Features AVP.  This can be done
by including the AVP in all answer messages or it can be done by
remembering to whom the AVP has been sent.
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, February 26, 2014 2:09 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> *Cc:* dime@ietf.org list
> *Subject:* Re: [Dime] Issue#30 status
>
>  
>
> I agree that a server can send a continuing stream of OLRs with a
> reduction percentage of zero.
>
> I don't agree that the server MUST do so.
>
> What is the point of sending the OLR for the 99% of the time when
> there is no overload when absence of an OLR communicates exactly the
> same thing?
>
> Steve
>
> On 2/26/14 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     that is neither correct nor did we agree so.
>
>      
>
>     No OLR means "no change", it does not mean "no overload".
>
>     When a reporting node is not in overload, it still is allowed to
>     send OLRs (indicating no overload/ end of overload) just to make
>     sure that the reacting node has up to date information (it needs
>     not do so when it knows that the reacting node already has
>     sufficiently up to date information).
>
>      
>
>     Ulrich
>
>      
>
>     *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Wednesday, February 26, 2014 1:35 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
>     *Cc:* dime@ietf.org <mailto:dime@ietf.org> list
>     *Subject:* Re: [Dime] Issue#30 status
>
>      
>
>     Ulrich,
>
>     An OLR is included in every answer message only when the reporting
>     node is in an overload state.  There are no overload reports when
>     the reacting node is not overloaded.
>
>     Steve
>
>     On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Steve, Ben, all,
>
>          
>
>         on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.
>
>          
>
>         On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).
>
>          
>
>         Ulrich
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
>
>         Sent: Tuesday, February 25, 2014 12:02 AM
>
>         To: Steve Donovan
>
>         Cc: dime@ietf.org <mailto:dime@ietf.org> list
>
>         Subject: Re: [Dime] Issue#30 status
>
>          
>
>          
>
>         On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> <mailto:srdonovan@usdonovans.com> wrote:
>
>          
>
>             I can see two additional reasons for requiring OC-Supported-Features:
>
>              
>
>             1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.
>
>              
>
>             this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.
>
>              
>
>             There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.
>
>              
>
>             2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.
>
>              
>
>             My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.
>
>          
>
>         +1 on both points
>
>         _______________________________________________
>
>         DiME mailing list
>
>         DiME@ietf.org <mailto:DiME@ietf.org>
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>          
>
>      
>
>  
>