Subject: [Dime] Issue#30 status

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 19 Feb 2014 09:57:39 +0000

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

Dear all,

It may be too early to finaly conclude on this one.

It seems we have consensus in the following: Absence of Supported-Features-AVP from an answer message MUST not result in reacting nodes to cease sending of any DOIC related AVPs in subsequent requests.

It is still open whether we can remove OC-Supported-Features from answer messages. However we seem to agree that the meaning of OC-OLR AVP is not dependent from any OC-Supported-Features AVP within the same answer.

The open question seems to be whether it is required for reacting nodes to do different throttlings based on implicit signals towards a) non-supporting destinations  and b) supporting but not traffic-reduction-requesting destinations. If required it seems also be clear that an additional indication is needed to indicate whether the OC-Supported-Feature AVP was inserted by the server (host) or by an agent (realm).

Ulrich

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 19 Feb 2014 12:24:49 +0200

> It seems we have consensus in the following: Absence of Supported-Features-AVP from an answer message MUST not result in reacting nodes to cease sending of any DOIC related AVPs in subsequent reque…

This is OK.

> It is still open whether we can remove OC-Supported-Features from answer messages. However we seem to agree that the meaning of OC-OLR AVP is not dependent from any OC-Supported-Features AVP within…

I do not agree that the OC-OLR meaning is not dependant on the OC-Supported-Features in the answer.

> The open question seems to be whether it is required for reacting nodes to do different throttlings based on implicit signals towards a) non-supporting destinations  and b) supporting but not traff…

Right.

- Jouni

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 19 Feb 2014 12:37:46 +0000

Hi Jouni,

thank you for your reply, and sorry for not having correctly summarized the status with regard to dependencies between OC-OLR AVP and OC-Supported-Features AVP in an answer message.

I would like to further discuss this aspect.
My understanding is: as long as only OLR_DEFAULT_ALGO (0x0000000000000001) is supported, there is no such dependency.
Furthermore: even with the introduction of Rate-control in draft-donovan-dime-doc-rate-control-00, no such dependency is introduced. 
An OLR is a loss-type OLR when it contains a Reduction-Percentage and it's a rate-type OLR when it contains an OC-Maximum-Rate AVP (see draft-donovan-dime-doc-rate-control-00 clause 4.1).

A future extension may introduce such dependency (although I don't think it's a good idea) e.g. by saying that an OLR is a new-feature-type OLR when the OC-Supported-Features AVP in the same answer message indicates support of new-feature, and a loss-type OLR otherwise; however this is subject to be specified in the extension spec, not in draft-ietf-dime-ovli.

Summary: currently no dependency; currently dependency is no reason to have OC-Supported-Feature in anwers; new feature may introduce the dependency and consequently introduce OC-Supported-Feature in answer.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Wednesday, February 19, 2014 11:25 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked] list
Subject: Re: [Dime] Issue#30 status

This is OK.

Right.

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 14:12:38 -0600

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.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Feb 2014 17:01:39 -0600

On Feb 24, 2014, at 2:12 PM, Steve Donovan <[email-masked]> wrote:

> 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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Feb 2014 09:23:19 +0000

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:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Tuesday, February 25, 2014 12:02 AM
To: Steve Donovan
Cc: [email-masked] list
Subject: Re: [Dime] Issue#30 status

+1 on both points

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Feb 2014 06:35:07 -0600

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Feb 2014 13:01:53 +0000

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:[email-masked]]
Sent: Wednesday, February 26, 2014 1:35 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked] 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

Steve, Ben, all,

Ulrich

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

To: Steve Donovan

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

On Feb 24, 2014, at 2:12 PM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

+1 on both points

DiME mailing list

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Feb 2014 07:08:58 -0600

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:
> 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:[email-masked]]
> *Sent:* Wednesday, February 26, 2014 1:35 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> *Cc:* [email-masked] 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
>     Cc: [email-masked] <mailto:[email-masked]> list
>
>     On Feb 24, 2014, at 2:12 PM, Steve Donovan <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Feb 2014 13:27:48 +0000

I did not say that the server MUST do so.

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"

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, February 26, 2014 2:09 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked] 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.

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

Ulrich

Ulrich,

Steve

Steve, Ben, all,

Ulrich

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

To: Steve Donovan

+1 on both points

DiME mailing list

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Feb 2014 09:08:56 -0600

We are going around in circles on this one. I don't agree for reasons I have stated before, but will state again for reference (see inline).

> 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 algori…

I think it's best to keep it there for all algorithms. I'd like to be able to look for a single field and understand wether DOIC is supported, what algorithm is being used, as well as any parameters for that algorithm (even if none.) I don't want to have to look for the field, then if it's not there look other places.

> 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 includ…

We have a requirement to be able to operate effectively in a mixed environment. Working with nodes that do not support DOIC is going to require other strategies. Steve's example is a possible such strategy. Taking away the ability to quickly learn which peers support DOIC makes working effectively in a mixed environment harder.

I'm really surprised people are so opposed to including OC-Supported-Features in every answer. It's very easy and cheap to do it. Leaving it out makes implementations harder and more error prone. Leaving it out makes it hard or impossible to take proactive measures to work with other nodes that don't support DOIC. This should be an easy choice.

We've mentioned several advantages of requiring it in every answer. The only advantage I see for removing it is to save having to insert one more AVP. I don't find that convincing. Are there other reasons for leaving it out?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Feb 2014 09:10:51 -0600

On Feb 26, 2014, at 7:27 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

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

Because B requires considerably more work for both sender and receiver, as well as more data overhead to essentially accomplish the same thing as A.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Feb 2014 09:13:49 -0600

On Feb 26, 2014, at 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> No OLR means “no change”, it does not mean “no overload”.

I agree that this is technically true. But in the case where the reacting node has not been informed of an overload condition, or all such conditions have expired, "no chance" is the same as "no overload". And unless we choose to mandate an OLR in every answer (which would be much more costly than mandating OC-Supported-Features), we are back where we started.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Feb 2014 09:14:42 -0600

See inline.

Steve
> 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
>
> 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.
> *Sent:* Wednesday, February 26, 2014 2:09 PM
> 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
>
>     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
>
>      
>
>     *Cc:* [email-masked] <mailto:[email-masked]> list
>     node is in an overload state.  There are no overload reports when
>     the reacting node is not overloaded.
>
>     Steve
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Feb 2014 09:18:34 -0600

On Feb 26, 2014, at 9:14 AM, Steve Donovan <[email-masked]> wrote:

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

Given the trivial nature of sending and reading OC-Supported-Features, I think we should put it in every answer. This mirrors the way we handle it in requests.

---

From: "Askerup, Anders" <[email-masked]>
Date: Thu, 27 Feb 2014 17:14:12 +0000

I also agree that including OC-Supported-Features in every answer is preferable. In addition to mirroring Requests, it is in-line with how Supported-Features are managed in at least some 3GPP interfaces as well.

/Anders

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 28 Feb 2014 07:50:41 +0000

Anders,

Yes, if we conclude that there is a requirement for OC-Supported-Features to be sent in answers, then it should be included in every answer. However, I still don't see that requirement. In addition we would need some text specifying the expected behaviour of the reacting node when receiving OC-Supported-Features in an answer, keeping in mind that the reacting node cannot know whether it was the server or an agent that inserted the OC-Supported-Feature, and whether or not a subsequent request will be routed via that node.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Askerup, Anders
Sent: Thursday, February 27, 2014 6:14 PM
To: Ben Campbell; Steve Donovan
Cc: [email-masked] list
Subject: Re: [Dime] Issue#30 status

/Anders

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 15:48:31 +0200

<as a chair>

Right. We are going back and forth and continue to do that as long
as none of these moving parts can be nailed down. My proposal here
is that we simply agree now that OC-Supported-Features is in every
answer message. Period. Get one corner nailed down.

The rest of the fixing inconsistencies and missing/excess parts
listed below then need to be done according to the above decision.

- JOuni