From nobody Wed Mar 12 07:36:07 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815B41A0731 for ; Wed, 12 Mar 2014 07:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTya5omfkcOI for ; Wed, 12 Mar 2014 07:36:00 -0700 (PDT) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 820731A0838 for ; Wed, 12 Mar 2014 07:35:59 -0700 (PDT) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge02.dlr.de (172.21.163.101) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 12 Mar 2014 15:35:30 +0100 Received: from DLREXMBX01.intra.dlr.de ([fe80::d198:77e5:d411:fccd]) by dlrexhub01.intra.dlr.de ([::1]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 15:35:30 +0100 From: To: Thread-Topic: CFP IEEE Globecom 2014 - Satellite and Space Communications (SSC) track Thread-Index: Ac89/vctaBWokiQ3SGSGykk69VKeyg== Date: Wed, 12 Mar 2014 14:35:30 +0000 Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC317020D2A@DLREXMBX01.intra.dlr.de> Accept-Language: it-IT, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1A39DCC13AF3C14B83CD74124D4DCFC317020D2ADLREXMBX01intra_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/jhrNWQBzTGWptp3JFdTDg_9sDCc Subject: [dtn-interest] CFP IEEE Globecom 2014 - Satellite and Space Communications (SSC) track X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 14:36:05 -0000 --_000_1A39DCC13AF3C14B83CD74124D4DCFC317020D2ADLREXMBX01intra_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleagues, Please find below the call for papers for Satellite and Space Communication= s track in Globecom 2014, held in Austin, Texas, USA, on December, 8-12, 20= 14. I apologize if you receive multiple copies of this announcement. As DTN and satellite/space environments are closely related, I think this C= FP can be of interest for most of you. ***************************************************************************= ******** CALL FOR PAPERS IEEE Globecom 2014 http://www.ieee-globecom.org/ Dec 8-12, 2014 - Austin, Texas, USA ***************************************************************************= ******** The recent advances of satellite communication technology have witnessed an= unprecedented increase of services possibly distributed according to anywh= ere-anytime paradigm. To this regard, the appearance of new standards and t= he simultaneous integration with terrestrial infrastructure has introduced = new technical challenges to be faced by the scientific community. The Satellite and Space Communications track solicits original and unpublis= hed work not currently under review by any other conference or journal. The= focus of this track is on exploring and discussing new technical breakthro= ughs and applications focusing on all aspects of satellite and space commun= ications. MAIN TOPICS of INTEREST * Satellite and space communications and networking * Near-Earth satellite communications * Antennas for Satellite Communications * MIMO satellite communications * Hybrid satellite/terrestrial networks * Coding, modulation and synchronization schemes for satellite communicatio= ns * Channel models for satellite communications * Reliable multicast protocols for satellite networks * Transport protocol performance over satellite * Game theory applications in satellite networks * Security, privacy, and trust in satellite networks * Radio resource management in satellite networks * Emerging standards: DVB-SX, DVB-SH, DVB-RCS2, IP over Satellite * Cognitive satellite networks * Delay Tolerant Networking for satellite networks * Cross-layer air interface design * On-board switching and processing technologies * QoS and performance for satellite networks * Fade mitigation techniques over satellite channels * Special protocols for nano-satellites * Nano-satellites communications * Nano-Satellite constellation design * M2M over satellite applications * Geographic information systems * Wireless positioning technologies and applications * Signal detection and estimation for satellite communications * RF engineering for satellite communications * Statistical and adaptive signal processing for satellite systems * Satellite-based disaster recovery * Satellite-based remote e-Health * Satellite based alarm systems * Satellite-based solutions for aeronautical applications * Interplanetary communications * Next-generation channel coding for deep-space communications Sponsoring Technical Committees: * Satellite and Space Communications (SSC) HOW TO SUBMIT A PAPER The submissions will be handled electronically at https://edas.info/newPape= r.php?c=3D16651 The IEEE Globecom 2014 website provides full instructions on the paper form= atting: http://www.ieee-globecom.org/2014/submguide.html#.UyBwE4Uz3oY IMPORTANT DATE Paper submission due APRIL 1, 2014 (hard deadline) ------------------------ Deutsches Zentrum f=FCr Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaff= enhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola@dlr.de= http://www.dlr.de/kn/institut/abteilungen/san --_000_1A39DCC13AF3C14B83CD74124D4DCFC317020D2ADLREXMBX01intra_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

 

Please find below the call for papers for Satellite = and Space Communications track in Globecom 2014, held in Austin, Texas, USA= , on December, 8-12, 2014.

I apologize if you receive multiple copies of this a= nnouncement.

As DTN and satellite/space environments are closely = related, I think this CFP can be of interest for most of you.

 

****************************************************= *******************************
                &nbs= p;             =           CALL FOR PAPERS

                = ;             &= nbsp;       IEEE Globecom 2014
               =    
                = ;  http://www.ieee-glob= ecom.org/

               =            Dec 8-12, 2014= - Austin, Texas, USA

***************************************************************************= ********
The recent advances of satellite communication technology have witnessed an= unprecedented increase of services possibly distributed according to anywh= ere-anytime paradigm. To this regard, the appearance of new standards and t= he simultaneous integration with terrestrial infrastructure has introduced new technical challenges to be f= aced by the scientific community.

The Satellite and Space Communications track solicit= s original and unpublished work not currently under review by any other con= ference or journal. The focus of this track is on exploring and discussing = new technical breakthroughs and applications focusing on all aspects of satellite and space communications.<= /p>

 

MAIN TOPICS of INTEREST

• Satellite and space communications and netwo= rking

• Near-Earth satellite communications

• Antennas for Satellite Communications

• MIMO satellite communications

• Hybrid satellite/terrestrial networks

• Coding, modulation and synchronization schem= es for satellite communications

• Channel models for satellite communications<= o:p>

• Reliable multicast protocols for satellite n= etworks

• Transport protocol performance over satellit= e

• Game theory applications in satellite networ= ks

• Security, privacy, and trust in satellite ne= tworks

• Radio resource management in satellite netwo= rks

• Emerging standards: DVB-SX, DVB-SH, DVB-RCS2= , IP over Satellite

• Cognitive satellite networks

• Delay Tolerant Networking for satellite netw= orks

• Cross-layer air interface design<= /p>

• On-board switching and processing technologi= es

• QoS and performance for satellite networks

• Fade mitigation techniques over satellite ch= annels

• Special protocols for nano-satellites

• Nano-satellites communications

• Nano-Satellite constellation design

• M2M over satellite applications

• Geographic information systems

• Wireless positioning technologies and applic= ations

• Signal detection and estimation for satellit= e communications

• RF engineering for satellite communications<= o:p>

• Statistical and adaptive signal processing f= or satellite systems

• Satellite-based disaster recovery=

• Satellite-based remote e-Health

• Satellite based alarm systems

• Satellite-based solutions for aeronautical a= pplications

• Interplanetary communications

• Next-generation channel coding for deep-spac= e communications

Sponsoring Technical Committees:

•       &nb= sp;     Satellite and Space Communications (SSC)

 

HOW TO SUBMIT A PAPER

The submissions will be handled electronically at https://edas.info/newPaper.php?c=3D16651

 

The IEEE Globecom 2014 website provides full instruc= tions on the paper formatting:

 

http://www.ieee-globecom.org/2014/submguide.html#.UyB= wE4Uz3oY

 

IMPORTANT DATE

 

Paper submission due      &= nbsp; APRIL 1, 2014 (hard deadline)

 

 

——————= ;——————————R= 12;———————
Deutsches Zentrum f=FCr Luft- und Raumfa= hrt (DLR)
German Aerospace Center
Institute of Communications and Navigation = | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany

Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax=   +49 8153 28-2844 | tomaso.decola@dlr.de
http://www.dlr.de/kn/institut/abtei= lungen/san

 

--_000_1A39DCC13AF3C14B83CD74124D4DCFC317020D2ADLREXMBX01intra_-- From nobody Wed Mar 12 10:43:59 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288011A076A for ; Wed, 12 Mar 2014 10:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6dN_Rtv-xAo for ; Wed, 12 Mar 2014 10:43:36 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id B1C201A0758 for ; Wed, 12 Mar 2014 10:42:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2CHgVlR023571; Wed, 12 Mar 2014 10:42:31 -0700 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2CHgT5g023539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 12 Mar 2014 10:42:30 -0700 Received: from XCH-BLV-308.nw.nos.boeing.com (2002:82f7:19dc::82f7:19dc) by XCH-PHX-110.sw.nos.boeing.com (2002:82f7:1927::82f7:1927) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 12 Mar 2014 10:42:29 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.59]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 10:42:29 -0700 From: "Templin, Fred L" To: "dtn-interest@irtf.org" Thread-Topic: "A Bundle of Problem" problem statements Thread-Index: Ac8+GnBHlSxcQv5OReK33RT/ngSVsQ== Date: Wed, 12 Mar 2014 17:42:29 +0000 Message-ID: <2134F8430051B64F815C691A62D983181ED5A5@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/KTA7XAviZE4egYzj5xdvok9elJ8 Subject: [dtn-interest] "A Bundle of Problem" problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:43:49 -0000 Hello, "A Bundle of Problems" [1] provides a useful analysis of the Bundle Protocol [2] and other works of the DTNRG. I see the document as "useful", because the healthy way to look at it is "here are some things to think about, so let's go fix them" as opposed to an alternate viewpoint of "the protocol is broken, and there is nothing we can do about it". In my experience, the first step toward resolution of problems is to start with a problem statement that invites solution proposals. To that end, I am starting a series of "Problem Statement" docs that address some of the issues raised with the goal of improving the protocol. It doesn't matter whether the solutions come in the form of new documents or as inclusions for an RFC5050(bis). What matters is an acknowledgement that we are aware of the problems and have best intentions of addressing them. I hope this can serve as the basis for some productive discussion. Thank you for your time. Fred Templin fred.l.templin@boeing.com=20 [1] Wood, L., Eddy, W. and P. Holliday, "A Bundle of Problems", IEEEAC paper #1023, December 2008. [2] Scott, K., and S. Burleigh, "Bundle Protocol Specification", RFC5050, November 2007. From nobody Wed Mar 12 10:44:01 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25B1A0758 for ; Wed, 12 Mar 2014 10:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiGRV6lxZzVR for ; Wed, 12 Mar 2014 10:43:45 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 787F71A048A for ; Wed, 12 Mar 2014 10:42:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2CHgfHR023678; Wed, 12 Mar 2014 10:42:41 -0700 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2CHgcj3023644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 12 Mar 2014 10:42:38 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.60]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 10:42:37 -0700 From: "Templin, Fred L" To: "dtn-interest@irtf.org" Thread-Topic: Delay Tolerant Networking Security Key Management - Problem Statement Thread-Index: AQHPPhbCGrD6CzJkC0S1L965dGpIMprduEbA Date: Wed, 12 Mar 2014 17:42:36 +0000 Message-ID: <2134F8430051B64F815C691A62D983181ED5AA@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/n3yIH8zmFXIhtJOz9OFHXYkGhk0 Subject: [dtn-interest] Delay Tolerant Networking Security Key Management - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:43:50 -0000 -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Wednesday, March 12, 2014 10:16 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-dtnskmps-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Delay Tolerant Networking Security Key Management= - Problem Statement Author : Fred L. Templin Filename : draft-templin-dtnskmps-00.txt Pages : 6 Date : 2014-03-12 Abstract: Delay/Disruption Tolerant Networking (DTN) introduces a network model in which communications may be subject to long delays and/or intermittent connectivity. These challenges render traditional security key management mechanisms infeasible since round trip delays may exceed the operational limitations of the protocol. This document therefore presents a problem statement for security key management in DTNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-dtnskmps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-dtnskmps-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Mar 12 10:44:17 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC191A07BA for ; Wed, 12 Mar 2014 10:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8EROM-0Fcd2 for ; Wed, 12 Mar 2014 10:43:56 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id F082B1A0795 for ; Wed, 12 Mar 2014 10:42:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2CHgmXF024060; Wed, 12 Mar 2014 12:42:48 -0500 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2CHglKv024035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 12 Mar 2014 12:42:48 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.31]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 10:42:46 -0700 From: "Templin, Fred L" To: "dtn-interest@irtf.org" Thread-Topic: Delay Tolerant Networking Time Synchronization - Problem Statement Thread-Index: AQHPPhc/88hBpDAHSUe67JBRxctFOZrduIdA Date: Wed, 12 Mar 2014 17:42:46 +0000 Message-ID: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/yACMNOTGacNkCN3FCwZMOSRMsts Subject: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:44:01 -0000 -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Wednesday, March 12, 2014 10:19 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-dtntsync-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Delay Tolerant Networking Time Synchronization - = Problem Statement Author : Fred L. Templin Filename : draft-templin-dtntsync-00.txt Pages : 5 Date : 2014-03-12 Abstract: Delay/Disruption Tolerant Networking (DTN) introduces a network model in which communications may be subject to long delays and/or intermittent connectivity. DTN nodes include timestamps in the bundles of data they send so that correspondents can identify the bundles and determine the length of time they have been in the system. However, there is currently no specified strategy for synchronizing the clocks between DTN nodes. This document therefore presents a problem statement for time synchronization in DTNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-dtntsync/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-dtntsync-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Mar 12 10:44:19 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FBC1A07BA for ; Wed, 12 Mar 2014 10:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC11V3r33BFV for ; Wed, 12 Mar 2014 10:43:59 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id EF7031A0768 for ; Wed, 12 Mar 2014 10:42:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2CHgmXD024060; Wed, 12 Mar 2014 12:42:48 -0500 Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2CHgjmv023966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 12 Mar 2014 12:42:45 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.153]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 10:42:44 -0700 From: "Templin, Fred L" To: "dtn-interest@irtf.org" Thread-Topic: Delay Tolerant Networking Header Integrity Assurance - Problem Statement Thread-Index: AQHPPhb8Fd1WveHnvEGVnFDrVc7/yZrduGyA Date: Wed, 12 Mar 2014 17:42:43 +0000 Message-ID: <2134F8430051B64F815C691A62D983181ED5B1@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/DSeh5cPL3iyOmWma1g3BVa-j6qY Subject: [dtn-interest] Delay Tolerant Networking Header Integrity Assurance - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:44:05 -0000 -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Wednesday, March 12, 2014 10:18 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-dtnhiaps-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Delay Tolerant Networking Header Integrity Assura= nce - Problem Statement Author : Fred L. Templin Filename : draft-templin-dtnhiaps-00.txt Pages : 5 Date : 2014-03-12 Abstract: Delay/Disruption Tolerant Networking (DTN) introduces a network model for environments in which communications may be subject to long delays and/or intermittent connectivity. A Bundle Protocol (BP) has been designed to accommodate data communications in such challenging environments through multi-hop store-and-forward message propagation, where each hop may be required to store bundles of data for long periods of time. It is therefore essential that bundles with corrupted headers (e.g., the primary bundle block) be detected as soon as possible in order to avoid resource exhaustion due to accidental or malicious factors, and to permit timely retransmission. In this document, we discuss the need for a hop-by-hop integrity assurance as a means for encouraging suitable solutions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-dtnhiaps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-dtnhiaps-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Mar 12 11:27:59 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0021A0752 for ; Wed, 12 Mar 2014 11:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4OkxrjNosvl for ; Wed, 12 Mar 2014 11:27:56 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id CA0D21A0736 for ; Wed, 12 Mar 2014 11:27:55 -0700 (PDT) Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 4E9982D80EA; Wed, 12 Mar 2014 13:27:49 -0500 (CDT) Received: from NDJSCHT106.ndc.nasa.gov (ndjscht106-pub.ndc.nasa.gov [198.117.1.206]) by ndjsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s2CIRnpi016307; Wed, 12 Mar 2014 13:27:49 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.153]) by NDJSCHT106.ndc.nasa.gov ([198.117.1.206]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 13:27:48 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Templin, Fred L" , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement Thread-Index: AQHPPiDF2W5hr1V5ykagVJyVgkUAPg== Date: Wed, 12 Mar 2014 18:27:48 +0000 Message-ID: In-Reply-To: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [184.56.61.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <330D3E0E0987E647B159234B0189F963@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-12_07:2014-03-12,2014-03-12,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/xo3MTlkFqvbBj6f9ydxwOaPCbJU Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:27:58 -0000 Fred, I appreciate the effort, but I think he effort to fix all these issues and remain backward compatible is probably not the best use of the community's time including your time. The following statement is general to all suggested drafts: I think DTNRG amd RFC5050 have served a great purpose in allowing the community to play with various concepts related to store, carry and forward. One prime example of this is all the various extension blocks and the ability to experiment with various Endpoint Identifiers. That being said, I think it is time to use what we learned to do a redo - albeit I don't perceive there is sufficient energy and resources (funding appears to have dried up here)to make that happen. Furthermore, I would be tempted to wait until ICN gets a handle on named objects as that is probably a very useful bit of information to use going forward. Regarding Time Synchronization: Take a look at the wiki in the dtnbone section: http://www.dtnrg.org/wiki/DtnBone A while back I asked what people set their bundle lifetimes to and why. The result was that most were setting the bundle lifetimes for the duration of the deployment/experiment. I also inquired from many if they use the lifetime for routing. That is, if I have bundle A and Bundle B and Bundle B of equal size. If bundle B is going to expire in 2 hours and bundle A in 3 years, in your particular implementation, is B sent first. I believe in all cases I was aware of, It is the bundle that is put in the queue first, the the one that will expire first. That is understandable in an initial implementation - particularly if you are sourcing all bundles from one place and all have the same size and same lifetime. It make the software much easier, but, if DTN ever took off, this would not be the case. By-the-way, I suspect this is how most systems have been tested, and probably more often than not in a connected network. BBN was the only group I know of that was tying to select bundle lifetimes, buy they only had 1 bit to use, so there were two settings: 15 minutes of 2 hours. Anyway, if you step back and look at the problem and how time is used, you realize it is not needed. Rather, you only need a couple of course priorities such as: 1) forward immediately or drop (for streaming), 2) forward within the next minute or two, 3) forward within the next day, 4) forward when you can (I'll do a cleanup when I defrost the refrigerator, clean the garage or sell the house). Time synchronization in the Bundle Protocol serves three purposes: 1. Bundle lifetimes keep bundles from looping continuously due to routing loops >>>> But it does a really bad job. I can send a small bundle with a long >>>>lifetime, 100 years, and the path will open in 100 years. 2. The lifetime allows the network to purge expired bundles >>> Yes, this is what lifetime will do properly 3. The creation timestamp is used to uniquely identify each bundle. >>>> True, but there are probably other, better ways (in a redo) ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic On 3/12/14 1:42 PM, "Templin, Fred L" wrote: > > >-----Original Message----- >From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Wednesday, March 12, 2014 10:19 AM >To: i-d-announce@ietf.org >Subject: I-D Action: draft-templin-dtntsync-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Delay Tolerant Networking Time Synchronization >- Problem Statement > Author : Fred L. Templin > Filename : draft-templin-dtntsync-00.txt > Pages : 5 > Date : 2014-03-12 > >Abstract: > Delay/Disruption Tolerant Networking (DTN) introduces a network model > in which communications may be subject to long delays and/or > intermittent connectivity. DTN nodes include timestamps in the > bundles of data they send so that correspondents can identify the > bundles and determine the length of time they have been in the > system. However, there is currently no specified strategy for > synchronizing the clocks between DTN nodes. This document therefore > presents a problem statement for time synchronization in DTNs. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-templin-dtntsync/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-templin-dtntsync-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >dtn-interest mailing list >dtn-interest@irtf.org >https://www.irtf.org/mailman/listinfo/dtn-interest From nobody Wed Mar 12 11:29:56 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351A41A0766 for ; Wed, 12 Mar 2014 11:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3v17L_8nY_r for ; Wed, 12 Mar 2014 11:29:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 28B3D1A0752 for ; Wed, 12 Mar 2014 11:29:52 -0700 (PDT) Received: from smp.bbn.com ([192.1.122.26]:54441) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNnua-000FKU-8b; Wed, 12 Mar 2014 14:29:52 -0400 Received: from senshu.bbn.com ([128.89.72.225]:49750) by smp.bbn.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WNnuO-000MWc-CH; Wed, 12 Mar 2014 14:29:40 -0400 Message-ID: <5320A794.7050604@bbn.com> Date: Wed, 12 Mar 2014 14:29:40 -0400 From: Daniel Ellard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dtn-interest@irtf.org References: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: dellard Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/2r7rTLK6wdW_cvC_ABtdcphSuu0 Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:29:54 -0000 On 3/12/14 1:42 PM, Templin, Fred L wrote: > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, March 12, 2014 10:19 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-templin-dtntsync-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Delay Tolerant Networking Time Synchronization - Problem Statement > Author : Fred L. Templin > Filename : draft-templin-dtntsync-00.txt > Pages : 5 > Date : 2014-03-12 > > Abstract: > Delay/Disruption Tolerant Networking (DTN) introduces a network model > in which communications may be subject to long delays and/or > intermittent connectivity. DTN nodes include timestamps in the > bundles of data they send so that correspondents can identify the > bundles and determine the length of time they have been in the > system. However, there is currently no specified strategy for > synchronizing the clocks between DTN nodes. This document therefore > presents a problem statement for time synchronization in DTNs. > I think this is too narrow of a statement of the problem: it assumes that time synchronization is necessary, and then asks how to provide it, rather than asking the question of whether time synchronization is truly an essential requirement of DTN in all scenarios, or whether the function currently provided by real time can, in a variety of useful and practical deployment scenarios, be provided by something else. -Dan -- Daniel Ellard, Ph.D. Senior Scientist, Network Research Raytheon BBN Technologies dellard@bbn.com 617-873-8004 From nobody Wed Mar 12 12:44:27 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EA51A04D2; Wed, 12 Mar 2014 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-RvKj59pRrq; Wed, 12 Mar 2014 12:44:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 300F01A04A4; Wed, 12 Mar 2014 12:44:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E8E007FC38D; Wed, 12 Mar 2014 12:44:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20140312194416.E8E007FC38D@rfc-editor.org> Date: Wed, 12 Mar 2014 12:44:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/fGn8CLvRoTksQC0w6RZAJ-0y-54 Cc: drafts-update-ref@iana.org, dtn-interest@irtf.org, rfc-editor@rfc-editor.org Subject: [dtn-interest] RFC 7122 on Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 19:44:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7122 Title: Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) Author: H. Kruse, S. Jero, S. Ostermann Status: Experimental Stream: IRTF Date: March 2014 Mailbox: kruse@ohio.edu, sjero@purdue.edu, ostermann@eecs.ohiou.edu Pages: 11 Characters: 25889 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-dtnrg-dgram-clayer-05.txt URL: http://www.rfc-editor.org/rfc/rfc7122.txt This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG. This document is a product of the Delay-Tolerant Networking Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Mar 12 13:28:14 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1E01A074E for ; Wed, 12 Mar 2014 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdBao8-s23lp for ; Wed, 12 Mar 2014 13:28:11 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF1F1A0450 for ; Wed, 12 Mar 2014 13:28:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2CKS5q6024263; Wed, 12 Mar 2014 13:28:05 -0700 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2CKRxGH024184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 12 Mar 2014 13:27:59 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.125]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 13:27:58 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement Thread-Index: AQHPPiDFQA9qs6NbQEGpRhqGIbA/E5rd4y0w Date: Wed, 12 Mar 2014 20:27:58 +0000 Message-ID: <2134F8430051B64F815C691A62D983181EEB60@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/dyav1ITUKXZLAEJopH63Li1g8Fw Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:28:14 -0000 Hi Will, > -----Original Message----- > From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov] > Sent: Wednesday, March 12, 2014 11:28 AM > To: Templin, Fred L; dtn-interest@irtf.org > Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronizatio= n - Problem Statement >=20 > Fred, I appreciate the effort, but I think he effort to fix all these > issues and remain backward compatible is probably not the best use of the > community's time including your time. I think I understand your point of view, but it would also be good to get a few more opinions. For example, I'm not sure if backward compatibility is a strict requirement? =20 > The following statement is general to all suggested drafts: >=20 > I think DTNRG amd RFC5050 have served a great purpose in allowing the > community to play with various concepts related to store, carry and > forward. One prime example of this is all the various extension blocks an= d > the ability to experiment with various Endpoint Identifiers. That being > said, I think it is time to use what we learned to do a redo But, would that necessarily entail throwing out everything that has come before (I wouldn't think so)? > - albeit I > don't perceive there is sufficient energy and resources (funding appears > to have dried up here)to make that happen. I don't have enough insight into this to know who would be willing to take on the effort and what the funding sources would be. I know I have some cycles, but I also know that it takes more than one.=20 > Furthermore, I would be > tempted to wait until ICN gets a handle on named objects as that is > probably a very useful bit of information to use going forward. I haven't written that problem statement yet, but the ICN work could certainly fall in the solution space. > Regarding Time Synchronization: >=20 > Take a look at the wiki in the dtnbone section: > http://www.dtnrg.org/wiki/DtnBone >=20 > A while back I asked what people set their bundle lifetimes to and why. > The result was that most were setting the bundle lifetimes for the > duration of the deployment/experiment. >=20 > I also inquired from many if they use the lifetime for routing. That is, > if I have bundle A and Bundle B and Bundle B of equal size. If bundle B > is going to expire in 2 hours and bundle A in 3 years, in your particular > implementation, is B sent first. I believe in all cases I was aware of, > It is the bundle that is put in the queue first, the the one that will > expire first. That is understandable in an initial implementation - > particularly if you are sourcing all bundles from one place and all have > the same size and same lifetime. It make the software much easier, but, > if DTN ever took off, this would not be the case. By-the-way, I suspect > this is how most systems have been tested, and probably more often than > not in a connected network. BBN was the only group I know of that was > tying to select bundle lifetimes, buy they only had 1 bit to use, so ther= e > were two settings: 15 minutes of 2 hours. >=20 > Anyway, if you step back and look at the problem and how time is used, yo= u > realize it is not needed. Rather, you only need a couple of course > priorities such as: 1) forward immediately or drop (for streaming), 2) > forward within the next minute or two, 3) forward within the next day, 4) > forward when you can (I'll do a cleanup when I defrost the refrigerator, > clean the garage or sell the house). This certainly looks like additional considerations for widening the problem statement. > Time synchronization in the Bundle Protocol serves three purposes: >=20 > 1. Bundle lifetimes keep bundles from looping continuously due to > routing loops >=20 > >>>> But it does a really bad job. I can send a small bundle with a lon= g > >>>>lifetime, 100 years, and the path will open in 100 years. Maybe setting healthy limits would be part of a solution proposal? > 2. The lifetime allows the network to purge expired bundles >=20 > >>> Yes, this is what lifetime will do properly OK. > 3. The creation timestamp is used to uniquely identify each bundle. >=20 > >>>> True, but there are probably other, better ways (in a redo) I think I understand your point of view. BTW, the three items I listed above came directly from "Bundle of Problems", but I don't see why addressing the concerns couldn't be done in an RFC5050(bis)? Thanks - Fred fred.l.templin@boeing.com > ****************************** > William D. Ivancic > Phone 216-433-3494 > Fax 216-433-8705 > Networking Lab 216-433-2620 > Mobile 440-503-4892 > http://roland.grc.nasa.gov/~ivancic >=20 >=20 >=20 >=20 >=20 >=20 > On 3/12/14 1:42 PM, "Templin, Fred L" wrote: >=20 > > > > > >-----Original Message----- > >From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > >internet-drafts@ietf.org > >Sent: Wednesday, March 12, 2014 10:19 AM > >To: i-d-announce@ietf.org > >Subject: I-D Action: draft-templin-dtntsync-00.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Delay Tolerant Networking Time Synchronization > >- Problem Statement > > Author : Fred L. Templin > > Filename : draft-templin-dtntsync-00.txt > > Pages : 5 > > Date : 2014-03-12 > > > >Abstract: > > Delay/Disruption Tolerant Networking (DTN) introduces a network model > > in which communications may be subject to long delays and/or > > intermittent connectivity. DTN nodes include timestamps in the > > bundles of data they send so that correspondents can identify the > > bundles and determine the length of time they have been in the > > system. However, there is currently no specified strategy for > > synchronizing the clocks between DTN nodes. This document therefore > > presents a problem statement for time synchronization in DTNs. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-templin-dtntsync/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-templin-dtntsync-00 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >_______________________________________________ > >dtn-interest mailing list > >dtn-interest@irtf.org > >https://www.irtf.org/mailman/listinfo/dtn-interest From nobody Wed Mar 12 13:33:44 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45201A0761 for ; Wed, 12 Mar 2014 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi_i_2hPaMxN for ; Wed, 12 Mar 2014 13:33:38 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3C81A0754 for ; Wed, 12 Mar 2014 13:33:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2CKXWG8018807; Wed, 12 Mar 2014 13:33:32 -0700 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2CKXM7V018687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 12 Mar 2014 13:33:22 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.116]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 13:33:21 -0700 From: "Templin, Fred L" To: Daniel Ellard , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement Thread-Index: AQHPPiEHQA9qs6NbQEGpRhqGIbA/E5rd5uYg Date: Wed, 12 Mar 2014 20:33:20 +0000 Message-ID: <2134F8430051B64F815C691A62D983181EEBA8@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> <5320A794.7050604@bbn.com> In-Reply-To: <5320A794.7050604@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/jiaPT4dErgv-Ivjo0P29S9Nnzq8 Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:33:41 -0000 Hi Dan, > -----Original Message----- > From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Da= niel Ellard > Sent: Wednesday, March 12, 2014 11:30 AM > To: dtn-interest@irtf.org > Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronizatio= n - Problem Statement >=20 > On 3/12/14 1:42 PM, Templin, Fred L wrote: > > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > > Sent: Wednesday, March 12, 2014 10:19 AM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-templin-dtntsync-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : Delay Tolerant Networking Time Synchronizatio= n - Problem Statement > > Author : Fred L. Templin > > Filename : draft-templin-dtntsync-00.txt > > Pages : 5 > > Date : 2014-03-12 > > > > Abstract: > > Delay/Disruption Tolerant Networking (DTN) introduces a network mode= l > > in which communications may be subject to long delays and/or > > intermittent connectivity. DTN nodes include timestamps in the > > bundles of data they send so that correspondents can identify the > > bundles and determine the length of time they have been in the > > system. However, there is currently no specified strategy for > > synchronizing the clocks between DTN nodes. This document therefore > > presents a problem statement for time synchronization in DTNs. > > >=20 > I think this is too narrow of a statement of the problem: it assumes > that time synchronization is necessary, and then asks how to provide > it, rather than asking the question of whether time synchronization > is truly an essential requirement of DTN in all scenarios, or > whether the function currently provided by real time can, in a > variety of useful and practical deployment scenarios, be provided by > something else. I think I understand the concern, and I don't mind expanding the problem statement. Thanks - Fred fred.l.templin@boeing.com =20 > -Dan >=20 >=20 > -- > Daniel Ellard, Ph.D. > Senior Scientist, Network Research > Raytheon BBN Technologies > dellard@bbn.com > 617-873-8004 >=20 > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest From nobody Wed Mar 12 20:58:17 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C291A08B5 for ; Wed, 12 Mar 2014 20:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euP35wo853AX for ; Wed, 12 Mar 2014 20:58:14 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 065C61A08B3 for ; Wed, 12 Mar 2014 20:58:13 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so501476vcb.27 for ; Wed, 12 Mar 2014 20:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VfnL7jbzPNOU37PF+S0E99jtrlPpiIOzxSSrygnuC24=; b=ofRyfGTVNXOX0LUMlqeNH1NJNJra35zxKKEQht1Vf6d8KoSt2ySVdgrI3hknywHT+0 Npsv2U9rxhcLyKrPLS0RqW0vpmZ6It9CdwLYSZIurYTZAk/VXjVcK3fWFVKIjWCJsuMV b7DB5dfMWXYwhbzzX8inMUyNx6h1gjV5LSahcESC+fiy5ybURnH4uix4j3YZXPdnU/Ua X99C8Vwo9u3Wu4kRKOsvNxoVrc4tILRbyhBqP+QSvyK6sFu1ppLxA6mmFblq5mw0BGpj NiH4EArkcazCrgq1iAXHs4RjDtCseSPFFzNqGf77R9pRIDYHXePLi/W3Xb2erk64emee HgZQ== MIME-Version: 1.0 X-Received: by 10.52.164.39 with SMTP id yn7mr713026vdb.25.1394683087465; Wed, 12 Mar 2014 20:58:07 -0700 (PDT) Received: by 10.52.144.13 with HTTP; Wed, 12 Mar 2014 20:58:07 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D983181ED5A5@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181ED5A5@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 12 Mar 2014 23:58:07 -0400 Message-ID: From: Eric Travis To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/JyW0EZNbeGUbUlz77BcMW6-H6iY Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 03:58:16 -0000 Fred, If you haven't already done so, I encourage you to browse the archives of this mailing list. You will find these topics "discussed" multiple times over the years... Opinions might have changed, but history suggests difficulty getting (eventual) consensus that these are indeed problems, let alone what protocol improvements are beneficial. Perhaps starting with a "Problem Statement" document seeking to provide consensus on defining the *minimal* characteristics/services required/provided of the ecosystem underlying of a [bundle-oriented] DTN (a store-and-forward overlay network) should be... is a worthy prequel to this series? I *fully* support with your intent here, but it is best to be mindful of the past... Regards, Eric eric.dot.travis@gmail.com On 3/12/14, Templin, Fred L wrote: > Hello, > > "A Bundle of Problems" [1] provides a useful analysis of the Bundle > Protocol [2] and other works of the DTNRG. I see the document as > "useful", because the healthy way to look at it is "here are some > things to think about, so let's go fix them" as opposed to an > alternate viewpoint of "the protocol is broken, and there is > nothing we can do about it". > > In my experience, the first step toward resolution of problems is > to start with a problem statement that invites solution proposals. > To that end, I am starting a series of "Problem Statement" docs > that address some of the issues raised with the goal of improving > the protocol. It doesn't matter whether the solutions come in the > form of new documents or as inclusions for an RFC5050(bis). What > matters is an acknowledgement that we are aware of the problems > and have best intentions of addressing them. > > I hope this can serve as the basis for some productive discussion. > Thank you for your time. > > Fred Templin > fred.l.templin@boeing.com > > > [1] Wood, L., Eddy, W. and P. Holliday, "A Bundle of Problems", > IEEEAC paper #1023, December 2008. > [2] Scott, K., and S. Burleigh, "Bundle Protocol Specification", > RFC5050, November 2007. > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > -- *Think of how stupid the average person is, and realize that half of them are stupider than that.* *--- George Carlin* From nobody Thu Mar 13 00:01:41 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002D1A08EC for ; Thu, 13 Mar 2014 00:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCXdgiWZp3fz for ; Thu, 13 Mar 2014 00:01:37 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) by ietfa.amsl.com (Postfix) with ESMTP id DA0CF1A0677 for ; Thu, 13 Mar 2014 00:01:36 -0700 (PDT) Received: from [85.158.136.51:20512] by server-10.bemta-5.messagelabs.com id 9C/29-27081-9C751235; Thu, 13 Mar 2014 07:01:29 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-49.messagelabs.com!1394694089!15739011!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17195 invoked from network); 13 Mar 2014 07:01:29 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-13.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 13 Mar 2014 07:01:29 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 13 Mar 2014 07:01:28 +0000 From: To: , Date: Thu, 13 Mar 2014 07:01:27 +0000 Thread-Topic: [dtn-interest] "A Bundle of Problem" problem statements Thread-Index: Ac8+cHmf3NHs3WeRT76FgaOg5zQzGwAGCkxK Message-ID: <290E20B455C66743BE178C5C84F1240847E633476B@EXMB01CMS.surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181ED5A5@XCH-BLV-504.nw.nos.boeing.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/wwLcZY_9jTKzYk1Xh5xO7rKgGds Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 07:01:39 -0000 I'm looking forward to reading some peer-reviewed 'A Bundle of Joy: how it all works just fine despite ignoring the end-to-end principle, and clocks a= nd reliability really aren't problems' paper. Until then, we do have 'A Bundle of Problems' [1] to fall back on. I'd like to see the Bundle Protocol decoupled from the DTN environment. DTN is the problem space, bundling is but one attempt to address that space= . Where bundling failed was scope creep - interplanetary probes to military to... Different use cases are able to leverage different things. Different use casess require different approaches to security. There's no one-size-fits-all solution here. Lloyd Wood http://about.me/lloydwood [1] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, Montana, March 2009. 16 pages. http://dx.doi.org/10.1109/AERO.2009.483938= 4 http://sat-net.com/L.Wood/dtn ________________________________________ From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of Eric Travis= [eric.dot.travis@gmail.com] Sent: 13 March 2014 03:58 To: Templin, Fred L Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements Fred, If you haven't already done so, I encourage you to browse the archives of this mailing list. You will find these topics "discussed" multiple times over the years... Opinions might have changed, but history suggests difficulty getting (eventual) consensus that these are indeed problems, let alone what protocol improvements are beneficial. Perhaps starting with a "Problem Statement" document seeking to provide consensus on defining the *minimal* characteristics/services required/provided of the ecosystem underlying of a [bundle-oriented] DTN (a store-and-forward overlay network) should be... is a worthy prequel to this series? I *fully* support with your intent here, but it is best to be mindful of the past... Regards, Eric eric.dot.travis@gmail.com On 3/12/14, Templin, Fred L wrote: > Hello, > > "A Bundle of Problems" [1] provides a useful analysis of the Bundle > Protocol [2] and other works of the DTNRG. I see the document as > "useful", because the healthy way to look at it is "here are some > things to think about, so let's go fix them" as opposed to an > alternate viewpoint of "the protocol is broken, and there is > nothing we can do about it". > > In my experience, the first step toward resolution of problems is > to start with a problem statement that invites solution proposals. > To that end, I am starting a series of "Problem Statement" docs > that address some of the issues raised with the goal of improving > the protocol. It doesn't matter whether the solutions come in the > form of new documents or as inclusions for an RFC5050(bis). What > matters is an acknowledgement that we are aware of the problems > and have best intentions of addressing them. > > I hope this can serve as the basis for some productive discussion. > Thank you for your time. > > Fred Templin > fred.l.templin@boeing.com > > > [1] Wood, L., Eddy, W. and P. Holliday, "A Bundle of Problems", > IEEEAC paper #1023, December 2008. > [2] Scott, K., and S. Burleigh, "Bundle Protocol Specification", > RFC5050, November 2007. > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > -- *Think of how stupid the average person is, and realize that half of them are stupider than that.* *--- George Carlin* _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest From nobody Thu Mar 13 05:46:55 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FDE1A07FA for ; Thu, 13 Mar 2014 05:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66_IPmr0Pwro for ; Thu, 13 Mar 2014 05:46:49 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 98CE41A077C for ; Thu, 13 Mar 2014 05:46:49 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so1040763vcb.27 for ; Thu, 13 Mar 2014 05:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tcf+hqhPvKKY+N8rq1nkJRCI/HLpG5snXxPjo1rQ984=; b=t00SI8gtkIji3Bq4xapjlsxaZYgAhrjO9ayIcsnOr0jZVfOf9xlQcQSDmqX4RUp3K/ Uiwss3GhgaFNK19JnGgGmnXAsGzhpOQlCacYkb3xGdOk8c8W4hbvQOKM8uPD7VeejEyC PTEBzwo0r2LqpIfYcTJbx6B404SkqIciQAnFP8byPK7l5wwD+C7vs2GgQGs1U9wX8W1/ Gx0oCJM2PWzo0lr+QqCFLSGXPSD/xVc0+StOBs8ZY5/OrfTOPEjLUHIL4UBKcY5Y59Lf ahwBlFgPDRvK/iZUsdfbmvu+554/VkYt56pTLtUNNqFVCFfXwkN5HBCRvm5neGQ9oOzE oeAQ== MIME-Version: 1.0 X-Received: by 10.52.137.143 with SMTP id qi15mr619778vdb.39.1394714802941; Thu, 13 Mar 2014 05:46:42 -0700 (PDT) Received: by 10.52.144.13 with HTTP; Thu, 13 Mar 2014 05:46:42 -0700 (PDT) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E633476B@EXMB01CMS.surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181ED5A5@XCH-BLV-504.nw.nos.boeing.com> <290E20B455C66743BE178C5C84F1240847E633476B@EXMB01CMS.surrey.ac.uk> Date: Thu, 13 Mar 2014 08:46:42 -0400 Message-ID: From: Eric Travis To: l.wood@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/wBXHLma45gsowqlzkt2TNwUSrj4 Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:46:52 -0000 Curiously, I've been looking forward to reading 'A Bundle of Joy: The Lloyd Wood. Approach to Persuasive Writing'. Until then, we have your collective postings in this mailing list archive to fall back upon... Bundling is an approach to communicating in the DTN problem space; The Bundle protocol and it's associated entities are *an* approach for implementing Bundling. While the existing Bundle Protocol [and friends] is arguably flawed (simultaneously overbuilt and yet incomplete), your assertion that Bundling has "failed" is not supported. The goal is a common framework supporting "different use cases are able leverage different things. Different use cases require different approaches to security". Bundling (and the existing Bundle Protocol) support the mixing and matching of mechanisms and policies as required by the different use cases. Engineering is an iterative process - there has not been anything identified that precludes Bundling being a viable approach to DTN. >From my perspective, the obstacles here are not technical, but philosophical (and parochial). And... your approach is NOT helping move things forward within this community, but that isn't your intent (any more?) is it? Eric Travis eric.dot.travis@gmail.com On 3/13/14, l.wood@surrey.ac.uk wrote: > I'm looking forward to reading some peer-reviewed 'A Bundle of Joy: how it > all works just fine despite ignoring the end-to-end principle, and clocks > and > reliability really aren't problems' paper. > > Until then, we do have 'A Bundle of Problems' [1] to fall back on. > > I'd like to see the Bundle Protocol decoupled from the DTN environment. > DTN is the problem space, bundling is but one attempt to address that > space. > > Where bundling failed was scope creep - interplanetary probes to military > to... Different use cases are able to leverage different things. Different > use casess require different approaches to security. There's no > one-size-fits-all solution here. > > Lloyd Wood > http://about.me/lloydwood > > [1] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', > peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, > Montana, March 2009. 16 pages. > http://dx.doi.org/10.1109/AERO.2009.4839384 > http://sat-net.com/L.Wood/dtn > ________________________________________ > From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of Eric Travis > [eric.dot.travis@gmail.com] > Sent: 13 March 2014 03:58 > To: Templin, Fred L > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements > > Fred, > > If you haven't already done so, I encourage you to browse the archives > of this mailing list. > > You will find these topics "discussed" multiple times over the years... > > Opinions might have changed, but history suggests difficulty getting > (eventual) consensus that these are indeed problems, let alone what > protocol improvements are beneficial. > > Perhaps starting with a "Problem Statement" document seeking to > provide consensus on defining the *minimal* characteristics/services > required/provided of the ecosystem underlying of a [bundle-oriented] > DTN (a store-and-forward overlay network) should be... is a worthy > prequel to this series? > > I *fully* support with your intent here, but it is best to be mindful > of the past... > > Regards, > > Eric > eric.dot.travis@gmail.com > > On 3/12/14, Templin, Fred L wrote: >> Hello, >> >> "A Bundle of Problems" [1] provides a useful analysis of the Bundle >> Protocol [2] and other works of the DTNRG. I see the document as >> "useful", because the healthy way to look at it is "here are some >> things to think about, so let's go fix them" as opposed to an >> alternate viewpoint of "the protocol is broken, and there is >> nothing we can do about it". >> >> In my experience, the first step toward resolution of problems is >> to start with a problem statement that invites solution proposals. >> To that end, I am starting a series of "Problem Statement" docs >> that address some of the issues raised with the goal of improving >> the protocol. It doesn't matter whether the solutions come in the >> form of new documents or as inclusions for an RFC5050(bis). What >> matters is an acknowledgement that we are aware of the problems >> and have best intentions of addressing them. >> >> I hope this can serve as the basis for some productive discussion. >> Thank you for your time. >> >> Fred Templin >> fred.l.templin@boeing.com >> >> >> [1] Wood, L., Eddy, W. and P. Holliday, "A Bundle of Problems", >> IEEEAC paper #1023, December 2008. >> [2] Scott, K., and S. Burleigh, "Bundle Protocol Specification", >> RFC5050, November 2007. >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest >> > > > -- > > > *Think of how stupid the average person is, and realize that half of them > are stupider than that.* > *--- George Carlin* > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > -- *Think of how stupid the average person is, and realize that half of them are stupider than that.* *--- George Carlin* From nobody Thu Mar 13 06:40:44 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97EB1A0848 for ; Thu, 13 Mar 2014 06:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwJSNYUdvHZ5 for ; Thu, 13 Mar 2014 06:40:40 -0700 (PDT) Received: from mail.ibr.cs.tu-bs.de (mail.ibr.cs.tu-bs.de [IPv6:2001:638:602:1181:5054:ff:fe75:abbf]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3011A07CB for ; Thu, 13 Mar 2014 06:40:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTP id 18402181999 for ; Thu, 13 Mar 2014 14:40:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ibr.cs.tu-bs.de; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:mime-version:user-agent :from:from:date:date:message-id:received:received; s=key1; t= 1394718031; x=1396532432; bh=/7NnH9Wd6evXqUhNMmlJy+2HNed5R6wryQf noIGI55g=; b=Mi+P+WUtBcTGOXcfz/f/nzw+nsz43/fiu3xgyp1xv7Df5h890by U+HOHheB5zl61NhoHVdlH5+vnIn4a0BM8dJhpUcVDryWKTGyJ7lY5IMtIIoS9it7 7I9eqgRtPZCZ3OhQROKP9R25myXpcy9MuBZdBYMuk/wCDH4b6ZTsWB9c= X-Virus-Scanned: Debian amavisd-new at ibr.cs.tu-bs.de Received: from mail.ibr.cs.tu-bs.de ([127.0.0.1]) by localhost (mail.ibr.cs.tu-bs.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id YjUaNOFHG_n5 for ; Thu, 13 Mar 2014 14:40:31 +0100 (CET) Received: from [IPv6:2001:638:602:1183:59b6:2443:e57:89a5] (unknown [IPv6:2001:638:602:1183:59b6:2443:e57:89a5]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: morgenro@ibr.cs.tu-bs.de) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 5EED6181994 for ; Thu, 13 Mar 2014 14:40:31 +0100 (CET) Message-ID: <5321B54C.6070903@ibr.cs.tu-bs.de> Date: Thu, 13 Mar 2014 14:40:28 +0100 From: Johannes Morgenroth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dtn-interest@irtf.org References: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> <5320A794.7050604@bbn.com> <2134F8430051B64F815C691A62D983181EEBA8@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181EEBA8@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/R-ASQV4Z2si38nBzSCGiX3igQ_Y Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:40:43 -0000 Am 12.03.2014 21:33, schrieb Templin, Fred L: > Delay Tolerant Networking Time Synchronization - Problem Statement Just to advertise my own work. There already exist an approach to synchronize time between DTN nodes published in [1]. It has been implemented/tested in IBR-DTN and uDTN (wireless sensor nodes). [1] http://dl.acm.org/citation.cfm?id=2348618 Regards, Johannes Morgenroth From nobody Thu Mar 13 09:52:18 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB641A0A0B for ; Thu, 13 Mar 2014 09:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWVOEcdl_qKR for ; Thu, 13 Mar 2014 09:52:14 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id B8C561A0484 for ; Thu, 13 Mar 2014 09:52:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2DGq8W4020869; Thu, 13 Mar 2014 09:52:08 -0700 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2DGpwpu020749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Mar 2014 09:51:58 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.213]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 09:51:57 -0700 From: "Templin, Fred L" To: Eric Travis Thread-Topic: [dtn-interest] "A Bundle of Problem" problem statements Thread-Index: AQHPPnB46xB2qLsH3USLZVQ9hMZC6ZrfOiPw Date: Thu, 13 Mar 2014 16:51:57 +0000 Message-ID: <2134F8430051B64F815C691A62D983181EF933@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181ED5A5@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/tt8vArrSiAxNzy4Fb1myPrlM_0A Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:52:17 -0000 Hi Eric, > -----Original Message----- > From: Eric Travis [mailto:eric.dot.travis@gmail.com] > Sent: Wednesday, March 12, 2014 8:58 PM > To: Templin, Fred L > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements >=20 > Fred, >=20 > If you haven't already done so, I encourage you to browse the archives > of this mailing list. Yes, I especially saw threads such as "DTN Time Sync Issues": http://www.ietf.org/mail-archive/web/dtn-interest/current/msg01913.html > You will find these topics "discussed" multiple times over the years... Right, and I don't mean to ignore any of the past discussions. > Opinions might have changed, but history suggests difficulty getting > (eventual) consensus that these are indeed problems, let alone what > protocol improvements are beneficial. I would like to see that problem statements would lead to requirements which would lead to solutions. But, I don't think that necessarily means throwing out everything that has already been done.=20 > Perhaps starting with a "Problem Statement" document seeking to > provide consensus on defining the *minimal* characteristics/services > required/provided of the ecosystem underlying of a [bundle-oriented] > DTN (a store-and-forward overlay network) should be... is a worthy > prequel to this series? >=20 > I *fully* support with your intent here, but it is best to be mindful > of the past... Thanks Eric, Fred fred.l.templin@boeing.com > Regards, >=20 > Eric > eric.dot.travis@gmail.com >=20 > On 3/12/14, Templin, Fred L wrote: > > Hello, > > > > "A Bundle of Problems" [1] provides a useful analysis of the Bundle > > Protocol [2] and other works of the DTNRG. I see the document as > > "useful", because the healthy way to look at it is "here are some > > things to think about, so let's go fix them" as opposed to an > > alternate viewpoint of "the protocol is broken, and there is > > nothing we can do about it". > > > > In my experience, the first step toward resolution of problems is > > to start with a problem statement that invites solution proposals. > > To that end, I am starting a series of "Problem Statement" docs > > that address some of the issues raised with the goal of improving > > the protocol. It doesn't matter whether the solutions come in the > > form of new documents or as inclusions for an RFC5050(bis). What > > matters is an acknowledgement that we are aware of the problems > > and have best intentions of addressing them. > > > > I hope this can serve as the basis for some productive discussion. > > Thank you for your time. > > > > Fred Templin > > fred.l.templin@boeing.com > > > > > > [1] Wood, L., Eddy, W. and P. Holliday, "A Bundle of Problems", > > IEEEAC paper #1023, December 2008. > > [2] Scott, K., and S. Burleigh, "Bundle Protocol Specification", > > RFC5050, November 2007. > > > > _______________________________________________ > > dtn-interest mailing list > > dtn-interest@irtf.org > > https://www.irtf.org/mailman/listinfo/dtn-interest > > >=20 >=20 > -- >=20 >=20 > *Think of how stupid the average person is, and realize that half of them > are stupider than that.* > *--- George Carlin* From nobody Thu Mar 13 10:36:25 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCEC1A0762 for ; Thu, 13 Mar 2014 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL5tVCWmaGFi for ; Thu, 13 Mar 2014 10:36:18 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 127961A072C for ; Thu, 13 Mar 2014 10:36:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2DHaBKc018120; Thu, 13 Mar 2014 10:36:11 -0700 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2DHa1jg017922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Mar 2014 10:36:02 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-312.sw.nos.boeing.com ([169.254.12.222]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 10:36:01 -0700 From: "Templin, Fred L" To: "l.wood@surrey.ac.uk" , "eric.dot.travis@gmail.com" Thread-Topic: [dtn-interest] "A Bundle of Problem" problem statements Thread-Index: AQHPPnB46xB2qLsH3USLZVQ9hMZC6ZrfDJKAgAAxs6A= Date: Thu, 13 Mar 2014 17:36:01 +0000 Message-ID: <2134F8430051B64F815C691A62D983181EFA2D@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181ED5A5@XCH-BLV-504.nw.nos.boeing.com>, <290E20B455C66743BE178C5C84F1240847E633476B@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E633476B@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/4D763KkKJu_iHN821_f9ZmBbFMU Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:36:24 -0000 Hi Lloyd, > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Thursday, March 13, 2014 12:01 AM > To: eric.dot.travis@gmail.com; Templin, Fred L > Cc: dtn-interest@irtf.org > Subject: RE: [dtn-interest] "A Bundle of Problem" problem statements >=20 > I'm looking forward to reading some peer-reviewed 'A Bundle of Joy: how i= t > all works just fine despite ignoring the end-to-end principle, and clocks= and > reliability really aren't problems' paper. I don't think the situation is quite as black-and-white as that. I don't think it is possible to write a "thing of joy" paper about any modern networking solution (e.g., OSPF, BGP, IPv6) but that does not mean that they cannot (or will not) be used on a wide scale. > Until then, we do have 'A Bundle of Problems' [1] to fall back on. Yes, it is a useful document in terms of pointing out shortcomings and calling for improvements, and I think the community is better off for having it. But, IMHO it could be looked at as a guidebook for moving forward rather than a disqualification of everything that came before. > I'd like to see the Bundle Protocol decoupled from the DTN environment. > DTN is the problem space, bundling is but one attempt to address that spa= ce. I am new to this community, but my experiences in the RRG showed that it may not ever be possible to gain full consensus in a research group but solutions go forward just the same. > Where bundling failed was scope creep - interplanetary probes to military > to... Different use cases are able to leverage different things. Differen= t > use casess require different approaches to security. There's no > one-size-fits-all solution here. Yet what I am seeing in the Bundle Protocol in my limited experience so far is design-for-flexibility rather than design-for-efficiency. A parallel can be seen in the way OSPF was found to be not optimal for all MANETs, and so myriad custom MANET routing protocols were designed for efficiency down to the bit level. But at the same time, OSPF/MANET extensions have shown that efficient adaptations of a flexible system are possible for many (if not most) use cases. Thanks - Fred fred.l.templin@boeing.com =20 > Lloyd Wood > http://about.me/lloydwood >=20 > [1] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems'= , > peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, > Montana, March 2009. 16 pages. http://dx.doi.org/10.1109/AERO.2009.4839= 384 > http://sat-net.com/L.Wood/dtn > ________________________________________ > From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of Eric Trav= is > [eric.dot.travis@gmail.com] > Sent: 13 March 2014 03:58 > To: Templin, Fred L > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] "A Bundle of Problem" problem statements >=20 > Fred, >=20 > If you haven't already done so, I encourage you to browse the archives > of this mailing list. >=20 > You will find these topics "discussed" multiple times over the years... >=20 > Opinions might have changed, but history suggests difficulty getting > (eventual) consensus that these are indeed problems, let alone what > protocol improvements are beneficial. >=20 > Perhaps starting with a "Problem Statement" document seeking to > provide consensus on defining the *minimal* characteristics/services > required/provided of the ecosystem underlying of a [bundle-oriented] > DTN (a store-and-forward overlay network) should be... is a worthy > prequel to this series? >=20 > I *fully* support with your intent here, but it is best to be mindful > of the past... >=20 > Regards, >=20 > Eric > eric.dot.travis@gmail.com >=20 > On 3/12/14, Templin, Fred L wrote: > > Hello, > > > > "A Bundle of Problems" [1] provides a useful analysis of the Bundle > > Protocol [2] and other works of the DTNRG. I see the document as > > "useful", because the healthy way to look at it is "here are some > > things to think about, so let's go fix them" as opposed to an > > alternate viewpoint of "the protocol is broken, and there is > > nothing we can do about it". > > > > In my experience, the first step toward resolution of problems is > > to start with a problem statement that invites solution proposals. > > To that end, I am starting a series of "Problem Statement" docs > > that address some of the issues raised with the goal of improving > > the protocol. It doesn't matter whether the solutions come in the > > form of new documents or as inclusions for an RFC5050(bis). What > > matters is an acknowledgement that we are aware of the problems > > and have best intentions of addressing them. > > > > I hope this can serve as the basis for some productive discussion. > > Thank you for your time. > > > > Fred Templin > > fred.l.templin@boeing.com > > > > > > [1] Wood, L., Eddy, W. and P. Holliday, "A Bundle of Problems", > > IEEEAC paper #1023, December 2008. > > [2] Scott, K., and S. Burleigh, "Bundle Protocol Specification", > > RFC5050, November 2007. > > > > _______________________________________________ > > dtn-interest mailing list > > dtn-interest@irtf.org > > https://www.irtf.org/mailman/listinfo/dtn-interest > > >=20 >=20 > -- >=20 >=20 > *Think of how stupid the average person is, and realize that half of them > are stupider than that.* > *--- George Carlin* >=20 > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest From nobody Thu Mar 13 10:39:52 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF66B1A0451 for ; Thu, 13 Mar 2014 10:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuxhYVbZRl8l for ; Thu, 13 Mar 2014 10:39:46 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 609281A0762 for ; Thu, 13 Mar 2014 10:39:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2DHddcc000838; Thu, 13 Mar 2014 12:39:39 -0500 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2DHdaI0000752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Mar 2014 12:39:37 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.141]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 10:39:35 -0700 From: "Templin, Fred L" To: Johannes Morgenroth , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement Thread-Index: AQHPPsHLQA9qs6NbQEGpRhqGIbA/E5rfSH1A Date: Thu, 13 Mar 2014 17:39:34 +0000 Message-ID: <2134F8430051B64F815C691A62D983181EFA68@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181ED5B9@XCH-BLV-504.nw.nos.boeing.com> <5320A794.7050604@bbn.com> <2134F8430051B64F815C691A62D983181EEBA8@XCH-BLV-504.nw.nos.boeing.com> <5321B54C.6070903@ibr.cs.tu-bs.de> In-Reply-To: <5321B54C.6070903@ibr.cs.tu-bs.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/6Q0Gvs4ysEynpKYBkClK99Car-4 Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:39:49 -0000 I would be happy to retire any problem statement for which there is one or more consensus solution - calling for solutions is the purpose for posting problem statements in the first place. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Jo= hannes Morgenroth > Sent: Thursday, March 13, 2014 6:40 AM > To: dtn-interest@irtf.org > Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronizatio= n - Problem Statement >=20 > Am 12.03.2014 21:33, schrieb Templin, Fred L: > > Delay Tolerant Networking Time Synchronization - Problem Statement >=20 > Just to advertise my own work. There already exist an approach to > synchronize time between DTN nodes published in [1]. It has been > implemented/tested in IBR-DTN and uDTN (wireless sensor nodes). >=20 > [1] http://dl.acm.org/citation.cfm?id=3D2348618 >=20 > Regards, > Johannes Morgenroth >=20 > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest From nobody Thu Mar 13 11:02:20 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C971A0A4A for ; Thu, 13 Mar 2014 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3U1zDJ0g-Nd for ; Thu, 13 Mar 2014 11:02:16 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE5A1A0A3E for ; Thu, 13 Mar 2014 11:02:16 -0700 (PDT) Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id CB787260078; Thu, 13 Mar 2014 13:02:09 -0500 (CDT) Received: from NDJSCHT110.ndc.nasa.gov (ndjscht110-pub.ndc.nasa.gov [198.117.1.210]) by ndjsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s2DI29vr031110; Thu, 13 Mar 2014 13:02:09 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.153]) by NDJSCHT110.ndc.nasa.gov ([198.117.1.210]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 13:02:09 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Templin, Fred L" , Johannes Morgenroth , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement Thread-Index: AQHPPiESnWd7kBzH0kO7iikThgwZ6prePCwAgAEe+gCAAELOAP//w0GA Date: Thu, 13 Mar 2014 18:02:08 +0000 Message-ID: In-Reply-To: <2134F8430051B64F815C691A62D983181EFA68@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [139.88.111.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-13_07:2014-03-13,2014-03-13,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/oRplyqYOm7Y5kC86cztdQprCrBo Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:02:18 -0000 Johannes, While I only currently read the abstract and not the full paper, I suspect the algorithm is independent of the Bundling protocol. Is that correct? Systems and applications within the disconnected and disjoint network may likely want to have some notion of time for things like security certificates, time-stamping sensor data and such. Thus, I see time-synchronization algorithms as quite useful independent of the store, carry and forward implementation. On the other hand, I would not want my forwarding implementation to require time-synchronization. I believe this is what would be called a chicken or the egg problem (I.E. circular reference). Will On 3/13/14 1:39 PM, "Templin, Fred L" wrote: >I would be happy to retire any problem statement for which there is >one or more consensus solution - calling for solutions is the purpose >for posting problem statements in the first place. > >Thanks - Fred >fred.l.templin@boeing.com > >> -----Original Message----- >> From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of >>Johannes Morgenroth >> Sent: Thursday, March 13, 2014 6:40 AM >> To: dtn-interest@irtf.org >> Subject: Re: [dtn-interest] Delay Tolerant Networking Time >>Synchronization - Problem Statement >>=20 >> Am 12.03.2014 21:33, schrieb Templin, Fred L: >> > Delay Tolerant Networking Time Synchronization - Problem Statement >>=20 >> Just to advertise my own work. There already exist an approach to >> synchronize time between DTN nodes published in [1]. It has been >> implemented/tested in IBR-DTN and uDTN (wireless sensor nodes). >>=20 >> [1] http://dl.acm.org/citation.cfm?id=3D2348618 >>=20 >> Regards, >> Johannes Morgenroth >>=20 >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest > >_______________________________________________ >dtn-interest mailing list >dtn-interest@irtf.org >https://www.irtf.org/mailman/listinfo/dtn-interest From nobody Thu Mar 13 14:31:09 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C01A0A47 for ; Thu, 13 Mar 2014 14:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPVkwHRmMRCC for ; Thu, 13 Mar 2014 14:31:05 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 98E841A0A10 for ; Thu, 13 Mar 2014 14:31:04 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so4543183wiv.13 for ; Thu, 13 Mar 2014 14:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=uXNxGK2hTVk4LvcE62MLUhrGk2CVZodLH5rhrs2w7nI=; b=Czv9l+OsTrXher0d8yD5rWiGIfGriuQ08k1By9AnhKG7iLy58L66KM3VpaNFczxDfw SJ9sRieWYBmp9+32aBE85RS4Xxzw+dEd7KhhCCZx4E881jD01KTR1gpjrTLy9Vnq+Ltr rSSV4G6yzGa+tHpZx7WOofgMssP8uj6bMhGoMV0XUfnYn2NwHQDvqX1tmrEqO07YR2zf MeaRncAdmahnsnM7HWc3mp9/8dRDNNOOp/ACVg55gPCghRl66Qwlnu88mQhlMHdf4gSZ DEmQA9vDeUO2BlLMkmn7HfgpHE33O1BBMG1v4R7eSL8zptEYzQLsUGY2fQZYNXqxYlI0 +ntQ== MIME-Version: 1.0 X-Received: by 10.194.90.107 with SMTP id bv11mr3539501wjb.11.1394746257344; Thu, 13 Mar 2014 14:30:57 -0700 (PDT) Sender: kfallca@gmail.com Received: by 10.194.80.40 with HTTP; Thu, 13 Mar 2014 14:30:57 -0700 (PDT) Date: Thu, 13 Mar 2014 17:30:57 -0400 X-Google-Sender-Auth: KHDTYiVgPsyGVvPGIVm8xUAoUFM Message-ID: From: Kevin Fall To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/si_U10kq2dSr2iO7673qoQ96QNM Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:31:07 -0000 Part of the issue is whether the issues raised are indeed considered to be 'problems', and in what context (operational, BP design, or what). The bundle protocol didn't set out to solve all the problems one might encounter in a DTN type of environment (evidently also now known as "DIL" -- Disconnected, Intermittent, Limited). Perhaps most relevant is that it didn't aim to sync clocks, didn't aim to provide integrity on data (except within the context of the security protocol) and didn't aim to solve the key management problem. All of this was (intentionally) left for further R&D and/or to other options available from the home system [e.g., many systems have their own non-BP time sync options and keying], but the BP made use of these things on the assumption (reasonable for many systems) they would be available. You will find these discussions back several years through the archives. I would suggest that it might be worth pursuing a couple of questions. There was once a discussion of 'what if some nodes don't have synchronized time' and how to deal with that issue. There were also explorations of, e.g., identity based encryption as an alternative to conventional PKI. About the only issue from the 'problems' paper that I accept as an actual issue is header integrity when BSP is not used. In my opinion, that might be worth pursuing also, but seems pretty straightforward-- likely not requiring its own 'problem statement' but rather some agreed-upon solution. With regards to time specifically, the timestamp was primarily there to know when throwing old data out is ok (as opposed to guiding the priority of forwarding). Also, it is if anything more the case today that most systems know the time. And please recall that one of the points was to be able to store data in transit outside a router.. being able to do this affects what can be assumed about how time is handled and when throwing data out is ok (as mentioned above). - Kevin On Thu, Mar 13, 2014 at 1:39 PM, Templin, Fred L wrote: > I would be happy to retire any problem statement for which there is > one or more consensus solution - calling for solutions is the purpose > for posting problem statements in the first place. > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Johannes Morgenroth >> Sent: Thursday, March 13, 2014 6:40 AM >> To: dtn-interest@irtf.org >> Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement >> >> Am 12.03.2014 21:33, schrieb Templin, Fred L: >> > Delay Tolerant Networking Time Synchronization - Problem Statement >> >> Just to advertise my own work. There already exist an approach to >> synchronize time between DTN nodes published in [1]. It has been >> implemented/tested in IBR-DTN and uDTN (wireless sensor nodes). >> >> [1] http://dl.acm.org/citation.cfm?id=2348618 >> >> Regards, >> Johannes Morgenroth >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > From nobody Fri Mar 14 18:26:19 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4991A024D for ; Fri, 14 Mar 2014 18:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.171 X-Spam-Level: * X-Spam-Status: No, score=1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FR_IMPORT_CSS=1.889, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc_un-kCKVPf for ; Fri, 14 Mar 2014 18:26:16 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id C36761A022B for ; Fri, 14 Mar 2014 18:26:16 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ma3so3301788pbc.41 for ; Fri, 14 Mar 2014 18:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:reply-to:mime-version:message-id:content-type; bh=IuMeHYpzAa3XGa0Q2itzhn4+ERlqh8XearSaZvj6aT8=; b=ujPI7smlS+VPZ4hVx8qrlBAi0jdT9JtzZUxhr69/NMg1TB5fuRerMshGsT8Xm3bOBs y5keVdkPQuUc3bXOJ3N7aPeOxNGaZImLOr7Ml/RjOgWWMfToly2iqRR2Oa0R83WkCJfc OVuGvWINV5B9V9wwv0Ji8L4j7JFuQOAsCGFewsKImep1s52ZkyGEtgj3rZr3iL+dFnHF bgWRpn3HxWkVz3xN2LCpi7qyFrOzEBcvoCKqDDMcF9lbci/DvhBGp5VrufT7cEz90d/0 ORNPiJd4CzPNqEtp7AxGbBomY/oiC050H+srJ/38HvWvUv5bk+LjCxCvQLfnZPBweRBc Hemw== X-Received: by 10.66.49.74 with SMTP id s10mr12562819pan.0.1394846769857; Fri, 14 Mar 2014 18:26:09 -0700 (PDT) Received: from yang (th019228.ip.tsinghua.edu.cn. [59.66.19.228]) by mx.google.com with ESMTPSA id kc9sm20702478pbc.25.2014.03.14.18.26.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 14 Mar 2014 18:26:08 -0700 (PDT) Date: Sat, 15 Mar 2014 09:26:03 +0800 From: "=?utf-8?B?5p2o5aKe5Y2w?=" To: "dtn-interest" X-Mailer: NetEase Flash Mail 2.3.1.12 X-Priority: 3 (Normal) MIME-Version: 1.0 Message-ID: <5323AC27.5090408@gmail.com> Content-Type: multipart/alternative; boundary="====003__MESSAGE__ID__54yg6f6h6y456345====" Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/8wPzQk87pwxbCoDU1F7fpXjX0tQ Subject: [dtn-interest] dtn-interest mailing list submissions X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yzengyin@gmail.com List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:26:18 -0000 --====003__MESSAGE__ID__54yg6f6h6y456345==== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZHRuLWludGVyZXN0IG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucw0KDQoyMDE0LTAzLTE1DQoNCg0K DQrmnajlop7ljbA= --====003__MESSAGE__ID__54yg6f6h6y456345==== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+IDwhLS1AaW1wb3J0IHVy bChzY3JvbGxiYXIuY3NzKTsgLS0+PC9TVFlMRT4NCg0KPE1FVEEgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxTVFlMRT4JCQlCTE9D S1FVT1RFe21hcmdpbi1Ub3A6IDBweDsgbWFyZ2luLUJvdHRvbTogMHB4OyBtYXJnaW4tTGVmdDog MmVtfQkJCWJvZHl7Rk9OVC1TSVpFOjEyLjFwdDsgQ09MT1I6IzAwMTsgRk9OVC1GQU1JTFk65a6L 5L2TLHNlcmlmO30JCTwvU1RZTEU+DQoNCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1T SFRNTCA5LjAwLjgxMTIuMTY0ODMiPjxCQVNFIA0KdGFyZ2V0PV9ibGFuaz48L0hFQUQ+DQo8Qk9E WSANCnN0eWxlPSJMSU5FLUhFSUdIVDogMS4zOyBCT1JERVItUklHSFQtV0lEVEg6IDBweDsgTUFS R0lOOiAxMnB4OyBCT1JERVItVE9QLVdJRFRIOiAwcHg7IEJPUkRFUi1CT1RUT00tV0lEVEg6IDBw eDsgQk9SREVSLUxFRlQtV0lEVEg6IDBweCIgDQptYXJnaW5oZWlnaHQ9IjAiIG1hcmdpbndpZHRo PSIwIj48U1RBVElPTkVSWT4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTMgZmFjZT3l rovkvZM+ZHRuLWludGVyZXN0IG1haWxpbmcgDQpsaXN0IHN1Ym1pc3Npb25zPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj0jYzBjMGMw IHNpemU9MiANCmZhY2U9VmVyZGFuYT4yMDE0LTAzLTE1PC9GT05UPjwvRElWPjxGT05UIHNpemU9 MiBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGlk PVNpZ25OYW1lSFIgYWxpZ249bGVmdCBTSVpFPTI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGNvbG9y PSNjMGMwYzAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1BBTiBpZD1fRmxhc2hTaWduTmFtZT4NCjxT VFlMRSB0eXBlPXRleHQvY3NzPg0KYm9keSB7DQoJZm9udC1zaXplOjEyLjFwdDsgZm9udC1mYW1p bHk6c2ltc3VuLHNlcmlmOw0KfQ0KPC9TVFlMRT4NCjwhLS0gZmxhc2htYWlsIHN0eWxlIGJlZ2lu IC0tPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+IDwhLS1AaW1wb3J0IHVybChEOlxQcm9ncmFtIEZp bGVzXE5ldGVhc2Vc572R5piT6Zeq55S16YKuXFxkYXRhXHNjcm9sbGJhci5jc3MpOyAtLT4NCmJs b2NrcXVvdGUgew0KCW1hcmdpbi10b3A6MDsgbWFyZ2luLWJvdHRvbTowOyBtYXJnaW4tbGVmdDoy ZW07DQp9DQpib2R5IHsNCglwYWRkaW5nOjA7IG1hcmdpbjowOw0KfQ0KPC9TVFlMRT4NCjxCQVNF IHRhcmdldD1fYmxhbms+PCEtLSBmbGFzaG1haWwgc3R5bGUgZW5kIC0tPg0KPE1FVEEgbmFtZT1H RU5FUkFUT1IgY29udGVudD0iTVNIVE1MIDkuMDAuODExMi4xNjQ4MyI+DQo8RElWPuadqOWinuWN sDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48L1NUQVRJT05FUlk+PC9TUEFOPjwvRk9OVD48L0RJ Vj48L1NUQVRJT05FUlk+PC9CT0RZPjwvSFRNTD4= --====003__MESSAGE__ID__54yg6f6h6y456345====-- From nobody Sat Mar 15 05:27:31 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E418A1A0132 for ; Sat, 15 Mar 2014 05:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8cmclNgd4n4 for ; Sat, 15 Mar 2014 05:27:27 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id 092351A01DD for ; Sat, 15 Mar 2014 05:27:26 -0700 (PDT) Received: from [195.245.231.67:54404] by server-6.bemta-5.messagelabs.com id 87/B1-19576-72744235; Sat, 15 Mar 2014 12:27:19 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-82.messagelabs.com!1394886438!34923146!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28112 invoked from network); 15 Mar 2014 12:27:18 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-10.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 15 Mar 2014 12:27:18 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sat, 15 Mar 2014 12:27:17 +0000 From: To: Date: Sat, 15 Mar 2014 12:27:17 +0000 Thread-Topic: [dtn-interest] problem statements Thread-Index: Ac8/A4/HmwC4TWrySdC9RgC9qwvDvABRFSnQ Message-ID: <290E20B455C66743BE178C5C84F1240847E633477B@EXMB01CMS.surrey.ac.uk> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/d6Z_zPClC3za4GIYsIduSShq5nI Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 12:27:30 -0000 Much of that discussion was on introducing the concepts of error detection and the end-to-end principle to a community unaware of them. I dispute the "intentionally" - it's hard to intentionally leave out someth= ing entirely unfamiliar, and from the early days of IPNSIG onward, I have not s= een a design document discussing and explicitly rejecting such options. There are existing expired drafts on the time sync problem, on error detect= ion sans security, etc. The group did not pursue them; they were not viewed as important.. DTN is a set of operational requirements - difficult conditions, introducin= g errors, dealing with unreliability. Designing to meet those requirements is something we call 'engineering'. It's worth trying. Lloyd Wood http://sat-net.com/L.Wood/dtn ________________________________________ From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of Kevin Fall = [kfall@kfall.net] Sent: 13 March 2014 21:30 To: Templin, Fred L Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] problem statements Part of the issue is whether the issues raised are indeed considered to be 'problems', and in what context (operational, BP design, or what). The bundle protocol didn't set out to solve all the problems one might encounter in a DTN type of environment (evidently also now known as "DIL" -- Disconnected, Intermittent, Limited). Perhaps most relevant is that it didn't aim to sync clocks, didn't aim to provide integrity on data (except within the context of the security protocol) and didn't aim to solve the key management problem. All of this was (intentionally) left for further R&D and/or to other options available from the home system [e.g., many systems have their own non-BP time sync options and keying], but the BP made use of these things on the assumption (reasonable for many systems) they would be available. You will find these discussions back several years through the archives. I would suggest that it might be worth pursuing a couple of questions. There was once a discussion of 'what if some nodes don't have synchronized time' and how to deal with that issue. There were also explorations of, e.g., identity based encryption as an alternative to conventional PKI. About the only issue from the 'problems' paper that I accept as an actual issue is header integrity when BSP is not used. In my opinion, that might be worth pursuing also, but seems pretty straightforward-- likely not requiring its own 'problem statement' but rather some agreed-upon solution. With regards to time specifically, the timestamp was primarily there to know when throwing old data out is ok (as opposed to guiding the priority of forwarding). Also, it is if anything more the case today that most systems know the time. And please recall that one of the points was to be able to store data in transit outside a router.. being able to do this affects what can be assumed about how time is handled and when throwing data out is ok (as mentioned above). - Kevin On Thu, Mar 13, 2014 at 1:39 PM, Templin, Fred L wrote: > I would be happy to retire any problem statement for which there is > one or more consensus solution - calling for solutions is the purpose > for posting problem statements in the first place. > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of J= ohannes Morgenroth >> Sent: Thursday, March 13, 2014 6:40 AM >> To: dtn-interest@irtf.org >> Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronizati= on - Problem Statement >> >> Am 12.03.2014 21:33, schrieb Templin, Fred L: >> > Delay Tolerant Networking Time Synchronization - Problem Statement >> >> Just to advertise my own work. There already exist an approach to >> synchronize time between DTN nodes published in [1]. It has been >> implemented/tested in IBR-DTN and uDTN (wireless sensor nodes). >> >> [1] http://dl.acm.org/citation.cfm?id=3D2348618 >> >> Regards, >> Johannes Morgenroth >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest= From nobody Sat Mar 15 09:15:40 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E431A00B1 for ; Sat, 15 Mar 2014 09:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5mv5RCYwmGI for ; Sat, 15 Mar 2014 09:15:36 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BD22D1A00B0 for ; Sat, 15 Mar 2014 09:15:35 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so3234669wgg.30 for ; Sat, 15 Mar 2014 09:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=osblP0Dr2XyMI2RjlyYOn5sKDsofclXYiBzKc1vikIw=; b=JA9m5DWleKiILLoMcnRS+ifPWU7QGkgslrXTCgk8NFoAawN7lmdk5RtbjMfdUspdmF gCK4gVMumb5nFUv3cnhouVbfNziOBY38oefzWiRzeGQrcdjur0iIdY5Du3Z+z7WaVm9/ D4MHfq3nDVu0+CwirAyEvPo5DZqZ+sQmRmociWREjo+Of/pU0Vx3N4XBvu7RJj79nQHW L8tCVFrEEuj58d5Xp6T0hE+yuC16batfdzuJ9KuL/vvXVBFTSuhallnFsBlMeZ4f9/be m9Cjgz6TkBJU9U8vb/lmlBx887Hekj6980dqPjyg3mU7LFwcfPP7pam5PTmZzZug0f0W mw6Q== MIME-Version: 1.0 X-Received: by 10.194.24.35 with SMTP id r3mr92648wjf.68.1394900127744; Sat, 15 Mar 2014 09:15:27 -0700 (PDT) Sender: kfallca@gmail.com Received: by 10.194.80.40 with HTTP; Sat, 15 Mar 2014 09:15:27 -0700 (PDT) Date: Sat, 15 Mar 2014 12:15:27 -0400 X-Google-Sender-Auth: glOck3JxqTnXIN5NF4qJXqMX34E Message-ID: From: Kevin Fall To: l.wood@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/hTEmwAHY1B_wh9AfANSLGeg8_SQ Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:15:38 -0000 Oh please... not the same old debate and false assertions. You may dispute 'intentionally', but you would be wrong. Go ahead and read the e2e paper. It is in fact what drove the design wrt error control. In particular: >The answer is that threat number four may have been eliminated, but the ca= reful file transfer application must still >counter the remaining threats, = so it should still provide its own retries based on an end-to-end checksum = of the file. >And if it does so, the extra effort expended in the communica= tion system to provide a guarantee of reliable data >transmission is only r= educing the frequency of retries by the file transfer application; it has n= o effect on inevitability or >correctness of the outcome, since correct fil= e transmission is assured by the end-to-end checksum and retry whether >or = not the data transmission system is especially reliable. >Thus the argument: in order to achieve careful file transfer, the applicat= ion program that performs the transfer must >supply a file-transfer-specifi= c, end-to-end reliability guarantee - in this case, a checksum to detect fa= ilures and a >retry/commit plan. For the data communication system to go ou= t of its way to be extraordinarily reliable does not >reduce the burden on = the application program to ensure reliability. Also, in the 2003 DTN paper (section 4.5): >Furthermore, the provision of the end-to-end optional acknowledgment is co= nsistent with the end-to-end argument >[16] ---that only the applications= truly know what they require. - Kevin On Sat, Mar 15, 2014 at 8:27 AM, wrote: > Much of that discussion was on introducing the concepts of error detectio= n > and the end-to-end principle to a community unaware of them. > > I dispute the "intentionally" - it's hard to intentionally leave out some= thing > entirely unfamiliar, and from the early days of IPNSIG onward, I have not= seen a design > document discussing and explicitly rejecting such options. > > There are existing expired drafts on the time sync problem, on error dete= ction > sans security, etc. The group did not pursue them; they were > not viewed as important.. > > DTN is a set of operational requirements - difficult conditions, introduc= ing > errors, dealing with unreliability. Designing to meet those > requirements is something we call 'engineering'. It's worth > trying. > > > Lloyd Wood > http://sat-net.com/L.Wood/dtn > ________________________________________ > From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of Kevin Fal= l [kfall@kfall.net] > Sent: 13 March 2014 21:30 > To: Templin, Fred L > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] problem statements > > Part of the issue is whether the issues raised are indeed considered > to be 'problems', and in what context (operational, BP design, or > what). The bundle protocol didn't set out to solve all the problems > one might encounter in a DTN type of environment (evidently also now > known as "DIL" -- Disconnected, Intermittent, Limited). Perhaps most > relevant is that it didn't aim to sync clocks, didn't aim to provide > integrity on data (except within the context of the security protocol) > and didn't aim to solve the key management problem. All of this was > (intentionally) left for further R&D and/or to other options available > from the home system [e.g., many systems have their own non-BP time > sync options and keying], but the BP made use of these things on the > assumption (reasonable for many systems) they would be available. You > will find these discussions back several years through the archives. > > I would suggest that it might be worth pursuing a couple of questions. > There was once a discussion of 'what if some nodes don't have > synchronized time' and how to deal with that issue. There were also > explorations of, e.g., identity based encryption as an alternative to > conventional PKI. About the only issue from the 'problems' paper that > I accept as an actual issue is header integrity when BSP is not used. > In my opinion, that might be worth pursuing also, but seems pretty > straightforward-- likely not requiring its own 'problem statement' but > rather some agreed-upon solution. > > With regards to time specifically, the timestamp was primarily there > to know when throwing old data out is ok (as opposed to guiding the > priority of forwarding). Also, it is if anything more the case today > that most systems know the time. And please recall that one of the > points was to be able to store data in transit outside a router.. > being able to do this affects what can be assumed about how time is > handled and when throwing data out is ok (as mentioned above). > > - Kevin > > On Thu, Mar 13, 2014 at 1:39 PM, Templin, Fred L > wrote: >> I would be happy to retire any problem statement for which there is >> one or more consensus solution - calling for solutions is the purpose >> for posting problem statements in the first place. >> >> Thanks - Fred >> fred.l.templin@boeing.com >> >>> -----Original Message----- >>> From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of = Johannes Morgenroth >>> Sent: Thursday, March 13, 2014 6:40 AM >>> To: dtn-interest@irtf.org >>> Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronizat= ion - Problem Statement >>> >>> Am 12.03.2014 21:33, schrieb Templin, Fred L: >>> > Delay Tolerant Networking Time Synchronization - Problem Statement >>> >>> Just to advertise my own work. There already exist an approach to >>> synchronize time between DTN nodes published in [1]. It has been >>> implemented/tested in IBR-DTN and uDTN (wireless sensor nodes). >>> >>> [1] http://dl.acm.org/citation.cfm?id=3D2348618 >>> >>> Regards, >>> Johannes Morgenroth >>> >>> _______________________________________________ >>> dtn-interest mailing list >>> dtn-interest@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-interest >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest >> > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > From nobody Sat Mar 15 16:35:22 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B501A023E for ; Sat, 15 Mar 2014 16:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jtjN2WDCvNC for ; Sat, 15 Mar 2014 16:35:18 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5A21A0216 for ; Sat, 15 Mar 2014 16:35:17 -0700 (PDT) Received: from [195.245.231.67:22560] by server-10.bemta-5.messagelabs.com id 29/5C-27081-DA3E4235; Sat, 15 Mar 2014 23:35:09 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-82.messagelabs.com!1394926507!14962163!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12062 invoked from network); 15 Mar 2014 23:35:08 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-15.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 15 Mar 2014 23:35:08 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sat, 15 Mar 2014 23:35:07 +0000 From: To: Date: Sat, 15 Mar 2014 23:35:06 +0000 Thread-Topic: [dtn-interest] problem statements Thread-Index: Ac9AaclGHsNPbKUjQTOxmKXcUS/diQAOXq/R Message-ID: <290E20B455C66743BE178C5C84F1240847E633477C@EXMB01CMS.surrey.ac.uk> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/akTuhtf3zBmZ3ns0HCfTPcnQaYg Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] problem statements X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 23:35:21 -0000 as has been said many times before, there are two dimensions to reliable de= livery getting there (in a timely fashion) preventing erasures getting the right stuff there (and knowing it's not wrong) - preventing err= ors the 2003 sigcomm paper discusses the first (and custody transfer helps with timeliness by limiting the scope of resends - often like proxying, sometimes like local ARQ resends). That handles packet loss and resends. that's where the focus of the sigcomm paper is. the sigcomm paper does not discuss the second. the E2E paper specifically concerns itself with error checking and checksums, no mention of those in t= he sigcomm paper. The importance of checksums wasn't understood; the importance of delivery was. But the sigcomm paper's emphasis on security gives errorchecking as an unconsidered sideeffect of a heavyweight security design, to guard against errors, first guard against attacks. And security needed timesync, so there's that. Lloyd Wood http://sat-net.com/L.Wood/dtn ________________________________________ From: kfallca@gmail.com [kfallca@gmail.com] On Behalf Of Kevin Fall [kfall@= kfall.net] Sent: 15 March 2014 16:15 To: Wood L Dr (Electronic Eng) Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] problem statements Oh please... not the same old debate and false assertions. You may dispute 'intentionally', but you would be wrong. Go ahead and read the e2e paper. It is in fact what drove the design wrt error control. In particular: >The answer is that threat number four may have been eliminated, but the ca= reful file transfer application must still >counter the remaining threats, = so it should still provide its own retries based on an end-to-end checksum = of the file. >And if it does so, the extra effort expended in the communica= tion system to provide a guarantee of reliable data >transmission is only r= educing the frequency of retries by the file transfer application; it has n= o effect on inevitability or >correctness of the outcome, since correct fil= e transmission is assured by the end-to-end checksum and retry whether >or = not the data transmission system is especially reliable. >Thus the argument: in order to achieve careful file transfer, the applicat= ion program that performs the transfer must >supply a file-transfer-specifi= c, end-to-end reliability guarantee - in this case, a checksum to detect fa= ilures and a >retry/commit plan. For the data communication system to go ou= t of its way to be extraordinarily reliable does not >reduce the burden on = the application program to ensure reliability. Also, in the 2003 DTN paper (section 4.5): >Furthermore, the provision of the end-to-end optional acknowledgment is co= nsistent with the end-to-end argument >[16] ---that only the applications= truly know what they require. - Kevin On Sat, Mar 15, 2014 at 8:27 AM, wrote: > Much of that discussion was on introducing the concepts of error detectio= n > and the end-to-end principle to a community unaware of them. > > I dispute the "intentionally" - it's hard to intentionally leave out some= thing > entirely unfamiliar, and from the early days of IPNSIG onward, I have not= seen a design > document discussing and explicitly rejecting such options. > > There are existing expired drafts on the time sync problem, on error dete= ction > sans security, etc. The group did not pursue them; they were > not viewed as important.. > > DTN is a set of operational requirements - difficult conditions, introduc= ing > errors, dealing with unreliability. Designing to meet those > requirements is something we call 'engineering'. It's worth > trying. > > > Lloyd Wood > http://sat-net.com/L.Wood/dtn > ________________________________________ > From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of Kevin Fal= l [kfall@kfall.net] > Sent: 13 March 2014 21:30 > To: Templin, Fred L > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] problem statements > > Part of the issue is whether the issues raised are indeed considered > to be 'problems', and in what context (operational, BP design, or > what). The bundle protocol didn't set out to solve all the problems > one might encounter in a DTN type of environment (evidently also now > known as "DIL" -- Disconnected, Intermittent, Limited). Perhaps most > relevant is that it didn't aim to sync clocks, didn't aim to provide > integrity on data (except within the context of the security protocol) > and didn't aim to solve the key management problem. All of this was > (intentionally) left for further R&D and/or to other options available > from the home system [e.g., many systems have their own non-BP time > sync options and keying], but the BP made use of these things on the > assumption (reasonable for many systems) they would be available. You > will find these discussions back several years through the archives. > > I would suggest that it might be worth pursuing a couple of questions. > There was once a discussion of 'what if some nodes don't have > synchronized time' and how to deal with that issue. There were also > explorations of, e.g., identity based encryption as an alternative to > conventional PKI. About the only issue from the 'problems' paper that > I accept as an actual issue is header integrity when BSP is not used. > In my opinion, that might be worth pursuing also, but seems pretty > straightforward-- likely not requiring its own 'problem statement' but > rather some agreed-upon solution. > > With regards to time specifically, the timestamp was primarily there > to know when throwing old data out is ok (as opposed to guiding the > priority of forwarding). Also, it is if anything more the case today > that most systems know the time. And please recall that one of the > points was to be able to store data in transit outside a router.. > being able to do this affects what can be assumed about how time is > handled and when throwing data out is ok (as mentioned above). > > - Kevin > > On Thu, Mar 13, 2014 at 1:39 PM, Templin, Fred L > wrote: >> I would be happy to retire any problem statement for which there is >> one or more consensus solution - calling for solutions is the purpose >> for posting problem statements in the first place. >> >> Thanks - Fred >> fred.l.templin@boeing.com >> >>> -----Original Message----- >>> From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of = Johannes Morgenroth >>> Sent: Thursday, March 13, 2014 6:40 AM >>> To: dtn-interest@irtf.org >>> Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronizat= ion - Problem Statement >>> >>> Am 12.03.2014 21:33, schrieb Templin, Fred L: >>> > Delay Tolerant Networking Time Synchronization - Problem Statement >>> >>> Just to advertise my own work. There already exist an approach to >>> synchronize time between DTN nodes published in [1]. It has been >>> implemented/tested in IBR-DTN and uDTN (wireless sensor nodes). >>> >>> [1] http://dl.acm.org/citation.cfm?id=3D2348618 >>> >>> Regards, >>> Johannes Morgenroth >>> >>> _______________________________________________ >>> dtn-interest mailing list >>> dtn-interest@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-interest >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest >> > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > From kliazovich@ieee.org Tue Mar 18 03:15:25 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA6D1A02D1 for ; Tue, 18 Mar 2014 03:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.646 X-Spam-Level: * X-Spam-Status: No, score=1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN3Ih-Bq-Q_5 for ; Tue, 18 Mar 2014 03:15:21 -0700 (PDT) Received: from mail1.unitn.it (mail1.unitn.it [193.205.206.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0D47E1A00A2 for ; Tue, 18 Mar 2014 03:15:21 -0700 (PDT) Received: from mail1.unitn.it (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 8FE85BD980_3281CAFB for ; Tue, 18 Mar 2014 10:15:11 +0000 (GMT) Received: from mailhub2.unitn.it (mailhub2.unitn.it [192.168.206.47]) by mail1.unitn.it (Sophos Email Appliance) with ESMTP id 0D16FBB6F9_3281CAFF for ; Tue, 18 Mar 2014 10:15:11 +0000 (GMT) Received: from disi.unitn.it (dit.unitn.it [193.205.194.4]) by mailhub2.unitn.it (Postfix) with ESMTP id F2824B0D3D8 for ; Tue, 18 Mar 2014 11:15:10 +0100 (CET) Received: by disi.unitn.it with ESMTP id s2IAF8L6003912; Tue, 18 Mar 2014 11:15:09 +0100 From: "Dzmitry Kliazovich" To: Date: Tue, 18 Mar 2014 21:15:04 +1100 Message-ID: <00a901cf4292$f01dffb0$d059ff10$@ieee.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AA_01CF42EF.238F3B00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9CZmgcw85ZUp2qRiSwr3equFzdHQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/qN7NJhkAghiUl7lfueIPufYmXWw Subject: [dtn-interest] CFP: Special Issue on Cloud Networking - IEEE Transactions on Cloud Computing X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 10:22:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AA_01CF42EF.238F3B00 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =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=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=3D=3D=3D=3D=3D=3D=3D=3D Special Issue on =93CLOUD NETWORKING=94 =20 IEEE Transactions on Cloud Computing =20 http://www.ieee-cloudnet.org/2014/TCC-SI-CloudNetworking.pdf =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=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=3D=3D=3D=3D=3D=3D=3D=3D =20 Guest Editors: Dzmitry Kliazovich, Bernabe Dorronsoro, Pascal Bouvry, = Albert Zomaya =20 Editor-in-Chief: Rajkumar Buyya =20 =20 *** Call for Papers *** =20 Cloud computing is entering our lives and changing the way people = consume information dramatically. Clouds transform IT infrastructures with an emphasis on making them flexible, affordable, and capable of serving millions of users, satisfying their computing or storage demands. The = design of early cloud computing systems has evolved from, and was dominated by, = the concepts of cluster and grid computing. Currently, as the concepts of = the cloud become advanced and mature, cloud networking and communication processes begin playing a central role. Cloud Networking has emerged as = a promising direction for cost-efficient and reliable service delivery = across data communication networks. The dynamic location of service facilities = and the virtualization of hardware and software elements are stressing the communication network and protocols, especially when datacenters are interconnected through the Internet. =20 The optimization of cloud networking can significantly increase system performance, reducing energy consumption and save costs not only inside individual data centers, but also globally, on the Internet scale. Developing novel network architectures would facilitate adoption of = modular container-based data centers. Advancements in internetworking become key enabler for building hybrid clouds and federations of clouds. Service provisioning over heterogeneous connections and wireless links can = enhance computational capacity and enrich application experience of mobile = users. Efficient resource management and scheduling in data centers and cloud infrastructures is open research challenge that has to be addressed and novel architectures, telecommunication technologies, and protocols must = be developed to ensure efficiency of future cloud computing systems. =20 =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=3D=3D=3D=3D=3D=3D=3D Topics =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=3D=3D=3D=3D=3D=3D=3D =20 The topics covered by this special issue include, but are not limited = to: - Data Center Network Management, Reliability, Optimization - Distributed Data Center Architectures and Services, IaaS, PaaS, SaaS - Energy-Efficient Data Centers and Networks - Big Data Management - Internet Routing of Cloud Data - Virtual Ethernet Switching, Data Center Bridging - Cloud Traffic Characterization and Measurements - Intra-Cloud vs. Inter-Cloud Management - Cloud Traffic Engineering and Control-Plane Architectures - Green Data Centers and Cloud Networking - Security, Privacy, and Confidentiality in Cloud Networking - Virtualization of Network Equipment - Unified User and Machine Mobility Management - Data Flow Management and Load Balancing - Mobile Cloud Networking - Network Programmability, Software-Defined Networks - Cloud Federation and Hybrid Cloud Infrastructure - Storage Area Networks, Optical Interconnect, Fiber Channels - Content and Service Distribution =20 =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=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=3D=3D=3D=3D=3D=3D=3D Full Paper Regular Submission Due: October 15, 2014 Extended versions of CLOUDNET 2014 Best Papers due: December 15, 2014 Notification of Results: March 15, 2015 Revisions Due: April 15, 2015 Notifications of Final Acceptance: May 15, 2015 Submissions of Final Revised Papers: June 15, 2015 =20 =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=3D=3D=3D=3D=3D=3D=3D Notes for Prospective Authors =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=3D=3D=3D=3D=3D=3D=3D We are looking for novel outstanding high quality contributions. = Submitted papers should not have been previously published nor be currently under consideration for publication elsewhere. =20 All papers are refereed through a strict review process. A general guide = for authors and other relevant information for submitting papers are = available on the IEEE Transactions on Cloud Computing journal website: http://www.computer.org/portal/web/tcc =20 When submitting your paper, please be sure to choose the special issue = on =93Cloud Networking=94. =20 =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=3D=3D=3D=3D=3D=3D=3D=3D Guest Editors =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=3D=3D=3D=3D=3D=3D=3D=3D =20 Dr. Dzmitry Kliazovich, Dr. Bernab=E9 Dorronsoro, Prof. Dr. Pascal = Bouvry University of Luxembourg, Luxembourg {dzmitry.kliazovich, bernabe.dorronsoro, pascal.bouvry}@uni.lu =20 Prof. Dr. Albert Zomaya The University of Sydney, Australia a.zomaya@usyd.edu.au =20 ------=_NextPart_000_00AA_01CF42EF.238F3B00 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

=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=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=3D=3D=3D=3D=3D=3D=3D=3D

Special Issue on “CLOUD = NETWORKING”

 

IEEE = Transactions on Cloud Computing

 

http://www.ieee-cloudnet.org/2014/TCC-SI-CloudNetworkin= g.pdf

=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=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=3D=3D=3D=3D=3D=3D=3D=3D

 

Guest = Editors: Dzmitry Kliazovich, Bernabe Dorronsoro, Pascal Bouvry, Albert = Zomaya

 

Editor-in-Chief: Rajkumar Buyya

 

 

*** Call for = Papers ***

 

Cloud computing is entering our lives and changing the = way people consume information dramatically. Clouds transform IT = infrastructures with an emphasis on making them flexible, affordable, = and capable of serving millions of users, satisfying their computing or = storage demands. The design of early cloud computing systems has evolved = from, and was dominated by, the concepts of cluster and grid computing. = Currently, as the concepts of the cloud become advanced and mature, = cloud networking and communication processes begin playing a central = role. Cloud Networking has emerged as a promising direction for = cost-efficient and reliable service delivery across data communication = networks. The dynamic location of service facilities and the = virtualization of hardware and software elements are stressing the = communication network and protocols, especially when datacenters are = interconnected through the Internet.

 

The = optimization of cloud networking can significantly increase system = performance, reducing energy consumption and save costs not only inside = individual data centers, but also globally, on the Internet scale. = Developing novel network architectures would facilitate adoption of = modular container-based data centers. Advancements in internetworking = become key enabler for building hybrid clouds and federations of clouds. = Service provisioning over heterogeneous connections and wireless links = can enhance computational capacity and enrich application experience of = mobile users. Efficient resource management and scheduling in data = centers and cloud infrastructures is open research challenge that has to = be addressed and novel architectures, telecommunication technologies, = and protocols must be developed to ensure efficiency of future cloud = computing systems.

 

=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=3D=3D=3D=3D=3D=3D=3D

Topics

=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=3D=3D=3D=3D=3D=3D=3D

 

The topics = covered by this special issue include, but are not limited = to:

- Data Center Network Management, = Reliability, Optimization

- = Distributed Data Center Architectures and Services, IaaS, PaaS, = SaaS

- Energy-Efficient Data Centers = and Networks

- Big Data = Management

- Internet Routing of = Cloud Data

- Virtual Ethernet = Switching, Data Center Bridging

- = Cloud Traffic Characterization and Measurements

- Intra-Cloud vs. Inter-Cloud = Management

- Cloud Traffic = Engineering and Control-Plane Architectures

- Green Data Centers and Cloud = Networking

- Security, Privacy, and = Confidentiality in Cloud Networking

- = Virtualization of Network Equipment

- = Unified User and Machine Mobility Management

- Data Flow Management and Load = Balancing

- Mobile Cloud = Networking

- Network Programmability, = Software-Defined Networks

- Cloud = Federation and Hybrid Cloud Infrastructure

- Storage Area Networks, Optical Interconnect, Fiber = Channels

- Content and Service = Distribution

 

=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=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=3D=3D=3D=3D=3D=3D=3D

Full Paper Regular Submission Due: = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 October 15, 2014

Extended versions of CLOUDNET 2014 Best Papers = due:=A0=A0=A0 December 15, 2014

Notification of = Results:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 March 15, 2015

Revisions = Due:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 April 15, = 2015

Notifications of Final = Acceptance:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 May 15, 2015

Submissions of Final Revised = Papers:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 June 15, 2015

 

=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=3D=3D=3D=3D=3D=3D=3D

Notes for Prospective Authors

=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=3D=3D=3D=3D=3D=3D=3D

We are looking for novel outstanding high quality = contributions. Submitted papers should not have been previously = published nor be currently under consideration for publication = elsewhere.

 

All papers are refereed through a strict review = process. A general guide for authors and other relevant information for = submitting papers are available on the IEEE Transactions on Cloud = Computing journal website: = http://www.computer.org/portal/web/tcc

 

When = submitting your paper, please be sure to choose the special issue on = “Cloud Networking”.

 

=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=3D=3D=3D=3D=3D=3D=3D=3D

Guest Editors

=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=3D=3D=3D=3D=3D=3D=3D=3D

 

Dr. Dzmitry = Kliazovich, Dr. Bernab=E9 Dorronsoro, Prof. Dr. Pascal = Bouvry

University of Luxembourg, = Luxembourg

{dzmitry.kliazovich, = bernabe.dorronsoro, pascal.bouvry}@uni.lu

 

Prof. Dr. = Albert Zomaya

The University of = Sydney, Australia

a.zomaya@usyd.edu.au

 

------=_NextPart_000_00AA_01CF42EF.238F3B00-- From nobody Tue Mar 18 03:47:40 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576281A03BA for ; Tue, 18 Mar 2014 03:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2XyynYwZYgo for ; Tue, 18 Mar 2014 03:47:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A6DED1A03C4 for ; Tue, 18 Mar 2014 03:47:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93B4FBE8E; Tue, 18 Mar 2014 10:47:27 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xccJ+SrNlVPw; Tue, 18 Mar 2014 10:47:27 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6E9ABBE8A; Tue, 18 Mar 2014 10:47:27 +0000 (GMT) Message-ID: <5328243F.2070504@cs.tcd.ie> Date: Tue, 18 Mar 2014 10:47:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dzmitry Kliazovich , dtn-interest@irtf.org References: <00a901cf4292$f01dffb0$d059ff10$@ieee.org> In-Reply-To: <00a901cf4292$f01dffb0$d059ff10$@ieee.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/6GGYzoiRwznbvfw8i6SLG8HLWoE Subject: Re: [dtn-interest] CFP: Special Issue on Cloud Networking - IEEE Transactions on Cloud Computing X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 10:47:39 -0000 Please do not send CFPs to this list without asking one of the RG chairs first. This CFP seems off topic as well. S. From nobody Fri Mar 21 09:50:14 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492F51A099C for ; Fri, 21 Mar 2014 09:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emSHxjjmJJC4 for ; Fri, 21 Mar 2014 09:50:07 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id AC16A1A08D2 for ; Fri, 21 Mar 2014 09:50:07 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 09FA1A80D8 for ; Fri, 21 Mar 2014 11:49:58 -0500 (CDT) Received: from NDJSCHT107.ndc.nasa.gov (ndjscht107-pub.ndc.nasa.gov [198.117.1.207]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s2LGnvPX032338 for ; Fri, 21 Mar 2014 11:49:57 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.153]) by NDJSCHT107.ndc.nasa.gov ([198.117.1.207]) with mapi id 14.03.0174.001; Fri, 21 Mar 2014 11:49:57 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "dtn-interest@irtf.org" Thread-Topic: DTNRG wiki Thread-Index: AQHPRSWXDAP826x6CEmzXV3YxrhJgw== Date: Fri, 21 Mar 2014 16:49:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [139.88.111.195] Content-Type: multipart/alternative; boundary="_000_CF51E5BB11151williamdivancicnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-21_05:2014-03-21,2014-03-21,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/b3BPTv6GbEjiT9QPN5IiSHlO4GI Subject: [dtn-interest] DTNRG wiki X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:50:10 -0000 --_000_CF51E5BB11151williamdivancicnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current URL for the DTNRG is: http://www.dtnrg.org And it takes you to the wiki hosted by Trinity College of Dubin. There was= discussion of moving the DTN wiki to google sites because support/maintenance at Trinity was unclear into the future. The sites.goo= gle.com wiki is up and running. URL is https://sites.google.com/site/dtnres= group/home. This link is currently on the Trinity wiki. Site Administrators currently are: * Hans Kruse, Ohio University (kruse AT ohio.edu) * Will Ivancic, NASA (william.d.ivancic AT nasa.gov) * Keith Scott, Mitre (kscott AT mitre.org) * Shawn Ostermann, Ohio University (osterman AT ohio.edu) Perhaps the URL should point to the google sites and we can put a link to the old site rather than the current way which has the URL point to the Trinity site with a link to sites.google.com. We believe Vint owns the= DTNRG.ORG domain so that would have to be re-pointed. All updates would then be on the sites.google.com wiki. Thoughts/suggestions/opposition? Will --_000_CF51E5BB11151williamdivancicnasagov_ Content-Type: text/html; charset="us-ascii" Content-ID: <0AF9F2207EF30F4D82D29888214658D3@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable
The current URL for the DTNRG is:


And it takes you to the wiki hosted by Trinity College of Dubin.  = ;There was discussion of moving the DTN= wiki to google sites because
support/maintenance  at Trinit= y was unclear into the future.  The sites.google.com wiki is up and ru= nning. URL is https://sites.google.com/sit= e/dtnresgroup/home.  This link is currently on the Trinity wiki.

Site Administrators currently are:
* Hans Kruse, Ohio University (kruse AT ohio.edu)
* Will Ivancic, NASA (william.d.ivancic AT nasa.gov)
* Keith Scott, Mitre (kscott AT mitre.org)
* Shawn Ostermann, Ohio University (osterman AT ohio.edu)

Perhaps the URL should point to the goog= le sites and we can put a link to
the old site rather than the current way= which has the URL point to
the Trinity site with a link to sites.go= ogle.com.  We believe Vint owns the DTNRG.ORG
domain so that would have to be re-point= ed.

All updates would then be on the sites.g= oogle.com wiki.  

Thoughts/suggestions/opposition?

Will


--_000_CF51E5BB11151williamdivancicnasagov_-- From nobody Tue Mar 25 00:57:27 2014 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AF21A010C for ; Tue, 25 Mar 2014 00:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekP-oYYjSani for ; Tue, 25 Mar 2014 00:57:20 -0700 (PDT) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7181A012F for ; Tue, 25 Mar 2014 00:57:19 -0700 (PDT) Received: from DLREXHUB02.intra.dlr.de (172.21.152.140) by dlrexedge01.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 25 Mar 2014 08:57:17 +0100 Received: from DLREXMBX01.intra.dlr.de ([fe80::d198:77e5:d411:fccd]) by dlrexhub02.intra.dlr.de ([::1]) with mapi id 14.03.0174.001; Tue, 25 Mar 2014 08:57:17 +0100 From: To: Thread-Topic: Globecom 2014: SAC-SSC Track: DEADLINE 1st April Thread-Index: Ac9H/6QcyfdakqcRRZiulzSptThWww== Date: Tue, 25 Mar 2014 07:57:17 +0000 Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC31744316F@DLREXMBX01.intra.dlr.de> Accept-Language: it-IT, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1A39DCC13AF3C14B83CD74124D4DCFC31744316FDLREXMBX01intra_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/jwBxYMNhgokhgHpV11Eg-Kqm0dM Subject: [dtn-interest] Globecom 2014: SAC-SSC Track: DEADLINE 1st April X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 07:57:25 -0000 --_000_1A39DCC13AF3C14B83CD74124D4DCFC31744316FDLREXMBX01intra_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleagues, This is a gentle reminder for submitting papers to the Satellite and Space = Communications track in Globecom 2014, held in Austin, Texas, USA, on Decem= ber, 8-12, 2014. Deadline: 1st of April. I apologize if you receive multiple copies of this announcement. ***************************************************************************= ******** CALL FOR PAPERS IEEE Globecom 2014 http://www.ieee-globecom.org/ Dec 8-12, 2014 - Austin, Texas, USA ***************************************************************************= ******** The recent advances of satellite communication technology have witnessed an= unprecedented increase of services possibly distributed according to anywh= ere-anytime paradigm. To this regard, the appearance of new standards and t= he simultaneous integration with terrestrial infrastructure has introduced = new technical challenges to be faced by the scientific community. The Satellite and Space Communications track solicits original and unpublis= hed work not currently under review by any other conference or journal. The= focus of this track is on exploring and discussing new technical breakthro= ughs and applications focusing on all aspects of satellite and space commun= ications. MAIN TOPICS of INTEREST * Satellite and space communications and networking * Near-Earth satellite communications * Antennas for Satellite Communications * MIMO satellite communications * Hybrid satellite/terrestrial networks * Coding, modulation and synchronization schemes for satellite communicatio= ns * Channel models for satellite communications * Reliable multicast protocols for satellite networks * Transport protocol performance over satellite * Game theory applications in satellite networks * Security, privacy, and trust in satellite networks * Radio resource management in satellite networks * Emerging standards: DVB-SX, DVB-SH, DVB-RCS2, IP over Satellite * Cognitive satellite networks * Delay Tolerant Networking for satellite networks * Cross-layer air interface design * On-board switching and processing technologies * QoS and performance for satellite networks * Fade mitigation techniques over satellite channels * Special protocols for nano-satellites * Nano-satellites communications * Nano-Satellite constellation design * M2M over satellite applications * Geographic information systems * Wireless positioning technologies and applications * Signal detection and estimation for satellite communications * RF engineering for satellite communications * Statistical and adaptive signal processing for satellite systems * Satellite-based disaster recovery * Satellite-based remote e-Health * Satellite based alarm systems * Satellite-based solutions for aeronautical applications * Interplanetary communications * Next-generation channel coding for deep-space communications Sponsoring Technical Committees: * Satellite and Space Communications (SSC) HOW TO SUBMIT A PAPER The submissions will be handled electronically at https://edas.info/newPape= r.php?c=3D16651 The IEEE Globecom 2014 website provides full instructions on the paper form= atting: http://www.ieee-globecom.org/2014/submguide.html#.UyBwE4Uz3oY IMPORTANT DATE Paper submission due APRIL 1, 2014 (hard deadline) ------------------------ Deutsches Zentrum f=FCr Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaff= enhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola@dlr.de= http://www.dlr.de/kn/institut/abteilungen/san --_000_1A39DCC13AF3C14B83CD74124D4DCFC31744316FDLREXMBX01intra_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

 

This is a gentle reminder for submitting papers to t= he Satellite and Space Communications track in Globecom 2014, held in Austi= n, Texas, USA, on December, 8-12, 2014.

 

Deadline: 1= st of April.

 

I apologize if you receive multiple copies of this a= nnouncement.

 

****************************************************= *******************************
                &nbs= p;             =           CALL FOR PAPERS

                = ;             &= nbsp;       IEEE Globecom 2014
               =    
                = ;  http://www.ieee-glob= ecom.org/

               =            Dec 8-12, 2014= - Austin, Texas, USA

***************************************************************************= ********
The recent advances of satellite communication technology have witnessed an= unprecedented increase of services possibly distributed according to anywh= ere-anytime paradigm. To this regard, the appearance of new standards and t= he simultaneous integration with terrestrial infrastructure has introduced new technical challenges to be f= aced by the scientific community.

The Satellite and Space Communications track solicit= s original and unpublished work not currently under review by any other con= ference or journal. The focus of this track is on exploring and discussing = new technical breakthroughs and applications focusing on all aspects of satellite and space communications.<= /p>

 

MAIN TOPICS of INTEREST

• Satellite and space communications and netwo= rking

• Near-Earth satellite communications

• Antennas for Satellite Communications

• MIMO satellite communications

• Hybrid satellite/terrestrial networks

• Coding, modulation and synchronization schem= es for satellite communications

• Channel models for satellite communications<= o:p>

• Reliable multicast protocols for satellite n= etworks

• Transport protocol performance over satellit= e

• Game theory applications in satellite networ= ks

• Security, privacy, and trust in satellite ne= tworks

• Radio resource management in satellite netwo= rks

• Emerging standards: DVB-SX, DVB-SH, DVB-RCS2= , IP over Satellite

• Cognitive satellite networks

• Delay Tolerant Networking for satellite netw= orks

• Cross-layer air interface design<= /p>

• On-board switching and processing technologi= es

• QoS and performance for satellite networks

• Fade mitigation techniques over satellite ch= annels

• Special protocols for nano-satellites

• Nano-satellites communications

• Nano-Satellite constellation design

• M2M over satellite applications

• Geographic information systems

• Wireless positioning technologies and applic= ations

• Signal detection and estimation for satellit= e communications

• RF engineering for satellite communications<= o:p>

• Statistical and adaptive signal processing f= or satellite systems

• Satellite-based disaster recovery=

• Satellite-based remote e-Health

• Satellite based alarm systems

• Satellite-based solutions for aeronautical a= pplications

• Interplanetary communications

• Next-generation channel coding for deep-spac= e communications

Sponsoring Technical Committees:

•       &nb= sp;     Satellite and Space Communications (SSC)

 

HOW TO SUBMIT A PAPER

The submissions will be handled electronically at https://edas.info/newPaper.php?c=3D16651

 

The IEEE Globecom 2014 website provides full instruc= tions on the paper formatting:

 

http://www.ieee-globecom.org/2014/submguide.html#.UyB= wE4Uz3oY

 

IMPORTANT DATE

 

Paper submission due      &= nbsp; APRIL 1, 2014 (hard deadline)

 

 

——————= ;——————————R= 12;———————
Deutsches Zentrum f=FCr Luft- und Raumfa= hrt (DLR)
German Aerospace Center
Institute of Communications and Navigation = | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany

Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax=   +49 8153 28-2844 | tomaso.decola@dlr.de
http://www.dlr.de/kn/institut/abtei= lungen/san

 

--_000_1A39DCC13AF3C14B83CD74124D4DCFC31744316FDLREXMBX01intra_--