Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features

[Jouni Korhonen <[e-mail]>]

Finally catching up with these.. see inline.


On Feb 4, 2014, at 10:46 AM, dime issue tracker <[e-mail]> wrote:

> #29: OC-Sequence-Number in OC-Supported-Features
> 
> According to the current definition of the OC-Supported-Features AVP in
> the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence-
> Number AVP.
> The author of this document believes that OC-Sequence-Number within OC-
> Supported-Feature is  not needed, is useless and could be misleading and
> therefore proposes to remove OC-Sequence-Number from OC-Supported-Feature.
> 
> The -01 draft says in clause 4.1:
>    The OC-Sequence-Number AVP is used to indicate whether the contents
>    of the OC-Supported-Features AVP has changed since last time the node
>    included the OC-Supported-Features AVP (see Section 4.4).  Although
>    sending the OC-Sequence-Number AVP is mandatory in the OC-Supported-
>    Features AVP, the receiving node MAY always choose to ignore the
>    sequence number if it can determine the feature support changes
>    otherwise.
> 
> The text seems to imply that the reporting DOIC endpoint, when receiving
> an application request message that contains an OC-Supported-Features AVP,
> needs to determine whether a feature support change occured (either by
> checking the value of the received sequence-number (probably) against a
> stored value, or by other unspecified means). However,  this is not
> correct. The reporting DOIC endpoint may  ignore the sequence-number even
> if it cannot determine whether or not a feature support change occured:
> The reporting DOIC endpoint simply takes the value of the OC-Feature-
> Vector as received in the request  into account (if absent the default
> value applies) when processing the request.  There is no need for the
> reporting DOIC endpoint to know whether a previous request contained the
> same or a different value in OC-Feature-Vector, i.e. whether there was a
> recent change.

This is true for the current default algorithm. May not be true in the
future. Note, in IETF space versioning Diameter applications is not that
straight forward as in 3GPP, thus I would rather have forward looking
solution, even if that in places would mean "placeholder" AVPs.

> It has been argued that the reporting DOIC endpoint may (optionally)
> benefit from the presence of a Sequence-Number within OC-Supported-
> Features: The reporting DOIC endpoint may have stored the Sequence-Number
> and Feature-Vector as received in a previous request, and when receiving a
> new request the reporting DOIC endpoint would compare the received
> Sequence-Number from the new request  with the stored Sequence-Number;  If
> they match (i.e. no change of supported features occured) the reporting
> DOIC endpoint would ignore the received Feature-Vector from the new
> request and use the stored Feature-Vector for further processing; if they
> don't match (i.e. a change of supported features occured), the reporting
> DOIC endpoint would update the stored Sequence-Number and Feature-Vector
> with the received values from the new request and use the updated Feature-
> Vector for further processing. While it is debatable whether the described
> usecase is reasonable, the following issues have not been addressed:
> In configurations where the client does not support DOIC, an agent (A1) on
> a path from client to reporting DOIC endpoint (e.g. server) may take the
> role of a reacting DOIC endpoint and insert an OC-Supported-Features AVP
> in the (first) request message indicating its supported features.  A
> subsequent request message sent from the same client to the same server
> may take another path on which another agent (A2) takes the role of the
> reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP in
> the subsequent request message indicating its supported features (which
> may be different from A1's supported features but may have the same
> sequence number).  Since the reporting DOIC endpoint (e.g.server) - when

Since seq-no is NTP time, this would not happen, excluding cases
where clocks either in A1 or A2 are wrong. But that is a different
issue then..

> receiving the subsequent request - cannot know whether the the reacting
> DOIC endpoint that inserted the OC-Supported-Features AVP in the
> subsequent request is identical to or different from the reacting DOIC
> endpoint that inserted the OC-Supported-Features AVP in the first request,

Right.

> it may frequently occure that the reporting DOIC endpoint receives request
> messages containing an OC-Supported-Features AVP with a Sequence-Number
> valuelower than the stored value (which may be interpreted as error), or
> equal to the stored value but with a different associated Feature Vector,
> or higher than the stored value but unmodified Feature Vector.

See the above comment on the NPT.

> In summary, the Sequence-Number within OC-Supported-Features is of no
> earthly use since the reporting DOIC endpoint cannot associate a received
> Sequence-Number (within OC-Supported-Features) with the identity of the
> reacting DOIC endpoint that sent the Sequence-Number.  Even when such
> association was possible by enhancing the OC-Supported-Features AVP with
> the Diameter Identity of the reacting DOIC endpoint that generated the
> Sequence-Number,  it would still simply not be needed as the reporting
> DOIC endpoint can base its processing on the received Feature-Vector
> (rather than on a stored Feature Vector).

I buy the reasoning for the lack of binding between the reacting node
identity and the supported features AVP.

However, we should not assume that _all_ implementations will behave
as expected above i.e. not storing the feature vector.

> It is therefore proposed to remove the OC-Sequence-Number AVP from the OC-
> Supported Features AVP.

I have no (more) strong view here. If folks are OK to remove
the seq-no, so be it.

- Jouni



> 
> -- 
> ----------------------------------------------+--------------------------
> Reporter:  [e-mail]  |      Owner:  Ulrich Wiehe
>     Type:  defect                            |     Status:  new
> Priority:  major                             |  Milestone:
> Component:  draft-docdt-dime-ovli             |    Version:  2.0
> Severity:  Active WG Document                |   Keywords:
> ----------------------------------------------+--------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/29>
> dime <http://tools.ietf.org/wg/dime/>
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime