Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 10 December 2013 14:31 UTC
Return-Path: <ulrich.wiehe@nsn.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362661ADF7D for <dime@ietfa.amsl.com>; Tue, 10 Dec 2013 06:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fTB5C0jiGKx for <dime@ietfa.amsl.com>; Tue, 10 Dec 2013 06:31:54 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C83B51A1F65 for <dime@ietf.org>; Tue, 10 Dec 2013 06:31:53 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBAEVk78024283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 15:31:46 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBAEViLU030989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 15:31:45 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Dec 2013 15:31:44 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 15:31:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Jouni Korhonen <jouni.nospam@gmail.com>, Ben Campbell <ben@nostrum.com>, "dime@ietf.org list" <dime@ietf.org>, Steve Donovan <srdonovan@usdonovans.com>
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9S7f8z1v638NLUKtrE/MnydsbJpM956AgAB0hdA=
Date: Tue, 10 Dec 2013 14:31:43 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> <C66C8914-AA7A-47F5-8EA4-7B0ECEDA5368@gmail.com> <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> <B81C3281-95F9-4F28-8662-2E20A6AE96A1@gmail.com>
In-Reply-To: <B81C3281-95F9-4F28-8662-2E20A6AE96A1@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 5374
X-purgate-ID: 151667::1386685906-00000661-304AF6EA/0-0/0-0
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 14:31:57 -0000
Jouni, 1. I find the texts a) "The sequence number ... does not need to be monotonically increasing" and b) "...the new sequence number MUST be greater or equal than the old sequence number..." contradicting. Can you please clarify. 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. 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? Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen Sent: Tuesday, December 10, 2013 8:28 AM To: Ben Campbell; dime@ietf.org 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 <ben@nostrum.com> wrote: > > On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> 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 >>> >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> >>> >> >> _______________________________________________ >> 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
- Re: [Dime] OVLI: comments to 4.3 Wiehe, Ulrich (NSN - DE/Munich)
- [Dime] OVLI: comments to 4.3 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.3 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.3 Ben Campbell
- Re: [Dime] OVLI: comments to 4.3 Nirav Salot (nsalot)
- Re: [Dime] OVLI: comments to 4.3 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.3 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.3 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.3 Shishufeng (Susan)
- [Dime] Conclusion for Sequence Numbers - was Re: … Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.3 Nirav Salot (nsalot)
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] OVLI: comments to 4.3 Ben Campbell
- Re: [Dime] Conclusion for Sequence Numbers - was … Ben Campbell
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.3 Maria Cruz Bartolome
- Re: [Dime] OVLI: comments to 4.3 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.3 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Ben Campbell
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] Conclusion for Sequence Numbers - was … Ben Campbell
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] Conclusion for Sequence Numbers - was … Ben Campbell
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Nirav Salot (nsalot)
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] Conclusion for Sequence Numbers - was … Maria Cruz Bartolome
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] Conclusion for Sequence Numbers - was … Jouni Korhonen
- Re: [Dime] Conclusion for Sequence Numbers - was … Nirav Salot (nsalot)
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Nirav Salot (nsalot)
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Nirav Salot (nsalot)
- Re: [Dime] Conclusion for Sequence Numbers - was … Steve Donovan
- Re: [Dime] Conclusion for Sequence Numbers - was … Nirav Salot (nsalot)