Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

[Steve Donovan <[e-mail]>]

Ulrich,

I don't understand your last statement.  How do new algorithms or
features get introduced to a network if the reporting node does not
detect that reacting nodes start supporting new features.

As I've said in other messages, the sequence number does not force
anyone to keep a state database.  It allows it but does not require it.

Steve

On 12/12/13 3:24 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> not sure if I correctly understand your second paragraph; please see
> inline.
>
>  
>
> Anyway I agree with your conclusion: Something is missing in the
> concept of "sequence-number in OC-Supported-Features". We WOULD need
> the DOIC end-point Diameter ID included in that AVP. I said WOULD
> because things are becoming more and more complex and complicated.
> This all is not worth the effort.  *Let's remove sequence number from
> Supported-Features*.
>
>  
>
> A Reporting node that does not support any extension (i.e. supports
> only OLR_DEFAULT_ALGO)  only needs to know whether there is a reacting
> node down stream that supports OLR_DEFAULT_ALGO    in order to decide
> whether or not a pre-calculated (default-algo-type) OLR must be
> returned or not. This can simply be done by checking bit 0 of the
> received Feature-Vector.
>
> The alternative
>
> -          to setup and maintain a database of DOIC end-point ID /
> sequence-number pairs containing the pre-calculated
> (last-known-supported-feature-type) OLR , and
>
> -          to check, when receiving a request, whether the included
> DOIC end-point ID / sequence-number pair is present in the database
> and if so return the corresponding OLR;
>
> is over-overkill.
>
>  
>
> Also there is no need for the reporting node (which still only
> supports OLR_DEFAULT_ALGO) to detect that the reacting nodes
> capabilities have been updated e.g. from "support of  
> OLR_DEFAULT_ALGO" to "support of  OLR_DEFAULT_ALGO   and
>   OLR_SOMETHING_NEW"
>
>  
>
>  
>
> Ulrich
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:[e-mail]]
> *Sent:* Wednesday, December 11, 2013 2:45 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
> *Cc:* [e-mail] list
> *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:
> comments to 4.3
>
>  
>
> Ulrich,
>
> Is your question how sequence numbers work when there are DOIC
> supporting agents?
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] yes, when there are more than one
> DOIC supporting agents that do DOIC on behalf of a (single)
> non-DOIC-supporting Client./*
>
> The capabilities exchange is between two DOIC endpoints,
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] I agree/*
>
> so in the case you outline, the server would see capability
> information from each agent in the path
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] the server would see capability
> information in a received request but does not know which downstream
> node included the capability information. Not more than one node in a
> path will incude capability information./*
>
> .  The server should not see the sequence numbers from the clients.
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] in the example there is only one
> client, and that does not support DOIC, so I don't understand
> "sequence numbers from the clients"/*
>
>
>
> This does point out that we are likely missing something from the
> OC-Feature-Vector AVP.  We likely need the DOIC end-point Diameter ID
> included in that AVP.
>
> Steve
>
> On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     how does this work in scenarios where a non supporting client C
>     sends some requests via the DOIC supporting agent A1 to the server
>     S and other requests via a different DOIC supporting agent A2 to
>     the same server S?
>
>      
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:[e-mail]] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Tuesday, December 10, 2013 2:25 PM
>     *To:* Ben Campbell
>     *Cc:* [e-mail] <mailto:[e-mail]> list
>     *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re:
>     OVLI: comments to 4.3
>
>      
>
>     inline
>
>     On 12/9/13 4:34 PM, Ben Campbell wrote:
>
>          
>
>         On Dec 9, 2013, at 10:00 AM, Steve Donovan <[e-mail]> <mailto:[e-mail]> wrote:
>
>          
>
>             Jouni,
>
>              
>
>             I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>
>              
>
>          
>
>         I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>
>          
>
>             We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>
>              
>
>          
>
>         Do we need a uniqueness across multiple nodes property? If so, why?
>
>     Strictly speaking, no.  The thought was to make it similar to
>     session-id and potentially make it easier for the reacting node to
>     keep differentiate sequence numbers from different reporting nodes.
>
>
>      
>
>      
>
>         Steve
>
>          
>
>         On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>
>             Folks
>
>              
>
>             Could we conclude on the sequence number vs. time stamp vs. something else?
>
>             We got more important places to spend our energy than this ;)
>
>              
>
>             My proposal is the following (based on the original pre-00 design):
>
>              
>
>             o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>
>               in the -01.
>
>             o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>
>               already exact definition how to handle the AVP.
>
>             o Define that the OC-Time-Stamp is the time of the creation of the 
>
>               "original" AVP within whose context the time stamp is present.
>
>             o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>
>               of the communicating endpoints.
>
>             o The time stamp can be used to quickly determine if the content of
>
>               the encapsulating AVP context has changed (among other properties).
>
>               This would be useful specifically in the future when the encapsulating
>
>               grouped AVPs  grow in size and functionality.
>
>              
>
>              
>
>             - Jouni
>
>              
>
>             _______________________________________________
>
>             DiME mailing list
>
>              
>
>             [e-mail] <mailto:[e-mail]>
>
>             https://www.ietf.org/mailman/listinfo/dime
>
>              
>
>              
>
>              
>
>          
>
>         _______________________________________________
>
>         DiME mailing list
>
>         [e-mail] <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>      
>
>      
>
>  
>