Subject: [Dime] meeting minutes uploada

From: Jouni Korhonen <[email-masked]>
Date: Mon, 28 Jul 2014 15:24:22 +0300

Thanks to Jean for extensive minutes & notes:
http://tools.ietf.org/wg/dime/minutes?item=minutes-90-dime.html

- Jouni

---

From: Dave Dolson <[email-masked]>
Date: Tue, 29 Jul 2014 13:29:24 +0000

I'm the "Dave" (Dolson, Dawson, etc.) in the minutes.

My understanding in the meeting discussion about DOIC was that the DOIC AVPs will have to be added to application protocols. 
In other words, NOT added to the base protocol, and no existing Diameter agents or end-points will be expected to understand it.

My reasoning was that abatement is always application-specific, requiring knowledge of message semantics.

But from the minutes, that conclusion isn't clear. I may have heard what I wanted to hear rather than what was actually said...

So, is the intent to define a new mechanism that may be used with new protocols and protocol updates, or is the intent to put DOIC in the base such that all protocols automatically inherit it?

> Dave - You will get the doc through quicker if you don't explain the
>           approaches when you get the AVP. 4006 type applications - session-based
>           applications. Here's one for stateless.

My point here is, just define the AVP and indicate how it should be used, in the sense of providing design patterns (for stateless, online charging, offline charging, etc). Then we don't have to debate the corner-cases of the abatement algorithms of all applications; we just need to agree on the wire format. Then applications can start to reference it, one by one.

David Dolson
Senior Software Architect, Sandvine Inc.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Monday, July 28, 2014 8:24 AM
To: [email-masked]
Subject: [Dime] meeting minutes uploada

- Jouni

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

---

From: Steve Donovan <[email-masked]>
Date: Tue, 29 Jul 2014 14:33:52 -0500

Dave,

My take is that it is clear the DOIC AVPs and behaviors will not be 
incorporated into the base protocol.  I was a little loose in my 
terminology during the meeting.

The goal, at least for me, has been to define a common mechanism for 
Diameter nodes to exchange Diameter Overload related AVPs, with the 
necessary behavior defined for the handling of those AVPs.

Application specifications will then be updated to reference the DOIC 
specification.  This process has already started in 3GPP, with updates 
to many of the 3GPP specification already made.

It is a measure of our success in defining a common mechanism that can 
be reused unchanged by Diameter applications that the updates to the 
application specifications has been a very straight forward process.  
This has consisted primarily of adding the AVPs to the list of 
application AVPs and referencing of the DOIC specification for behavior 
associated with those AVPs.

Regards,

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 30 Jul 2014 04:34:40 +0000

I agree with Steve.

Additionally, just defining the wire format of the AVP does not suffice since we have to provide guidelines/information on how to generate those AVPs and how to use those AVPs.
This requires taking of different types/categories of the application into account and coming up with a general solution which works across all the applications.

In my view, the current state of the draft is successful in achieving the same.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Wednesday, July 30, 2014 1:04 AM
To: [email-masked]
Subject: Re: [Dime] meeting minutes uploada

Dave,

My take is that it is clear the DOIC AVPs and behaviors will not be incorporated into the base protocol.  I was a little loose in my terminology during the meeting.

The goal, at least for me, has been to define a common mechanism for Diameter nodes to exchange Diameter Overload related AVPs, with the necessary behavior defined for the handling of those AVPs.

Application specifications will then be updated to reference the DOIC specification.  This process has already started in 3GPP, with updates to many of the 3GPP specification already made.

It is a measure of our success in defining a common mechanism that can be reused unchanged by Diameter applications that the updates to the application specifications has been a very straight forward process.  
This has consisted primarily of adding the AVPs to the list of application AVPs and referencing of the DOIC specification for behavior associated with those AVPs.

Regards,

Steve

---

From: <[email-masked]>
Date: Wed, 30 Jul 2014 15:18:06 +0000

More than perfect! :)

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 29 juillet 2014 21:34
À : [email-masked]
Objet : Re: [Dime] meeting minutes uploada

Dave,

Regards,

Steve

_________________________________________________________________________________________________________________________

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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jul 2014 15:19:44 -0500

I'm not sure I agree. I think we may be skirting the first sentence in Req 2, quoted here:

>    REQ 2:  The solution MUST allow Diameter nodes to support overload
>            control regardless of which Diameter applications they
>            support.  Diameter clients and agents must be able to use the
>            received load and overload information to support graceful
>            behavior during an overload condition.  Graceful behavior
>            under overload conditions is best described by REQ 3.
> 

The word "node" was carefully selected. If an agent with no knowledge of the "foo" application cannot apply DOIC to messages for "foo", then we have failed to meet that requirement.

Allowing that implies that DOIC AVPs mean the same for all applications, and can be inserted into messages for any application without a new specification for that application. That's a stronger statement than just saying any application can incorporate them. This seems to mean they need to be part of the base specification.

That all being said, I agree that often will be beneficial to explicitly incorporate DOIC into applications, so that one can make application-specific statements about things like detecting overload, message prioritization under overload, and client application behavior under overload.

On Jul 29, 2014, at 2:33 PM, Steve Donovan <[email-masked]> wrote:

> It is a measure of our success in defining a common mechanism that can be reused unchanged by Diameter applications that the updates to the application specifications has been a very straight forward process.  This has consisted primarily of adding the AVPs to the list of application AVPs and referencing of the DOIC specification for behavior associated with those AVPs.
> 
> Regards,
> 
> Steve
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jul 2014 15:22:35 -0500

(oops, I meant to comment on the changed subect line, and to to add "was: meeting minutes uploaded" to the new subject. Fixed here.)

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 31 Jul 2014 10:03:24 +0300

Ben,

> The word "node" was carefully selected. If an agent with no knowledge of the "foo" application cannot apply DOIC to messages for "foo", then we have failed to meet that requirement.

In this requirement the "node" does not apply to proxies. A proxy won't 
even receive messages for the "foo" application unless it advertises 
one. And if the proxy advertises a specific application it implicitly 
supports one.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 Jul 2014 09:02:36 -0500

On Jul 31, 2014, at 2:03 AM, Jouni Korhonen <[email-masked]> wrote:

> In this requirement the "node" does not apply to proxies. A proxy won't even receive messages for the "foo" application unless it advertises one. And if the proxy advertises a specific application it implicitly supports one.

I would say it's non-constraining for proxies. But "node" also includes relays.

---

From: <[email-masked]>
Date: Thu, 31 Jul 2014 14:20:30 +0000

The current solution has been designed to be generic enough to be supported over any application.
Any existing Diameter node can be upgraded to support overload control. Any new node can be designed to support this mechanism.
Client and servers can use overload report for graceful behavior.

I fail to see where the requirement is not meant. And I think that it is what it is already stated in the introduction:

   Furthermore, the solution is designed to apply to existing and future
   Diameter applications, requires no changes to the Diameter base
   protocol [RFC6733] and is deployable in environments where some
   Diameter nodes do not implement the Diameter overload control
   solution defined in this specification.

Anyhow, I have no problem to agree that this solution fails to completely cover the REQ2 if it is your understanding. The real requirement is to have a solution supporting DOICable and non-DOCIable nodes. After, any vendor/operator can decide which nodes are deemed required to support DOIC. This is/will be decided for 3GPP networks and in any network in which DOIC will have to be introduced.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : jeudi 31 juillet 2014 16:03
À : Jouni Korhonen
Cc : [email-masked]
Objet : Re: [Dime] DOIC: Base protocol vs application

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 Jul 2014 09:59:59 -0500

> Anyhow, I have no problem to agree that this solution fails to completely cover the REQ2 if it is your understanding. The real requirement is to have a solution supporting DOICable and non-DOCIable…

Hi Lionel,

I'm not sure if we are agreeing or disagreeing.

Given the existing specification, do you believe that any node (including an agent that does not recognize the application in question) can insert DOIC AVPs into messages for any arbitrary application? 

If so, then I am happy with it, and consider the "base vs application" discussion to be a red herring. (Although I think a discussion on whether these might count as "routing" AVPs might be interesting.)

---

From: <[email-masked]>
Date: Thu, 31 Jul 2014 15:55:43 +0000

Hi Ben,

I disagree on the fact that the REQ 2 is not covered by the current solution providing a generic solution at the application level, without any impact on the base protocol.
A node that will implement DOIC will have to understand the application conveying the DOIC AVP. Otherwise, it will not be able to know what to do when receiving the overload report (e.g. drop the request, divert, differ, etc.) as this behavior heavily depends on the application.

Now speaking about agent, as per the RFC6733, a Relay or a Redirect, agent advertizing the Relay App Id (0xffffffff) cannot do much more than performing look-up into their routing table to select of the next hop for a given request. If several peers are available for a given entry in the routing, they may perform some load balance of requests between peers. But nothing else. 
Updating the RFC6733 to indicate that Relay and Redirect must now support DOIC would be a non-sense as OLR are only meaningful at the application level to know how to perform efficient overload control. And an agent that would have to manage something at the application is called a Proxy, even if the application specific behavior is only related to the overload control functions. 
In the same line, a node that would be designed to relay any application request and only provide overload control as enhanced functionality would be a simple proxy that would have to advertize in CER/CEA all the application-Id used in the network in which it is deployed and support the abatement treatment to apply per application (note: the same abatement treatment principle may be reused for multiple applications). And this node can be reused for any application, as long as it list of supported app-id and the corresponding abatement treatments are kept up to date.

So, in summary, I can agree that your understanding of the REQ2 is not the same than mine. I could even agree that your understanding is correct if I'm forced to. And I would then agree that the REQ2 is not fulfilled by a solution at the application level. But this would not change my position: I'm perfectly fine with current approach and no update of the RFC6733 is needed. 

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : jeudi 31 juillet 2014 17:00
À : MORAND Lionel IMT/OLN
Cc : Jouni Korhonen; [email-masked]
Objet : Re: [Dime] DOIC: Base protocol vs application

Hi Lionel,

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 Jul 2014 14:05:28 -0500

Thank you for clarifying that we disagree :-)  Details inline:

> A node that will implement DOIC will have to understand the application conveying the DOIC AVP. Otherwise, it will not be able to know what to do when receiving the overload report (e.g. drop the r…

I disagree. We've gone to a great deal of trouble to separate things so that an agent without application knowledge can take reasonable action.

For example, an agent cannot just drop a request, with our without application knowledge. It needs to _reject_ a request so that the client (which already must have application knowledge) can do the right thing. It can _divert_ a request in a way that is legal across applications. It may lack knowledge on the best way to prioritize requests under overload for a specific application, which is why I think agents should prefer diversion over throttling. But it at least understands what's in a session and what is not, and can make some decisions that are probably at least reasonable, if not optimal. (Certainly it could do better with application specific knowledge, but it should still be better than nothing.)

The idea of abatement algorithms is also intended to be application independent. Algorithms don't say which messages get abated, only how many.

Ignoring the relay case for the moment (Don't worry, I will pick it up again further down :-)  ), we at least need to allow a proxy to implement overload control based entirely on DIME specifications. It should not have to wait for the owner of some application (e.g. 3GPP) to describe specifics of how to optimize overload control for that application. This is pretty clearly the intent of RFC 7068, as described in section 6.

> Now speaking about agent, as per the RFC6733, a Relay or a Redirect, agent advertizing the Relay App Id (0xffffffff) cannot do much more than performing look-up into their routing table to select o…

( I'm intentionally ignoring redirect agents, because I think they are effectively servers. Maybe they can become overloaded too, and should probably be able to report that. But I think it's enough of an edge case we can ignore it for the moment.)

Relays are allowed to do what you say, and _also_ allowed to insert specific AVPs that have been designated as "routing information"  IMO, DOIC AVPs should be treated as "routing information". Their purpose is closely relate to the kind of routing decisions relays already make.

Based on this discussion so far, I think in order to achieve our application independence requirement, DOIC AVPs should be considered extensions of the base protocol, not application AVPs. This would require the draft to explicitly update RFC6733. I realize people would rather use the normal application extension points of Diameter, but I do not believe they are appropriate for DOIC.

> So, in summary, I can agree that your understanding of the REQ2 is not the same than mine. I could even agree that your understanding is correct if I'm forced to. 

I plan to limit myself to persuasion, not force ;-)

But in my interpretation of Req 2 (as an editor of RFC 7068), I think that when you look at the carefully chosen term "node" (the meaning of which was discussed rather heavily), and in the context of section 6, treating DOIC AVPs as application AVPs fails to meet the requirement. 

> And I would then agree that the REQ2 is not fulfilled by a solution at the application level. But this would not change my position: I'm perfectly fine with current approach and no update of the RFC6733 is needed. 

I would find it very unfortunate if we throw out a MUST level requirement from RFC 7068 just because we don't want to extend the base protocol. It's not a question of being able to extend it--any RFC can be updated. It's not especially costly to do so. If we want to argue that doing so would be _harmful_, that's different. I haven't seen such an argument so far.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 01 Aug 2014 00:39:05 +0300

Restating my view here..

> Relays are allowed to do what you say, and _also_ allowed to insert specific AVPs that have been designated as "routing information"  IMO, DOIC AVPs should be treated as "routing information". Thei…

A "node" as a proxy is somewhat trivial. It does not receive application 
messages it does not advertise. Thus a DOICable "node" that is a proxy 
implicitly supports DOIC for applications it advertises from external 
viewer point of views. Wheteher the proxy _implementation_ is actually 
able to do "DOIC stuff" on all applications it advertises, is another thing.

A "node" as a DOICable relay can do DOIC stuff to _any_ application 
within certain limits. If the "DOIC stuff" is just applying the 
abatement, then that is OK for _any_ application depending on the 
abatement algorithm. If the "DOIC stuff" is beyond that e.g. 
adding/removing DOIC AVPs then the DOICable relay has to be application 
aware _internally_ i.e. a proxy.. otherwise it might e.g. cause trouble 
with applications whose messages' CCF has no *[AVP]. In that regard, I 
would have hard time understanding why such "relay" is not acting as a 
proxy to its peers. I agree more with Lionel that "relay" shall not 
fiddle around with non-routing AVPs. On the other hand, if everybody 
agrees that DOIC AVPs are _routing_information_ I have no issue relays 
fooling around with DOIC AVPs in the messages.

The thing we need keep in mind is that if we have e.g. multiple agent 
nodes in a row, an agent on the path that is not DOICable MUST NOT get 
confused if other DOICable agents do weird stuff. So at the very end, 
what goes on wire is the key and has to be RFC6733 compliant.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 Jul 2014 16:45:16 -0500

On Jul 31, 2014, at 4:39 PM, Jouni Korhonen <[email-masked]> wrote:

> A "node" as a proxy is somewhat trivial. It does not receive application messages it does not advertise. Thus a DOICable "node" that is a proxy implicitly supports DOIC for applications it advertises from external viewer point of views. Wheteher the proxy _implementation_ is actually able to do "DOIC stuff" on all applications it advertises, is another thing.

I don't think we have much controversy about DOICable proxies.

> 
> A "node" as a DOICable relay can do DOIC stuff to _any_ application within certain limits. If the "DOIC stuff" is just applying the abatement, then that is OK for _any_ application depending on the abatement algorithm. If the "DOIC stuff" is beyond that e.g. adding/removing DOIC AVPs then the DOICable relay has to be application aware _internally_ i.e. a proxy.. otherwise it might e.g. cause trouble with applications whose messages' CCF has no *[AVP].

Adam did a survey way back when, and found that such applications are vanishingly rare. (Was it just the watchdog application?). Hopefully people won't try to define new applications without *[AVP]/

> In that regard, I would have hard time understanding why such "relay" is not acting as a proxy to its peers. I agree more with Lionel that "relay" shall not fiddle around with non-routing AVPs. On the other hand, if everybody agrees that DOIC AVPs are _routing_information_ I have no issue relays fooling around with DOIC AVPs in the messages.
> 
> The thing we need keep in mind is that if we have e.g. multiple agent nodes in a row, an agent on the path that is not DOICable MUST NOT get confused if other DOICable agents do weird stuff. So at the very end, what goes on wire is the key and has to be RFC6733 compliant.

I agree completely.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 01 Aug 2014 08:37:06 +0300

Ben,

> Adam did a survey way back when, and found that such applications are vanishingly rare. (Was it just the watchdog application?). Hopefully people won't try to define new applications without *[AVP]/

I know. *[AVP] was just an example. Another example would be new 
applications that embed DOIC as a part of their formal CCF and there 
even changing the location of the DOIC AVP could break the CCF check.

- Jouni