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

[Ben Campbell <[e-mail]>]

I think that's close to correct. A couple of comments:

On Dec 10, 2013, at 1:28 AM, Jouni Korhonen <[e-mail]> wrote:

> 
> Fine.. lets define then the sequence number semantics. Basic
> unsigned integer math. The text proposal is the following:
> 
> 4.4.  OC-Sequence-Number AVP
> 
>   The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>   Its usage in the context of the overload control is described in
>   Sections 4.1 and 4.3.
> 
>   From the functionality point of view, the OC-Sequence-Number AVP
>   MUST be used as a non-volatile increasing counter between two
>   overload control endpoints.  The sequence number is only required
>   to be unique between two overload control endpoints and does not
>   need to be monotonically increasing.

I think "increasing" and "monotonically increasing" mean the same thing. I believe the term we are looking for is "strictly increasing".

> 
>   When comparing two sequence numbers, the new sequence number MUST
>   be greater or equal than the old sequence number within a window
>   that is half of the size of the maximum sequence number. This
>   allows a simple handling of the sequence number overflow using
>   unsigned integer arithmeticf:

The MUST probably belongs in the generation side, not the comparison side. For comparison, we can say something like "a new sequence number is greater than a previous one if the new sequence number..."

> 
>     #define WINDOW 0x8000000000000000ULL
> 
>     bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>         if (newsn - oldsn <= WINDOW)
>             // newsn >= oldsn
>             return true;   
>         } else
>             // outside window or newsn < oldsn
>             return false;  
>         }
>     }
> 
> 
> 
> The above should even work is someone shovels NTP times into
> sequence numbers with a blind typecasting.
> 
> - Jouni
> 
> On Dec 10, 2013, at 12:34 AM, Ben Campbell <[e-mail]> wrote:
> 
>> 
>> On Dec 9, 2013, at 10:00 AM, Steve Donovan <[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?
>> 
>>> 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]
>>>> https://www.ietf.org/mailman/listinfo/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
>