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

Jouni Korhonen <jouni.nospam@gmail.com> Thu, 12 December 2013 10:58 UTC

Return-Path: <jouni.nospam@gmail.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 21ACF1ACCDC for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 02:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 n-m0MD9i1yay for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 02:58:17 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9A1AE087 for <dime@ietf.org>; Thu, 12 Dec 2013 02:58:16 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id n7so170447lam.7 for <dime@ietf.org>; Thu, 12 Dec 2013 02:58:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i3VoWj4aljehsq+oV06nrqjylKI9lD8LDXutkRSXol8=; b=vfo25oUgtK7tknVen73kTcyk+cy6Kz7J+ZHgSWQiQVQzLNYwbtedx8oMxxNWupehfh dicZcI9AwwtQATjGGcjwFKGwf+g3gj2d8O/f9xn4Ref+r5eYp1goh95DYcccFmzULrHO CQsC+bvH6EcSuUDi2IZ/3JF8Y8wtMJ6APT7loxddtXicfy2JbeVjO0+htXEEr90mrzvK LFa79ZMRq3lDVQLPKsUAu4V9PXDDcMj5v/ZAS8WArRqdr3nwjOJco/DpD4wO0kkLxuXN O/v35mT6a8aLzRkQnWxA1ONDSZSvkZfvtm6n+AoP/Tl2tSVo4ywOcPyLayQsHfZ/lOQ0 q6hQ==
X-Received: by 10.152.180.228 with SMTP id dr4mr3402935lac.32.1386845889782; Thu, 12 Dec 2013 02:58:09 -0800 (PST)
Received: from [192.168.250.53] ([194.100.71.98]) by mx.google.com with ESMTPSA id a8sm34007195lae.5.2013.12.12.02.58.05 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 02:58:06 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E8D9@DEMUMBX014.nsn-intra.net>
Date: Thu, 12 Dec 2013 12:58:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A51393B-7AC4-4185-BA29-93801F6811D0@gmail.com>
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> <5BCBA1FC2B7F0B4C9D935572D90006681519E8D9@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1510)
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:58:19 -0000

Ulrich,

On Dec 12, 2013, at 12:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

> Jouni,
> 
> I dont find it acceptable to say "well, the concept of real-type OLRs has unresolved issues; implementatios are expected to resolve those."

If you need synchronisation for one thing.. then you achieve it
somehow. Just like in you example how you would keep realm reports
in sync between agents? It is equivalent issue unless you are fine
with conflicting reports..

It is not necessarily our job to define how some things at the 
deployment level are achieved. We already made rather rough 
assumptions how front ends and such work.


> 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.

So? How would that change the situation? The realm status should 
be the same for all reports representing the same realm.

> 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.

So now you are saying that it would be acceptable that multiple
sources (agents) from the same realm tell different truth about
the realm state to the reacting node? I would find that somewhat 
unacceptable assumption.

- Jouni



> 
> 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