Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBVAawXI015955 for ; Thu, 31 Dec 2009 02:36:59 -0800 X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-83.messagelabs.com!1262255817!22282042!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 29147 invoked from network); 31 Dec 2009 10:36:57 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-14.tower-83.messagelabs.com with AES128-SHA encrypted SMTP; 31 Dec 2009 10:36:57 -0000 Received: from [192.168.1.209] (131.227.200.4) by EXHT011P.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 31 Dec 2009 10:36:57 +0000 MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset="us-ascii" From: Lloyd Wood X-Priority: 3 In-Reply-To: <3834412.330441262251827037.JavaMail.coremail@bj126app34.126.com> Date: Thu, 31 Dec 2009 10:36:52 +0000 Message-ID: <19DF16B9-14A7-4CA7-B3A2-2FE17E038530@surrey.ac.uk> References: <3834412.330441262251827037.JavaMail.coremail@bj126app34.126.com> To: xlwujunying X-Mailer: Apple Mail (2.1077) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nBVAawXI015955 Cc: dtn-interest , Lloyd Wood Subject: Re: [dtn-interest] what about connectivity in DTN X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 10:37:00 -0000 On 31 Dec 2009, at 09:30, xlwujunying wrote: > how can we measur connectivity in DTN, You can try graphing range of individual link or path delay (y) vs range of persistence of links or paths (x). Bottom right is core of the Internet - very reliable, long persistence, short delay. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/ Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBV9sQto013911 for ; Thu, 31 Dec 2009 01:54:26 -0800 Received: from p5b03ec90.dip.t-dialin.net ([91.3.236.144] helo=[192.168.0.183]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NQHjc-0006zd-FZ for dtn-interest@mailman.dtnrg.org; Thu, 31 Dec 2009 10:54:25 +0100 Message-ID: <4B3C74CD.4020803@cs.uni-goettingen.de> Date: Thu, 31 Dec 2009 10:54:21 +0100 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Subject: [dtn-interest] IWQoS 2010 Call for Papers X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 09:54:27 -0000
Apologies if you receive multiple copies. 

--------------------------------------------------------------------------------------------------------
18th IEEE International Workshop on Quality of Service (IWQoS 2010)
--------------------------------------------------------------------------------------------------------
June 16-18, 2010, Tsinghua University, Beijing, China
http://www.ieee-iwqos.org/2010/cfp.html

Improving quality of service ( QoS ) in both networks and end systems has been a long lasting research focus worldwide. The seventeen-year-long success of IWQoS has established it as a highly reputable forum to present novel ideas on all research subjects related to QoS. While QoS research for future generations of wired and wireless networks continues to captivate much interest, recent exploration of data centers, virtualization, cloud computing, industrial communication, and “green” computing has motivated a new wave of research interest in QoS and its related metrics such as Quality of Experience (QoE) and Quality of Protection (QoP) . The scope of IWQoS 2010 covers both theoretical and experimental research on QoS related issues such as survivability, availability, reliability, security, privacy, pricing, resource provisioning and management, user experience, and system performance guarantees. Topics of interest include QoS issues in (but not limited to) the following areas:

  • Data centers, virtualization and cloud computing
  • Energy saving in networks and end systems; IT technologies to reduce energy consumption in applications
  • Protection, experience, security and privacy
  • System dependability, availability; resilience and robustness to faults and DoS attacks
  • Scheduling, resource management, queue management, admission control; traffic engineering approaches and tools for provisioning and evaluation
  • Quality evaluation metrics and methodologies; application-aware QoS parsing, identification and control
  • Measurement, evaluation, adaptation and verification
  • Network operations, pricing and billing, network and service management
  • Architectures and protocols for IP and WDM networks, overlay and peer-to-peer networks; wireless ad hoc, mesh, and sensor networks
  • Design for the future Internet

Paper Submission Guidelines: IWQoS invites submission of manuscripts with original research results that have not been previously published or that are not currently under review by another conference or journal. Submissions will be judged based on originality, significance, interest, clarity, relevance, and correctness. Paper submissions should be no longer than 9 single-spaced, double-column pages with font-size of 10. Papers must be submitted electronically as PDF files through the EDAS system (http://edas.info/N8541). All submitted papers will be subject to peer reviews by Technical Program Committee members and other experts in the field. IWQoS aims at rapid dissemination of research results. For fast turnaround in the review process, a short review and publication cycle is designed, with the submission deadline as close to the workshop as the publisher allows.

The proceedings will be published in IEEE Xplore and EI indexed.  However, IEEE reserves the right to exclude a paper from distribution after the conference (e.g., removal from IEEE Xplore) if the paper is not presented at the conference.
 

IMPORTANT DATES
---------------------------
Paper submission deadline: Feb. 8, 2010
Notification of accept: April 5, 2010
Camera-ready papers: April 23, 2010

Technical Program Committee
-------------------------------------------

Abhishek Chandra, University of Minnesota, USA
Amund Kvalbein, Simula Research Laboratory, Norway
Baochun Li, University of Toronto, Canada
Burkhard Stiller, University of Zurich, Switzerland
Byrav Ramamurthy, University of Nebraska-Lincoln, USA
Cheng-Zhong Xu, Wayne State University, USA
Carlos Calafate, Technical University of Valencia, Spain
Gang Feng, University of Electronic Science and Technology of China, China
David Yau, Purdue University, USA
Dan Marinescu, University of Central Florida, USA
Edmundo Monteiro, University of Coimbra, Portugal
Georgios Karagiannis, University of Twente, The Netherlands
Haining Wang, College of William and Mary, USA
Himabindu Pucha, IBM ARC, USA
Iordanis Koutsopoulos, UTH, Greece
Jiangchuan Liu, Simon Fraser University, Canada
Joel Rodrigues IT, University of Beira Interior, Portugal
John Chi Shing Lui, The Chinese University of Hong Kong, Hong Kong
Martin Reisslein, Arizona State University, USA
Matthew Caesar, University of Illinois at Urbana-Champaign, USA
Narasimha Reddy, Texas A & M University, USA
Oliver Hohlfeld, TU Berlin, Germany
Pascal Lorenz, University of Haute Alsace, France
Patrick Pak-Ching Lee, The Chinese University of Hong Kong, Hong Kong
Qun Li, College of William and Mary, USA
Rade Stanojevic, Telefonica Research, Spain
Sridhar Machiraju, Google, USA
Srihari Nelakuditi, University of South Carolina, USA
Steve Uhlig, TU Berlin/T-labs, Germany
Torsten Braun, University of Bern, Switzerland
Vasilios Siris, ICS-FORTH / Athens University of Economics and Business, Greece
Weiyi Zhang, North Dakota State University, USA
Xiuzhen Cheng, George Washington Univ., USA
Xue Liu, McGill University, Canada
Yan Chen, Northwestern University, USA

--
Xiaoming Fu, http://user.informatik.uni-goettingen.de/~fu
Received: from m15-34.126.com (m15-34.126.com [220.181.15.34]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id nBV9UT9F012750 for ; Thu, 31 Dec 2009 01:30:29 -0800 Received: from xlwujunying ( [219.224.166.136] ) by ajax-webmail-wmsvr34 (Coremail) ; Thu, 31 Dec 2009 17:30:27 +0800 (CST) Date: Thu, 31 Dec 2009 17:30:27 +0800 (CST) From: xlwujunying To: dtn-interest Message-ID: <3834412.330441262251827037.JavaMail.coremail@bj126app34.126.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_86403_6067457.1262251827036" X-Originating-IP: [219.224.166.136] X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 090923(9022.2651.2651) Copyright (c) 2002-2009 www.mailtech.cn 126com X-CM-CTRLDATA: 5pBh02Zvb3Rlcl9odG09MzUzOjQ0 X-CM-TRANSID: IsqowLB7lgczbzxLAFpiAg--.41263W X-CM-SenderInfo: p0oz3ypxq1x0bj6rjloofrz/1tbiHQtK8EihO+rDkwABsF X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJTRUUUb-kYjxAI6xAIw2 8IcVW8XFylb7IF0VCF04k20xvEw2I207IF0wAYjxAI6xCIbckI1I0E57IF64kEYxAxMc80 4VCqF7xvr2I5M4IEnf9ElVAFpTB2q-sK649IAas0WaI_GwCS07vEb7Iv0xC_Jr1lV2xY67 kC6x804xWlV2xY67CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DMIAIbVAFxVCF77xC 64kEw24lV2xY67C26IkvcIIF6IxKo4kEV4ylV2xY628EF7xvwVC0I7IYx2IY67AKxVWDJV Cq3wCS07vE84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_GcCE3s1lV2xY628EF7xvwVC2z280 aVAFwI0_GcCE3s1lV2xY628EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wCS07vE5I8CrV ACY4xI64kE6c02F40Ex7xfMIAIbVAv7VC0I7IYx2IY67AKxVWUXVWUAwCS07vEYx0Ex4A2 jsIE14v26r1j6r4UMIAIbVCjxxvEw4WlV2xY6xkIecxEwVAFwVW8uwCS07vEc2IjII80xc xEwVWxJVW3JwCS07vE4x8a6x804xWlV2xY6I8E67AF67kF1VAFwI0_Jr0_JrylV2xY6IIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lV2xY6IIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CS07vEIxAIcVCF04k26cxKx2IYs7xG6Fyj6rWUJwCS07vEIxAIcVC2z280aVAFwI0_Jr0_ Gr1lV2xY6IIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUU== Subject: [dtn-interest] what about connectivity in DTN X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 09:30:30 -0000 ------=_Part_86403_6067457.1262251827036 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: base64 SGkgYWxsIQpob3cgY2FuIHdlIG1lYXN1ciBjb25uZWN0aXZpdHkgaW4gRFROLG9yIHRoZXJlIGlz IG5vIGNvbm5lY3Rpdml0eSBhdCBhbGw/CmhvdyB0byBkZWZpbmUgdGhpczogIEkgY2FuIHNlbmQg YW55IG1lc3NhZ2UgYmV0d2VlbiBhbnkgdHdvIG5vZGVzIGluIGEgZGVmaW5lZCB0aW1lIGluIERU Ti4gCklzIHRoaXMgbmV0d29yayBjb25uZWN0ZWQ/Ci0tCgrO4r7806oKMTg5MTE1Njc4ODkKCgo= ------=_Part_86403_6067457.1262251827036 Content-Type: text/html; charset=gbk Content-Transfer-Encoding: base64 PERJVj5IaSBhbGwhPC9ESVY+CjxESVY+aG93IGNhbiB3ZSBtZWFzdXIgY29ubmVjdGl2aXR5IGlu IERUTixvciB0aGVyZSBpcyBubyBjb25uZWN0aXZpdHkgYXQgYWxsPzwvRElWPgo8RElWPmhvdyB0 byBkZWZpbmUgdGhpczombmJzcDsgSSBjYW4gc2VuZCBhbnkgbWVzc2FnZSBiZXR3ZWVuIGFueSB0 d28gbm9kZXMgaW4gYSBkZWZpbmVkIHRpbWUgaW4gRFROLiA8L0RJVj4KPERJVj5JcyB0aGlzIG5l dHdvcmsgY29ubmVjdGVkPzxCUj4tLTxCUj48L0RJVj4KPERJVj4KPERJVj7O4r7806o8L0RJVj4K PERJVj4xODkxMTU2Nzg4OTwvRElWPjwvRElWPjxCUj48QlI+PFNQQU4gdGl0bGU9Im5ldGVhc2Vm b290ZXIiPjwvU1BBTj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNlZm9vdGVyIi8+PC9zcGFu Pg== ------=_Part_86403_6067457.1262251827036-- Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBUH9m81031213 for ; Wed, 30 Dec 2009 09:09:48 -0800 Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 6A2534DDF; Wed, 30 Dec 2009 17:09:48 +0000 (GMT) Received: from [10.87.48.9] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id nBUH9i4G011189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Dec 2009 17:09:44 GMT Message-ID: <4B3B896F.7060908@cs.tcd.ie> Date: Wed, 30 Dec 2009 17:10:07 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Scott Burleigh , DTN X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.9999 (Score 5) X-Spam-Score: 5.00 (*****) [Hold at 8.00] X-Canit-Stats-ID: 60636623 - 89ea0bfe7103 X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Subject: [dtn-interest] LTP CL X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 17:09:49 -0000 Hi Scott, Just noticed you've published draft-burleigh-dtnrg-ltpcl-00, which is good. I'll probably have more comments later, but this part of the spec just seems wrong: The requirement that green segment service data be self-identifying to the client service -- in this case, the Bundle Protocol -- implies that the service data of each green segment must be a single complete bundle, even if possibly a BP "fragment." Firstly, where's that "self-identifying" requirement come from? I don't recall it in the LTP RFCs. (But I didn't look, maybe its there.) Secondly that requires the BP agent to know the segment sizing used within the LTP CL (to use green segments). I don't think any other CL has a similar requirement does it? Perhaps just limiting this to one bundle per LTP session (or all-red or all-green) would be better and a good bit simpler? S. Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBMGvvHh026467 for ; Tue, 22 Dec 2009 08:57:57 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [157.185.80.152] by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KV200DEDCGKOP10@asmtp019.mac.com> for dtn-interest@mailman.dtnrg.org; Tue, 22 Dec 2009 08:57:58 -0800 (PST) From: Peter Lovell To: Stephen Farrell , DTN Date: Tue, 22 Dec 2009 11:57:58 -0500 Message-id: <20091222165758.1915769747@smtp.mac.com> In-reply-to: <4B30F8AD.6010100@cs.tcd.ie> References: <4B30F8AD.6010100@cs.tcd.ie> X-Mailer: CTM PowerMail version 6.0.3 build 4609 English (PPC) Subject: Re: [dtn-interest] DTNRG slot at IETF 77 X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 16:57:57 -0000 On Tue, Dec 22, 2009, Stephen Farrell wrote: >Folks, > >IETF 77 [1] is in Anaheim next March and scheduling has >started. (Registration is also open.) > >We're planning to request a slot for DTNRG. We'll do >agenda stuff etc closer to the time. > >Regards, >Stephen. I will have to miss this one, unfortunately, as my daughter's wedding is that week. Cheers.....Peter Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBMGnb54026097 for ; Tue, 22 Dec 2009 08:49:39 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id DCE0A360076 for ; Tue, 22 Dec 2009 16:49:37 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kt7o56PwK65 for ; Tue, 22 Dec 2009 16:49:36 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 5516536006F for ; Tue, 22 Dec 2009 16:49:35 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id BC3487C309 for ; Tue, 22 Dec 2009 16:49:35 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4koEGvnFh+2p for ; Tue, 22 Dec 2009 16:49:35 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id 3101C7C12D for ; Tue, 22 Dec 2009 16:49:35 +0000 (GMT) Message-ID: <4B30F8AD.6010100@cs.tcd.ie> Date: Tue, 22 Dec 2009 16:49:49 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: DTN X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-interest] DTNRG slot at IETF 77 X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 16:49:39 -0000 Folks, IETF 77 [1] is in Anaheim next March and scheduling has started. (Registration is also open.) We're planning to request a slot for DTNRG. We'll do agenda stuff etc closer to the time. Regards, Stephen. [1] http://www.ietf.org/meeting/77/index.html Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBJ7VId9011531 for ; Fri, 18 Dec 2009 23:31:18 -0800 Received: by ywh12 with SMTP id 12so4172955ywh.21 for ; Fri, 18 Dec 2009 23:31:18 -0800 (PST) Received: by 10.150.30.6 with SMTP id d6mr7839674ybd.140.1261207877645; Fri, 18 Dec 2009 23:31:17 -0800 (PST) Received: from ?10.0.0.120? (adsl-71-141-226-80.dsl.snfc21.pacbell.net [71.141.226.80]) by mx.google.com with ESMTPS id 4sm1406180ywi.57.2009.12.18.23.31.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Dec 2009 23:31:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Kevin Fall In-Reply-To: <7AA44B99-5062-426D-B13D-0EEF185423C6@surrey.ac.uk> Date: Fri, 18 Dec 2009 23:31:11 -0800 Message-Id: <75B03D92-A47A-40B3-8CDA-2F367F6354FB@gmail.com> References: <4B2B8D4F.9080409@cs.tcd.ie> <7AA44B99-5062-426D-B13D-0EEF185423C6@surrey.ac.uk> To: Lloyd Wood X-Mailer: Apple Mail (2.1077) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nBJ7VId9011531 Cc: DTN Subject: Re: [dtn-interest] Hiroshima DTNRG minutes X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 07:31:19 -0000 fixed. - K On Dec 18, 2009, at Dec 18 10:40 AMPST, Lloyd Wood wrote: > All the links to presentations cited in the minutes are broken. > > You've uploaded ppt, which get sort-of-converted to html (on a Mac, with attendant Mac files and directory structure) a random time after they're uploaded. > > If you'd uploaded pdf, the links given in the minutes would still be valid, and no conversion effort need be expended. Or, if you'd left off the .ppt filename extension, http content negotiation would have avoided breakage, since the core filename is unchanged after munging (though there are still a few extra clicks to get through the Mac-induced directory layout). > > See the presentations at > http://www.ietf.org/proceedings/09nov/slides/DTNRG-0/ > http://www.ietf.org/proceedings/09nov/slides/DTNRG-1/ > http://www.ietf.org/proceedings/09nov/slides/DTNRG-2/ > http://www.ietf.org/proceedings/09nov/slides/DTNRG-3/ > http://www.ietf.org/proceedings/09nov/slides/DTNRG-4/ > > > On 18 Dec 2009, at 14:10, Stephen Farrell wrote: > >> >> Hi all, >> >> I finally got around to getting the minutes [1] from Hiroshima done. >> Thanks to Elwyn Davies and Peter Lovell for taking notes and to >> Peter St. Andre for jabber scribing. >> >> If there are any changes/additions needed let me and/or the list >> know before Jan 6 please. >> >> Thanks, >> Stephen. >> >> [1] http://www.ietf.org/proceedings/09nov/minutes/DTNRG.html >> >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest > > DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/ > > > > > > > > > > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBIIeiHR007612 for ; Fri, 18 Dec 2009 10:40:45 -0800 X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-80.messagelabs.com!1261161643!71531992!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 16182 invoked from network); 18 Dec 2009 18:40:43 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-11.tower-80.messagelabs.com with AES128-SHA encrypted SMTP; 18 Dec 2009 18:40:43 -0000 Received: from [192.168.1.209] (131.227.200.4) by EXHT011P.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 18 Dec 2009 18:40:42 +0000 MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset="us-ascii" From: Lloyd Wood In-Reply-To: <4B2B8D4F.9080409@cs.tcd.ie> Date: Fri, 18 Dec 2009 18:40:42 +0000 Message-ID: <7AA44B99-5062-426D-B13D-0EEF185423C6@surrey.ac.uk> References: <4B2B8D4F.9080409@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1077) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nBIIeiHR007612 Cc: DTN , Lloyd Wood Subject: Re: [dtn-interest] Hiroshima DTNRG minutes X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 18:40:46 -0000 All the links to presentations cited in the minutes are broken. You've uploaded ppt, which get sort-of-converted to html (on a Mac, with attendant Mac files and directory structure) a random time after they're uploaded. If you'd uploaded pdf, the links given in the minutes would still be valid, and no conversion effort need be expended. Or, if you'd left off the .ppt filename extension, http content negotiation would have avoided breakage, since the core filename is unchanged after munging (though there are still a few extra clicks to get through the Mac-induced directory layout). See the presentations at http://www.ietf.org/proceedings/09nov/slides/DTNRG-0/ http://www.ietf.org/proceedings/09nov/slides/DTNRG-1/ http://www.ietf.org/proceedings/09nov/slides/DTNRG-2/ http://www.ietf.org/proceedings/09nov/slides/DTNRG-3/ http://www.ietf.org/proceedings/09nov/slides/DTNRG-4/ On 18 Dec 2009, at 14:10, Stephen Farrell wrote: > > Hi all, > > I finally got around to getting the minutes [1] from Hiroshima done. > Thanks to Elwyn Davies and Peter Lovell for taking notes and to > Peter St. Andre for jabber scribing. > > If there are any changes/additions needed let me and/or the list > know before Jan 6 please. > > Thanks, > Stephen. > > [1] http://www.ietf.org/proceedings/09nov/minutes/DTNRG.html > > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/ Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBIHU7T0004178 for ; Fri, 18 Dec 2009 09:30:08 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id BD586360088 for ; Fri, 18 Dec 2009 14:10:18 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLw+iLGDxqrl for ; Fri, 18 Dec 2009 14:10:18 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 2D2C3360086 for ; Fri, 18 Dec 2009 14:10:17 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 9F5F67C327 for ; Fri, 18 Dec 2009 14:10:17 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IF6IGD8W7c1 for ; Fri, 18 Dec 2009 14:10:17 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id 171377C309 for ; Fri, 18 Dec 2009 14:10:17 +0000 (GMT) Message-ID: <4B2B8D4F.9080409@cs.tcd.ie> Date: Fri, 18 Dec 2009 14:10:23 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: DTN X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-interest] Hiroshima DTNRG minutes X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 17:30:08 -0000 Hi all, I finally got around to getting the minutes [1] from Hiroshima done. Thanks to Elwyn Davies and Peter Lovell for taking notes and to Peter St. Andre for jabber scribing. If there are any changes/additions needed let me and/or the list know before Jan 6 please. Thanks, Stephen. [1] http://www.ietf.org/proceedings/09nov/minutes/DTNRG.html Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBB6A0Ip007050 for ; Thu, 10 Dec 2009 22:10:01 -0800 Received: by ywh3 with SMTP id 3so557043ywh.22 for ; Thu, 10 Dec 2009 22:10:00 -0800 (PST) Received: by 10.101.180.10 with SMTP id h10mr1534843anp.95.1260511799292; Thu, 10 Dec 2009 22:09:59 -0800 (PST) Received: from ?67.188.59.148? (c-67-188-59-148.hsd1.ca.comcast.net [67.188.59.148]) by mx.google.com with ESMTPS id 36sm741023yxh.13.2009.12.10.22.09.57 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 22:09:58 -0800 (PST) Sender: Alex McMahon From: Alex McMahon To: "Burleigh, Scott C (313B)" In-Reply-To: References: <1260405186.4039.433.camel@sphere> <4B208B3E.6060708@jpl.nasa.gov> <1260484672.4039.3562.camel@sphere> Content-Type: text/plain Organization: Trinity College Dublin Date: Thu, 10 Dec 2009 22:09:56 -0800 Message-Id: <1260511796.4039.5597.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: DTN Subject: Re: [dtn-interest] fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 06:10:01 -0000 My query was only concerned with gaining a better understanding of administrative records. Specifically with establishing whether a bundle with bit 1 set indicating the bundle's ADU is an administrative record explicitly meant that the administrative record ADU must be contained in the payload block, establishing the distinction between an administrative record ADU and payload that is an administrative record ADU, whether the only application of fragment fields in an administrative record was when and administrative record was requested for each fragment bundle of a bundle and whether the administrative record depicted in RFC 5050 which depicts fragmentation fields (Fragment offset & Fragment length) was correct. All of which you have answered. In the context of my query when I said "primary block of an administrative record", I am aware of my error. What I had meant and what I should have said properly was "primary block of a bundle with a payload that is an administrative record". By saying "bundle that is an administrative record" in this context I meant "bundle with a payload that is an administrative record" and am aware of this error too. Had I known the answers to my questions (and i probably should have) prior to asking them I would have phrased them properly. My references to RFC 5050 were only intended to provide context to my query in which by 'indicates' I meant 'suggests to me' and not intended to be taken to claim or to state to be true that RFC 5050 says an administrative record ADU has a primary block, says an administrative record is a bundle, or say anything other. I have said previously on this thread "There is nothing in 5050 (that I know of) that states that an administrative record is a bundle". Thanks, Alex On Thu, 2009-12-10 at 15:57 -0800, Burleigh, Scott C (313B) wrote: > > -----Original Message----- > > From: Alex McMahon [mailto:alexmcm@gmail.com] On Behalf Of Alex McMahon > > Sent: Thursday, December 10, 2009 2:38 PM > > To: Burleigh, Scott C (313B) > > Cc: DTN > > Subject: Re: [dtn-interest] fragmentation fields in administrative records > > > > > > On Wed, 2009-12-09 at 21:46 -0800, Scott C. Burleigh wrote: > > > Alex McMahon wrote: > > > > The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC > > > > 5050 depicts an administrative record that includes the fragmentation > > > > fields (Fragment offset & Fragment length). > > > Correct. > > > > However, as RFC 5050 also > > > > indicates that the processing control flag of the primary block of an > > > > administrative record is set to indicate the ADU is an administrative > > > > record. > > > Actually I'm pretty sure it never says this anywhere. > > It says at the start of 4.2. that bit 1 characterizes the bundle as > > "Application data unit is an administrative record". > Right, bit 1 of the processing control flags in the primary block OF A BUNDLE has exactly this significance. But "the processing control flag of the primary block of an administrative record" is meaningless, because an administrative record has no primary block, because it is not a bundle. RFC 5050 does not say, anywhere, what you claim it says. > > > I think it says > > > that bit 1 of the bundle processing control flags in the primary block > > > of a bundle that contains an administrative record is set to indicate > > > that the bundle's ADU is an administrative record. > > > > Although it does say 'Bundle's ADU is an administrative record' in the > > later text it does not (that i am aware of) say 'bundle that contains an > > administrative record'. > > That particular phrase happens not to have been required anywhere in the RFC, but step 2 of 6.2 certainly makes the relationship clear. Do a text search on "administrative record" in RFC 5050; if you can find any text that says an administrative record is a bundle rather than an ADU that may form the payload of a bundle, please point it out. > > These would seem to have different meanings. > > 'Bundle's ADU "is" an administrative record' could indicate that a > > payload block of that Bundle "is" an administrative record while 'bundle > > that contains an administrative record' indicates that a payload block > > of that bundle must contain an administrative record. > > No, a payload block cannot "be" an administrative record; it's a block, not an ADU. The payload block has some flags (which are entirely distinct from the bundle processing control flags in the primary block) and it also has some content, an ADU, which we refer to as "the payload of the bundle". "Bundle's application data unit" and "bundle's payload" are synonymous. > > > So.. if a bundle has bit 1 set indicating the bundle's ADU is an > > administrative record, this means that the administrative record ADU > > must be contained in the payload block....right ? > > Yes. > > > > An administrative record has no primary block. It can't, because it's > > > not a bundle; it's an application data unit, in standard form, that may > > > be the payload of a bundle. > > > > This implies that an administrative record has a primary block > > > > that includes the fragmentation fields (Fragment offset & Fragment > > > > length) if fragmented. > > > No, it doesn't, for the reason explained above. An administrative record > > > has no primary block (containing fragmentation fields or otherwise), > > > because it's not a bundle. > > > > > > Is there a scenario in which fragmentation offsets would be included in > > > > an administrative record ? > > > Yes: the scenario in which the bundle to which the administrative record > > > pertains (the one that is partially identified by the admin record's > > > "Copy of bundle X's Creation Timestamp time", "Copy of bundle X's > > > Creation Timestamp sequence number", and source endpoint ID; e.g., the > > > bundle for which custody has been taken) is a fragment. > > > In that case, the source endpoint ID and creation timestamp are > > insufficient to > > > identify fully the bundle to which the admin record pertains: that > > > bundle's fragment offset and length are needed as well. > > > > Is the only scenario in which fragmentation offsets would be included in > > an administrative record, one in which an administrative record is > > requested for each fragment bundle of a bundle? > > I think it comes to that. I don't know of any administrative records that would be generated for only a subset of the fragments of a fragmented bundle. > > > As a requested administrative record would already be transmitted for a > > a set of fragmented bundles upon reassembly it seems like the main > > reason requesting reports per fragment is for transmission or > > retransmission of all fragment bundles of that bundle which might not > > have been received by the destination yet - right? > > I don't think so. If you're requesting status reports on bundle reception (for example) for a given bundle, then I think fragmentation of that bundle will cause status reports to be individually generated upon reception of each of the fragments at each router along the end-to-end path. > > > Therefore, it seems that the 'Fragment offset' & 'Fragment length' of an > > administrative record refer to a copy of bundle X's fragments and > > perhaps Figure 10 and Figure 13 should indicate 'Copy of bundle X's > > Fragment offset' & 'Copy of bundle X's Fragment length' if this is the > > case. > > Sure, we could change those labels when we submit the replacement I-D for RFC 5050. > > Scott > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBANveHL021940 for ; Thu, 10 Dec 2009 15:57:40 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by smtp.jpl.nasa.gov (Switch-3.4.1/Switch-3.4.1) with ESMTP id nBANvaJx012491 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Thu, 10 Dec 2009 15:57:40 -0800 Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.80]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Thu, 10 Dec 2009 15:57:36 -0800 From: "Burleigh, Scott C (313B)" To: DTN Date: Thu, 10 Dec 2009 15:57:34 -0800 Thread-Topic: [dtn-interest] fragmentation fields in administrative records Thread-Index: Acp56WyUDRh3UPTWSaOj2WmwQT+e0gABaVfw Message-ID: References: <1260405186.4039.433.camel@sphere> <4B208B3E.6060708@jpl.nasa.gov> <1260484672.4039.3562.camel@sphere> In-Reply-To: <1260484672.4039.3562.camel@sphere> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nBANveHL021940 Subject: Re: [dtn-interest] fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 23:57:40 -0000 > -----Original Message----- > From: Alex McMahon [mailto:alexmcm@gmail.com] On Behalf Of Alex McMahon > Sent: Thursday, December 10, 2009 2:38 PM > To: Burleigh, Scott C (313B) > Cc: DTN > Subject: Re: [dtn-interest] fragmentation fields in administrative records > > > On Wed, 2009-12-09 at 21:46 -0800, Scott C. Burleigh wrote: > > Alex McMahon wrote: > > > The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC > > > 5050 depicts an administrative record that includes the fragmentation > > > fields (Fragment offset & Fragment length). > > Correct. > > > However, as RFC 5050 also > > > indicates that the processing control flag of the primary block of an > > > administrative record is set to indicate the ADU is an administrative > > > record. > > Actually I'm pretty sure it never says this anywhere. > It says at the start of 4.2. that bit 1 characterizes the bundle as > "Application data unit is an administrative record". Right, bit 1 of the processing control flags in the primary block OF A BUNDLE has exactly this significance. But "the processing control flag of the primary block of an administrative record" is meaningless, because an administrative record has no primary block, because it is not a bundle. RFC 5050 does not say, anywhere, what you claim it says. > > I think it says > > that bit 1 of the bundle processing control flags in the primary block > > of a bundle that contains an administrative record is set to indicate > > that the bundle's ADU is an administrative record. > > Although it does say 'Bundle's ADU is an administrative record' in the > later text it does not (that i am aware of) say 'bundle that contains an > administrative record'. That particular phrase happens not to have been required anywhere in the RFC, but step 2 of 6.2 certainly makes the relationship clear. Do a text search on "administrative record" in RFC 5050; if you can find any text that says an administrative record is a bundle rather than an ADU that may form the payload of a bundle, please point it out. > These would seem to have different meanings. > 'Bundle's ADU "is" an administrative record' could indicate that a > payload block of that Bundle "is" an administrative record while 'bundle > that contains an administrative record' indicates that a payload block > of that bundle must contain an administrative record. No, a payload block cannot "be" an administrative record; it's a block, not an ADU. The payload block has some flags (which are entirely distinct from the bundle processing control flags in the primary block) and it also has some content, an ADU, which we refer to as "the payload of the bundle". "Bundle's application data unit" and "bundle's payload" are synonymous. > So.. if a bundle has bit 1 set indicating the bundle's ADU is an > administrative record, this means that the administrative record ADU > must be contained in the payload block....right ? Yes. > > An administrative record has no primary block. It can't, because it's > > not a bundle; it's an application data unit, in standard form, that may > > be the payload of a bundle. > > > This implies that an administrative record has a primary block > > > that includes the fragmentation fields (Fragment offset & Fragment > > > length) if fragmented. > > No, it doesn't, for the reason explained above. An administrative record > > has no primary block (containing fragmentation fields or otherwise), > > because it's not a bundle. > > > > Is there a scenario in which fragmentation offsets would be included in > > > an administrative record ? > > Yes: the scenario in which the bundle to which the administrative record > > pertains (the one that is partially identified by the admin record's > > "Copy of bundle X's Creation Timestamp time", "Copy of bundle X's > > Creation Timestamp sequence number", and source endpoint ID; e.g., the > > bundle for which custody has been taken) is a fragment. > > In that case, the source endpoint ID and creation timestamp are > insufficient to > > identify fully the bundle to which the admin record pertains: that > > bundle's fragment offset and length are needed as well. > > Is the only scenario in which fragmentation offsets would be included in > an administrative record, one in which an administrative record is > requested for each fragment bundle of a bundle? I think it comes to that. I don't know of any administrative records that would be generated for only a subset of the fragments of a fragmented bundle. > As a requested administrative record would already be transmitted for a > a set of fragmented bundles upon reassembly it seems like the main > reason requesting reports per fragment is for transmission or > retransmission of all fragment bundles of that bundle which might not > have been received by the destination yet - right? I don't think so. If you're requesting status reports on bundle reception (for example) for a given bundle, then I think fragmentation of that bundle will cause status reports to be individually generated upon reception of each of the fragments at each router along the end-to-end path. > Therefore, it seems that the 'Fragment offset' & 'Fragment length' of an > administrative record refer to a copy of bundle X's fragments and > perhaps Figure 10 and Figure 13 should indicate 'Copy of bundle X's > Fragment offset' & 'Copy of bundle X's Fragment length' if this is the > case. Sure, we could change those labels when we submit the replacement I-D for RFC 5050. Scott Received: from mail-yx0-f186.google.com (mail-yx0-f186.google.com [209.85.210.186]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBAMw0JV019141 for ; Thu, 10 Dec 2009 14:58:00 -0800 Received: by yxe16 with SMTP id 16so328475yxe.27 for ; Thu, 10 Dec 2009 14:58:00 -0800 (PST) Received: by 10.101.135.38 with SMTP id m38mr839074ann.163.1260485879961; Thu, 10 Dec 2009 14:57:59 -0800 (PST) Received: from ?10.212.112.174? (bldmz-nat-161-164.berkeley.intel-research.net [12.155.161.164]) by mx.google.com with ESMTPS id 22sm594442yxe.57.2009.12.10.14.57.55 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 14:57:56 -0800 (PST) Sender: Alex McMahon From: Alex McMahon To: Peter Lovell In-Reply-To: <20091210095549.1637771369@smtp.mac.com> References: <1260405186.4039.433.camel@sphere> <20091210013028.2134662025@smtp.mac.com> <1260419232.4039.728.camel@sphere> <20091210095549.1637771369@smtp.mac.com> Content-Type: text/plain Organization: Trinity College Dublin Date: Thu, 10 Dec 2009 14:57:44 -0800 Message-Id: <1260485864.4039.3623.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: dtn interest Subject: Re: [dtn-interest] Re(2): fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 22:58:00 -0000 Thanks Peter On Thu, 2009-12-10 at 04:55 -0500, Peter Lovell wrote: > On Wed, Dec 9, 2009, Alex McMahon wrote: > > >> Every bundle must have a primary. > >> If a bundle is fragmented, each > >> fragment becomes a new bundle ("fragment-bundle") and has a primary > >> block. > >Right, every bundle, but what if an administrative record was not a > >bundle. > >> So I don't understand your question here. > >There is nothing in 5050 (that I know of) that states that an > >administrative record is a bundle, it is only stated that it is a > >standard ADU that is used in providing some of the features of the > >Bundle Protocol. Also the example shown in figure 13 depicts an > >administrative record is not in the Canonical Bundle Block Format. > > > >It is stated in 5050 that if a bundle is an administrative record then > >it will indicate this in the primary block. > > > >>From this I gather that while an administrative record can be a bundle, > >it does not have to be. It could, for example, be an ADU, not > >transformed by BP into a bundle, that provides only some of the features > >of the Bundle Protocol and as such might not have a primary block.. > > > Hi Alex, > > I think we're getting at cross-purposes here. Perhaps I was being too > brief in my response. > > An admin record is not a bundle, in and of itself. It doesn't have its > own primary block. But any admin record going between nodes must be > conveyed in a bundle. > > Section 5.1 says ... > > When > required to "generate" an administrative record (a bundle status > report or a custody signal), the bundle protocol agent itself is > responsible for causing a new bundle to be transmitted, conveying > that record. > > This says (to me, at least) that you can't have an admin record going > naked on the wire -- it has to be contained in a "bundle" wrapper. So an > admin record on-the-fly will always have a primary block associated with > it. After all, primary is the only place that source and destination are > specified, so it has to be there. > > That said, when it comes off the wire and goes to the BPA, the primary > might well be gone. That all depends upon how one writes a BPA (and I've > not thought very hard about that specific issue). > > But the lower levels of the protocol have to tell BPA about the content. > That is, BPA has to know whether to handle the payload as user-data or > admin-record, at the very least. > > >Is there a scenario in which fragmentation offsets would be included in > >an administrative record ? > > Yes. The fragment-offset-and-length fields in an admin record refer to > original bundle for which this admin record was generated. For example, > if you're accepting custody and you receive a bundle-fragment, you send > a custody acknowledgement for the fragment you received. You can't (must > not) send one for the whole, original bundle because you don't have it. > So the fragment fields in the admin record refer to the original bundle, > the fields in your own primary will deal with the case that the admin > record itself is fragmented (ugh). > > >Also the example shown in figure 13 depicts an > >administrative record is not in the Canonical Bundle Block Format. > > What that figure shows is the content of the record. The record will be > the payload of a bundle and will therefore have the payload header (Fig > 6) prepended when being packaged into a real bundle. > > Cheers.....Peter > Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.211.176]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBAMbueA018211 for ; Thu, 10 Dec 2009 14:37:56 -0800 Received: by ywh6 with SMTP id 6so303625ywh.4 for ; Thu, 10 Dec 2009 14:37:56 -0800 (PST) Received: by 10.150.120.10 with SMTP id s10mr1254973ybc.12.1260484675922; Thu, 10 Dec 2009 14:37:55 -0800 (PST) Received: from ?10.212.112.174? (bldmz-nat-161-164.berkeley.intel-research.net [12.155.161.164]) by mx.google.com with ESMTPS id 9sm588253yxf.59.2009.12.10.14.37.54 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 14:37:54 -0800 (PST) Sender: Alex McMahon From: Alex McMahon To: "Scott C. Burleigh" In-Reply-To: <4B208B3E.6060708@jpl.nasa.gov> References: <1260405186.4039.433.camel@sphere> <4B208B3E.6060708@jpl.nasa.gov> Content-Type: text/plain Organization: Trinity College Dublin Date: Thu, 10 Dec 2009 14:37:52 -0800 Message-Id: <1260484672.4039.3562.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: DTN Subject: Re: [dtn-interest] fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 22:37:56 -0000 On Wed, 2009-12-09 at 21:46 -0800, Scott C. Burleigh wrote: > Alex McMahon wrote: > > The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC > > 5050 depicts an administrative record that includes the fragmentation > > fields (Fragment offset & Fragment length). > Correct. > > However, as RFC 5050 also > > indicates that the processing control flag of the primary block of an > > administrative record is set to indicate the ADU is an administrative > > record. > Actually I'm pretty sure it never says this anywhere. It says at the start of 4.2. that bit 1 characterizes the bundle as "Application data unit is an administrative record". > I think it says > that bit 1 of the bundle processing control flags in the primary block > of a bundle that contains an administrative record is set to indicate > that the bundle's ADU is an administrative record. Although it does say 'Bundle's ADU is an administrative record' in the later text it does not (that i am aware of) say 'bundle that contains an administrative record'. These would seem to have different meanings. 'Bundle's ADU "is" an administrative record' could indicate that a payload block of that Bundle "is" an administrative record while 'bundle that contains an administrative record' indicates that a payload block of that bundle must contain an administrative record. So.. if a bundle has bit 1 set indicating the bundle's ADU is an administrative record, this means that the administrative record ADU must be contained in the payload block....right ? > An administrative record has no primary block. It can't, because it's > not a bundle; it's an application data unit, in standard form, that may > be the payload of a bundle. > > This implies that an administrative record has a primary block > > that includes the fragmentation fields (Fragment offset & Fragment > > length) if fragmented. > No, it doesn't, for the reason explained above. An administrative record > has no primary block (containing fragmentation fields or otherwise), > because it's not a bundle. > > Is there a scenario in which fragmentation offsets would be included in > > an administrative record ? > Yes: the scenario in which the bundle to which the administrative record > pertains (the one that is partially identified by the admin record's > "Copy of bundle X's Creation Timestamp time", "Copy of bundle X's > Creation Timestamp sequence number", and source endpoint ID; e.g., the > bundle for which custody has been taken) is a fragment. > In that case, the source endpoint ID and creation timestamp are insufficient to > identify fully the bundle to which the admin record pertains: that > bundle's fragment offset and length are needed as well. Is the only scenario in which fragmentation offsets would be included in an administrative record, one in which an administrative record is requested for each fragment bundle of a bundle? As a requested administrative record would already be transmitted for a a set of fragmented bundles upon reassembly it seems like the main reason requesting reports per fragment is for transmission or retransmission of all fragment bundles of that bundle which might not have been received by the destination yet - right? Therefore, it seems that the 'Fragment offset' & 'Fragment length' of an administrative record refer to a copy of bundle X's fragments and perhaps Figure 10 and Figure 13 should indicate 'Copy of bundle X's Fragment offset' & 'Copy of bundle X's Fragment length' if this is the case. > > Does this imply that a BPA should be capable of processing an > > administrative record without a primary block as well as a bundle that > > is an administrative record ? > > > Almost. A BPA should be capable of processing an administrative record > without a primary block, because all administrative records lack primary > blocks, because they are not bundles. And a BPA should be capable of > processing a bundle that contains an administrative record (because > that's the only way it's going to receive an administrative record), but > it will never need to process a bundle that is an administrative record > because none are. > Thanks, Alex > Scott > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBA9tqxq028821 for ; Thu, 10 Dec 2009 01:55:52 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.7] (pool-96-255-127-102.washdc.fios.verizon.net [96.255.127.102]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUF009WUKX27E00@asmtp013.mac.com> for dtn-interest@mailman.dtnrg.org; Thu, 10 Dec 2009 01:55:52 -0800 (PST) From: Peter Lovell To: alex.mcmahon@cs.tcd.ie Date: Thu, 10 Dec 2009 04:55:49 -0500 Message-id: <20091210095549.1637771369@smtp.mac.com> In-reply-to: <1260419232.4039.728.camel@sphere> References: <1260405186.4039.433.camel@sphere> <20091210013028.2134662025@smtp.mac.com> <1260419232.4039.728.camel@sphere> X-Mailer: CTM PowerMail version 6.0.3 build 4609 English (intel) Cc: dtn interest Subject: [dtn-interest] Re(2): fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 09:55:52 -0000 On Wed, Dec 9, 2009, Alex McMahon wrote: >> Every bundle must have a primary. >> If a bundle is fragmented, each >> fragment becomes a new bundle ("fragment-bundle") and has a primary >> block. >Right, every bundle, but what if an administrative record was not a >bundle. >> So I don't understand your question here. >There is nothing in 5050 (that I know of) that states that an >administrative record is a bundle, it is only stated that it is a >standard ADU that is used in providing some of the features of the >Bundle Protocol. Also the example shown in figure 13 depicts an >administrative record is not in the Canonical Bundle Block Format. > >It is stated in 5050 that if a bundle is an administrative record then >it will indicate this in the primary block. > >>From this I gather that while an administrative record can be a bundle, >it does not have to be. It could, for example, be an ADU, not >transformed by BP into a bundle, that provides only some of the features >of the Bundle Protocol and as such might not have a primary block.. Hi Alex, I think we're getting at cross-purposes here. Perhaps I was being too brief in my response. An admin record is not a bundle, in and of itself. It doesn't have its own primary block. But any admin record going between nodes must be conveyed in a bundle. Section 5.1 says ... When required to "generate" an administrative record (a bundle status report or a custody signal), the bundle protocol agent itself is responsible for causing a new bundle to be transmitted, conveying that record. This says (to me, at least) that you can't have an admin record going naked on the wire -- it has to be contained in a "bundle" wrapper. So an admin record on-the-fly will always have a primary block associated with it. After all, primary is the only place that source and destination are specified, so it has to be there. That said, when it comes off the wire and goes to the BPA, the primary might well be gone. That all depends upon how one writes a BPA (and I've not thought very hard about that specific issue). But the lower levels of the protocol have to tell BPA about the content. That is, BPA has to know whether to handle the payload as user-data or admin-record, at the very least. >Is there a scenario in which fragmentation offsets would be included in >an administrative record ? Yes. The fragment-offset-and-length fields in an admin record refer to original bundle for which this admin record was generated. For example, if you're accepting custody and you receive a bundle-fragment, you send a custody acknowledgement for the fragment you received. You can't (must not) send one for the whole, original bundle because you don't have it. So the fragment fields in the admin record refer to the original bundle, the fields in your own primary will deal with the case that the admin record itself is fragmented (ugh). >Also the example shown in figure 13 depicts an >administrative record is not in the Canonical Bundle Block Format. What that figure shows is the content of the record. The record will be the payload of a bundle and will therefore have the payload header (Fig 6) prepended when being packaged into a real bundle. Cheers.....Peter Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBA5kavw017089 for ; Wed, 9 Dec 2009 21:46:36 -0800 Received: from [192.168.1.2] (really [75.82.186.89]) by cdptpa-omta01.mail.rr.com with ESMTP id <20091210054635858.KPDY5708@cdptpa-omta01.mail.rr.com> for ; Thu, 10 Dec 2009 05:46:35 +0000 Message-ID: <4B208B3E.6060708@jpl.nasa.gov> Date: Wed, 09 Dec 2009 21:46:38 -0800 From: "Scott C. Burleigh" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DTN References: <1260405186.4039.433.camel@sphere> In-Reply-To: <1260405186.4039.433.camel@sphere> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dtn-interest] fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 05:46:37 -0000 Alex McMahon wrote: > The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC > 5050 depicts an administrative record that includes the fragmentation > fields (Fragment offset & Fragment length). Correct. > However, as RFC 5050 also > indicates that the processing control flag of the primary block of an > administrative record is set to indicate the ADU is an administrative > record. Actually I'm pretty sure it never says this anywhere. I think it says that bit 1 of the bundle processing control flags in the primary block of a bundle that contains an administrative record is set to indicate that the bundle's ADU is an administrative record. An administrative record has no primary block. It can't, because it's not a bundle; it's an application data unit, in standard form, that may be the payload of a bundle. > This implies that an administrative record has a primary block > that includes the fragmentation fields (Fragment offset & Fragment > length) if fragmented. > No, it doesn't, for the reason explained above. An administrative record has no primary block (containing fragmentation fields or otherwise), because it's not a bundle. > Is there a scenario in which fragmentation offsets would be included in > an administrative record ? Yes: the scenario in which the bundle to which the administrative record pertains (the one that is partially identified by the admin record's "Copy of bundle X's Creation Timestamp time", "Copy of bundle X's Creation Timestamp sequence number", and source endpoint ID; e.g., the bundle for which custody has been taken) is a fragment. In that case, the source endpoint ID and creation timestamp are insufficient to identify fully the bundle to which the admin record pertains: that bundle's fragment offset and length are needed as well. > Does this imply that a BPA should be capable of processing an > administrative record without a primary block as well as a bundle that > is an administrative record ? > Almost. A BPA should be capable of processing an administrative record without a primary block, because all administrative records lack primary blocks, because they are not bundles. And a BPA should be capable of processing a bundle that contains an administrative record (because that's the only way it's going to receive an administrative record), but it will never need to process a bundle that is an administrative record because none are. Scott Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBA4RGFJ013365 for ; Wed, 9 Dec 2009 20:27:17 -0800 Received: by ywh8 with SMTP id 8so7964649ywh.3 for ; Wed, 09 Dec 2009 20:27:16 -0800 (PST) Received: by 10.150.46.7 with SMTP id t7mr5050934ybt.118.1260419235983; Wed, 09 Dec 2009 20:27:15 -0800 (PST) Received: from ?67.188.59.148? (c-67-188-59-148.hsd1.ca.comcast.net [67.188.59.148]) by mx.google.com with ESMTPS id 15sm245477yxh.22.2009.12.09.20.27.14 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Dec 2009 20:27:14 -0800 (PST) Sender: Alex McMahon From: Alex McMahon To: Peter Lovell In-Reply-To: <20091210013028.2134662025@smtp.mac.com> References: <1260405186.4039.433.camel@sphere> <20091210013028.2134662025@smtp.mac.com> Content-Type: text/plain Organization: Trinity College Dublin Date: Wed, 09 Dec 2009 20:27:12 -0800 Message-Id: <1260419232.4039.728.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: dtn interest Subject: Re: [dtn-interest] fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 04:27:17 -0000 Hi Peter, > but I believe that it's there. I don't think it is (but it might be that I just can't find it), perhaps the part you are referring to is at the end of 4.2. which indicates the processing control flags setting if the record is administrative. However in this paragraph the part which refers to the "Bundle must not be fragmented" flag relates to when a bundle's source endpoint ID is "dtn:none" > > I can't imagine any scenario where fragmentation would make sense for a > custody signal. I agree, however a custody signal is only one type of administrative record. There might be a need to fragment other type of administrative records that have not yet been defined. > So although the field might be depicted, I don't think > that there's a way for it to actually be used. I agree, but even if it was fragmented these field would be in the primary block and not where depicted. The only reason I can see (assuming there is one) for fragmentation fields to exist as depicted in both Figure 10 and 13 is if the administrative record does not have a primary block.. > > Every bundle must have a primary. > If a bundle is fragmented, each > fragment becomes a new bundle ("fragment-bundle") and has a primary > block. Right, every bundle, but what if an administrative record was not a bundle. > So I don't understand your question here. There is nothing in 5050 (that I know of) that states that an administrative record is a bundle, it is only stated that it is a standard ADU that is used in providing some of the features of the Bundle Protocol. Also the example shown in figure 13 depicts an administrative record is not in the Canonical Bundle Block Format. It is stated in 5050 that if a bundle is an administrative record then it will indicate this in the primary block. >From this I gather that while an administrative record can be a bundle, it does not have to be. It could, for example, be an ADU, not transformed by BP into a bundle, that provides only some of the features of the Bundle Protocol and as such might not have a primary block.. Thanks Alex On Wed, 2009-12-09 at 20:30 -0500, Peter Lovell wrote: > On Wed, Dec 9, 2009, Alex McMahon wrote: > > >The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC > >5050 depicts an administrative record that includes the fragmentation > >fields (Fragment offset & Fragment length). However, as RFC 5050 also > >indicates that the processing control flag of the primary block of an > >administrative record is set to indicate the ADU is an administrative > >record. This implies that an administrative record has a primary block > >that includes the fragmentation fields (Fragment offset & Fragment > >length) if fragmented. > > > >Is there a scenario in which fragmentation offsets would be included in > >an administrative record ? > > > >Does this imply that a BPA should be capable of processing an > >administrative record without a primary block as well as a bundle that > >is an administrative record ? > > > >Thanks > > > >Alex > > > > Hi Alex, > > I think that there's a statement somewhere that says that an > administrative record can't be fragmented. I don't see it right now, but > I believe that it's there. > > I can't imagine any scenario where fragmentation would make sense for a > custody signal. So although the field might be depicted, I don't think > that there's a way for it to actually be used. > > >administrative record without a primary block > Every bundle must have a primary. If a bundle is fragmented, each > fragment becomes a new bundle ("fragment-bundle") and has a primary > block. So I don't understand your question here. > > Cheers.....Peter > Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBA1UuCw005089 for ; Wed, 9 Dec 2009 17:30:56 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.7] (pool-96-255-127-102.washdc.fios.verizon.net [96.255.127.102]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUE004C4XIS8D80@asmtp013.mac.com> for dtn-interest@mailman.dtnrg.org; Wed, 09 Dec 2009 17:30:31 -0800 (PST) From: Peter Lovell To: alex.mcmahon@cs.tcd.ie, dtn interest Date: Wed, 09 Dec 2009 20:30:28 -0500 Message-id: <20091210013028.2134662025@smtp.mac.com> In-reply-to: <1260405186.4039.433.camel@sphere> References: <1260405186.4039.433.camel@sphere> X-Mailer: CTM PowerMail version 6.0.3 build 4609 English (intel) Subject: Re: [dtn-interest] fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 01:30:56 -0000 On Wed, Dec 9, 2009, Alex McMahon wrote: >The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC >5050 depicts an administrative record that includes the fragmentation >fields (Fragment offset & Fragment length). However, as RFC 5050 also >indicates that the processing control flag of the primary block of an >administrative record is set to indicate the ADU is an administrative >record. This implies that an administrative record has a primary block >that includes the fragmentation fields (Fragment offset & Fragment >length) if fragmented. > >Is there a scenario in which fragmentation offsets would be included in >an administrative record ? > >Does this imply that a BPA should be capable of processing an >administrative record without a primary block as well as a bundle that >is an administrative record ? > >Thanks > >Alex > Hi Alex, I think that there's a statement somewhere that says that an administrative record can't be fragmented. I don't see it right now, but I believe that it's there. I can't imagine any scenario where fragmentation would make sense for a custody signal. So although the field might be depicted, I don't think that there's a way for it to actually be used. >administrative record without a primary block Every bundle must have a primary. If a bundle is fragmented, each fragment becomes a new bundle ("fragment-bundle") and has a primary block. So I don't understand your question here. Cheers.....Peter Received: from mail-yx0-f186.google.com (mail-yx0-f186.google.com [209.85.210.186]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBA0X9dW002357 for ; Wed, 9 Dec 2009 16:33:09 -0800 Received: by yxe16 with SMTP id 16so870450yxe.27 for ; Wed, 09 Dec 2009 16:33:09 -0800 (PST) Received: by 10.90.217.11 with SMTP id p11mr4627290agg.82.1260405189784; Wed, 09 Dec 2009 16:33:09 -0800 (PST) Received: from ?10.212.112.174? (bldmz-nat-161-164.berkeley.intel-research.net [12.155.161.164]) by mx.google.com with ESMTPS id 5sm170247yxd.17.2009.12.09.16.33.08 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Dec 2009 16:33:09 -0800 (PST) Sender: Alex McMahon From: Alex McMahon To: DTN Content-Type: text/plain Organization: Trinity College Dublin Date: Wed, 09 Dec 2009 16:33:06 -0800 Message-Id: <1260405186.4039.433.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [dtn-interest] fragmentation fields in administrative records X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 00:33:09 -0000 The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC 5050 depicts an administrative record that includes the fragmentation fields (Fragment offset & Fragment length). However, as RFC 5050 also indicates that the processing control flag of the primary block of an administrative record is set to indicate the ADU is an administrative record. This implies that an administrative record has a primary block that includes the fragmentation fields (Fragment offset & Fragment length) if fragmented. Is there a scenario in which fragmentation offsets would be included in an administrative record ? Does this imply that a BPA should be capable of processing an administrative record without a primary block as well as a bundle that is an administrative record ? Thanks Alex Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB9ND4eo030958 for ; Wed, 9 Dec 2009 15:13:04 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by smtp.jpl.nasa.gov (Switch-3.4.1/Switch-3.4.1) with ESMTP id nB9ND2cW007268 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Wed, 9 Dec 2009 15:13:04 -0800 Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.80]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Wed, 9 Dec 2009 15:13:03 -0800 From: "Burleigh, Scott C (313B)" To: "Ivancic, William D. (GRC-RHN0)" , DTN Date: Wed, 9 Dec 2009 15:13:01 -0800 Thread-Topic: Network Synchronization Requirements - some thoughts Thread-Index: Acp3hLOvO0lo6E1ASxC9HjHHcgtpDwBmr9PA Message-ID: References: <3A5AA67A8B120B48825BFFCF54438561945FE470B5@NDJSSCC03.ndc.nasa.gov> In-Reply-To: <3A5AA67A8B120B48825BFFCF54438561945FE470B5@NDJSSCC03.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nB9ND4eo030958 Subject: Re: [dtn-interest] Network Synchronization Requirements - some thoughts X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 23:13:04 -0000 > -----Original Message----- > From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn- > interest-bounces@maillists.intel-research.net] On Behalf Of Ivancic, > William D. (GRC-RHN0) > Sent: Monday, December 07, 2009 1:32 PM > To: DTN > Subject: [dtn-interest] Network Synchronization Requirements - some > thoughts > > I believe some of the discussion and disagreement on network > synchronization requirements may be due to the vast environments DTN may be > applied to. > > Once a system reaches steady state (and how that done is not addressed in > this email), I believe that the network probably has to be synchronized to > within some percentage of the shortest bundle lifetime that network will > have to handle. Whether that is 1%, 10% or 500% probably depends on the > network, the amount and length of disconnection and applications. > > Consider operating as the N4C group was in this summer's field exercise. > If the bundle lifetimes are many hours or days, the network probably only > requires synchronization to a hour or so (Assuming you will accept bundles > from the an hour or two into the future). > > Consider military environment where DTN is providing the network layer > rather than an overlay. DTN is being used to handle short-term fades and > disconnection as well as near-real time communications. In such an > environment, some bundles may have very short lifetimes - perhaps a few to > tens of seconds. If so, the network will have to be synchronized to > within a some fraction of this. This is an interesting point. The intent of the bundle lifetime is to clear undelivered bundles out of the network when they get "stuck" at some node for such a long time that the utility of delivering them to the final destination drops to zero. Bundles that do get delivered need not be purged. Bundles that have not yet gotten delivered but still have potential value to their intended recipients should not be purged. Bundles that are not "stuck" -- that is, they have been transmitted via some convergence-layer protocol (and possibly not received, depending on the reliability of that CL protocol) and are not retained for possible custodial retransmission -- cannot be purged. There may not be much left, and in fact during DINET we saw only a handful of bundles deleted due to lifetime expiration over a 4-week period. The only bundles for which the absence of highly accurate clock synchronization might marginally degrade DTN performance (by unnecessary occupation of non-volatile storage) would be those that lose all their value to users and applications in a matter of seconds -- the only reason for a short lifetime -- and are (a) stuck in a transmission queue longer than expected due to a routing failure or (b) transmitted, and important enough to merit custody transfer handling, but not yet acknowledged due to a convergence-layer protocol failure or routing failure. If your routing and/or CL protocols are flaky enough to make this sort of anomaly commonplace, you've probably got lots bigger fish to fry than sub-optimal non-volatile storage space utilization. Scott Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB8FvZlR005143 for ; Tue, 8 Dec 2009 07:57:35 -0800 Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 832A72604A6 for ; Tue, 8 Dec 2009 09:57:35 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB8FvZ2d026203 for ; Tue, 8 Dec 2009 09:57:35 -0600 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 8 Dec 2009 09:57:35 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: DTN Date: Tue, 8 Dec 2009 09:57:05 -0600 Thread-Topic: Network Synchronization Requirements - some thoughts Thread-Index: Acp3hLOvO0lo6E1ASxC9HjHHcgtpDw== Message-ID: <3A5AA67A8B120B48825BFFCF54438561945FE472FB@NDJSSCC03.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-08_08:2009-11-30, 2009-12-08, 2009-12-08 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nB8FvZlR005143 Subject: [dtn-interest] Network Synchronization Requirements - some thoughts X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 15:57:36 -0000 I believe some of the discussion and disagreement on network synchronization requirements may be due to the vast environments DTN may be applied to. Once a system reaches steady state (and how that done is not addressed in this email), I believe that the network probably has to be synchronized to within some percentage of the shortest bundle lifetime that network will have to handle. Whether that is 1%, 10% or 500% probably depends on the network, the amount and length of disconnection and applications. Consider operating as the N4C group was in this summer's field exercise. If the bundle lifetimes are many hours or days, the network probably only requires synchronization to a hour or so (Assuming you will accept bundles from the an hour or two into the future). Consider military environment where DTN is providing the network layer rather than an overlay. DTN is being used to handle short-term fades and disconnection as well as near-real time communications. In such an environment, some bundles may have very short lifetimes - perhaps a few to tens of seconds. If so, the network will have to be synchronized to within a some fraction of this. Networks with scheduled connectivity have to have some sort of clock. Deep Space networks are one such example. In this case bundle lifetimes are probably much longer than the synchronization requirements for pointing antennas, turning on transmitters and other such lower layer functions. If one has a closed network, one probably has some reasonable idea of the expected minimum lifetime of a bundle. However, if the DTN is open, estimating the expected minimum lifetime of a bundle is problematic and thus, so are the network synchronization requirements. --Will Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB8FomHf004855 for ; Tue, 8 Dec 2009 07:50:48 -0800 Received: from [10.0.0.120] (adsl-71-141-248-21.dsl.snfc21.pacbell.net [71.141.248.21]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nB8FolO7006400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 8 Dec 2009 07:50:48 -0800 (PST) From: Kevin Fall Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 8 Dec 2009 07:50:46 -0800 Message-Id: <4FEC5A4B-4DE3-4D03-903D-2C19C4838689@cs.berkeley.edu> To: DTN Interest List Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [dtn-interest] test e-mail -- please ignore X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 15:50:48 -0000 we have been having some mailing list server issues... Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB8FbctS004250 for ; Tue, 8 Dec 2009 07:37:39 -0800 Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 013B82D8304 for ; Tue, 8 Dec 2009 09:37:38 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB8Fbbo7022014 for ; Tue, 8 Dec 2009 09:37:38 -0600 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Tue, 8 Dec 2009 09:37:38 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: DTN Date: Tue, 8 Dec 2009 09:36:29 -0600 Thread-Topic: Test Message Thread-Index: Acp4HCpLoJY5ITRMS86+H/AQ5eU2cg== Message-ID: <3A5AA67A8B120B48825BFFCF54438561945FE472B3@NDJSSCC03.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AzeZ B3KC CxCg DOio EOEG ErL8 F7BG GoYS HEWr Hop5 IeSw JaYx Lx1P MDjZ MSO+ MwIU; 1; ZAB0AG4ALQBpAG4AdABlAHIAZQBzAHQAQABtAGEAaQBsAG0AYQBuAC4AZAB0AG4AcgBnAC4AbwByAGcA; Sosha1_v1; 7; {C76943B1-99C5-4B87-B874-BA84CD90871C}; dwBpAGwAbABpAGEAbQAuAGQALgBpAHYAYQBuAGMAaQBjAEAAbgBhAHMAYQAuAGcAbwB2AA==; Tue, 08 Dec 2009 15:36:29 GMT;VABlAHMAdAAgAE0AZQBzAHMAYQBnAGUA x-cr-puzzleid: {C76943B1-99C5-4B87-B874-BA84CD90871C} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-08_08:2009-11-30, 2009-12-08, 2009-12-08 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nB8FbctS004250 Subject: [dtn-interest] Test Message X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 15:37:39 -0000 This is a test message as test the mail list server as it appears to have been down. -- Will Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB8EvpYS002304 for ; Tue, 8 Dec 2009 06:57:51 -0800 Received: from mail104-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 8.1.240.5; Tue, 8 Dec 2009 14:57:50 +0000 Received: from mail104-va3 (localhost.localdomain [127.0.0.1]) by mail104-va3-R.bigfish.com (Postfix) with ESMTP id 763581438438 for ; Tue, 8 Dec 2009 14:57:50 +0000 (UTC) X-SpamScore: 7 X-BigFish: VPS7(zzzz1202hzzz2dh6bh87h68o) X-Spam-TCS-SCL: 7:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail104-va3 (localhost.localdomain [127.0.0.1]) by mail104-va3 (MessageSwitch) id 1260284267999697_2832; Tue, 8 Dec 2009 14:57:47 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.247]) by mail104-va3.bigfish.com (Postfix) with ESMTP id 4EDC1A2806C for ; Tue, 8 Dec 2009 14:57:47 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server id 14.0.482.32; Tue, 8 Dec 2009 14:57:44 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 03CC868002 for ; Tue, 8 Dec 2009 14:57:44 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A02BB200164; Tue, 08 Dec 2009 14:57:44 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id E618668002 for ; Tue, 8 Dec 2009 14:57:43 +0000 (GMT) Message-ID: <4B1E6970.2090002@cs.tcd.ie> Date: Tue, 8 Dec 2009 14:57:52 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: DTN X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A12BB200164 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.115.3) X-Reverse-DNS: imx2.tcd.ie Subject: [dtn-interest] test ignore X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 14:57:52 -0000 see the subject line Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB8ETONm000948 for ; Tue, 8 Dec 2009 06:29:24 -0800 Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 37ED332833D for ; Tue, 8 Dec 2009 08:29:24 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB8ETOZw009177 for ; Tue, 8 Dec 2009 08:29:24 -0600 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 8 Dec 2009 08:29:24 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: DTN Date: Tue, 8 Dec 2009 08:28:54 -0600 Thread-Topic: Network Synchronization Requirements - some thoughts Thread-Index: Acp3hLOvO0lo6E1ASxC9HjHHcgtpDw== Message-ID: <3A5AA67A8B120B48825BFFCF54438561945FE4721C@NDJSSCC03.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-08_08:2009-11-30, 2009-12-08, 2009-12-08 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nB8ETONm000948 Subject: [dtn-interest] Network Synchronization Requirements - some thoughts X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 14:29:25 -0000 I believe some of the discussion and disagreement on network synchronization requirements may be due to the vast environments DTN may be applied to. Once a system reaches steady state (and how that done is not addressed in this email), I believe that the network probably has to be synchronized to within some percentage of the shortest bundle lifetime that network will have to handle. Whether that is 1%, 10% or 500% probably depends on the network, the amount and length of disconnection and applications. Consider operating as the N4C group was in this summer's field exercise. If the bundle lifetimes are many hours or days, the network probably only requires synchronization to a hour or so (Assuming you will accept bundles from the an hour or two into the future). Consider military environment where DTN is providing the network layer rather than an overlay. DTN is being used to handle short-term fades and disconnection as well as near-real time communications. In such an environment, some bundles may have very short lifetimes - perhaps a few to tens of seconds. If so, the network will have to be synchronized to within a some fraction of this. Networks with scheduled connectivity have to have some sort of clock. Deep Space networks are one such example. In this case bundle lifetimes are probably much longer than the synchronization requirements for pointing antennas, turning on transmitters and other such lower layer functions. If one has a closed network, one probably has some reasonable idea of the expected minimum lifetime of a bundle. However, if the DTN is open, estimating the expected minimum lifetime of a bundle is problematic and thus, so are the network synchronization requirements. --Will (This is a resend. I did not see it show up after I sent it yesterday.) Received: from avas-univ-1.cineca.it (avas-univ-1.cineca.com [130.186.81.104]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB8E8D0v032483 for ; Tue, 8 Dec 2009 06:08:14 -0800 X-IronPort-AV: E=McAfee;i="5300,2777,5825"; a="43513595" Received: from unibo.mm.cineca.it ([130.186.10.202]) by avas-univ-1.cineca.it with ESMTP; 08 Dec 2009 15:08:14 +0100 Received: from localhost (unibo.mm.cineca.it [130.186.10.202]) as user anonymous by unibo.mm.cineca.it (Postfix) with ESMTP id 4F638189D8D1 for ; Tue, 8 Dec 2009 15:08:13 +0100 (MET) Received: from 78.86.206.139 ( [78.86.206.139]) as user piero.cornice@studio.unibo.it@posta.studio.unibo.it by posta.studio.unibo.it with HTTP; Tue, 8 Dec 2009 15:08:13 +0100 Message-ID: <1260281293.4b1e5dcd40dc8@posta.studio.unibo.it> Date: Tue, 8 Dec 2009 15:08:13 +0100 From: Piero Cornice To: dtn-interest@maillists.intel-research.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 78.86.206.139 Subject: [dtn-interest] DTN2 on Maemo X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 14:08:15 -0000 The research team of Prof. Carlo Caini (DEIS, University of Bologna, Italy) have successfully installed DTN2 on a Nokia N900 with Maemo 5. A first set of transfers has been carried out with the new DTNPerf 2.5 and other tests will follow in the next days. More details will be available soon on the DEIS website. Kind regards, Piero Cornice Received: from avas-univ-1.cineca.it (avas-univ-1.cineca.com [130.186.81.104]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB881jVw014935 for ; Tue, 8 Dec 2009 00:01:46 -0800 X-IronPort-AV: E=McAfee;i="5300,2777,5825"; a="43481330" Received: from unibo.mm.cineca.it ([130.186.10.202]) by avas-univ-1.cineca.it with ESMTP; 08 Dec 2009 09:01:44 +0100 Received: from Melania.local (62-31-234-193.cable.ubr12.aztw.blueyonder.co.uk [62.31.234.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) as user piero.cornice@studio.unibo.it by unibo.mm.cineca.it (Postfix) with ESMTP id 7829C2642D8F for ; Tue, 8 Dec 2009 09:01:43 +0100 (MET) Message-ID: <4B1E07C8.30905@studio.unibo.it> Date: Tue, 08 Dec 2009 08:01:12 +0000 From: Piero Cornice User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: dtn-interest@maillists.intel-research.net X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [dtn-interest] DTN2 on Maemo X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 08:01:46 -0000 The research team of Prof. Carlo Caini (DEIS, University of Bologna, Italy) have successfully installed DTN2 on a Nokia N900 with Maemo 5. A first set of transfers has been carried out with the new DTNPerf 2.5 and other tests will follow in the next days. More details will be available soon on the DEIS website. Kind regards, Piero Cornice Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB7LZp2Q018339 for ; Mon, 7 Dec 2009 13:35:51 -0800 Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id EE814A83A0 for ; Mon, 7 Dec 2009 15:36:20 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB7LZc7N024527 for ; Mon, 7 Dec 2009 15:36:20 -0600 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Mon, 7 Dec 2009 15:32:23 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: DTN Date: Mon, 7 Dec 2009 15:31:56 -0600 Thread-Topic: Network Synchronization Requirements - some thoughts Thread-Index: Acp3hLOvO0lo6E1ASxC9HjHHcgtpDw== Message-ID: <3A5AA67A8B120B48825BFFCF54438561945FE470B5@NDJSSCC03.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-07_10:2009-11-30, 2009-12-07, 2009-12-07 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nB7LZp2Q018339 Subject: [dtn-interest] Network Synchronization Requirements - some thoughts X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 21:35:51 -0000 I believe some of the discussion and disagreement on network synchronization requirements may be due to the vast environments DTN may be applied to. Once a system reaches steady state (and how that done is not addressed in this email), I believe that the network probably has to be synchronized to within some percentage of the shortest bundle lifetime that network will have to handle. Whether that is 1%, 10% or 500% probably depends on the network, the amount and length of disconnection and applications. Consider operating as the N4C group was in this summer's field exercise. If the bundle lifetimes are many hours or days, the network probably only requires synchronization to a hour or so (Assuming you will accept bundles from the an hour or two into the future). Consider military environment where DTN is providing the network layer rather than an overlay. DTN is being used to handle short-term fades and disconnection as well as near-real time communications. In such an environment, some bundles may have very short lifetimes - perhaps a few to tens of seconds. If so, the network will have to be synchronized to within a some fraction of this. Networks with scheduled connectivity have to have some sort of clock. Deep Space networks are one such example. In this case bundle lifetimes are probably much longer than the synchronization requirements for pointing antennas, turning on transmitters and other such lower layer functions. If one has a closed network, one probably has some reasonable idea of the expected minimum lifetime of a bundle. However, if the DTN is open, estimating the expected minimum lifetime of a bundle is problematic and thus, so are the network synchronization requirements. --Will Received: from smtp.iit.cnr.it (mx7.iit.cnr.it [146.48.98.140]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB4DnLjx030193 for ; Fri, 4 Dec 2009 05:49:24 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id F309A12EDC4 for ; Fri, 4 Dec 2009 14:49:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx7.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx7.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBLhHUly272P for ; Fri, 4 Dec 2009 14:49:27 +0100 (CET) Received: from [146.48.98.167] (perlab-pc1.iit.cnr.it [146.48.98.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id A7FEE12EDA2 for ; Fri, 4 Dec 2009 14:49:27 +0100 (CET) Message-ID: <4B19136A.4070007@iit.cnr.it> Date: Fri, 04 Dec 2009 14:49:30 +0100 From: Emilio Ancillotti User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: dtn-interest@maillists.intel-research.net Content-Type: multipart/alternative; boundary="------------050600000700060403040701" Subject: [dtn-interest] Call for Extended Abstracts PhD Forum ACM/SIGMOBILE MobiOpp 2010 X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:49:25 -0000 This is a multi-part message in MIME format. --------------050600000700060403040701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ******************************************************************************* Our Sincere apologies if you receive multiple copies of this Call The Second International Workshop on Mobile Opportunistic Networking ACM/SIGMOBILE MobiOpp 2010, February 22-23, 2010, PISA ITALY http://cnd.iit.cnr.it/mobiopp2010/ *Call for Extended Abstracts* *PhD Forum* The first PhD Forum on Opportunistic Networking will be hosted at Second International Workshop on Mobile Opportunistic Networking (MobiOpp2010). Doctoral students working in areas related to opportunistic networking and computing are solicited to submit an extended abstract comprising a summary of their research findings, work in progress and planned research. The forum will be a platform for PhD students to interact both with their peers as well as experienced researchers from industry. The forum will be organized as a poster session preceded by a '1-minute madness' introduction by each student. Current Ph.D. students, as well as researchers who have completed their Ph.D. dissertations since May 2009, are encouraged to submit extended abstracts. The Ph.D. student should be the sole author, although contributions of the advisor and others may be acknowledged in the extended abstract. Submissions will be reviewed to ensure quality and relevance. Authors of accepted submissions are expected to travel to MobiOpp 2010 to present their poster at the PhD Forum. The best presentation at the Forum, will receive an award sponsored by Elsevier Publications and there is likely to be travel assistance for some students. Accepted extended abstracts will appear in conference proceedings. * Extended Abstract Submission*: Ph.D. students are invited to submit two-page extended abstracts that describe current research and potential contributions to theory and innovation in pervasive computing and communications. Submissions must be received by no later than December 7, 2009. Extended abstracts should include the author's name, affiliation, and email address. Submissions must be PDF files and be written in English. Submissions should adhere to the ACM format and be no more than two pages in length (all inclusive). Papers must be submitted via email to mobiopp-PhD@iit.cnr.it. *Important Dates* Extended abstract submission deadline: December 7, 2009 Notification of acceptance: January 10, 2010 Camera-ready paper due: January 22, 2010 MobiOpp: February 22-23, 2010 *PhD Forum Co-Chairs* Silvia Giordano, SUPSI, Switzerland Mohan Kumar, The University of Texas at Arlington *Corporate Sponsor TBD* -- ============================================================ Ing. Emilio Ancillotti, PhD Pervasive Computing & Networking Lab. (PerLab) Institute for Informatics and Telematics (IIT) National Research Council (CNR) Via G. Moruzzi, 1 || voice: +39 050 315 2437 56124 Pisa, Italy || fax: +39 050 315 2113 || mobile: +39 328 2963760 ============================================================ --------------050600000700060403040701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit *******************************************************************************
Our Sincere apologies if you receive multiple copies of this Call
 
     The Second International Workshop on Mobile Opportunistic Networking
          ACM/SIGMOBILE MobiOpp 2010, February 22-23, 2010, PISA ITALY
                      http://cnd.iit.cnr.it/mobiopp2010/
                         Call for Extended Abstracts
                                  PhD Forum

The first PhD Forum on Opportunistic Networking will be hosted at Second
International Workshop on Mobile Opportunistic Networking (MobiOpp2010). 
Doctoral students working in areas related to opportunistic networking and
computing are solicited to submit an extended abstract comprising a summary of
their research findings, work in progress and planned research. The forum will
be a platform for PhD students to interact both with their peers as well as
experienced researchers from industry. The forum will be organized as a poster
session preceded by a '1-minute madness' introduction by each student.

Current Ph.D. students, as well as researchers who have completed their Ph.D.
dissertations since May 2009, are encouraged to submit extended abstracts. The
Ph.D. student should be the sole author, although contributions of the advisor
and others may be acknowledged in the extended abstract. Submissions will be
reviewed to ensure quality and relevance. Authors of accepted submissions are
expected to travel to MobiOpp 2010 to present their poster at the PhD Forum.
The best presentation at the Forum, will receive an award sponsored by Elsevier
Publications and there is likely to be travel assistance for some students.
Accepted extended abstracts will appear in conference proceedings.

Extended Abstract Submission
: Ph.D. students are invited to submit two-page
extended abstracts that describe current research and potential contributions
to theory and innovation in pervasive computing and communications. Submissions
must be received by no later than December 7, 2009. Extended abstracts should
include the author's name, affiliation, and email address. Submissions must be
PDF files and be written in English. Submissions should adhere to the ACM
format and be no more than two pages in length (all inclusive).
Papers must be submitted via email to mobiopp-PhD@iit.cnr.it.

Important Dates
Extended abstract submission deadline: December 7, 2009
Notification of acceptance: January 10, 2010
Camera-ready paper due: January 22, 2010
MobiOpp: February 22-23, 2010

PhD Forum Co-Chairs
Silvia Giordano, SUPSI, Switzerland
Mohan Kumar, The University of Texas at Arlington
Corporate Sponsor    TBD

-- 
============================================================
Ing. Emilio Ancillotti, PhD
   Pervasive Computing & Networking Lab. (PerLab)
   Institute for Informatics and Telematics (IIT)
   National Research Council (CNR)
      Via G. Moruzzi, 1    ||    voice:    +39 050 315 2437
      56124 Pisa, Italy    ||    fax:    +39 050 315 2113
                           ||    mobile:    +39 328 2963760
============================================================

--------------050600000700060403040701-- Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB3HHPbk007737 for ; Thu, 3 Dec 2009 09:17:26 -0800 Received: by fxm8 with SMTP id 8so398170fxm.27 for ; Thu, 03 Dec 2009 09:17:34 -0800 (PST) MIME-Version: 1.0 Sender: pablo.serrano@gmail.com Received: by 10.239.144.79 with SMTP id n15mr172092hba.107.1259860654547; Thu, 03 Dec 2009 09:17:34 -0800 (PST) In-Reply-To: <41f944e70912030913o2e231536n33fbfa860e32261a@mail.gmail.com> References: <41f944e70912030842g7c9d712aj63a2fcc8c03be3fa@mail.gmail.com> <41f944e70912030842w16eec7e4xea03962a8260d86d@mail.gmail.com> <41f944e70912030842m405ba1edme91df0c12e799435@mail.gmail.com> <41f944e70912030843x79e62061n9bf4a43a7c99dfd4@mail.gmail.com> <41f944e70912030843r7fd24820h8373df4b75a077c5@mail.gmail.com> <41f944e70912030853g40e6e1c9t5e91f04c08b959d2@mail.gmail.com> <41f944e70912030856x3ef00791q97cf604f8694c068@mail.gmail.com> <41f944e70912030913o2e231536n33fbfa860e32261a@mail.gmail.com> From: Pablo Serrano Date: Thu, 3 Dec 2009 18:17:14 +0100 X-Google-Sender-Auth: 93ad1812fbf41699 Message-ID: <41f944e70912030917l2b55ac9djed0f01dbf10243a2@mail.gmail.com> To: dtn-interest@mailman.dtnrg.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nB3HHPbk007737 Subject: [dtn-interest] CFP: 2nd IEEE WoWMoM Workshop on Hot Topics in Mesh Networking (HotMESH 2010) X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:17:27 -0000 [Please accept our apologies if you receive multiple copies of this CFP.] ---------------------------------------------------------------------- The Second IEEE WoWMoM Workshop on Hot Topics in  Mesh Networking (HotMESH 2010) http://cnd.iit.cnr.it/mesh2010/ Montreal, Canada June 14, 2010 In conjunction with the 11th IEEE International Symposium on a "World of Wireless, Mobile and Multimedia Networks" (WoWMoM’10) http://wowmom2010.netgroup.uniroma2.it/ ---------------------------------------------------------------------- THEME AND SCOPE The huge advances of wireless broadband technologies lay the foundation of a future where ubiquitous wireless network access will be anywhere at anytime. Wireless mesh networks are expected to be a key element of this future by providing a highly scalable, reliable and cost-effective wireless backbone to mobile devices a multi-hop wireless communication system. However, there are still a lot of technical challenges that need to be solved in order to reach the full potentialities of this innovative technology. This workshop aims to bring together the technologist and researchers who share interest in the area of wireless mesh networks. The main purpose is to promote discussions on recent advances in the analysis design and implementation of systems, protocols and services for next generation mobile mesh networks. It also aims at increasing the synergy between academic and industry professionals working in this area. We plan to seek papers that address theoretical, experimental, and work in-progress at all layers of mesh networks, from application to physical layer. Topics of interest include, but are not limited to:        Cross layer design and optimizations        Capacity analysis        Greening the Internet        Multi-radio and multi-channel wireless mesh networking        Medium access control protocols        Self-configuration and self-management procedures        Routing, scheduling, and channel assignment protocols        Mesh networks measurement        QoS provisioning        Mobility management        Topology construction and maintenance        Security architectures, functions and protocols        Privacy enhancing technologies for mesh networks        Testbed, prototype, and practical systems PAPER SUBMISSIONS Authors should prepare a PDF file following the IEEE 8.5x11 conference format in accordance with the IEEE Computer Society author guidelines (http://www.computer.org/portal/web/cscps/formatting). Manuscripts should not exceed six (6) pages in size including all text, figures, tables, and references. Papers significantly exceeding this limit will be automatically rejected. Attendance to the workshop will require a Full Registration to the main conference. Accepted papers will be published by the IEEE Computer Society Press in the combined WoWMoM 2010 workshop proceedings. Accepted papers not presented at the workshop will not be included in the IEEE Digital Library. IMPORTANT DATES Submission due:                  February 5, 2010 Acceptance notification:           March 25, 2010 Final manuscript due:              April 10, 2010 Workshop:                           June 14, 2010 WORKSHOP CO-CHAIRS Albert Banchs, Univ. Carlos III de Madrid, Spain Raffaele Bruno, IIT-CNR, Italy PUBLICITY CHAIR Pablo Serrano, Univ. Carlos III de Madrid, Spain PROGRAM COMMITTEE TBA Received: from web24507.mail.ird.yahoo.com (web24507.mail.ird.yahoo.com [87.248.114.234]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id nB1LqRXs020954 for ; Tue, 1 Dec 2009 13:52:28 -0800 Received: (qmail 15992 invoked by uid 60001); 1 Dec 2009 21:52:28 -0000 Message-ID: <128935.15350.qm@web24507.mail.ird.yahoo.com> X-YMail-OSG: sJk_Hb0VM1l1TpqPeb34rhPQmb2HlIKhnSOjT274tbxEO1v5q.xoOLhnARUrCUcYJI.Dg152d0J39soybpxWw15l5F.BNjb6amAMEGZ0s1up_cZ9kJ_jhulKilw1GC75FJgSD0zPalKEyH02.fescfNIqnR1I5J8vmK8q3e_phCSQLTR0Uy9OdrZoBFbT53V5jZdTIRDzvCYsqJLk7XVJ.kzPL8X_atz3VGf6Iuf3AwtVX6eEOk3lttu3U3Vq3Fi37BMhzABoQzShPaidFxo3DWLbNUaORUFktekcyRxP5ovVLteZ.idQL4zgjcze00Bv.DQbaR_K2pUIQ-- Received: from [86.25.186.213] by web24507.mail.ird.yahoo.com via HTTP; Tue, 01 Dec 2009 13:52:28 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 Date: Tue, 1 Dec 2009 13:52:28 -0800 (PST) From: Scott Fowler To: dtn-interest@maillists.intel-research.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-775492143-1259704348=:15350" Subject: [dtn-interest] CFP:Symposium on Smart Homes (SH-10) X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 21:52:28 -0000 --0-775492143-1259704348=:15350 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable SH 2010 Call for Papers=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AThe Fifth International Symposium on Sm= art Home=0AIn Conjunction with FutureTech 2010. May 21-23, 2010. Busan, Kor= ea=0Ahttp://www.ftrg.org/sh2010/index.php=0A=0A=0ASmart Home Environments (= SHEs) are emerging rapidly as an exciting new paradigm including ubiquitous= , grid, and peer-to-peer computing to provide computing and communication s= ervices any time and anywhere. To full realize the advantages of the paradi= gm, we require a host of suitable security services and their applications.= They will offer the user remote access to all information about appliances= in the workplace as well as at home, and help easily and conveniently use = various services to enable working from home, and facilitate remote educati= on, remote diagnosis, virtual shopping, network gaming, and portal & high q= uality VOD with no limitations on space and time. SH-2010 is intended to fo= ster the dissemination of state-of-the-art research in the area of SHE incl= uding business models, security services, and novel applications associated= with its utilization. As a follow-up of the symposium, we plan to publish = high quality papers, covering the various theories and practical applications related to smart home. The published p= apers are expected to present the high level results to solve the applicati= on services and various problems in the various SH fields. In addition, we = expect they will trigger further related research and technological improve= ments of the SH. The goal of the SH-2010 is to bring together the researche= rs from academia and industry as well as practitioners to share ideas, prob= lems and solutions relating to the multifaceted aspects of Information Tech= nology. =0A=0AWe invite new and original submissions addressing theoretical= and practical topics in information technology and intelligent computing f= ields including (but not limited to these topics): =0A=0ASH Applications=0A= =0A- Smart home (Building) applications and services=0A- Smart home network= middleware and protocols Mobile / Wearable intelligence=0A- Commercial and= industrial application for SH=0A- Mobile / Wearable intelligence=0A- Frame= works for integrating AI and data mining=0A- Context awareness model for sm= art home services=0A- Wireless sensor networks (WSN) / RFID application for= SH=0A=0A=0ASH Security=0A=0A- Multimedia Security and Services in SH=0A- S= mart home security issues and model=0A- Access control and privacy protecti= on in SH=0A- Forensics and Security Policy in SH=0A- WSN/ RFID Security in = SH=0A- Security Protocol for smart home service=0A=0A SH Embedded Hardware = and Software=0A=0A- Embedded Hardware Support for SH=0A- Embedded Software = for SH=0A- Embedded System Architecture for SH=0A- Real-time OS for SH=0A- = Smart and Personal Devices for SH=0A- Power-Aware Computing for SH=0A- Midd= leware for SH=0A- Specification, Validation and Verification of Embedded So= ftware=0A- Computational Models=0A=0A=0ASubmission Guidelines=0A=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A= Submitted papers must be unpublished and not considered elsewhere for publi= cation.Only electronic submissions in PDF format will be considered. Papers= must be 8 pages or less in size, including references, figures and tables = (at least 10pt font, 2-column format). The IEEE LaTeX and Microsoft Word te= mplates, as well as information for formatting the manuscript can be found = at http://www2.computer.org/portal/web/cscps/formatting. Papers will be rig= orously reviewed by the international technical program committee. All acce= pted papers will be included in the FutureTech-10 Workshop Proceeding publ= ished by IEEE. (The proceeding will be included in EI and other index). Fin= al author manuscripts will be 8.5" x 11" (two columns IEEE format), not exc= eeding 8 pages; ( 2 extra pages will be allowed at additional cost only for= camera ready papers). =0A=0AAll paper submissions will be handled electro= nically. The submission process is described on the Submission Page at http= ://www.editorialsystem.net/sh2010/=0A=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0ASpecial Issue Internatio= nal Journal Publication=0A=0AExtended versions of best papers of the Sympos= ium will be considered for publication in a Special issue of an Internation= al journal planned shortly after the event.=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0AImportant Da= tes=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=0APaper Submission: January 31, 2010 =0AAcceptance Notification: = March 5, 2010 =0ACamera-Ready Version: March 15, 2010 =0ASymposium Date: M= ay 21-23, 2010 =0A=0A=0A --0-775492143-1259704348=:15350 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
SH 2010 Call for Papers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The Fifth Internati= onal Symposium on Smart Home
In Conjunction with FutureTech 2010. May 21= -23, 2010. Busan, Korea
http://www.ftrg.org/sh2010/index.php

Smart Home Environments (SHEs) are emerging rapidly as an exciting= new paradigm including ubiquitous, grid, and peer-to-peer computing to pro= vide computing and communication services any time and anywhere. To full re= alize the advantages of the paradigm, we require a host of suitable securit= y services and their applications. They will offer the user remote access t= o all information about appliances in the workplace as well as at home, and= help easily and conveniently use various services to enable working from home, and facilitate remote education, remote diagnosi= s, virtual shopping, network gaming, and portal & high quality VOD with= no limitations on space and time. SH-2010 is intended to foster the dissem= ination of state-of-the-art research in the area of SHE including business = models, security services, and novel applications associated with its utili= zation. As a follow-up of the symposium, we plan to publish high quality pa= pers, covering the various theories and practical applications related to s= mart home. The published papers are expected to present the high level resu= lts to solve the application services and various problems in the various S= H fields. In addition, we expect they will trigger further related research= and technological improvements of the SH. The goal of the SH-2010 is to br= ing together the researchers from academia and industry as well as practiti= oners to share ideas, problems and solutions relating to the multifaceted aspects of Information Technology.

We invite new and = original submissions addressing theoretical and practical topics in informa= tion technology and intelligent computing fields including (but not limited= to these topics):

SH Applications

- Smart home (Building) a= pplications and services
- Smart home network middleware and protocols M= obile / Wearable intelligence
- Commercial and industrial application fo= r SH
- Mobile / Wearable intelligence
- Frameworks for integrating AI= and data mining
- Context awareness model for smart home services
- = Wireless sensor networks (WSN) / RFID application for SH


SH Secu= rity

- Multimedia Security and Services in SH
- Smart home securi= ty issues and model
- Access control and privacy protection in SH
- F= orensics and Security Policy in SH
- WSN/ RFID Security in SH
- Secur= ity Protocol for smart home service

 SH Embedded Hardware and Software

- Embedded Hardware Support for SH
- Embed= ded Software for SH
- Embedded System Architecture for SH
- Real-time= OS for SH
- Smart and Personal Devices for SH
- Power-Aware Computin= g for SH
- Middleware for SH
- Specification, Validation and Verifica= tion of Embedded Software
- Computational Models


Submission G= uidelines
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

Submitted papers must be unpublished and no= t considered elsewhere for publication.Only electronic submissions in PDF f= ormat will be considered. Papers must be 8 pages or less in size, including= references, figures and tables (at least 10pt font, 2-column format). The = IEEE LaTeX and Microsoft Word templates, as well as information for formatt= ing the manuscript can be found at http://www2.computer.org/portal/= web/cscps/formatting. Papers will be rigorously reviewed by the international technical program committee. All accepted pa= pers will be included in the FutureTech-10  Workshop Proceeding publis= hed by IEEE. (The proceeding will be included in EI and other index). Final= author manuscripts will be 8.5" x 11" (two columns IEEE format), not excee= ding 8 pages; ( 2 extra pages will be allowed at additional cost only for c= amera ready papers). 

All paper submissions will = be handled electronically. The submission process is described on the Submi= ssion Page at http://www.editorialsystem.net/sh2010/


=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DSpecial Issue International Journal Publication

Extended versions o= f best papers of the Symposium will be considered for publication in a Spec= ial issue of an International journal planned shortly after the event.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D


Important Dates
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Paper Submission:= January 31, 2010
Acceptance Notification: March 5, 2010
Camera-Rea= dy Version: March 15, 2010 
Symposium Date: May 21-23, 2010

=0A=0A

=0A=0A=0A=0A --0-775492143-1259704348=:15350--