Subject: [Dime] OC-Supported Feature AVP

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 13 Dec 2013 13:44:49 +0000

Dear all

When analysing the discussion of the sequence number in the OC-Supported-Features AVP , it has driven me to some other considerations regarding this  feature negotiation that I hereafter present:  it is a bit long but it raises  a certain number of questions   and then we have to draw some conclusion  and adapt the text  of the draft if needed

A)     Behaviours for sending the  OC-Supported-Features AVP

Currently there is only one default algorithm. So the use of  OC-Supported-Features AVP containing the OC-Feature-Vector is  only to indicate the support of DOIC with the default algorithm, given that en entity not supporting DOIC will never sends the OC-Supported-Features AVP.

This AVP in the future  will allow to add new feature/capabilities .

This AVP is needed initially to advertise the mutual  capabilities between reacting and reporting node  and  when changes occur in the  supported  features (eg in general to add a new feature, but may be also to remove  one). A sequence number was introduced to manage these changes, but this introduction is still under discussion (cf Ulrich's mails questioning this point)

Then there is the question about when the OC-Supported-Features AVP is sent.  The current draft  has related statements in 3.2 and 4.1  :

The several hereafter possible  behaviors are compliant for me with 3.2 and 4.1  statements (are you sharing this reading?), we have to see if the draft allows all of them or if additional rules must be  fulfilled:

a)      The reacting node sends the OC-Supported-Features AVP in each request and the reporting node sends back its own OC-Supported-Features AVP in each answer.

b)      The reacting nodes initially sends its  OC-Supported-Features AVP, but does not repeat it any more , until a change in the features to be advertised  happens or after a node restart

c)       Something intermediate, so when there is a change as in b)  plus  a periodic advertisement of the supported features although unchanged

About a):

Steve,  and I agree,   indicated that the features are quite stable over time, and modifications will appear when a new feature is deployed (OAM case); I think  it is also needed at restart. So there are very few events over the year where the advertisement is actually needed (have you others in mind?) . Now my questioning:   why to permanently do such an exchange in each request/answer?  I observe that this behavior  is used in 3GPP where supported features are advertised in each request/answer, so we can apply  the same principle, but I nevertheless raise the question.

About the sequence number:

o   the receiving node has to open the sequence number AVP and checks if it has changed, given the value will change only a few times a year.  A besides  question,  which value the seq number takes after a restart

o   if we do not use the sequence number, the  receiving node has to open the OC-feature-Vector AVP and see if it has changed, so I do not see much difference with the above

o   the sequence number has the property  to be equal  or to increase in order to detect an eventual  change of the order of the messages and avoid to come back to a previous value of the feature-vector. But further messages will all be with the new feature-vector, so the right result. I am not sure that the seq number bring a value for the transient period when the supported feature is  modified. So question: can we suppress the seq number in this a) behaviour?
In this a ) behaviour, if the OC-Supported-Features AVP is no more present in a message (and in later messages) ,  it would  be interpreted  that DOIC is no more supported . ( so different from the b) or c) case)

About b): this is the other extreme use case compared to a).

Here in practice all the messages will not contain an  OC-Supported-Features AVP (except in the  rare cases of a change or after a restart), So the absence of this AVP in a message  does not mean that DOIC is not supported. Capability negotiation  happens once and remain valid until a change. At restart or when a change  a reacting node sends an OC-Supported-Features AVP in a request, and wait for an OC-Supported-Features AVP   in the answer; if nothing, it means the reporting node is not supporting DOIC. If the answer is lost the reacting node may repeat the request or use another one with its OC Supported-feature AVP.

If the change occurs in the reporting node, it cannot wait for a request coming from the reacting node with an OC Supported-feature AVP,  (as it will  never come if no change at the reacting node side), so the reporting node should advertise the  OC Supported-feature AVP in answers (although the corresponding request do not contain this AVP).  I think this behavior is currently allowed by the draft text, do you agree?.   To secure a bit more, the reacting node may then  send a request with its own OC Supported-feature AVP, acting as an acknowledgement to the reporting node. The reporting node may repeat if needed  or to be more secure.

There may be some corner cases to investigate more, but I currently stop here.

In this use case, I do not see a need  for a sequence number .

Do you think such an approach is applicable? it will save many checks compared to a).

About c): it is the same principle as in b) but with some periodic  "refresh" that may make the a) approach  still more secure. But not sure  it is actually needed.

So do you think the draft should  allow these different  behaviors  or only mandate one?

Then do you think we need a sequence number for the OC-Supported-Features AVP?

B)      Another point also related to the OC-Supported-Features AVP and OC-Feature-Vector:

For example a node can use the default mechanism  and in addition support extensions (eg the APN or the session group examples). I would think extensions should be advertized by the reacting node , otherwise the server does not know if it can use an extension or not, and  a server should avoid  to send OLRs that the client will not understand .
 So here we may have  a set of extensions compatible with the default mechanism

The other example is "exclusive" or not compatible features, for example Traffic reduction %control  and rate control. I do not consider  a reporting node  will  use both with a reacting node. A reacting node , even if it supports both does not want to mix  throttling based on % traffic and throttling on rate control with the same reporting node. But the current  text does not say anything about which feature is selected .
I remember that in our initial discussions, the reacting node was advertising its features / capabilities and the reporting node was selecting the ones it wants to use. Should not we come back to this rule? or do you consider that when we will introduce new features , we will introduce statements  to indicate rules on their presence in OC-Feature-Vector. Personnaly, I think  the advertisement  followed  by selection  was a good approach. Views on this?

I have  described this B part  here, as it may have some interaction with the  A part.

Best regards

JJacques

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 16 Dec 2013 14:49:33 +0200

Hi,

On Dec 13, 2013, at 3:44 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]> wrote:

> This AVP is needed initially to advertise the mutual  capabilities between reacting and reporting node  and  when changes occur in the  supported  features (eg in general to add a new feature, but may be also to remove  one). A sequence number was introduced to manage these changes, but this introduction is still under discussion (cf Ulrich’s mails questioning this point)
>  

I would be strongly supporting a) type of behaviour specifically for Diameter applications that do not maintain state. b) or c) could work for applications that have a state on Diameter level.

> Steve,  and I agree,   indicated that the features are quite stable over time, and modifications will appear when a new feature is deployed (OAM case); I think  it is also needed at restart. So the…

Because for applications that do not maintain state you typically need to send everything to express your intentions properly. As said earlier for certain types of applications you can drop AVPs once your intentions regarding behaviour have been made clear.

> o   the sequence number has the property  to be equal  or to increase in order to detect an eventual  change of the order of the messages and avoid to come back to a previous value of the feature-v…

IMHO the above is good reasoning/analysis why not use seqnum in OC-Supported-Features. My counter argument has been (and still is) whether we could have a situation where the OC-Feature-Vector remain unchanged but some additional AVPs related to the supported features would change? At the moment I do not have a valid use case in mind, specifically outside 3GPP context, but could those arise? In that case just looking into OC-Feature-Vector would not tell the difference but you would need to parse the whole OC-Supported-Features.

> About c): it is the same principle as in b) but with some periodic  “refresh” that may make the a) approach  still more secure. But not sure  it is actually needed.
>  
> The other example is “exclusive” or not compatible features, for example Traffic reduction %control  and rate control. I do not consider  a reporting node  will  use both with a reacting node. A reacting node , even if it supports both does not want to mix  throttling based on % traffic and throttling on rate control with the same reporting node. But the current  text does not say anything about which feature is selected .
> I remember that in our initial discussions, the reacting node was advertising its features / capabilities and the reporting node was selecting the ones it wants to use. Should not we come back to this rule? or

I would love to come back to this rule where the reporting node picks up one common feature. Now the text just mandates that at least one feature must be common on both side (and be advertised by both). This does not preclude reporting node implementations to do the "select one common feature" though. They can advertise back only the one selected but they do not have to.. they can add more information on will. IMHO this complicates implementations. For example if both ends have three common (and advertised) features, the reacting node must be prepared to receive OLRs on any of those for the same reporting node in parallel (why would the reporting node do so, no idea, but it could based on the spec).

> do you consider that when we will introduce new features , we will introduce statements  to indicate rules on their presence in OC-Feature-Vector. Personnaly, I think  the advertisement  followed  by selection  was a good approach. Views on this?

Agree.

- Jouni

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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 06:59:48 -0600

JJacques,

See my responses inline.

Regards,

Steve

On 12/13/13 7:44 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Dear all
>
>  
>
> When analysing the discussion of the sequence number in the
> OC-Supported-Features AVP , it has driven me to some other
> considerations regarding this  feature negotiation that I hereafter
> present:  it is a bit long but it raises  a certain number of
> questions   and then we have to draw some conclusion  and adapt the
> text  of the draft if needed
>
>  
>
> Currently there is only one default algorithm. So the use of
>  OC-Supported-Features AVP containing the OC-Feature-Vector is  only
> to indicate the support of DOIC with the default algorithm, given that
> en entity not supporting DOIC will never sends the
> OC-Supported-Features AVP.
>
SRD> OC-Supported-Features is also there for extensibility.  Once we
have rate defined then your statement no longer holds.
> This AVP is needed initially to advertise the mutual  capabilities
> between reacting and reporting node  and  when changes occur in the
>  supported  features (eg in general to add a new feature, but may be
> also to remove  one). A sequence number was introduced to manage these
> changes, but this introduction is still under discussion (cf Ulrich's
> mails questioning this point)
>
>  
>
> Then there is the question about when the OC-Supported-Features AVP is
> sent.  The current draft  has related statements in 3.2 and 4.1  :
>
> The several hereafter possible  behaviors are compliant for me with
> 3.2 and 4.1  statements (are you sharing this reading?), we have to
> see if the draft allows all of them or _if additional rules must be 
> fulfilled_:
>
>  
>
> a)      The reacting node sends the OC-Supported-Features AVP in each
> request and the reporting node sends back its own
> OC-Supported-Features AVP in each answer.
>
> b)      The reacting nodes initially sends its  OC-Supported-Features
> AVP, but does not repeat it any more , until a change in the features
> to be advertised  happens or after a node restart
>
> c)       Something intermediate, so when there is a change as in b)
>  plus  a periodic advertisement of the supported features although
> unchanged
>
SRD> I agree that a) does not need to be a MUST.  The requirement is
that the reacting node knows that all reporting nodes have received the
overload capabilities advertisement.  This is difficult in the presence
of agents when using piggybacking. 
>
>  
>
>  
>
> _About a):_
>
> Steve,  and I agree,   indicated that the features are quite stable
> over time, and modifications will appear when a new feature is
> deployed (OAM case); I think  it is also needed at restart.
>
SRD> Whether it needs a restart of a node is an implementation decision. 
>
> So there are very few events over the year where the advertisement is
> actually needed (have you others in mind?) .
>
SRD> There are two needs -- initial advertisment and change of capabilities.
>
> Now my questioning:   why to permanently do such an exchange in each
> request/answer?  I observe that this behavior  is used in 3GPP where
> supported features are advertised in each request/answer, so we can
> apply  the same principle, but I nevertheless raise the question.
>
SRD> I don't know the thought behind 3GPP feature advertisement.  My
reason for thinking it is needed every time is to address Diameter
networks with agents. 
> o   the receiving node has to open the sequence number AVP and checks
> if it has changed, given the value will change only a few times a
> year.  A besides  question,  which value the seq number takes after a
> restart
>
SRD> This needs to be specified.  If we have a time component of the
value then we can be sure that the value will have increased after
restart.  Having a new sequence number with the same report, as would
happen in this case, would not break anything.
>
> o   if we do not use the sequence number, the  receiving node has to
> open the OC-feature-Vector AVP and see if it has changed, so I do not
> see much difference with the above
>
SRD> If the OC-Feature-Vector is the only thing being advertised then
this might be true.  We have already talked about other parameters being
included as part of the advertisement.  This means that the
advertisement could become arbitrarily complex and parsing it every time
when it will change very infrequently will add real cost to the
reporting nodes.
>
> o   the sequence number has the property  to be equal  or to increase
> in order to detect an eventual  change of the order of the messages
> and avoid to come back to a previous value of the feature-vector. But
> further messages will all be with the new feature-vector, so the right
> result. I am not sure that the seq number bring a value for the
> transient period when the supported feature is  modified. So question:
> can we suppress the seq number in this a) behaviour?
>
SRD> No, for the reasons discussed.
>
> In this a ) behaviour, if the OC-Supported-Features AVP is no more
> present in a message (and in later messages) ,  it would  be
> interpreted  that DOIC is no more supported . ( so different from the
> b) or c) case)
>
>    
>
> _About b):_ this is the other extreme use case compared to a).
>
> Here in practice all the messages will not contain an
>  OC-Supported-Features AVP (except in the  rare cases of a change or
> after a restart), So the absence of this AVP in a message  does not
> mean that DOIC is not supported. Capability negotiation  happens once
> and remain valid until a change. At restart or when a change  a
> reacting node sends an OC-Supported-Features AVP in a request, and
> wait for an OC-Supported-Features AVP   in the answer; if nothing, it
> means the reporting node is not supporting DOIC. If the answer is lost
> the reacting node may repeat the request or use another one with its
> OC Supported-feature AVP.
>
SRD> How does a client (reacting node) know that all servers (reporting
nodes) have received the advertisement?
>
>  
>
> If the change occurs in the reporting node, it cannot wait for a
> request coming from the reacting node with an OC Supported-feature
> AVP,  (as it will  never come if no change at the reacting node side),
> so the reporting node should advertise the  OC Supported-feature AVP
> in answers (although the corresponding request do not contain this
> AVP).  I think this behavior is currently allowed by the draft text,
> do you agree?.   To secure a bit more, the reacting node may then
>  send a request with its own OC Supported-feature AVP, acting as an
> acknowledgement to the reporting node. The reporting node may repeat
> if needed  or to be more secure.
>
SRD> This seems pretty complex.  Why not just assume a)?
> In this use case, I do not see a need  for a sequence number .
SRD> The need for a sequence number does go away if we can insure a
single handshake between each reacting and reporting node.  We don't
have a mechanism insure this using the piggyback approach.
> _About c):_ it is the same principle as in b) but with some periodic
>  "refresh" that may make the a) approach  still more secure. But not
> sure  it is actually needed.
>
>  
>
SRD> As stated above, I think the requirement is that the reacting nodes
MUST have a capability exchange with all reporting nodes.  To achieve
this the reacting node SHOULD send advertisements in all requests. 
> For example a node can use the default mechanism  and in addition
> support extensions (eg the APN or the session group examples). I would
> think extensions should be advertized by the reacting node , otherwise
> the server does not know if it can use an extension or not, and  a
> server should avoid  to send OLRs that the client will not understand
> .    
>
> The other example is "exclusive" or not compatible features, for
> example Traffic reduction %control  and rate control. I do not
> consider  a reporting node  will  use both with a reacting node. A
> reacting node , even if it supports both does not want to mix
>  throttling based on % traffic and throttling on rate control with the
> same reporting node. But the current  text does not say anything about
> which feature is selected .
>
> I remember that in our initial discussions, the reacting node was
> advertising its features / capabilities and the reporting node was
> selecting the ones it wants to use. Should not we come back to this
> rule? or do you consider that when we will introduce new features , we
> will introduce statements  to indicate rules on their presence in
> OC-Feature-Vector. Personnaly, I think  the advertisement  followed
>  by selection  was a good approach. Views on this?
>
SRD> I think the interactions between features should be addressed in
the extension documents.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 15:16:34 -0600

> I would be strongly supporting a) type of behaviour specifically for Diameter applications that do not maintain state. b) or c) could work for applications that have a state on Diameter level.

As I've mentioned before, I don't see that tying OC-Supported-Features to the lifetime of Diameter application state to be very useful. In the example of user sessions, you will typically have many (maybe millions) of sessions come and go, and features are typically not going to change nearly that often.

We might consider adding a validity time ;-)  (I'm only partially joking.)

> IMHO the above is good reasoning/analysis why not use seqnum in OC-Supported-Features. My counter argument has been (and still is) whether we could have a situation where the OC-Feature-Vector rema…

I think that if we have some feature related AVPs that change a lot more often than "feature support" changes, those values belong somewhere other than in OC-Supported-Features.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 17 Dec 2013 10:15:15 +0000

Hi JJacques,

ad A)
I support to mandate a) for applications that do and also for applications that do not maintain state, because:
                for applications that do not maintain state: "if the OC-Supported-Features AVP is no more present in a message (and in later messages) ,  it would  be interpreted  that DOIC is no more supported"     and
                for applications that maintain state: State is maintained at session endpoints which are not necessarily DOIC endpoints.

With regard to SequenceNumber it has been argued that
we could have a situation where the OC-Feature-Vector remain unchanged but some additional AVPs related to the supported features would change
however, we should cross the bridge when we come to it , e.g. the additional AVP, when introduced, could be of type grouped with a sequence number as first component.

Ad B)
Advertisement (OC-Supported-Features AVP in request messages) followed by selection (OC-OLR AVP in answer messages) is a good approach. I never understood why we need the  OC-Supported-Features AVP in answer messages as long as no extension is defined.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Friday, December 13, 2013 2:45 PM
To: [email-masked]
Subject: [Dime] OC-Supported Feature AVP

Dear all

About a):

Best regards

JJacques