IETF Logo Mail Archive

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

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 12 December 2013 10:29 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 C83CA1AE124 for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 02:29:40 -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 fkM4j84QjzqM for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 02:29:38 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1920A1AE14E for <dime@ietf.org>; Thu, 12 Dec 2013 02:29:37 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBCATTmc029494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 11:29:29 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBCATOGf030030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 11:29:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 11:29:24 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, Jouni Korhonen <jouni.nospam@gmail.com>, Steve Donovan <srdonovan@usdonovans.com>
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9pWZ7YfhbdfaPk+qdX0KkzOyj5pQVpIg
Date: Thu, 12 Dec 2013 10:29:23 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E8D9@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> <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com> <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.104]
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: 1882
X-purgate-ID: 151667::1386844169-00000661-142D943D/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: Thu, 12 Dec 2013 10:29:41 -0000

Jouni,

I dont find it acceptable to say "well, the concept of real-type OLRs has unresolved issues; implementatios are expected to resolve those."
Also, there may be deployments where agent A1 has connections to Servers S1 and S2 but not S3, A2 has connections to S1 and S3 but not S2, A3 has connections to S1 and S3 but not S2.

Note there are still other open issue of realm type concept e.g. like partitioned servers.


MCruz,
I'm afraid TimeStamp does not help. Even if the agents are 100% time synchronized it is not guaranteed that all agents will go into the (same) overload state exactly at the same time. Also: with the deployment scenario outlined above different agents  may be in different overload states.

Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, December 11, 2013 6:22 PM
To: Jouni Korhonen; Steve Donovan
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Dear all,

> [Steve] Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  

[Jouni] Could we simply say that in this case the agents (or who ever inserts the realm report) MUST share the same view of the realm overload condition? Obviously how it is achieved would be implementation specific. I recall we have surfaced this topic earlier..

[MCruz] But... isn't simpler to use time instead of sequence? It would solve this case as long as any number of agents serving same realm are time synchronized.  

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

v2.23.0 | Report a Bug | By Email