Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 11 December 2013 07:43 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 DBDD41AE3A1 for <dime@ietfa.amsl.com>; Tue, 10 Dec 2013 23:43:30 -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 h7H7va43ls4c for <dime@ietfa.amsl.com>; Tue, 10 Dec 2013 23:43:28 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB9E1ADF65 for <dime@ietf.org>; Tue, 10 Dec 2013 23:43:27 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBB7hJI2003902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 08:43:19 +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 rBB7hID9022666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 08:43:19 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Dec 2013 08:43:18 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 08:43:17 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Jouni <jouni.nospam@gmail.com>
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9e8qVWG779dz9k2pnHnmYU487ZpOiY/wgAABi4CAABHrIA==
Date: Wed, 11 Dec 2013 07:43:17 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E712@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> <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net> <F60A8AF3-C853-4E4A-A023-13E7238066D7@gmail.com>
In-Reply-To: <F60A8AF3-C853-4E4A-A023-13E7238066D7@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: 8476
X-purgate-ID: 151667::1386747799-00001A6F-7CF9F6E3/0-0/0-0
Cc: Ben Campbell <ben@nostrum.com>, "dime@ietf.org list" <dime@ietf.org>
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: Wed, 11 Dec 2013 07:43:31 -0000
That's not predictable. It may be the same server in some cases, and different servers in other cases. -----Original Message----- From: ext Jouni [mailto:jouni.nospam@gmail.com] Sent: Wednesday, December 11, 2013 8:38 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: Ben Campbell; dime@ietf.org list; Steve Donovan Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3 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:jouni.nospam@gmail.com] > Sent: Tuesday, December 10, 2013 10:31 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: Ben Campbell; dime@ietf.org 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)" <ulrich.wiehe@nsn.com> 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: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)