From jlloret@dcom.upv.es Wed Sep 8 14:31:46 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4803A6A04 for ; Wed, 8 Sep 2010 14:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG9dVD4LwdA6 for ; Wed, 8 Sep 2010 14:31:41 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by core3.amsl.com (Postfix) with ESMTP id D61B83A696A for ; Wed, 8 Sep 2010 14:31:40 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id o88LW6iW003945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Sep 2010 23:32:06 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id o88LW6xo011629 for ; Wed, 8 Sep 2010 23:32:06 +0200 Received: from JLLORET (vpn245-25.vpns.upv.es [158.42.245.25]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id o88LW34T025026 for ; Wed, 8 Sep 2010 23:32:05 +0200 Date: Wed, 8 Sep 2010 23:32:05 +0200 Message-Id: <201009082132.o88LW34T025026@smtp.upv.es> From: Jaime Lloret Mauri To: sam@irtf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SAM] Extended Deadline: Special Issue "Cross-layer optimization techniques and security in next generation networks" X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 21:31:46 -0000 Special Issue of the IJCNIS Journal "Cross-layer optimization techniques and security in next generation networks" Editor-in-Chief : Shafiullah Khan Guest Editors: Velmurugan Ayyadurai, Jaime Lloret, Rastislav Róka International Journal of Communication Networks and Information Security (IJCNIS, http://ijcnis.kust.edu.pk/) is preparing the first Special Issue focusing on theories, methods, and applications in cross-layer optimization techniques and security in next generation networks. The topics covered by this Special Issue of the IJCNIS Journal include, but not limited to, the following topics: - Cross-layer Optimization Techniques in Next Generation Networks - Optimization Techniques in Communication Networks - Optimization Techniques for Network Virtualization - Optimization Techniques for Energy Efficient Usage - Optimization Techniques for Seamless Mobility Management - Optimization Techniques for Resource Allocation - Optimization Techniques for Cognitive Networks - Cross-layer Optimization Techniques for Wireless Mesh Networks - Cross-functionality Designs in Next Generation Networks - Cross-layer Design and Security in Next Generation Networks - Cross-layer Mechanisms for QoS - Cross-layer Control for next generation networks - Cognitive Radio Optimization in Next Generation Networks - Cross-layer Security Protocols - Cryptographic Techniques in Next Generation Networks - Emerging Security Issues in Next Generation Networks - Security Optimization in Next Generation Networks - User Profiling and Context Awareness for Social Networking - Open Smart City Networks using Next generation networks Peer Review All manuscripts will be subject to a well established, fair, unbiased peer review and refereeing procedure, and are considered on the basis of their significance, novelty and usefulness to the Journals readership. Papers should be submitted to the contact editor. The review process may take approximately one month to be completed. Time Schedule Submission date: September 15, 2010 (extended deadline) Notification date: October 1, 2010 Camera ready: November 1, 2010 Tentative Publication: End of 2010. Velmurugan Ayyadurai (Contact Editor) University of Surrey v.ayyadurai@surrey.ac.uk Jaime Lloret Polytechnic University of Valencia, Spain jlloret@dcom.upv.es Rastislav Róka Slovak University of Technology in Bratislava, Slovakia rastislav.roka@stuba.sk From mko@cs.stir.ac.uk Mon Sep 13 06:10:26 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE98F3A69B9 for ; Mon, 13 Sep 2010 06:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZTgO1JqEUPS for ; Mon, 13 Sep 2010 06:10:20 -0700 (PDT) Received: from mailscanner2.stir.ac.uk (mailscanner2.stir.ac.uk [139.153.13.35]) by core3.amsl.com (Postfix) with ESMTP id DEAA33A69A3 for ; Mon, 13 Sep 2010 06:10:09 -0700 (PDT) Received: from [139.153.254.70] (helo=yen.cs.stir.ac.uk) by mailscanner2.stir.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Ov8m1-0006CO-6q for sam@irtf.org; Mon, 13 Sep 2010 14:08:41 +0100 Received: from [139.153.253.90] by yen.cs.stir.ac.uk (8.9.3) id OAA25205; Mon, 13 Sep 2010 14:08:41 +0100 (BST) Message-ID: <4C8E2258.5070104@cs.stir.ac.uk> Date: Mon, 13 Sep 2010 14:08:40 +0100 From: Dr Mario Kolberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sam Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-stir.ac.uk-MailScanner-ID: 1Ov8m1-0006CO-6q X-stir.ac.uk-MailScanner: Found to be clean X-stir.ac.uk-MailScanner-From: mko@cs.stir.ac.uk Subject: [SAM] Deadline approaching: IEEE CCNC 2011 Call for Demonstrations X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 13:10:27 -0000 Call for Demonstrations IEEE CCNC 2011 Call for Demonstrations Deadline: 15 September 2010 IEEE CCNC 2011 January 8 - 11, 2011, Las Vegas, Nevada, USA http://www.ieee-ccnc.org/ IEEE Consumer Communications and Networking Conference, sponsored by the IEEE Communications Society, is a major annual international conference organized with the objective of bringing together researchers, developers, and practitioners from academia and industry working in all areas of consumer communications and networking. IEEE CCNC 2011 will feature a special demonstration session showcasing the latest technological advances in the area of consumer communications and networking. We invite researchers and developers from academic, industrial, and government laboratories to present their novel ideas, including works in progress and results that do not warrant a full technical paper. CCNC especially welcomes demonstrations of emerging and innovative technologies that have potential commercial application from nascent and incubating companies. Technology demonstrations, however, must be prototypes and/or research ideas -- they cannot consist of actual commercial products. The demonstration session will provide an exciting forum for researchers, developers, and entrepreneurs to present and discuss new applications and techniques, research demonstrations, recent research/implementation results, upcoming research challenges, practical implementations, commercial developments, future directions and novel application concepts. We envision the demonstration session as a means to exhibit innovations that have the potential to change the future landscape of consumer communications and networking. Submissions should be in the form of a proposal describing the main contributions of the demonstration and the merits of the proposed ideas. Be as specific as possible in describing what you will show. Demonstration proposals should be one or two pages in length and will appear in the conference proceedings. Submission guidelines and formatting details can be found under Author Information on the CCNC web site. A technology prototype can range from a mockup using computers (instead of actual consumer devices) to a full-fledged collection of networked consumer devices. Each demonstration should be accompanied by a poster of approximately 30" by 40" describing your research. Of course, many variations are possible. Proposals should include space, power and networking requirements. A Demonstration Committee, headed by the demonstration chairs, will evaluate the proposals. Proposals will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas, and promote collaborations. Accepted demonstrations will be presented during a special demonstration session during the conference. The presenter is responsible for the demonstration and equipment setup. The presenter is expected to stand next to his/her exhibit and discuss the work with other conference attendees. Note that bandwidth of available Internet connection may vary in the demonstration room. Please consult the demonstration chairs if you are uncertain whether your demonstration falls within the scope of the conference or if you require additional information. Demo Proposals Due: 15 September 2010 Acceptance Notification: 20 September 2010 Final Camera Ready Submission: 1 October 2010 Demo Chair: Alan Kaplan, Drakontas LLC, USA kaplana@ieee.org -- The Sunday Times Scottish University of the Year 2009/2010 The University of Stirling is a charity registered in Scotland, number SC 011159. From gjcarneiro@gmail.com Mon Sep 13 08:40:56 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40F33A69F8 for ; Mon, 13 Sep 2010 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.486 X-Spam-Level: * X-Spam-Status: No, score=1.486 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G00t71d4ypU for ; Mon, 13 Sep 2010 08:40:53 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id EF9D03A6A01 for ; Mon, 13 Sep 2010 08:40:50 -0700 (PDT) Received: by qwg5 with SMTP id 5so3895832qwg.13 for ; Mon, 13 Sep 2010 08:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GKrVXunBbphauGef3Q0KMP+3CUNW23TKkfrkK78kHuc=; b=Z04FaTil6rT5poE4zXD5DLO48XNyB6H/79Gm6mmnkcPvKIXuQhO1WyGGURRRHHzlZN bV4xWK426qUtHk5qpTdO0oREm2woM/Mgv+nIyBzClr7YYJg/NWHYIChc5OEe1GZTNHqI 2ztDGUhPF6W894bFaaXV6KFZMblYUCMHBAbq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eQ4aHoP+F9VZS3bhEqahBhb6v0Nyr6wlNIteBhyz050+FDMceIDEKRZjswC0jmf8Nw 0ZQYsxBTyu4JRLObvxjpMA+5Oow787fH40oD/fTMZHiWVxchjOjrAzvcMH42rFvwNLyA roaXkya6PBjS0PQIB4NPBgIHFf4FupoWlGuhw= MIME-Version: 1.0 Received: by 10.229.11.14 with SMTP id r14mr2932968qcr.228.1284392475416; Mon, 13 Sep 2010 08:41:15 -0700 (PDT) Received: by 10.229.183.78 with HTTP; Mon, 13 Sep 2010 08:41:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Sep 2010 16:41:15 +0100 Message-ID: From: Gustavo Carneiro To: Matthias Waehlisch Content-Type: multipart/alternative; boundary=0016364ec8843fdb35049025ed01 Cc: sam Subject: Re: [SAM] New Version draft common multicast API X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 15:40:56 -0000 --0016364ec8843fdb35049025ed01 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 28, 2010 at 22:22, Matthias Waehlisch wrote: > Hi all, > > we submitted an updated version of the draft "A Common API for > Transparent Hybrid Multicast": > > * http://www.ietf.org/id/draft-waehlisch-sam-common-api-04.txt > > This includes the following changes: > > 1. Use cases added for illustration. > > 2. Service calls added for inquiring on the multicast distribution > system. > > 3. Namespace examples added. > > 4. Clarifications and editorial improvements. > > > Comments are very welcome! > Hi, I am proposing to use/implement a subset of this API inside a european research project; let's see how it goes. I have a question regarding the send() API. 4.3.2. Receive > The receive call passes multicast data and the corresponding Group Name to the application. > int receive(int s, const uri group_name, size_t msg_len, msg *msg_buf); > The s argument identifies the multicast socket. > The group_name argument identifies the multicast group for which data was received. > The msg_len argument holds the length of the received message. > The msg_buf argument points to the payload of the received multicast data. > On success the value 0 is returned, otherwise -1. Is this a synchronous call? What if there are multiple multicast sockets to listen to, we need to create a separate thread for each? I think we could use a select/poll/WaitForMultipleObjects equivalent for the abstract multicast sockets. I'd be happy to contribute text or ideas to this end if you think is a good idea. Best regards. -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert --0016364ec8843fdb35049025ed01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 28, 2010 at 22:22, Matthias = Waehlisch <waehl= isch@ieee.org> wrote:
Hi all,

=C2=A0we submitted an updated version of the draft "A Common API for<= br> Transparent Hybrid Multicast":

=C2=A0* http://www.ietf.org/id/draft-waehlisch-sam-common-= api-04.txt

=C2=A0This includes the following changes:

=C2=A0 1. =C2=A0Use cases added for illustration.

=C2=A0 2. =C2=A0Service calls added for inquiring on the multicast distrib= ution
=C2=A0 =C2=A0 =C2=A0 system.

=C2=A0 3. =C2=A0Namespace examples added.

=C2=A0 4. =C2=A0Clarifications and editorial improvements.


=C2=A0Comments are very welcome!

Hi,

I am proposing to use/implement a subset of this AP= I inside a european research project; let's see how it goes.

I have a question regarding the send() API.


= 4.3.2. =C2=A0Receive
=
= =C2=A0=C2=A0 The receive call passes multicast data and the corresponding G= roup
= =C2=A0=C2=A0 Name to the application.
=
= =C2=A0=C2=A0 =C2=A0 =C2=A0 int receive(int s, const uri group_name,<= /blockquote>
= =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t= msg_len, msg *msg_buf);
=
= =C2=A0=C2=A0 The s argument identifies the multicast socket.
=
= =C2=A0=C2=A0 The group_name argument identifies the multicast group for whi= ch data
= =C2=A0=C2=A0 was received.
=
= =C2=A0=C2=A0 The msg_len argument holds the length of the received message.=
=
= =C2=A0=C2=A0 The msg_buf argument points to the payload of the received mul= ticast
= =C2=A0=C2=A0 data.
=
= =C2=A0=C2=A0 On success the value 0 is returned, otherwise -1.


Is this a synchronous call?= =C2=A0What if there are multiple multicast sockets to listen to, we need t= o create a separate thread for each?

I think we could use a select/poll/WaitForMultipleObjec= ts equivalent for the abstract multicast sockets. =C2=A0I'd be happy to= contribute text or ideas to this end if you think is a good idea.

Best regards.

--
Gustavo J. A.= M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one s= tep beyond logic." -- Frank Herbert
--0016364ec8843fdb35049025ed01-- From waehlisch@ieee.org Mon Sep 13 13:33:33 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245E53A6A92 for ; Mon, 13 Sep 2010 13:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.049 X-Spam-Level: X-Spam-Status: No, score=-99.049 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_73=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCLH9FntbETM for ; Mon, 13 Sep 2010 13:33:31 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 033323A6A73 for ; Mon, 13 Sep 2010 13:33:31 -0700 (PDT) Envelope-to: sam@irtf.org Received: from g231226004.adsl.alicedsl.de ([92.231.226.4] helo=mw-thinkpad.fritz.box) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OvFit-0004lI-WC; Mon, 13 Sep 2010 22:33:56 +0200 Date: Mon, 13 Sep 2010 22:33:51 +0200 From: Matthias Waehlisch To: Gustavo Carneiro In-Reply-To: Message-ID: References: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: sam Subject: Re: [SAM] New Version draft common multicast API X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 20:33:33 -0000 Hi Gustavo, many thanks for your interest on the API draft! Please, see comments inline. On Mon, 13 Sep 2010, Gustavo Carneiro wrote: > I am proposing to use/implement a subset of this API inside a european > research project; let's see how it goes. > This sounds interesting. It would be great, if you do not mind to share some more details. > I have a question regarding the send() API. > > int receive(int s, const uri group_name, > size_t msg_len, msg *msg_buf); > > Is this a synchronous call? What if there are multiple multicast > sockets to listen to, we need to create a separate thread for each? > Yes, it is a synchronous call and thus you need separate threads for multiple receive calls. Is this a problem? As suggested in Section 3.2 (cf., Figure 2) one may implement the API based on a middleware. This middleware abstracts from current system sockets. In general, you can use one receive call at the application to receive data on multiple interfaces. > I think we could use a select/poll/WaitForMultipleObjects equivalent > for the abstract multicast sockets. I'd be happy to contribute text > or ideas to this end if you think is a good idea. > The intention of the draft is to provide a basic set of primitives. Currently, we are not intending to define additional asynchronous polling mechanisms. However, we are happy to hear more about your thoughts and experiences. Thanks again & Best regards matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From jlloret@dcom.upv.es Tue Sep 14 17:41:42 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0183A6AA3 for ; Tue, 14 Sep 2010 17:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_50=0.001, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOPXyqy+UJ+n for ; Tue, 14 Sep 2010 17:41:40 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by core3.amsl.com (Postfix) with ESMTP id 4F6103A6846 for ; Tue, 14 Sep 2010 17:41:39 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id o8F0g24N019032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Sep 2010 02:42:03 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id o8F0g255031142 for ; Wed, 15 Sep 2010 02:42:02 +0200 Received: from JLLORET (vpn245-13.vpns.upv.es [158.42.245.13]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id o8F0fwU3005351 for ; Wed, 15 Sep 2010 02:42:01 +0200 Date: Wed, 15 Sep 2010 02:42:01 +0200 Message-Id: <201009150042.o8F0fwU3005351@smtp.upv.es> From: Jaime Lloret Mauri To: sam@irtf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SAM] CFP: Network Protocols and Algorithms X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 00:41:42 -0000 ********************* Call for Papers ********************* Network Protocols and Algorithms ISSN 1943-3581 http://www.macrothink.org/journal/index.php/npa/ Network Protocols and Algorithms is a free-access online international journal, peer-reviewed and published by Macrothink Institute. It publishes papers focused on the design, development, manage, optimize or monitoring any type of network protocol, communication system, algorithm for communication and any protocol and algorithm to communicate network devices. The scope of the journal include, but are not limited to, the following topic areas: - Synchronization Protocols and Algorithms - Security Protocols and Algorithms - QoS Protocols and Algorithms - Ad-Hoc and Sensor Network Protocols and Algorithms - Content Delivery Networks Protocols and Algorithms - P2P Protocols and Algorithms - Cluster-Based Protocols and Algorithms - Real-Time Protocols and Algorithms - Wireless Protocols and Algorithms - MAC Protocols and Algorithms for Wired Networks - Mobile wireless internet protocols and algorithms - Delay Tolerant protocols and algorithms - Mesh network protocols and algorithms - Protocols and algorithms for Voice over IP delivery - Cognitive Radio Network Protocols and Algorithms - Monitoring and management protocols and algorithms - optical networking protocols and algorithms - Scalable Network Protocols and Algorithms - Protocols and algorithms for Green Computing and Resource Allocation - Routing Protocols and Algorithms - Tree-based Protocols and Algorithms - Distributed/Decentralized Algorithms for Networks - Fault tolerant Protocols and Algorithms - Protocols and algorithms for Mobile and Dynamic Networks - Cross-Layer Collaborative Protocols and Algorithms - Formal methods and cryptographic algorithms for communication - Power Efficient and Energy Saving Network Protocols and Algorithms - Multimedia Network Protocols and Algorithms - Network Protocols and Algorithms for Context-Aware and Semantic Networks - Localized Network Protocols and Algorithms - Transport Layer Protocols Network Protocols and Algorithms has linked its papers to references by DOI (Digital Object Identifier) numbers. Network Protocols and Algorithms appears in the next search engines: Google Scholar, Bing, Yahoo and Ask. Network Protocols and Algorithms is added and indexed in Index Copernicus, ProQuest, EBSCO, Ulrichsweb.com, Directory of Open Access Journals (DOAJ), Open J-Gate, Gale, Socolar, io-port Database, NewJour - Electronic Journals and Newsletters, Public Knowledge Project metadata harvester, Ovid LinkSolver, Genamics JournalSeek and PublicationsList.org. It is also requested to be included in other major Indexing Databases. You are welcome to submit a paper or forward this call for papers to any people working in Network Protocols and Algorithms that may be interested in submitting a paper. The topics suggested by the journal can be discussed in term of concepts, state of the art, standards, implementations, running experiments and applications. Proposals and deployments are also welcome. Submission Information: Only original and unpublished research papers will be considered in this journal. Manuscripts must be writen in English. All submissions will be reviewed based on technical merit and relevance. Instructions for authors and submissions can be found in http://www.macrothink.org/journal/index.php/npa/about/submissions Jaime Lloret Mauri Editor in Chief of the International Journal of Network Protocols and Algorithms Associate Professor Department of Communications Polytechnic University of Valencia From schmidt@informatik.haw-hamburg.de Wed Sep 15 01:24:17 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F203A684D for ; Wed, 15 Sep 2010 01:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.209 X-Spam-Level: X-Spam-Status: No, score=-93.209 tagged_above=-999 required=5 tests=[AWL=-6.614, BAYES_50=0.001, FRT_MEETING=2.697, FS_BROKEN_MEETING=10.357, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BtFJhCrTUtS for ; Wed, 15 Sep 2010 01:24:15 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 3D5EB3A6830 for ; Wed, 15 Sep 2010 01:24:14 -0700 (PDT) Envelope-to: sam@irtf.org Received: from g231226005.adsl.alicedsl.de ([92.231.226.5] helo=[192.168.178.58]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OvnIF-000O5P-BX; Wed, 15 Sep 2010 10:24:39 +0200 Message-ID: <4C90753A.3050609@informatik.haw-hamburg.de> Date: Wed, 15 Sep 2010 09:26:50 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: sam Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [SAM] Beijing Meetting X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 08:24:17 -0000 Dear all, we've requested a two hour meeting slot in Beijing. Please consider your work for presentation in SAM and drop us a node for your agenda item. Best, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From gjcarneiro@gmail.com Wed Sep 15 06:50:27 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CDA3A6832 for ; Wed, 15 Sep 2010 06:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.044 X-Spam-Level: * X-Spam-Status: No, score=1.044 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjxaq3LQpq3t for ; Wed, 15 Sep 2010 06:50:26 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id E1D8C3A63CB for ; Wed, 15 Sep 2010 06:50:25 -0700 (PDT) Received: by qwg5 with SMTP id 5so180004qwg.13 for ; Wed, 15 Sep 2010 06:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=wYpUdnHEZx/eQ7CxkpfF4BrRfibzzQsJ0GUgF1N4dsI=; b=AVCLPynWwDiGiUFBsIY+Khvc8Ari94iQ5KraM1RzMi8BTLFaGk94JU0dvZn6sz8ke6 xZIFPy06JS34/sRrGr77YP7TCJXp9uE9XX9RcW4ZrsbGjBlz7CrLeBQzPXCHSg3joLma 1BxbvgQ8qX+xWasQkSdDMjIwA6JCpgD/NFz0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wOCUJ4CrsoFW3H6sVyBZ//DE71jsfkY6+JnxT8+eFIaaU4Z34SL3AAa9U+JKIEQQ3j tkKh3ZEvODYbTxVaSpJeC+ye4FTTAQDBMy2HiratK4h8mcoZc9jKzGvpSDflg/LcpFKQ 79WaIb+Tn3S4HA7fYpkSHWGJLYVGwHHhKQ1Wk= MIME-Version: 1.0 Received: by 10.224.74.82 with SMTP id t18mr1118684qaj.95.1284558649045; Wed, 15 Sep 2010 06:50:49 -0700 (PDT) Received: by 10.229.183.78 with HTTP; Wed, 15 Sep 2010 06:50:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Sep 2010 14:50:49 +0100 Message-ID: From: Gustavo Carneiro To: Matthias Waehlisch Content-Type: multipart/alternative; boundary=0015175cd2c0f8354604904c9dee Cc: sam Subject: Re: [SAM] New Version draft common multicast API X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 13:50:27 -0000 --0015175cd2c0f8354604904c9dee Content-Type: text/plain; charset=UTF-8 On Mon, Sep 13, 2010 at 21:33, Matthias Waehlisch wrote: > Hi Gustavo, > > many thanks for your interest on the API draft! > > Please, see comments inline. > > On Mon, 13 Sep 2010, Gustavo Carneiro wrote: > > > I am proposing to use/implement a subset of this API inside a european > > research project; let's see how it goes. > > > This sounds interesting. It would be great, if you do not mind to > share some more details. > Not much is defined yet, not much to share. The project is still starting. The web site is http://www.ict-alicante.eu/ In a few months I should have more info, then I will share. > > > I have a question regarding the send() API. > > > > int receive(int s, const uri group_name, > > size_t msg_len, msg *msg_buf); > > > > Is this a synchronous call? What if there are multiple multicast > > sockets to listen to, we need to create a separate thread for each? > > > Yes, it is a synchronous call and thus you need separate threads for > multiple receive calls. Is this a problem? > It could be a scalability problem, depending on the context. It's too early to tell whether this will be a problem in my project. > > As suggested in Section 3.2 (cf., Figure 2) one may implement the API > based on a middleware. This middleware abstracts from current system > sockets. > > In general, you can use one receive call at the application to receive > data on multiple interfaces. > Yes, but not one thread to receive data from multiple "multicast sockets", as far as I can tell. > > > I think we could use a select/poll/WaitForMultipleObjects equivalent > > for the abstract multicast sockets. I'd be happy to contribute text > > or ideas to this end if you think is a good idea. > > > The intention of the draft is to provide a basic set of primitives. > > Currently, we are not intending to define additional asynchronous > polling mechanisms. However, we are happy to hear more about your > thoughts and experiences. > Ok. In a few more months I should know. In the mean time, keep up the good work. Best regards. -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert --0015175cd2c0f8354604904c9dee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 13, 2010 at 21:33, Matthias = Waehlisch <waehl= isch@ieee.org> wrote:
Hi Gustavo,

=C2=A0many thanks for your interest on the API draft!

=C2=A0Please, see comments inline.

On Mon, 13 Sep 2010, Gustavo Carneiro wrote:

> I am proposing to use/implement a subset of this API inside a european=
> research project; let's see how it goes.
>
=C2=A0This sounds interesting. It would be great, if you do not mind= to
share some more details.

Not much is de= fined yet, not much to share. =C2=A0The project is still starting. =C2=A0Th= e web site is=C2=A0http://www.ict-a= licante.eu/

In a few months I should have more info, then I will sh= are.
=C2=A0

> I have a question regarding the send() API.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0int receive(int s, = const uri group_name,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s= ize_t msg_len, msg *msg_buf);
>
> Is this a synchronous call? =C2=A0What if ther= e are multiple multicast
> sockets to listen to, we need to create a separate thread for each? >
=C2=A0Yes, it is a synchronous call and thus you need separate threa= ds for
multiple receive calls. Is this a problem?

<= div>It could be a scalability problem, depending on the context. =C2=A0It&#= 39;s too early to tell whether this will be a problem in my project.
<= div> =C2=A0

=C2=A0As suggested in Section 3.2 (cf., Figure 2) one may implement the AP= I
based on a middleware. This middleware abstracts from current system
sockets.

=C2=A0In general, you can use one receive call at the application to recei= ve
data on multiple interfaces.

Yes, but n= ot one thread to receive data from multiple "multicast sockets", = as far as I can tell.
=C2=A0

> I think we could use a select/poll/WaitForMultipleObjects equivalent > for the abstract multicast sockets. =C2=A0I'd be happy to contribu= te text
> or ideas to this end if you think is a good idea.
>
=C2=A0The intention of the draft is to provide a basic set of primit= ives.

=C2=A0Currently, we are not intending to define additional asynchronous polling mechanisms. However, we are happy to hear more about your
thoughts and experiences.

Ok. =C2=A0In = a few more months I should know. =C2=A0In the mean time, keep up the good w= ork.

Best regards.

--
Gustavo J= . A. M. Carneiro
INESC Porto, UTM, WiN, http://win.= inescporto.pt/gjc
"The universe is always one step beyond logic= ." -- Frank Herbert
--0015175cd2c0f8354604904c9dee-- From gjcarneiro@gmail.com Wed Sep 15 06:59:46 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483B73A68E8 for ; Wed, 15 Sep 2010 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.123 X-Spam-Level: * X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvVn9vHfxnmz for ; Wed, 15 Sep 2010 06:59:44 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id 991073A67AE for ; Wed, 15 Sep 2010 06:59:44 -0700 (PDT) Received: by qwg5 with SMTP id 5so188237qwg.13 for ; Wed, 15 Sep 2010 07:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zslntI4mpny7BfjM54V0DHD6YN4sMh+9iTWkT1rTUsI=; b=DD2GKZuPfWaMvj47e83MNRSqxTURkyGqAKrO0Dv1Wrj/Jlqj5HbY//C7QwqEFKG+WP ybBXIY3A7mCv+ZJcTXTkUXfXbru5o7K4ljjhoJAiUqDMn82RGeTansN9q/wYAbwXzD4v aXo4pWfVmNlY4ObcnQAYs+jS2KSwqRnG0E2+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fd6E+cksbbsUaMKKnV303eyIXHHmW2EbXbuJ0QEs6Wr9Vuriw9+WrlgCvtm2BpdZTo P95D0Xk0wWUMHFd7e22otTVGro1bzJt9O0Oqa9JADY8uC20v+PEZRZPYmGdwZBxSfGcP slDQJVnA2unLXH47vso7OsqS357qvf2OcI+RM= MIME-Version: 1.0 Received: by 10.224.74.82 with SMTP id t18mr1127660qaj.95.1284559209596; Wed, 15 Sep 2010 07:00:09 -0700 (PDT) Received: by 10.229.183.78 with HTTP; Wed, 15 Sep 2010 07:00:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Sep 2010 15:00:09 +0100 Message-ID: From: Gustavo Carneiro To: Matthias Waehlisch Content-Type: multipart/alternative; boundary=0015175cd2c0618b8304904cbf4c Cc: sam Subject: Re: [SAM] New Version draft common multicast API X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 13:59:46 -0000 --0015175cd2c0618b8304904cbf4c Content-Type: text/plain; charset=UTF-8 On Wed, Sep 15, 2010 at 14:50, Gustavo Carneiro wrote: > > > On Mon, Sep 13, 2010 at 21:33, Matthias Waehlisch wrote: > >> Hi Gustavo, >> >> many thanks for your interest on the API draft! >> >> Please, see comments inline. >> >> On Mon, 13 Sep 2010, Gustavo Carneiro wrote: >> >> > I am proposing to use/implement a subset of this API inside a european >> > research project; let's see how it goes. >> > >> This sounds interesting. It would be great, if you do not mind to >> share some more details. >> > > Not much is defined yet, not much to share. The project is still starting. > The web site is http://www.ict-alicante.eu/ > > In a few months I should have more info, then I will share. > > >> >> > I have a question regarding the send() API. >> > >> > int receive(int s, const uri group_name, >> > size_t msg_len, msg *msg_buf); >> > >> > Is this a synchronous call? What if there are multiple multicast >> > sockets to listen to, we need to create a separate thread for each? >> > >> Yes, it is a synchronous call and thus you need separate threads for >> multiple receive calls. Is this a problem? >> > > It could be a scalability problem, depending on the context. It's too > early to tell whether this will be a problem in my project. > Sorry, after sending I realized I wanted to expand on this a bit, but forgot. This is not SAM-specific, but in any OS threads occupy resources that should be considered. Some OS'es have context switching penalties at runtime (CPU time overhead). All OSes have a memory overhead. At the very least there's a stack segment to be duplicated for each thread. For instance, in Linux the default stack size is 8 MB, therefore 10 threads for receiving from 10 sockets will waste 80 MB of RAM. But, like I said, only time will tell if this is a problem in practice. Best regards. > > >> >> As suggested in Section 3.2 (cf., Figure 2) one may implement the API >> based on a middleware. This middleware abstracts from current system >> sockets. >> >> In general, you can use one receive call at the application to receive >> data on multiple interfaces. >> > > Yes, but not one thread to receive data from multiple "multicast sockets", > as far as I can tell. > > >> >> > I think we could use a select/poll/WaitForMultipleObjects equivalent >> > for the abstract multicast sockets. I'd be happy to contribute text >> > or ideas to this end if you think is a good idea. >> > >> The intention of the draft is to provide a basic set of primitives. >> >> Currently, we are not intending to define additional asynchronous >> polling mechanisms. However, we are happy to hear more about your >> thoughts and experiences. >> > > Ok. In a few more months I should know. In the mean time, keep up the > good work. > > Best regards. > > -- > Gustavo J. A. M. Carneiro > INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc > "The universe is always one step beyond logic." -- Frank Herbert > -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert --0015175cd2c0618b8304904cbf4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 15, 2010 at 14:50, Gustavo C= arneiro <gjcar= neiro@gmail.com> wrote:


On Mon, Sep 13, 2010 a= t 21:33, Matthias Waehlisch <waehlisch@ieee.org> wrote:
=
Hi Gustavo,

=C2=A0many thanks for your interest on the API draft!

=C2=A0Please, see comments inline.

On Mon, 13 Sep 2010, Gustavo Carneiro wrote:

> I am proposing to use/implement a subset of this API inside a european=
> research project; let's see how it goes.
>
=C2=A0This sounds interesting. It would be great, if you do not mind= to
share some more details.

Not much= is defined yet, not much to share. =C2=A0The project is still starting. = =C2=A0The web site is=C2=A0http://www.ict-alicante.eu/

In a few months I should have more info, then I will sh= are.
=C2=A0

> I have a question regarding the send() API.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0int receive(int s, const uri gro= up_name,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s= ize_t msg_len, msg *msg_buf);
>
> Is this a synchronous call? =C2=A0What if there are multipl= e multicast
> sockets to listen to, we need to create a separate thread for each? >
=C2=A0Yes, it is a synchronous call and thus you need separate threa= ds for
multiple receive calls. Is this a problem?

<= /div>
It could be a scalability problem, depending on the context. =C2= =A0It's too early to tell whether this will be a problem in my project.=

Sorry, after sending I realized I wa= nted to expand on this a bit, but forgot.

This is = not SAM-specific, but in any OS threads occupy resources that should be con= sidered. =C2=A0Some OS'es have context switching penalties at runtime (= CPU time overhead). =C2=A0All OSes have a memory overhead. =C2=A0At the ver= y least there's a stack segment to be duplicated for each thread. =C2= =A0For instance, in Linux the default stack size is 8 MB, therefore 10 thre= ads for receiving from 10 sockets will waste 80 MB of RAM.

But, like I said, only time will tell if this is a prob= lem in practice.

Best regards.
=C2=A0
=C2=A0

=C2=A0As suggested in Section 3.2 (cf., Figure 2) one may implement the AP= I
based on a middleware. This middleware abstracts from current system
sockets.

=C2=A0In general, you can use one receive call at the application to recei= ve
data on multiple interfaces.

Yes,= but not one thread to receive data from multiple "multicast sockets&q= uot;, as far as I can tell.
=C2=A0

> I think we could use a select/poll/WaitForMultipleObjects equivalent > for the abstract multicast sockets. =C2=A0I'd be happy to contribu= te text
> or ideas to this end if you think is a good idea.
>
=C2=A0The intention of the draft is to provide a basic set of primit= ives.

=C2=A0Currently, we are not intending to define additional asynchronous polling mechanisms. However, we are happy to hear more about your
thoughts and experiences.

Ok. =C2= =A0In a few more months I should know. =C2=A0In the mean time, keep up the = good work.

Best regards.

--
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one= step beyond logic." -- Frank Herbert



--
Gustavo J. = A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one= step beyond logic." -- Frank Herbert
--0015175cd2c0618b8304904cbf4c-- From schmidt@informatik.haw-hamburg.de Fri Sep 17 00:37:58 2010 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DEB3A67E1 for ; Fri, 17 Sep 2010 00:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.832 X-Spam-Level: X-Spam-Status: No, score=-98.832 tagged_above=-999 required=5 tests=[AWL=3.417, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUjxrw5YBZ37 for ; Fri, 17 Sep 2010 00:37:56 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id AA22A3A677E for ; Fri, 17 Sep 2010 00:37:56 -0700 (PDT) Envelope-to: sam@irtf.org Received: from g231105064.adsl.alicedsl.de ([92.231.105.64] helo=[192.168.178.58]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OwVWW-00075M-2o for sam@irtf.org; Fri, 17 Sep 2010 09:38:20 +0200 Message-ID: <4C931A5F.5010105@informatik.haw-hamburg.de> Date: Fri, 17 Sep 2010 09:35:59 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: sam Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [SAM] Fwd: NomCom 2010-2011: Call for More Nominations X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 07:37:58 -0000 Hi all, NomCom urges for nominations in several areas. Please take a look and consider to nominate appropriate candidates (including yourself). Thanks, Thomas ---------- Forwarded message ---------- From: NomCom Chair Date: Thu, Sep 16, 2010 at 6:26 PM Subject: NomCom 2010-2011: Call for More Nominations To: IETF Announcement list Hi Folks, Nominations have slowed down dramatically, so this update is to enlist the community in an effort to pick up the pace. We are very far behind in nominations for all the open positions but in particular we need nominations for the IESG and IAOC open positions. There have been no nominations received (other than for the incumbents) in INT, RAI, and RTG, and only 1 for OPS. Likewise, in IAOC there have been no nominations submitted other than the incumbent. The acceptance rates of those nominated has also been very slow. In order to initiate the open list of willing nominees we are in need of a reasonable number of acceptances, and due to the low number of nominees and acceptances have delayed the start date for publishing the first open list to September 20. So if you have been nominated and are willing to serve, but have not yet confirmed this by email back to the NomCom, please do so as soon as possible. We need Community input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations – it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come next March and to ensure we have chosen the best candidate. There are several ways you can help the IETF Nominating Committee. - You may nominate yourself. - You can nominate someone you know whom you think would do a good job. Do not worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/2468/ You may enter a nomination by going to the following URL https://wiki.tools.ietf.org/group/nomcom/10/nominate You may also nominate someone by sending an email to nomcom10@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login and password. If you need a login and password, request one from the tools page at the following URL http://trac.tools.ietf.org/newlogin Open List: ---------- As you already know, NomCom 2010-2011 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- Once the open list is available, the entire community will be invited to provide feedback. I will send a further announcement requesting feedback on the nominees, describing how to submit feedback, and how to view the open list of nominees. Thank you, Thomas Walsh Chair, NomCom 2010-2011 nomcom-chair@ietf.org twalsh@juniper.net _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce