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

[Steve Donovan <[e-mail]>]

Ulrich,

Is your question how sequence numbers work when there are DOIC
supporting agents?

The capabilities exchange is between two DOIC endpoints, so in the case
you outline, the server would see capability information from each agent
in the path.  The server should not see the 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] 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
>
>  
>  
>
>  
>