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 15:33 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 9B9B01AE324 for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 07:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Wm5eU2phyJ8n for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 07:32:56 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A37B81AE319 for <dime@ietf.org>; Thu, 12 Dec 2013 07:32:55 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBCFWlQT002183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 16:32:47 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBCFWkR2007172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 16:32:46 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 16:32:46 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9atFkoRa3B+doUWxxFMNrNdzoppNfy7wgAFzLACAAUbUgIAAT1uAgAAothA=
Date: Thu, 12 Dec 2013 15:32:45 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E9DA@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> <52A71632.7040806@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E48F@DEMUMBX014.nsn-intra.net> <52A86C6E.4030602@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E888@DEMUMBX014.nsn-intra.net> <52A9C129.30501@usdonovans.com>
In-Reply-To: <52A9C129.30501@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9DADEMUMBX014nsnin_"
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: 32558
X-purgate-ID: 151667::1386862368-00001A6F-159DDCA1/0-0/0-0
Cc: "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 15:33:01 -0000

Steve,

Why would a reporting node that only supports OLR_DEFAULT_ALGO  and does not support any other feature need to detect that a reacting node supports lots of new features in addition to OLR_DEFAULT_ALGO ? Even if it dectets support of new features by the reacting node, the reporting node would not behave any differently than before detecting this.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 2:59 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

I don't understand your last statement.  How do new algorithms or features get introduced to a network if the reporting node does not detect that reacting nodes start supporting new features.

As I've said in other messages, the sequence number does not force anyone to keep a state database.  It allows it but does not require it.

Steve
On 12/12/13 3:24 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

not sure if I correctly understand your second paragraph; please see inline.

Anyway I agree with your conclusion: Something is missing in the concept of "sequence-number in OC-Supported-Features". We WOULD need the DOIC end-point Diameter ID included in that AVP. I said WOULD because things are becoming more and more complex and complicated. This all is not worth the effort.  Let's remove sequence number from Supported-Features.

A Reporting node that does not support any extension (i.e. supports only OLR_DEFAULT_ALGO)  only needs to know whether there is a reacting node down stream that supports OLR_DEFAULT_ALGO    in order to decide whether or not a pre-calculated (default-algo-type) OLR must be returned or not. This can simply be done by checking bit 0 of the received Feature-Vector.
The alternative

-          to setup and maintain a database of DOIC end-point ID / sequence-number pairs containing the pre-calculated (last-known-supported-feature-type) OLR , and

-          to check, when receiving a request, whether the included DOIC end-point ID / sequence-number pair is present in the database and if so return the corresponding OLR;
is over-overkill.

Also there is no need for the reporting node (which still only supports OLR_DEFAULT_ALGO ) to detect that the reacting nodes capabilities have been updated e.g. from "support of   OLR_DEFAULT_ALGO" to "support of  OLR_DEFAULT_ALGO   and   OLR_SOMETHING_NEW "


Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, December 11, 2013 2:45 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org<mailto:dime@ietf.org> list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

Is your question how sequence numbers work when there are DOIC supporting agents?
[Wiehe, Ulrich (NSN - DE/Munich)] yes, when there are more than one DOIC supporting agents that do DOIC on behalf of a (single) non-DOIC-supporting Client.

The capabilities exchange is between two DOIC endpoints,
[Wiehe, Ulrich (NSN - DE/Munich)] I agree
so in the case you outline, the server would see capability information from each agent in the path
[Wiehe, Ulrich (NSN - DE/Munich)] the server would see capability information in a received request but does not know which downstream node included the capability information. Not more than one node in a path will incude capability information.
.  The server should not see the sequence numbers from the clients.
[Wiehe, Ulrich (NSN - DE/Munich)] in the example there is only one client, and that does not support DOIC, so I don't understand "sequence numbers from the clients"


This does point out that we are likely missing something from the OC-Feature-Vector AVP.  We likely need the DOIC end-point Diameter ID included in that AVP.

Steve
On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

how does this work in scenarios where a non supporting client C sends some requests via the DOIC supporting agent A1 to the server S and other requests via a different DOIC supporting agent A2 to the same server S?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 10, 2013 2:25 PM
To: Ben Campbell
Cc: dime@ietf.org<mailto:dime@ietf.org> list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

inline
On 12/9/13 4:34 PM, Ben Campbell wrote:



On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com><mailto: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?
Strictly speaking, no.  The thought was to make it similar to session-id and potentially make it easier for the reacting node to keep differentiate sequence numbers from different reporting nodes.








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<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime









_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime