Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

I cannot understand what is the problem with mandating timestamp.
But I can see interoperability problems with the current definition:

Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.

Are we sure that this cannot happen?

Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, February 05, 2014 4:57 PM
To: ext lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.

On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:

> Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
> We are not violating anything.
> 
> Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.
> 
> -----Message d'origine-----
> De : Ben Campbell [mailto:ben@nostrum.com] 
> Envoyé : mercredi 5 février 2014 16:47
> À : MORAND Lionel IMT/OLN
> Cc : Steve Donovan; dime@ietf.org
> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
> 
> I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:
> 
> "In particular, [normative requirements] MUST only be used where it is
>   actually required for interoperation or to limit behavior which has
>   potential for causing harm (e.g., limiting retransmisssions)  "
> 
> The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.
> 
> On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
> 
>> I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.
>> 
>> Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?
>> 
>> Lionel
>> 
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>> Envoyé : mercredi 5 février 2014 15:34
>> À : dime@ietf.org
>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>> 
>> How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.
>> 
>> Steve
>> 
>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>> I also agree.
>> 
>> Regards,
>> Nirav.
>> 
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
>> Sent: Tuesday, February 04, 2014 11:50 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>> 
>> The existing wording seems actually fuzzy.
>> If it is "like an NTP timestamp", be proud and say it loud!
>> 
>> In summary: ok with the proposal if it clarifies this handling of this sequence-number.
>> 
>> Lionel
>> 
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoyé : mardi 4 février 2014 09:50
>> À : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>> 
>> #32: Sequence-Number Time-Stamp values within OC-OLR
>> 
>> The -01 draft says in clause 4.4:
>>    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 (neglecting the fact that the contents of the AVP
>>    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
>>    required to be unique between two overload control endpoints.
>>    Sequence numbers are treated in uni-directional manner, i.e. two
>>    sequence numbers on each direction between two endpoints are not
>>    related or correlated.
>> 
>>    When generating sequence numbers, the new sequence number MUST be
>>    greater than any sequence number previously seen between two
>>    endpoints within a time window that tolerates the wraparound of the
>>    NTP timestamp (i.e. approximately 68 years).
>> 
>> 
>> With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
>> It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.
>> 
>> 
>> _________________________________________________________________________________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> 
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime