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

[Jouni <[e-mail]>]

Ulrich,

On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

> Jouni,
> 
> ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".
> 
> Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.

Would the server in both cases (via A1 and A2) be the same?

- Jouni


> 
> Ulrich
> 
> 
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:[e-mail]] 
> Sent: Tuesday, December 10, 2013 10:31 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: Ben Campbell; [e-mail] list; Steve Donovan
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
> 
> Ulrich,
> 
> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]> wrote:
> 
>> Jouni,
>> 
>> 1. I find the texts
>> a) "The sequence number ... does not need to be monotonically increasing"
>> and 
> 
> Means the delta from old-seqno to new-seqno can be any non-negative integer
> (within the given limits) not something fixed step/delta (like +1). As long as
> "new-seqno >= old-seqno" holds we are fine.
> 
>> b) "...the new sequence number MUST be greater or equal than the old sequence number..."
>> contradicting.
>> Can you please clarify.
> 
> See above. (mind the overflow case)
> 
>> 2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
>>  "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
>> I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.
> 
> I find it more robust in a sense that I should not care about stale old information.
> However, since we are piggybacking (by popular demand) we have little room for seqno
> re-sync negotiation.
> 
> What is the mistake you refer here? A misbehaving implementation? In that case, it 
> deserves to get a manual intervention once figured out by admins checking alarms and
> logs. If the mistake is due other things, like endpoints being out of sync, we currently
> have no written down mechanism to survive that.
> 
>> 3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?
> 
> No intention. Just a sloppy specification. You are right that something needs to be
> done & clarified here. (again the semantics of Time would nice..)
> 
> I'll propose something. Others should too ;)
> 
> - Jouni
> 
>> 
>> Ulrich
>> 
>> -----Original Message-----
>> From: DiME [mailto:[e-mail]] On Behalf Of ext Jouni Korhonen
>> Sent: Tuesday, December 10, 2013 8:28 AM
>> To: Ben Campbell; [e-mail] list; Steve Donovan
>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>> 
>> 
>> 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.
>> 
>>  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:
>> 
>>    #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
>> 
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>