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

[Steve Donovan <[e-mail]>]

If we agree that the lifetime of the OC-Supported-Features capability
advertisement is a single transaction then the utility of the sequence
number is reduced. 

My reason for pushing for having the sequence number originally was
based on the assumption that the capability advertised by a reacting
node was semi permanent.  While there might be no earthly use, the
heavenly use was to decrease the work for reporting nodes needing to
parse the AVP on every request received. 

It is still the case that the OC-Supported-Features AVP contents will
almost never change.  The contents of the AVP will also become more
complex as new extensions are defined.  The value of the sequence number
is to allow a reporting node to save the advertisement and not parse the
full content of the AVP unless the sequence number changes. 

I still think there is enough value in the reduced work on a reporting
node to keep the sequence number.

Steve

On 2/7/14 2:01 AM, Jouni Korhonen wrote:
> 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
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>