Received: from mail.packeteer.com (mail.packeteer.com [12.104.153.35]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j7GHdGIj023525 for ; Tue, 16 Aug 2005 19:39:17 +0200 Received: from mailcup1.packeteer.com ([10.100.99.30]) by mail.packeteer.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Aug 2005 10:39:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 16 Aug 2005 10:39:13 -0700 Message-ID: <3F8201EE931AD34E90B4564631A2A9689E9D54@mailcup1.packeteer.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scalability of Netconf Thread-Index: AcWiAZRmQ57B6yPhTQyFGQG87LGUugAhu3iQ From: "Branislav Meandzija" To: "Len Nieman" , X-OriginalArrivalTime: 16 Aug 2005 17:39:14.0420 (UTC) FILETIME=[6B4AA340:01C5A289] X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id j7GHdGIj023525 X-Mailman-Approved-At: Sun, 21 Aug 2005 09:17:26 +0200 Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: [nmrg] RE: Scalability of Netconf X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2005 17:39:21 -0000 Yes. How about the case where devices update their config autonomously and communicate this back to the NMSs which need to reconcile the updates and re-distribute them? Branislav > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Len Nieman > Sent: Monday, August 15, 2005 6:21 PM > To: netconf@ops.ietf.org > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de; Eliot Lear > Subject: Re: Scalability of Netconf > > > More likely a single NMS trying to manage 800 - 1,200 routers. > > Len > > >Date: Wed, 06 Jul 2005 12:15 -0400 (EDT) > >From: Eliot Lear > >To: j.schoenwaelder@iu-bremen.de > >CC: netconf@ops.ietf.org, > > nmrg@ibr.cs.tu-bs.de > >Subject: Re: Scalability of Netconf > > > >Yeah, I just had this funny thought of 1200 NMSes trying to > configure a > >router. That's the sort of locking contention we certainly did NOT > >optimize for! > > > >Eliot > > > > > >Juergen Schoenwaelder wrote: > >> On Tue, Jul 05, 2005 at 04:01:17PM +0200, Juergen > Schoenwaelder wrote: > >> > >> > >>>I am running this script on a 3GHz Pentium with 512 MB Ram > (so really > >>>nothing high end for a management system) running Linux 2.6.10. I > >>>keep 300 connections open and the funny thing is that this > box does > >>>not at really get stressed by this. The load never went above 0.1% > >>>and was most of the time significantly below. The memory > used excluding > >>>buffers was ~235 MB. > >> > >> > >> Today I was running 1200 ssh connections using the same > basic script > >> on the same box. The load again never went above 0.1 while > the memory > >> usage went up to ~494 MB. Shall I try 10.000 tomorrow? With 2GB of > >> memory this should be possible. The two Linux XEON servers > that play > >> the remote end for 600 connections each do not seem to bother much > >> about all this. > >> > >> /js > >> > > > >-- > >to unsubscribe send a message to netconf-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j7GG8vIj025764 for ; Tue, 16 Aug 2005 18:08:58 +0200 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Aug 2005 09:08:57 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7GG8mQM020843; Tue, 16 Aug 2005 09:08:48 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp468.cisco.com [10.61.65.212]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7GG5P5S019055; Tue, 16 Aug 2005 09:05:25 -0700 Message-ID: <43020F93.9090209@cisco.com> Date: Tue, 16 Aug 2005 18:08:51 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Len Nieman References: <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost> In-Reply-To: <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=95; t=1124208327; x=1124640527; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20Scalability=20of=20Netconf| From:Eliot=20Lear=20| Date:Tue,=2016=20Aug=202005=2018=3A08=3A51=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=evkYaPY5ZnQLDOU+Rudwy7eo0pN48mV8SH2y8/pUUf5hfl03xoqO5bp4U8RGyOPUKXX/2DzA CJOYFS4RSNdpPNZo/THIkxDCzTRumdQG2UByPcitiSD/Q1TNRJZXiJ8UQ7OjUjVSpBYLi7yErBw hbusQw01/b5LJkU15pqM2mok= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-IBRFilter-SpamReport: -0.001 () BAYES_44 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Mailman-Approved-At: Sun, 21 Aug 2005 09:17:47 +0200 Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de, netconf@ops.ietf.org Subject: [nmrg] Re: Scalability of Netconf X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2005 16:09:00 -0000 Len Nieman wrote: > More likely a single NMS trying to manage 800 - 1,200 routers. We'd like to aim for higher. Eliot Received: from imf19aec.mail.bellsouth.net (imf19aec.mail.bellsouth.net [205.152.59.67]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j7G1HZ0A002934 for ; Tue, 16 Aug 2005 03:17:35 +0200 Received: from ibm60aec.bellsouth.net ([68.214.179.11]) by imf19aec.mail.bellsouth.net with ESMTP id <20050816011734.TYK28108.imf19aec.mail.bellsouth.net@ibm60aec.bellsouth.net> for ; Mon, 15 Aug 2005 21:17:34 -0400 Received: from localHost ([68.214.179.11]) by ibm60aec.bellsouth.net with ESMTP id <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost>; Mon, 15 Aug 2005 21:17:33 -0400 Date: Mon, 15 Aug 2005 21:21 -0400 (EDT) From: Len Nieman X-Mailer: MailRoom for Internet v3.3d (www.SierraSol.com) To: netconf@ops.ietf.org Message-Id: <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Mailman-Approved-At: Sun, 21 Aug 2005 09:17:47 +0200 Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: [nmrg] Re: Scalability of Netconf X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2005 01:17:38 -0000 More likely a single NMS trying to manage 800 - 1,200 routers. Len >Date: Wed, 06 Jul 2005 12:15 -0400 (EDT) >From: Eliot Lear >To: j.schoenwaelder@iu-bremen.de >CC: netconf@ops.ietf.org, > nmrg@ibr.cs.tu-bs.de >Subject: Re: Scalability of Netconf > >Yeah, I just had this funny thought of 1200 NMSes trying to configure a >router. That's the sort of locking contention we certainly did NOT >optimize for! > >Eliot > > >Juergen Schoenwaelder wrote: >> On Tue, Jul 05, 2005 at 04:01:17PM +0200, Juergen Schoenwaelder wrote: >> >> >>>I am running this script on a 3GHz Pentium with 512 MB Ram (so really >>>nothing high end for a management system) running Linux 2.6.10. I >>>keep 300 connections open and the funny thing is that this box does >>>not at really get stressed by this. The load never went above 0.1% >>>and was most of the time significantly below. The memory used excluding >>>buffers was ~235 MB. >> >> >> Today I was running 1200 ssh connections using the same basic script >> on the same box. The load again never went above 0.1 while the memory >> usage went up to ~494 MB. Shall I try 10.000 tomorrow? With 2GB of >> memory this should be possible. The two Linux XEON servers that play >> the remote end for 600 connections each do not seem to bother much >> about all this. >> >> /js >> > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: Received: from boskop.local (tui75-2-82-229-178-125.fbx.proxad.net [82.229.178.125]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j735mbve018841 for ; Wed, 3 Aug 2005 07:48:42 +0200 Received: by boskop.local (Postfix, from userid 501) id 832CF3A1FDA; Wed, 3 Aug 2005 07:47:31 +0200 (CEST) Date: Wed, 3 Aug 2005 07:47:30 +0200 From: Juergen Schoenwaelder To: Dan Romascanu , Amy Pendleton , Alan Clark Message-ID: <20050803054730.GA7816@boskop.local> Mail-Followup-To: Dan Romascanu , Amy Pendleton , Alan Clark , nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-IBRFilter-SpamReport: -1.524 () BAYES_01 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] article on voip metrics and their measurements X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 05:48:44 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. At the last NMRG meeting, we discussed that it would be useful to have a paper which describes the various VoIP metrics being defined (e.g. RTCP XR) and the mechanism to access or transport them. The idea was to provide a summary like overview which can serve as an introductionary reference for people entering the field. Today, I received the attached call for papers for the Network and Service Management Series of the IEEE Communications Magazine series. This seems to be a natural fit and it would be very timely if something suitable could be produced by the deadline (Sept. 15). I am happy to review a draft paper in case there is interest in some review service. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="commag-cfp.txt" ******************************************************************** Call for Papers IEEE Communications Magazine - Network & Service Management Series Second issue (deadline: September 15, 2005) http://www.comsoc.org/pubs/commag/cfpcommag1005.html ******************************************************************** IEEE Communications Magazine announces the creation of a new series on Network and Service Management. The series will be published twice a year, with the first issue already under way to be published in October 2005 and the second issue accepting submissions now to be published in March 2006. The series intends to provide articles on the latest developments in this well-established and thriving discipline. Published articles are expected to highlight recent research achievements in this field and provide insight into theoretical and practical issues related to the evolution of network and service management from different perspectives. The series will provide a forum for the publication of both academic and industrial research, addressing the state of the art, theory and practice in network and service management. Both original research and review papers are welcome, in the style expected for IEEE Communications Magazine. Articles should be of tutorial nature, written in a style comprehensible to readers outside the speciality of Network and Service Management. This series therefore complements the newly established IEEE Electronic Transactions on Network & Service Management (eTNSM) - http://www.comsoc.org/etnsm/. General areas include but are not limited to: - Management models, architectures and frameworks - Network and service provisioning, reliability and quality assurance - Management functions - Management standards, technologies and platforms - Management policies - Applications, case studies and experiences IEEE Communications Magazine is read by tens of thousands of readers from both academia and industry. The magazine has also been ranked the number one telecommunications journal according to the ISI citation database for year 2000, and the number three for year 2001. The published papers will also be available on-line through Communications Magazine Interactive, the WWW edition of the magazine. Details about IEEE Communications Magazine can be found at http://www.comsoc.org/ci/. Schedule for the first issue: - Manuscripts due: September 15, 2005 - Acceptance notification: November 30, 2006 - Publication date: March 2006 Series Editors: Prof. George Pavlou, University of Surrey, UK. Dr. Aiko Pras, University of Twente, Netherlands. --SUOF0GtieIMvvwua-- Received: from open-27-68.ietf63.ietf.org (open-27-68.ietf63.ietf.org [86.255.27.68]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j71H9rve029518 for ; Mon, 1 Aug 2005 19:09:53 +0200 Received: by open-27-68.ietf63.ietf.org (Postfix, from userid 501) id 6472E39F9B4; Mon, 1 Aug 2005 19:09:52 +0200 (CEST) Date: Mon, 1 Aug 2005 19:09:52 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20050801170952.GA3116@open-27-68.ietf63.ietf.org> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-IBRFilter-SpamReport: -1.524 () BAYES_01 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] nancy nmrg meeting conclusions X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 17:09:54 -0000 I tried to write down some conclusions from the meeting in Paris that can go into the next report I have to submit to the IRTF chair. Please review the following text and share your comments. As usual, concrete proposals in the form "replace this with that" are especially welcome. --- [1] The NMRG held its 18th meeting in Nancy on July 30/31. The meeting focused on VoIP management. The details can be found at: During the meeting, topics such as measurements and metrics, fault isolation and reporting mechanisms, provisioning, data modeling, speech quality, and security aspects were discussed in the context of VoIP applications. Several observations were made: (1) VoIP management requirements largely depend on the underlying VoIP business model. There seems to be a continuum of business models ranging from classic centralized managed voice services to fully distributed P2P voice services where management aspects are handled within a distributed P2P infrastructure. It might be useful to document the management requirements for typical VoIP business models. (2) There are several ongoing activities to define VoIP metrics and mechanisms to obtain / access / distribute / aggregate measurements. There seems to be a need for a document which explains how the various activities fit together and complement each other. There also seems to be a need for additional research on aggregation mechanisms tailored to VoIP metrics. (3) For VoIP calls, especially those which cross network domain boundaries, it seem to be useful to explore how VoIP endpoints and intermediaries can take an active role in fault isolation and diagnostics by providing detailed fault reports that include information gathered from other nodes in the network. This requires the definition and execution of suitable diagnostic procedures, potentially executed on nodes in different parts of the Internet. (4) On a longer perspective, there is interest in more fundamental research to replace the classic manager-agent management model with a more distributed P2P style management model where nodes in the network cooperate to identify and solve problems and to exchange management information. Another way to describe this would be a self-organizing management overlay. This approach seems especially interesting for managing applications crossing domain boundaries and which themself organize in a P2P fashion (some VoIP solutions being an example for this). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from open-27-68.ietf63.ietf.org (open-27-68.ietf63.ietf.org [86.255.27.68]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j71Gpqve024276 for ; Mon, 1 Aug 2005 18:51:52 +0200 Received: by open-27-68.ietf63.ietf.org (Postfix, from userid 501) id C8F8439F965; Mon, 1 Aug 2005 18:51:50 +0200 (CEST) Date: Mon, 1 Aug 2005 18:51:50 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [nmrg] draft nancy meeting minutes Message-ID: <20050801165150.GA3070@open-27-68.ietf63.ietf.org> Mail-Followup-To: "Romascanu, Dan (Dan)" , nmrg@ibr.cs.tu-bs.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 16:51:53 -0000 On Mon, Aug 01, 2005 at 07:29:31PM +0300, Romascanu, Dan (Dan) wrote: > Replace: > > 'FCAPS SIP Data or Information Model' > > By: > > 'SIP-enabled VoIP FCAPS Data or Information Model' done /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j71GVSvf018038 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 1 Aug 2005 18:31:30 +0200 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j71GInJd026195 for ; Mon, 1 Aug 2005 12:18:50 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j71GGuJd024222 for ; Mon, 1 Aug 2005 12:17:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] draft nancy meeting minutes Date: Mon, 1 Aug 2005 19:29:31 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] draft nancy meeting minutes Thread-Index: AcWWtBICPSKtIzrFTae6WCuwoCa90wAAatdQ From: "Romascanu, Dan \(Dan\)" To: X-IBRFilter-SpamReport: -0.001 () BAYES_40 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id j71GVSvf018038 Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 16:31:31 -0000 > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen > Schoenwaelder ... > That said: Do you have a concrete proposal how to change the > draft minutes? > Replace: 'FCAPS SIP Data or Information Model' By: 'SIP-enabled VoIP FCAPS Data or Information Model' Dan Received: from open-27-68.ietf63.ietf.org (open-27-68.ietf63.ietf.org [86.255.27.68]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j71GBqve011486 for ; Mon, 1 Aug 2005 18:11:52 +0200 Received: by open-27-68.ietf63.ietf.org (Postfix, from userid 501) id 1707039F904; Mon, 1 Aug 2005 18:11:50 +0200 (CEST) Date: Mon, 1 Aug 2005 18:11:50 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [nmrg] draft nancy meeting minutes Message-ID: <20050801161150.GC2989@open-27-68.ietf63.ietf.org> Mail-Followup-To: "Romascanu, Dan (Dan)" , nmrg@ibr.cs.tu-bs.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 16:11:53 -0000 On Mon, Aug 01, 2005 at 07:00:30PM +0300, Romascanu, Dan (Dan) wrote: > Juergen, > > I remember that we had a discussion wrt. the scope of the model in item > #1. The outcome was as far as I remember that we will deal with FCAPS > model for SIP-enable networks rather than 'FCAPS for SIP' the argument > being that VoIP is not only SIP, and in order to manage a SIP solution > you need to define management object beyond the borders of the SIP > protocol itself. I think I asked this question, but I am not so sure what the answer really was. Personally, I believe this work needs to be scoped since VoIP at then end even runs over Ethernet - but I do consider that to be out of scope, which you might agree with. That said: Do you have a concrete proposal how to change the draft minutes? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j71G2Xvf008620 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 1 Aug 2005 18:02:34 +0200 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j71FxvHX007957 for ; Mon, 1 Aug 2005 11:59:57 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j71Fw1HX005140 for ; Mon, 1 Aug 2005 11:58:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] draft nancy meeting minutes Date: Mon, 1 Aug 2005 19:00:30 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] draft nancy meeting minutes Thread-Index: AcWWsWXEucMlD6YrQFeRiCYJjnOpawAAD+Ag From: "Romascanu, Dan \(Dan\)" To: , X-IBRFilter-SpamReport: -0.001 () BAYES_44 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id j71G2Xvf008620 Cc: X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 16:02:35 -0000 Juergen, I remember that we had a discussion wrt. the scope of the model in item #1. The outcome was as far as I remember that we will deal with FCAPS model for SIP-enable networks rather than 'FCAPS for SIP' the argument being that VoIP is not only SIP, and in order to manage a SIP solution you need to define management object beyond the borders of the SIP protocol itself. Regards, Dan > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen > Schoenwaelder > Sent: Monday, August 01, 2005 6:52 PM > To: nmrg@ibr.cs.tu-bs.de > Subject: [nmrg] draft nancy meeting minutes > > Hi! > > Attached are the draft meeting minutes of the 18th NMRG > meeting last weekend in Nancy. Aiko, who volunteered to > produce the minutes, has already left for vacation and so I > am now in charge to finalize them. If you think something is > wrong and important things are missing, please let me know > quickly since I want to publish the final version of the > minutes before the weekend. > > Silence will be counted as agreement. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > Received: from open-27-68.ietf63.ietf.org (open-27-68.ietf63.ietf.org [86.255.27.68]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j71FqNve005465 for ; Mon, 1 Aug 2005 17:52:27 +0200 Received: by open-27-68.ietf63.ietf.org (Postfix, from userid 501) id C39F639F8D4; Mon, 1 Aug 2005 17:52:21 +0200 (CEST) Date: Mon, 1 Aug 2005 17:52:21 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20050801155221.GA2989@open-27-68.ietf63.ietf.org> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] draft nancy meeting minutes X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 15:52:28 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! Attached are the draft meeting minutes of the 18th NMRG meeting last weekend in Nancy. Aiko, who volunteered to produce the minutes, has already left for vacation and so I am now in charge to finalize them. If you think something is wrong and important things are missing, please let me know quickly since I want to publish the final version of the minutes before the weekend. Silence will be counted as agreement. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nmrg-18-minutes-incomplete.txt" Minutes of the 18th NMRG meeting INRIA/LORIA, Nancy, France 30-31 July 2005 Minutes: Aiko Pras Participants: - Michael Alexander (WU Vienna, Austria) - Remi Badonnel (LORIA-INRIA, France) - Vincent Cridlig (LORIA-INRIA, France) - Olivier Festor (LORIA-INRIA, France) - James Hong (Postech, Korea) - Christian Hoene (TU Berlin, Germany) - Azita Kia (Cisco Systems, USA) - Abdelkader Lahmadi (LORIA-INRIA, France) - Saverio Niccolini (NEC Europe, Germany) - Amy Pendleton (Nortel Networks, USA) - David Perkins (SNMPInfo, USA) - Aiko Pras (University of Twente, the Netherlands) - Juergen Quittek (NEC Europe, Germany) - Dan Romascanu (Avaya, Israel) - Juergen Schoenwaelder (International University Bremen, Germany) - Henning Schulzrinne (Columbia University, USA) - Radu State (LORIA-INRIA, France) Agenda: Saturday (2005-07-30) - Welcome (Juergen Schoenwaelder, Olivier Festor) - Real-time Application Quality of Service Monitoring (Dan Romascanu) - RTP Control Protocol Extended Reports (Amy Pendleton) - RTP, RTCP XR and SIP MIB Modules (Dan Romascanu) - SIP Service Quality Reporting (Amy Pendleton) - Pre-provisioning, Template, Individual and Per-Subscriber Provisioning for VoIP Services (Michael Alexander) - Management and QoS for VoIP (Henry Sinnreich / Juergen Schoenwaelder) - User-oriented Management of VoIP Applications (Henning Schulzrinne) - Service Provider VoIP OSS - Lessons Learned (Azita Kia) - Calculation of Speech Quality by Aggregating the Impacts of Individual Frame Losses (Christian Hoene) - VoIP Security Threat Analysis (Saverio Niccolini) - VoIP Fuzzer, Cracker and Spammer - incl. demo (Olivier Festor, Radu State) Sunday (2005-07-31) - Discussion: Identify main research/engineering questions to be addressed - Discussion: Develop plans how the research/engineering questions could be addressed - Wrap Up (Juergen Schoenwaelder, Olivier Festor) ======================================================================= 10:15: Welcome by Juergen Schoenwaelder. Roll call. The structure of this meeting differs from traditional NMRG meetings, in the sense that the first day is entirely reserved for presentations. Many discussions will therefore be postponed until the second day. Saturday morning started with four presentations that covered more or less identical topics: monitoring VoIP quality at end devices. 10:25 Real-time Application Quality of Service Monitoring (RAQMON) Dan Romascanu (Avaya, Israel) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/raqmon.pdf RAQMON is being developed by the IETF RMON WG. There are three Internet Drafts, covering the following topics: Framework, PDUs and MIB. The idea is that every end device includes a RAQMON data source, which sends RAQMON PDUs to a collector. These PDUs are used by the collector to maintain "a kind of RMON MIB", which can be queried by managers via SNMP. Information between data source and collector is exchanged using TCP or SNMP notifications. Many parameters have been defined, like addresses of the communicating parties, number of packets, delay, jitter, loss and CPU utilization; for a complete overview see the slides. There are currently two different code bases, and probably 10 applications that use these bases. The question was raised for whom RAQMON was developed. Dan answered that RAQMON may be interesting for providers running VoIP or video distribution networks. A discussion followed on the fact that RAQMON should be implemented in all end systems. Since there may be millions of them, scalability might become problematic. 11:00 RTP Control Protocol Extended Reports (RTCP XR) Amy Pendleton (Nortel, USA) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/rtcp-xr.pdf Control Protocol Extended Reports (RTCP XR) is being developed by the IETF Audio/Video Transport (AVT) WG. Its definition can be found in RFC 3611, which is at Proposed Standard level. The principle goal is facilitate monitoring / measurements on a per call basis. The provided metrics include: loss, jitter, high/low signal level, echo, noise and delay; for a complete overview see the slides. Possible application scenarios include fault management, provisioning and accounting. The presentation included a number of measurement results. One of the interesting conclusions was that it is not very useful to know only average loss / discard figures; it is much more important to know the distribution. To determine such distribution, a four-state Markov Packet Loss model is proposed. There are two states for Gaps, which indicate minor problems, and two for Bursts, which indicate serious problem. A window of 16 packets is needed to maintain these states. Henning questioned the use of four states, and assumed that two would be sufficient. Amy continued her presentation with explaining how signal level problems, like clipping, can be detected, as well as Echo. The last part of her presentation concentrated on the design philosophy behind RTCP XR, as well as a framework for VoIP performance management (see slides). The framework allowed the use of probes to capture VoIP related data. In the subsequent discussion the problem was raised of how to analyze such data in case of encryption, as well as the level at which VoIP quality measurements should take place. Christian believed that such measurements should be performed at a much higher level, yielding easy to use metrics. He said that there are many research papers that demonstrate that VoIP quality can be measured with little knowledge of network parameters. Henning did not agree on this, and also Azita said that we still have a long way to go before we understand VoIP quality measurement like we understand traditional PSTN telephone quality measurements. 11:45 RTP, RTCP XR and SIP MIB Modules Dan Romascanu (Avaya, Israel) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/voip-mibs.pdf Dan gave an overview of VoIP related MIB activities within the IETF. Three MIB modules are under development; these modules are not overlapping, but complementary. The first module is the RTP MIB, which is being revised and currently and Internet Draft. This module is intended for end systems, and keeps track of call history. Aiko asked if this module could also be used for "data retention" purposes. Dan wasn't sure, because the MIBs structure may be too complex for this purpose. The second module is the RTCP XR MIB, and is based on the extended reports technology as defined in RFC 3611 Proposed Standard). The MIB is structured around the following RTP concepts: Session, Sender and Receiver. It can be implemented in RTP Host Systems, as well as Intermediate Systems. The data model includes History as well as Call Quality parameters. The third module is the SIP MIB, which is still an Internet Draft and not on standards track yet. The module can be implemented in all kinds of SIP entities (see RFC 3261), thus within User Agents, as well as Servers (Proxy, Redirect and Registrar). The supported operations include status monitoring, protocol statistics and configuration of notifications. The structure and indexing of the SIP MIB is based on the Network-Services MIB (RFC 2788). It should be noted that all three modules can be used for monitoring purposes only; they can not be used for VoIP configuration purposes. For that purpose there are other tools and protocols, however (see URL in Dan's slides). The level of deployment of the three MIB modules is unclear; in fact the meeting participants questioned that SNMP will become the technology of choice for VoIP management. 12:10 SIP Service Quality Reporting Amy Pendleton (Nortel, USA) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/sip-qr.pdf The last presentation of this morning session focused on event notification capabilities in SIP. These notifications are not related to the SIP MIB, but are separate messages with a textual syntax following SIP conventions (which is not XML). The work is performed within the SIPPING WG and still at Internet Draft level; in February 2005 it went for last call, but there were many comments that a new draft needs to be created. 12:30 Lunch Break 15:00 Management and QoS for VoIP Henry Sinnreich (pulver.com) and Juergen Schoenwaelder (IUB, Germany) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/qos.pdf Juergen made two provocative statements to trigger discussion. First, QoS is not an issue to worry about for VoIP in general, and for VoIP management in particular. Second, P2P self organizing networks will provide the highest possible availability for VoIP services. Juergen argued that specific management mechanisms for VoIP may not be necessary, but that we need more generic management mechanisms, which are also useful for other applications. In addition, we do not need a centralized "operator", but can have a P2P network to coordinate and exchange management data (for his precise reasoning: see the slides). Although some agreed with his statements, others strongly disagreed. A discussion than started on where you need to measure: in end systems, or elsewhere. Another discussion popped up whether perceived quality does not largely depend on the codecs being used; Skype uses high quality codecs and many therefore perceive Skype as a high quality VoIP system. Some participants had doubts how easy it is to replace the common G.7** codecs by higher quality codecs, since most of the technology is patented and may not become available as open source codecs. 15:40 Preprovisioning, Template, Individual and Per-Subscriber Provisioning for VoIP Services Michael Alexander (WU Vienna, Austria) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/voip-provisioning.pdf Provisioning a VoIP subscriber entails setting a variety of per-line and per-customer group parameters in several devices and Operation Support Systems (OSS). In mixed PSTN/VoIP Systems with local PSTN gateways, at the minimum 3 devices need to be provisioned; for in-network VoIP the count is two plus OSS - with at the minimum inventory management being affected. The resulting element and OS management overhead is considerable especially when considering that CPE provisioning is expected to be performed primarily by operators going forward. Michael presented various approaches to lower the management burden of provisioning VoIP circuits. When utilizing pre-provisioning and template-based provisioning in addition to per-subscriber provisioning, he claimed that the management burden could potentially be reduced. The advantages of the former two approaches in conjunction with per-circuit provisioning were discussed and some notions on needs requirements for VoIP management protocols were derived. 16:40 User-oriented Management of VoIP Applications Henning Schulzrinne (Columbia University, USA) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/dyswis.pdf Henning explained that VoIP can fail for any number of reasons, from low-level connectivity problems to signaling failure, NAT issues, packet loss and jitter as well as subtle end-system-related problems that have the same effect as network problems. Often, these problems are transient and cannot be reproduced. While the user sees one application, the end user application, user OS, home network, access network, voice service provider (proxy operator) and the remote party all need to cooperate to complete a call. Thus, there are probably half a dozen parties that can be blamed, in mutual finger pointing, if something goes wrong. Although Henning argued that you need a relatively small number of "health measurement" tests to detect such problems, traditional network management tools are of only limited help in this environment. Henning's proposal was therefore to introduce a "Do you see what I see" mechanism, which allows the various parties to query neighboring systems if they experience similar problems. For example, a system could ask a neighboring system if it has connectivity, can pass the NAT, and if it is able to get a certain DNS address. In the discussion the participants agreed that such "Do you see what I see" mechanism will have certain implications for security, which require further research. 17:05 Service Provider VoIP OSS - Lessons Learned Azita Kia (Cisco Systems, USA) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/voip-oss.pdf Azita presented a short (3 slides) but nice historical overview of VoIP management. She summarized some lessons learned in 10 years of VoIP deployments, and identified some areas of standardization that might help to improve these deployments. One of the recommendations is to work further on accounting; this recommendation was followed by a discussion what items we expect operators will charge for. Some argued that all kind of supplementary services, like Calling Line Identification Presentation, will be separately charged for. Others argued that the investment for operators could be too high to charge for this. In addition, customers may not be willing to pay for this and move to alternative providers. 17:20 Calculation of Speech Quality by Aggregating the Impacts of Individual Frame Losses Christian Hoene (TU Berlin, Germany) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/speech.pdf Christian gave a similar presentation as its previous IWQoS presentation in Passau; his findings were part of his PhD work. His message is that packet loss doesn't say much; it depends on which packets get lost. There are less important packets, and more important packets. Christian gave a demonstration, in which he simulated 35% packet loss, and made clear that if the most important packets get lost, you can not understand anything. If only the less important packets get lost, voice is still understandable. Christian's results may be useful for WIFI environments at home, or if you want to save on energy of handhelds. Christian expected that the backbone network will be good enough and does not need to do differentiate between important and less important packets. During the discussion, it became clear that there is currently no good online mechanism to classify VoIP packets into important and unimportant ones and that this is a subject for further research. 17:45 VoIP Security Threat Analysis Saverio Niccolini (NEC Europe, Germany) Saverio gave an overview of all kind of security threats for VoIP (see slides for details). These threats come from the fact that the signaling is sent using the same network as the multimedia data and that the traffic is not encrypted. In his talk Saverio also presented possible countermeasures and the pros and cons of some currently proposed solutions. Saverio's work is quite similar to the work of VoIP security Alliance, although his work is less advanced. Saverio referenced the SIPPING WG's Internet Draft on SIP SPAM (http://ietf.org/internet-drafts/draft-ietf-sipping-spam-01.txt), and told that NEC applied for a patent on this topic. Saverio's intention is to submit this work as paper to IEEE Network Magazine Special Issue on Securing Voice over IP. 18:00 VoIP Fuzzer, Cracker and Spammer (incl. demo) Olivier Festor, Radu State (LORIA-INRIA, France) http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2005/nancy/fuzzer.pdf The first day of the meeting ended with a demo on management of an Asterix VoIP system, using INRIA/LORIA's netconf implementation. This demo was followed by a demo of a security assessment tool, called "fuzzy packet". This tool manipulates and generates data messages by injecting and capturing packets into the network. It used "random" users and passwords (generated by script), and is able to inject SPAM into an ongoing call. Quite interesting! 19:00 Leaving for Dinner ======================================================================= July 31 - start at 9:30 Dan: There is a difference in understanding what VoIP management really means. Two extremes: 1) alternative / replacement of existing POTS -> VoIP should comply to same regulatory requirements as VoIP (legal interception / CDRs) -> has many technical / management implications. Same reliability & QoS requirements as POTS. 2) Skype. Dan explained the need in some environments to have CDRs. Aiko said that you do not need SNMP like agent capabilities in end systems, but you can use Netflow to create CDRs. Henning and Amy said that Netflow captures data at a too low level, you have IP addresses and not end-user (SIP) information. Dan went on discussing about performance management, like we have for the POTS (route optimization, trunk provisioning etc). He said he is not aware of much work in this area (within standardization). Aiko asked what the management requirements would be if the the second extreme (=Skype) would be successful. Dan did not know if / what they did to manage a network like things. Henning said they are primarily monitoring / gathering statistics, but not active interfering. Henning said that we're not clearly defining what we mean with management. Amy said Skype is doing a lot of management within the application, like buffer management / auto gain control. Question by Juergen: What are the challenging problems we have to work on? Henning made an inventory of possible management activities: provisioning, SLA management, CDRs (AAA, billing, fraud management, dimensioning), QoS Statistics (Real time, utilization), security (SBC, firewalls, IDS, patch management), real-time alarms. Juergen said we should not list all possible management functions. Challenges for research include: security impact in management (like intercept of RTCP-XR), automation versus human planning, scalability (data reduction, filtering), what are the SLA metrics (problems in case of multiple providers), modeling. Henning concluded that these are not very specific for VoIP. Is there something that is specific for VoIP? Discussion started on what level you should define measures. On a per call basis (fine granularities), or on a monthly (for example) basis? Aiko believed that metrics are not much different between VoIP and other application (like video). Michael argued that you need more modeling. Currently the device has a big MIB, and you don't know which objects you need to modify if you want to achieve a specific effect. For TDM networks, to name an example, we have such models, but not for IP. In addition, metrics equivalent to errored seconds in TDM systems would be useful to have for VoIP networks. Dave said that this is a well-known problem, but that within the IETF we have not been able to do so, since you need for this the operators, and they do not know. Meeting did not agree on the feasibility / possible success of such modeling work. We agreed that we should have a small number of "objects". Henning put on the white board possible protocol / technology needs. For discovery you have several approaches, like LLDP, Bonjour and SLP. It was noted that LLDP is based on the ENTITY-MIB (RFC 2737). Juergen said that we are making the same mistake as in the past. We think in terms of the manager-agent model, and believe that we're done if the agents are able to provide all kind of information. The actual problem, however, is how the "magic" / intelligence performed within the manager looks like. Aiko said that he wants to get rid of such centralized components as much as possible, let's put more intelligence within the devices, like the "do you see what I see" approach, outlined by Henning the day before. Michael would like to see work on SIP specific FCAPS. Dan proposed, as example, to discuss a bit more performance. Latency was mentioned as one of the interesting metrics. The question was if you have to measure this specific for SIP, but for all kind of applications. Juergen collected proposals for further work: 1) FCAPS SIP Data or Information Model (could be an informational RFC) 2) VoIP metric framework (at a higher level than MIBs) which explains which metrics and which access/distribution mechanisms are being defined. 3) Fault incident reports (readable by machines) which provide a structured high-level explanation of a fault experienced by VoIP entity. 4) Fault isolation / diagnostic procedures that can be used locally or called remotely to produce fault incident reports. 5) Management implications of VoIP business models (enterprises, operators who own the network, pure VoIP operators which do not have a network and non-standard compliant operators, like Skype) How to proceed with respect to the various proposals: 1) Juergen does not yet sufficiently understand this idea, and asked Michael to create a document that explains this idea a bit better and provides examples. Initiative taken by Michael, Dan is also interested. 2) VoIP metric framework could be an article for IEEE Communications Magazine or IEEE Surveys and Tutorials). Initiative taken by Amy, Dan and others. 3) Fault incident report. Initiative taken by Henning. 4) Fault isolation / Diagnostic procedures. Initiative taken by Henning. 5) Management implications of VoIP business models. Initiative taken by Aiko. Meeting closed Sunday at 12:05 --gKMricLos+KVdGMg--