Subject: [dtn-interest] Fwd: wireless location tracking
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Date: Sat, 23 Nov 2002 11:58:15 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

>Date: Fri, 22 Nov 2002 22:52:16 +0000
>From: Tatiana Covington <[email-masked]>
>X-Originating-IP: [150.135.48.79]
>To: [email-masked], [email-masked]
>Bcc:
>X-OriginalArrivalTime: 22 Nov 2002 22:52:16.0793 (UTC)
> FILETIME=[CE32D090:01C29279]
>
>Indiana University researchers present new tools at supercomputing conference
>
>BLOOMINGTON, Ind. -- Indiana University information technology experts working with others from the state's leading educational institutions presented several new tools in high-performance computing, networks and visualization this week to colleagues at the international Supercomputing2002 conference in Baltimore, Md. Among the tools demonstrated were a system that can track the physical location of wireless devices and a powerful mapping application.
>
>The contributions of IU and its Research in Indiana (http://www.research-indiana.org) partners, Purdue University, the University of Notre Dame and Rose-Hulman Institute of Technology, were displayed at the Baltimore Convention Center.
>
>"Once again we have demonstrated that collaboration among some of Indiana's top universities is possible and beneficial to all involved," said IU Vice President for Information Technology and Chief Information Officer Michael A. McRobbie. "The Research in Indiana booth is the only research exhibit organized by a consortium of universities working together to promote their state as a venue for high-tech research, development and industry."
>
>One of the new tools, GeoMapper, has an innovative tabletop display and allows groups of people to get information about businesses or other points of interest from a map of the world. By placing a small physical marker over a location or area, visitors to SC2002 could study geography at scales ranging from the entire earth's surface down to locations within walking distance of the convention. The system was developed by Polly Baker, director of the Visualization and Interactive Spaces Lab, and Senior Technical Lead Rob Stein. The Visualization and Interactive Spaces Lab in Indianapolis is one of five IU Pervasive Technology Labs (http://www.pervasivetechnologylabs.iu.edu).
>
>Also on display was the wireless network Warscope, which uses a rotating antenna to locate, identify and display the physical location of network devices by detecting their wireless connections. Developed in Pervasive Tech Labs' Bloomington-based Advanced Network Management Lab by Director Steven Wallace's research group, Warscope has a number of potential applications, such as identifying hackers who are using mobile computing devices for malicious purposes.
>
>"The response to the technology developed by Pervasive Technology Labs has been just phenomenal," said Dennis Gannon, chair of the IU Computer Science Department and science director of Pervasive Technology Labs. "This really demonstrates the importance of the cutting-edge information technology being developed at Indiana University by Pervasive Technology Labs."
>
>Members from the other three Pervasive Tech Labs -- the Knowledge Acquisition and Projection Lab, directed by Donald F. McMullen; the Open Systems Lab, directed by Andrew Lumsdaine; and the Community Grids Lab, directed by Geoffrey C. Fo -- also presented new technologies to conventioneers.
>
>Craig Stewart, University Information Technology Services (UITS) director of research and academic computing, lauded Research in Indiana's support of inter-institutional research. "In addition to the national exposure we have received, the Research in Indiana display has provided many benefits within the state of Indiana," Stewart said. "This collaborative display is now in its third year, and in that time we have seen several research collaborations develop between the universities as a result, thus enabling new and innovative research."
>
>Since its inception, the IU Pervasive Technology Labs have brought over $4.5 million in out-of-state funding into Indiana. IU's other IT-related research and development efforts have brought $35 million in out-of-state monies to the state since 1998. Research in Indiana images and multimedia, including descriptions of the research projects displayed, are available at http://www.research-indiana.org/pics.html.
>
>Office of Communications & Marketing
>530 E. Kirkwood Ave., Suite 201
>Bloomington, IN 47408
>(812) 855-3911
>[email-masked]
>Christine Fitzpatrick
>UITS 317-278-1818
>[email-masked]
>November 21, 2002
>
>
>
>
>
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

Date: Mon, 18 Nov 2002 21:44:30 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: WHY I'M NOT FEELING CONFIDENT
Sender: [email-masked]

--Boundary_(ID_hjCvVm3QJXiNjFH3+doe1Q)
Content-type: text/plain; charset=us-ascii

this just showed up in my inbox.

>Bush.jpg

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

--Boundary_(ID_hjCvVm3QJXiNjFH3+doe1Q)
Content-id: <[email-masked]>
Content-type: image/jpeg; x-mac-creator=4A565752; x-mac-type=4A504547;
 name=Bush.jpg
Content-transfer-encoding: base64
Content-disposition: inline; filename=Bush.jpg

--Boundary_(ID_hjCvVm3QJXiNjFH3+doe1Q)--

Date: Thu, 14 Nov 2002 08:44:24 -0800
To: dtn-interest <[email-masked]>
From: Scott Burleigh <[email-masked]>
Subject: [dtn-interest] Re: Logistical networking intro? (was Re: [dtn-interest] Dialup andlaptop as DTN cases?)
Sender: [email-masked]

At 12:15 AM 11/14/2002 +0100, Benja Fallenstein wrote:

>BTW, the current DTN code implements both gatewaying and the software used 
>at the endpoints, right? (Or just the software run at the endpoints?) That 
>question goes to those familiar with the prototype, obviously.

Yes, the prototype bundleDaemon implementation functions at both the 
endpoints and the gateways.

Date: Wed, 13 Nov 2002 23:36:46 -0500
From: Greg Miller <[email-masked]>
Subject: Re: [dtn-interest] CHIPSat
To: Eric Travis <[email-masked]>
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Eric Travis writes:
[...]
>My memory is getting hazy but onboard, the satellite used:
>
>     FTP, TCP, IP, SCPS-SP & SCPS-NP 
>     (and *maybe* UDP; I remember us coding it up but don't 
>     recall it ever being flight-tested - it would have been 
>     a worthless test)

yep, you're right. I was still hacking away at the UDP code while you
guys were doing the onboard testing. UDP wasn't finished in time for
flight testing. Must have been the sophisticated vegas-style
congestion control that took me so long to perfect. :-)

I don't think we had any UDP apps anyway, except ttcp.

Greg

Date: Thu, 14 Nov 2002 00:15:54 +0100
From: Benja Fallenstein <[email-masked]>
To: Micah Beck <[email-masked]>, dtn-interest <[email-masked]>
Subject: Re: Logistical networking intro? (was Re: [dtn-interest] Dialup and laptop as DTN cases?)
Sender: [email-masked]

Hi Micah (taking this back to [dtn-interest] after off-list clarification),

Me (Benja):

>>Anyways, my summary of this discussion for myself is: IBP is useful for
>>many network applications that need transient storage. Implementation of
>>DTN gateways are one example of such an application.
>>
>>- Benja
>>    
>>
Micah:

>That's a conclusion that I can agree with.  If you were willing, it might be
>helpful if you were to explain it to the dtn-interest mailing list.   As you
>can tell, it's not easy for me to explain the utility of IBP in a way that
>people on that list understand [...]. Once the DTN code is released, I am 
>interested in porting it to be able to use IBP as storage substrate, 
>and I'm sure that will also generate some interesting discussion.
>  
>

Well, I think that's probably the most sensible thing to do. Of course I 
haven't seen the code and everything, but I would actually guess that it 
doesn't make too much sense to build the first prototype of DTN on top 
of IBP-- because you *can* build it on ordinary local storage, which 
makes it easy to understand, easy to program and easy to deploy. I 
understand why IBP could be a useful tool to build a DTN gateway-- but 
not to get DTN started. OTOH, there's only benefit in you porting the 
prototype to IBP and thus providing additional experience with different 
DTN implementations :-) (And if DTN becomes popular, and it turns out 
that the IBP implementation is more efficient, surely people will be 
using it.)

BTW, the current DTN code implements both gatewaying and the software 
used at the endpoints, right? (Or just the software run at the 
endpoints?) That question goes to those familiar with the prototype, 
obviously.

>>>I think of it less as donating spare resources than as pooling resources,
>>>across higher-level services and across geographic boundaries.
>>>
>>>      
>>>
>>Yes, but *if* a gateway doesn't need more resources than are provided by
>>some of-the-shelf, cheap hard disk, it would become donating resources
>>(except of course, the people running the gateway could *also* use the
>>storage of the gateway then). Taking the Internet analogy, it would be
>>like a network that connects two other networks but never makes outbound
>>connections itself.
>>    
>>
>
>OK, but I would point out that if the two networks being connected both
>implement IBP storage pools for general purpose use, and if the DTN gateways
>are IBP-enabled, the there would be no need for DTN gateways to have any
>storage associated with them at all.  They could instead simply implement
>the control and routing necessary to move data between IBP storage pools on
>the networks they connect.  In this case, DTN would not be donating
>resources but using resources that are provisioned for common use, and
>perhaps allowing the gateway itself not to need a hard disk at all, which
>might have engineering benefits!
>

Yes, possibly. That's true.

Cheers,
- Benja

Date: Wed, 13 Nov 2002 15:34:12 -0500
From: Eric Travis <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] CHIPSat
Sender: [email-masked]

I'm not sure what relevance *any* of this has to DTN 
(an invitation for Kevin to drop a rather large hammer), 
but to correct some slight misunderstandings:

/ At 12:04 AM 11/13/2002, Timothy J. Salo wrote:/

>If I understand correctly,
>
>o    SpaceDev claims to be the first satellite to be controlled using
>     the Internet protocols

They unfortunately missed that mark by at *least* 6 years;

Others have flowed IP datagrams to/from a spacecraft and 
altered the behavior of things resident on the spacecraft.

While one can argue about precisely what "controlling a satellite" 
means, I believe the most "interesting" part of SpaceDev effort 
is to be dependent only on Internet protocols for monitoring, 
control, health/status etc.  A bold decision and I do hope it 
works out well for them.

None of the pushback on "being first" undercuts what SpaceDev 
seems to be attempting to do, but in terms of beating one breast 
and planting a flag as being pioneers (you know, the folks that 
usually meet unfortunate ends) other folks have been there before 
(AMSAT, CCSDS, DERA, NASA, DERA, etc.)

It's not like nobody has ever considered the possibility before,
it's an idea probably as old as the internet protocols themselves :o)

Nobody ever made a big deal out of previous internet protocol 
testing in the mid-90s because it wasn't (and still isn't) such 
a big deal in terms in any really relevant metric for spacecraft 
operations or advancing the state of the art.

Conspiracy theories aside, mission folks have the latitude to
use whatever communications protocols they choose for TT&C.  

>o    The Space Technology Research Vehicle used the SCPS protocols.

My memory is getting hazy but onboard, the satellite used:

     FTP, TCP, IP, SCPS-SP & SCPS-NP 
     (and *maybe* UDP; I remember us coding it up but don't 
     recall it ever being flight-tested - it would have been 
     a worthless test)

I still have vivid memories of the the transport testing and 
slight recollection of the FTP testing (silly);

>o    Internet addresses (or at least 10.x.x.x Internet addresses)
>     can be used in SCPS-NP packets.

While any IPv4 (or IPv6) address can be used in SCPS-NP header,
the relevant point is that for the transport testing on STRV
it was IPv4 that was used.  SCPS-NP testing came later.

>I assume that you are not including the SCPS protocols within the
>rubric of "Internet protocols".

I dunno... is it safe to assume that FTP/TCP/UDP/IPv4 haven't 
stopped being "Internet protocols"...

>Am I correct in understanding that the STRV used the SCPS protocols
>end-to-end, and didn't translate between the SCPS and Internet protocols

TCP (SCPS-TP/TCP-Tranquility) over IPv4 was used end-to-end in transport 
testing;

I don't actually recall it , but I can't imagine that the SCPS-NP testing 
involved end-to-end use of SCPS-NP encapsulation as I don't recall us having 
written a translating gateway that far back in time.

So, if you'll allow TCP & IP to be included in the rubric of "Internet Protocols"
then the answer to your question is yes: there was no translation involved.

>It appears to me that SpaceDev does have an interesting claim, namely
>an intent to use the Internet protocols end-to-end to control a satellite.
>I doesn't appear to me that the STRV attempted to do this.

The primary purpose of the STRV experiments was protocol testing;
In the process, payload (the experiment itself) was controlled
end-to-end using internet protocols (TCP and IP). It was all very
low-key - and rightly so.

The main interest in internet protocols was for end-to-end
communications with the payloads, nobody (at least back them)
was bold enough to seriously propose TT&C over IP.

>It also doesn't seem to me that the use of 10.x.x.x addresses within
>SCPS-NP packets (although I don't think the article indicates which
>SCPS-NP address family was used) invalidates SpaceDev's claim.
>But, perhaps I don't understand your point

In the interest of correcting your misimpression: the vast bulk of 
STRV protocol testing was done with IPv4 datagrams, not SCPS-NP packets.

Date: Wed, 13 Nov 2002 12:04:52 -0600 (CST)
From: "Timothy J. Salo" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] CHIPSat
Sender: [email-masked]

> From: "Adrian J. Hooke" <[email-masked]>
> Subject: Re: [dtn-interest] CHIPSat
> Date: Wed, 13 Nov 2002 08:17:43 -0800
> 
> At 08:20 PM 11/12/2002, Timothy J. Salo wrote:
> >SpaceDev's claim to be the first to use the Internet protocols to operate 
> >a satellite may be correct
> 
> Er, well, like most "company marketing news" it's not:
> 
> http://www.sdl.usu.edu/conferences/smallsat/proceedings/10/sess1/strv.pdf
> 
> The Space Technology Research Vehicle (STRV 1b) became the first spacecraft 
> that we know about to have an IP address on 02 January, 1996. Section 3 of 
> the paper chronicles that experiment:
> 
> The STRV demonstration was conducted by many of the same people who are now 
> principals in the DTN work. The protocols used are available at 
> http://www.scps.org

I'm not sure that I want to arbitrate between marketing departments,
but...

If I understand correctly,

o    SpaceDev claims to be the first satellite to be controlled using
     the Internet protocols.

o    The Space Technology Research Vehicle used the SCPS protocols.

o    Internet addresses (or at least 10.x.x.x Internet addresses)
     can be used in SCPS-NP packets.

I assume that you are not including the SCPS protocols within the
rubric of "Internet protocols".

Am I correct in understanding that the STRV used the SCPS protocols
end-to-end, and didn't translate between the SCPS and Internet protocols?

It appears to me that SpaceDev does have an interesting claim, namely
an intent to use the Internet protocols end-to-end to control a satellite.
I doesn't appear to me that the STRV attempted to do this.

It also doesn't seem to me that the use of 10.x.x.x addresses within
SCPS-NP packets (although I don't think the article indicates which
SCPS-NP address family was used) invalidates SpaceDev's claim.
But, perhaps I don't understand your point.

By the way, thanks for the reference.  I always wondered whether
and how widely the SCPS protocols were actually used.

(And, I must admit, that I haven't yet looked at the SCPS reference
implementation that you so kindly made available.)

-tjs

Date:     Wed, 13 Nov 2002 12:22:43 EST
From: Dave Mills <[email-masked]>
To: "Adrian J. Hooke" <[email-masked]>
cc: [email-masked]
Subject:  Re:  [dtn-interest] CHIPSat
Sender: [email-masked]

Adrian,

Not so fast. I recall that NTP was tested experimentally with an AMSAT
satellite sometime prior to 1996. That however was only an experiment
and IP may not have been used on an ongoing basis.

Dave

Date: Wed, 13 Nov 2002 08:17:43 -0800
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] CHIPSat
Sender: [email-masked]

At 08:20 PM 11/12/2002, Timothy J. Salo wrote:
>SpaceDev's claim to be the first to use the Internet protocols to operate 
>a satellite may be correct

Er, well, like most "company marketing news" it's not:

http://www.sdl.usu.edu/conferences/smallsat/proceedings/10/sess1/strv.pdf

The Space Technology Research Vehicle (STRV 1b) became the first spacecraft 
that we know about to have an IP address on 02 January, 1996. Section 3 of 
the paper chronicles that experiment:

The STRV demonstration was conducted by many of the same people who are now 
principals in the DTN work. The protocols used are available at 
http://www.scps.org

Best regards
Adrian

Date: Tue, 12 Nov 2002 22:20:48 -0600 (CST)
From: "Timothy J. Salo" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] CHIPSat
Sender: [email-masked]

> From: "David L. Mills" <[email-masked]>
> Subject: Re: [dtn-interest] CHIPSat
> Date: Wed, 13 Nov 2002 03:33:02 +0000
> 
> What is UoSat-12?  That's a AMSAT designation, but I show only 11, 14, 22
> and 36 in that series.

UoSat-12 is UO-36.

See http://www.amsat.org/amsat/sats/n7hpr/uo36.html

> I rang http://spacedev.com, but nobody was home.

SpaceDev published a paper on their use of the Internet
protocols on CHIPSat at the latest Small Satellite Conference.
Unfortunately, the only copy I can find is an (ugly) HTML version
cached by Yahoo.  Search for "Jeff Janicik".  Perhaps, with some
poking, SpaceDev will put the paper back online where it can be found.

SpaceDev's claim to be the first to use the Internet protocols
to operate a satellite may be correct, to answer Vint's question.

> Far as I know, all 28 AMSAT satellites now orgiting use ad-hoc TT&C on
> the beacon frequencies.

As I have said in other forums, I think it is pretty neat that NASA
had to use an academic/amateur satellite to demonstrate the use
of the Internet protocols in space.  And, I am disappointed that
amateurs didn't do it first.

-tjs

Date: Wed, 13 Nov 2002 03:33:02 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: Lloyd Wood <[email-masked]>
CC: Mark Adler <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] CHIPSat
Sender: [email-masked]

Lloyd,

What is UoSat-12? That's a AMSAT designation, but I show only 11, 14, 22
and 36 in that series. I rang http://spacedev.com, but nobody was home.
Far as I know, all 28 AMSAT satellites now orgiting use ad-hoc TT&C on
the beacon frequencies.

Dave

Lloyd Wood wrote:
> 
> On Mon, 11 Nov 2002, Mark Adler wrote:
> 
> > Possibly of interest to this list, the following was in a newsletter I
> > just got from SpaceDev (http://spacedev.com):
> >
> > "CHIPSat will be the first mission ever to use end-to-end satellite
> > operations over the Internet with TCP/IP and FTP. This concept was
> > analyzed and demonstrated by the NASA OMNI team via UoSat-12; however,
> > SpaceDev will be the first to implement the concept as the only means of
> > satellite communication."
> 
> TT&C by ftp?
> 
> novel.
> 
> L.
> 
> first time a satellite will have been lost due to CR/LF conversion.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: "Micah Beck" <[email-masked]>
To: "Benja Fallenstein" <[email-masked]>, "Lloyd Wood" <[email-masked]>
Cc: "J. Leigh Torgerson" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Dialup and laptop as DTN cases?
Date: Tue, 12 Nov 2002 10:37:10 -0500
Sender: [email-masked]

It is true that all bandwidth is constrained, and as are latency and
connectivity guarantees.  Internet flows that are aggregates of IP datagrams
delivered end-to-end are designed to operate in a certain portion of the
space of such constraints (in particular, placing upper bounds on latency
and diconnections).

The DTN architecture is designed to work in another portion of the contraint
space, one in which there are in fact lower bounds on expected latency and
disconnection which rule out certain applications altogether.  For this
reason, the DTN has adopted a "postal" model of message passing which may
not be well adapted to ceratin applications, such as streaming video or
interactive remote operation of experiments; we don't expect to be able to
support such applications in deep space.

If we consider terrestrial applications which call outside of the space for
which IP is designed, we find that the flows that they can produce may also
fall outside of the assumptions of the DTN architecture.   For instance,
terrestrial flows might have high bandwidth and low latency but somtimes be
disconnected.  While the DTN architecture would work for such applications,
they might not be able to take advantage of the ways in which the
terrestrial network differs from the stringent assumptions of deep space.

In order to take account of the many different ways in which the terrestrial
networking might fall outside the assumptions of the terrestrial Internet,
it is necessary to address the key archicectural issue with a highly generic
mechanism.  The central issue is that it may not be possible for data
arriving at an intermediate node to be forwarded immediately (or immeidate
forwarding may not even be desirable).  In DTN as in these other terrestrial
scenarios, the data may have to be stored for a while at the intermediate
node.  That said, there are a number of strategies that can be used to
determine how long data resides at the intermediate node, when it is relayed
to other nodes and when it is discarded.  DTN represents just one such
strategy.

There are scenarios that are very different from DTN where storing data
rather than forwarding it immediately is an important function.  For
instance, caching, content delivery and reliable multicast all make use of
storage in terrestrial networking in order to reduce bandwidth consumption
and latency.  In these cases, the incentives may be economic or
performance-related, not due to a challenged network.

The Internet Backplane Protocol (IBP) is a mechanism that was design
specifically to provide a mechanism that allows data to be stored at an
intermediate node, but rather than building routing and other functions into
IBP, they are left to higher layers in our "Network Storage Stack", which is
modeled on the IP Network Stack.  IBP can support higher level protocols
that are as different as DTN, Content Delivery, Data Grids, P2P file
distribution and even robust, buffered video delivery.  In all cases,
management of storage at intermeidate nodes is a key issue; we call the
general paradigm Logistical Networking.  I would suggest that anyone
interested in our approach read our paper that appeared at SIGCOMM 2002:

 An End-to-End Approach to Globally Scalable Network Storage
Beck, M., Moore, T., and Plank, J.
ACM SIGCOMM 2002 Conference, Pittsburgh, PA, USA, August 19-23
http://loci.cs.utk.edu/modules.php?name=Downloads&d_op=getit&lid=133

I guess we should have been thinking beyond "global scalability" when we
wrote that title!  There is more information on our project at our
Logistical Computing and Internetworking Lab Web site:
http://loci.cs.utk.edu.

Bringing the DTN architecture to the terrestrial Internet without factoring
it into appropriate layers, with a generic scalable storage management layer
below and more specific routing and application protocols layered on top of
it risks balkanization of this important area of asynrhonous networking.  I
think that a good step towards avoiding this would be to try porting the DTN
code  to use IBP as an underlying storage fabric.

Micah Beck
Associate Professor, Computer Science
Director, Logistical Computing and Internetworking Lab
University of Tennessee

----- Original Message -----
From: "Benja Fallenstein" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>
Cc: "J. Leigh Torgerson" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, November 12, 2002 7:58 AM
Subject: Re: [dtn-interest] Dialup and laptop as DTN cases?

> Lloyd Wood wrote:
>
> >On Tue, 12 Nov 2002, Benja Fallenstein wrote:
> >
> >
> >
> >>How about including dialup connections and laptop users in the examples
> >>under "What is DTNRG," on dtnrg.org?
> >>
> >>
> >
> >because we'd rather not have to think about PPP and AAA, thanks all
> >the same?
> >
>
> Would you have to? :-) Hey, I'm only saying "you should explain this is
> a use case for the DTN architecture"-- not "you should be working on it"
> if you're not interested.
>
> (Well, I admit I *do* think you should make the DTN architecture so that
> it can encompass those cases too, if that is possible-- but hopefully,
> that shouldn't be too hard.)
>
> >'performance-constrained' (whether by physics or policy limitations)
> >would cover both cases.
> >
> >But since everything's performance-constrained, it's something of an
> >empty phrase.
> >
>
> Hm. I guess I have to agree on both counts :-)
>
> - Benja
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 12 Nov 2002 13:58:30 +0100
From: Benja Fallenstein <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: "J. Leigh Torgerson" <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Dialup and laptop as DTN cases?
Sender: [email-masked]

Lloyd Wood wrote:

>On Tue, 12 Nov 2002, Benja Fallenstein wrote:
>
>  
>
>>How about including dialup connections and laptop users in the examples
>>under "What is DTNRG," on dtnrg.org?
>>    
>>
>
>because we'd rather not have to think about PPP and AAA, thanks all
>the same?
>

Would you have to? :-) Hey, I'm only saying "you should explain this is 
a use case for the DTN architecture"-- not "you should be working on it" 
if you're not interested.

(Well, I admit I *do* think you should make the DTN architecture so that 
it can encompass those cases too, if that is possible-- but hopefully, 
that shouldn't be too hard.)

>'performance-constrained' (whether by physics or policy limitations)
>would cover both cases.
>
>But since everything's performance-constrained, it's something of an
>empty phrase.
>

Hm. I guess I have to agree on both counts :-)

- Benja

Date: Tue, 12 Nov 2002 02:23:23 -0500
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] CHIPSat
To: Mark Adler <[email-masked]>, [email-masked]
Sender: [email-masked]

mark,

how does this differ from the use of TCP/IP and FTP over the SATNET in 1977?

vint

At 03:17 PM 11/11/2002 -0800, Mark Adler wrote:
>Possibly of interest to this list, the following was in a newsletter I just got from SpaceDev (http://spacedev.com):
>
>"CHIPSat will be the first mission ever to use end-to-end satellite operations over the Internet with TCP/IP and FTP. This concept was analyzed and demonstrated by the NASA OMNI team via UoSat-12; however, SpaceDev will be the first to implement the concept as the only means of satellite communication."
>
>mark
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

Date: Tue, 12 Nov 2002 01:55:45 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: CFP for the inaugural, International Conference on Space Mission Challenges for Information Technology (SMC-IT'2003)
Sender: [email-masked]

in case anyone is interested 

v

>Date: Mon, 11 Nov 2002 14:16:30 -0800
>From: "Sven U. Grenander" <[email-masked]>
>Subject: CFP for the inaugural, International Conference on Space Mission
> Challenges for Information Technology (SMC-IT'2003)
>X-Sender: [email-masked]
>To: "vinton g. cerf" <[email-masked]>
>
>CALL FOR PAPERS
>
>
>INTERNATIONAL CONFERENCE ON SPACE MISSION CHALLENGES FOR
>INFORMATION TECHNOLOGY (SMC-IT'2003)
>
>Pasadena Convention Center, Pasadena, California, USA
>July 13-16, 2003
>
>http://smc-it.jpl.nasa.gov
>
>
>SCOPE:
>
>The role of space information technology has progressively grown in
>importance from the earliest days of space exploration to today, with
>the result that it often dominates the costs and schedules of space
>mission projects. The International Conference on Space Mission
>Challenges for Information Technology (SMC-IT) is the first forum to
>gather system designers, engineers, scientists, practitioners, and
>space explorers for the objective of advancing information technology
>for space missions. The forum will provide an excellent opportunity for
>fostering technical interchange on all hardware and software aspects of
>IT applications in space missions.
>
>The conference will focus on current IT practice and challenges as well
>as emerging information technologies with applicability for future
>space missions. IT in all aspects of the space mission will be
>explored, including flight systems, relevant ground systems, science
>data processing, engineering and development tools, operations, and
>telecommunications. The entire IT lifecycle of the mission development
>will also be covered, such as conceptual design, engineering tools
>development, integration and test, operations, science analysis, and
>quality control.
>
>
>VENUE:
>
>The conference will be held in the beautiful Southern California city
>of Pasadena, home of the California Institute of Technology, the Jet
>Propulsion Laboratory, and the Tournament of Roses Parade, which is
>conveniently located near all popular attractions within the greater
>Los Angeles area, including Universal Studios, Hollywood, Disneyland,
>Beverly Hills, and many beaches.
>
>
>PAPER SUBMISSION:
>
>Novel space IT papers are solicited from all sectors of the space
>community, including earth orbiting systems, deep space missions,
>ground support systems, instruments, science, landers, rovers, and
>probes. The conference will address all space end application areas,
>including civilian, military, and commercial.  All submitted papers
>will be peer reviewed in a two-step process, starting with a one-page
>abstract, and if accepted, following with a 4-8 page manuscript that
>will be published in a conference proceedings.
>
>In addition to orally presented papers, the conference will include
>panel and poster sessions, tutorials, and an exhibition of the latest
>commercial products and technologies (industry, research labs, and
>universities).  For further information on participating in these
>areas, please refer to the conference web site.
>
>
>IMPORTANT DATES:
>
>One-Page Abstracts Deadline:           December 16, 2002
>Author Acceptance Notification:        January 15, 2003
>Final Full Manuscript Deadline:        March 17, 2003
>Publication Editorial Comments:        April 15, 2003
>Conference:                            July 13-16, 2003
>
>
>FURTHER INFORMATION:
>
>For more detailed information on specific IT topic areas, schedule,
>author information, and general logistics information please refer to
>the conference website:
>
>http://smc-it.jpl.nasa.gov
>
>To be placed on the SMC-IT informational mailing list, please refer to:
>
>http://smc-it.jpl.nasa.gov/joinList.cfm
>
>We look forward to seeing you in Pasadena in July of 2003!
>
>
>CONFERENCE CHAIRS:
>
>Sven Grenander (+1 818 354-0156)
>Larry Bergman (+1 818 393-5314)
>California Institute of Technology
>Jet Propulsion Laboratory
>4800 Oak Grove Drive
>Pasadena, California 91109-8099
>
>
>-Sven  (in the office with the window to the future)
>
>
>__________________________________________________________________________
>  Deputy  -  Center for Space Mission Information and Software Systems
>               Acting Manager - CSMISS Partnership Program
>   X4-0156 - MS 301-285 - Rm 301-280N - <http://csmiss.jpl.nasa.gov/>
>__________________________________________________________________________

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

Date: Mon, 11 Nov 2002 19:26:02 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: Re: kernelizing the network resolver
Sender: [email-masked]

have the DTN folks been following this discussion about network resolution?
The direction it is heading is very much like the discussion the DTN team
at JPL just had last week about new notions for identifying endpoints in
the DTN communication space. At least, on first reading of the attached,
that's the conclusion I reached. 

Vint

>Date: Sat, 09 Nov 2002 09:01:05 -0500
>From: V Guruprasad <[email-masked]>
>Subject: Re: kernelizing the network resolver
>Sender: [email-masked]
>To: Keith Moore <[email-masked]>
>Cc: [email-masked]
>Reply-to: [email-masked]
>X-Loop: [email-masked]
>User-Agent: Mutt/1.4i
>X-Authentication-warning: ietf.org: majordom set sender to [email-masked]
> using -f
>
>
>Dear Keith,
>
>
>Sorry I couldn't respond earlier (if, that is, a response was expected).
>
>On Thu 2002.11.07, Keith Moore wrote:
>
>> problem is, if you keep the same API, then apps that depend on that API
>> will expect that the name space has the same characteristics as DNS,
>> (benefits and shortcomings and everything else).  so for instance they
>> will still try to bypass DNS when DNS would have been a poor choice for
>> them.
>>
>> even if the resulting architecture makes more sense than the old one,
>> you can't expect to be compatible with existing apps if you significantly
>> change how the services that were accessed by those APIs work.
>
>The essence of my thesis is as follows:
>
>- A namespace suffices as the end to end primary/effective address space in
>  itself - no lower level or manually set up destination labels are necessary
>  to define names. A distributed name tree is itself an effective addressing
>  mechanism, and provides default end to end routes by up-and-down treewalk.
>
>  (Of course it wouldn't be optimal, hold your horses. Let's start with a
>  Pascal-like simplification at the high level for once, and treat the
>  practical/optimal/efficient/whatever routing as
>  a separate implementational/compiler/route-translation problem.)
>
>
>- Fixed length numeric addresses (FLNA) for routing, as in IP, can be
>  automatically assigned and reassigned to the names for
>  non-triangular/efficient/etc. routing, so long as
>
>        * an end to end primary EA space remains available
>                for datagrams and new connections;
>
>        * ongoing connected sessions are switched over transparently,
>          but this, as in Snoeren/Balakrishnan's paper for TCP,
>          should be treated as an individual protocol level issue
>          rather than an address space and management issue.
>
>  Note: I prefer the terms 'allocation' and 'assignment' for FLNA because
>  these terms are already used broadly in automated software like OS's and
>  device drivers for things like real memory/IO/bus addresses and interrupts.
>
>  'Renumbering' appears to be special to IP and connotes two things:
>  (a) that a human agent must be involved in deciding and effecting it, and
>  (b) that the connected universe constitutes a single numeric label space.
>
>  This is undue baggage that would limit reconsideration of the assumptions
>  currently made for IP, as will be clear from the next bullet. (In fact,
>  (b) is not even physically sound on the unlimited scale that I allow for.)
>
>
>- Notice that:
>        * Routing with FLNA can and would be done using automatic route
>          discovery, within each FLNA space, which ensures *independence*
>          of the FLNA-based actual routes from the namespace structure.
>
>        * Since every FLNA space involves management and FLNA are reflected in
>          routing tables, each FLNA represents *networking state*.
>
>        * We do not need, and in fact do not use a single FLNA today.
>          VPNs are FLNAs stacked vertically because of the end to end
>          paradigm we have been following philosophically. NAT gateways
>          illustrate horizontal tiling of FLNA spaces, although in
>          conventional NAT, the FLNA spaces overlap (over 192.168 etc.
>          private network ranges) and are not disjoint.
>
>          Using virtual path style state representation in the gateways
>          can yield the same level of connectivity for the same state volume,
>          with the essential difference that the address will now be faked
>          both ways making the client space disjoint. Secondary issues
>          like how the traffic will distribute across gateways concerns
>          distribution of the state across gateways. This has been in effect
>          shown for IP-like FLNAs in IPNL, and primary difference in going
>          to 2-way NAT or virtual paths is the signalling/initialization
>          mechanism for the state set up, not its resulting volume.
>
>          In other words, virtual path/circuit state represents horizontal
>          tiling form of network state - there's no getting away from state
>          altogether, only how much we keep horizontal and how much vertical.
>          To compare, IPNL describes a limited form of tiling.
>
>        * Given the state equivalence and the availability of an end to end
>          EA in the form of names, which applications already have to consult
>          every so often (from what I seem to recall reading, netscape caps
>          the ttl to 15 mins regardless of what the dns said), there is no
>          reason to continue mandating end-to-endness of an FLNA, which means
>          vertical stacking only as in VPNs.
>
>
>- Within an FLNA space, the route translation problem
>        from    namespace
>        to      non-triangular/efficient/optimal/
>                best-effort-but-better-than-Prasad's-namespace/
>                whatever-you-want-to-do routes
>        reduces to
>                the name->FLNA problem
>        which is
>                the DNS.
>
>  This essentially answers your comment above.  However, the treatment is now
>  more general than the current IETF/IRTF/IP vision:
>
>  Section 2 of my thesis describes linkage of the local DNS-equivalent
>  namespaces across FLNA spaces, provide the default "Prasad's stupid routes"
>  (PSR) defined by the namespace treewalks.
>
>  Section 3.2 describes IP-like datagram routing across FLNA spaces and
>  Section 3.3 describes route discovery and connection state setup across
>  FLNAs.
>
>  The latter routes need to partially dependent on PSRs, but only on the
>  unlimited scale allowed by horizontal tiling, because of very basic rules
>  of logic and physics, as explained in Section 1.1. On any finite scale,
>  however, the routing would reduce to being independent and IP-like.
>
>
>- Lastly, I haven't considered variable length numeric addresses (VLNA) other
>  than referring to the Nimrod. The only practical application that I can
>  recall is the worm routing in IBM's SP switch fabric, and the scarcity
>  of examples makes me a bit wary.
>
>  In any case, the namespace is in principle of variable length (ignoring the
>  pragmatic limits set in the dns), and the combination of namespace EA and
>  horizontal tiling of FLNA transports like IP seem to achieve the same thing.
>  There seems to be little motivation for an VLNA solely as transport, and
>  none, imho, as EA other than as textual names.
>
>
>> > It's so frustrating to work alone and become unable to communicate, even
>> > if it lightens the inertia to make great leaps quietly :(
>>
>> agreed.
>
>thanks ;-)
>
>
>-prasad.

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

Date: Mon, 11 Nov 2002 19:23:04 -0500
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] Dialup and laptop as DTN cases?
To: Benja Fallenstein <[email-masked]>, [email-masked]
Sender: [email-masked]

I'm in agreement with you and this notion of persistent processes communicating through frequently connectionless conditions is one of the reasons I got excited about the whole DTN concept. We've been focusing mostly on the IPN versionof this but we've have any number of discussions along the lines you mention.

Definitely worth pursuing!

Vint

At 10:02 PM 11/9/2002 +0100, Benja Fallenstein wrote:
>So anyhow, now I got myself excited over this again. :-) Why's nobody talking about this? What am I missing that makes this impossible/uninteresting?

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

Date: Tue, 12 Nov 2002 00:36:31 +0100
From: Benja Fallenstein <[email-masked]>
To: "J. Leigh Torgerson" <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Dialup and laptop as DTN cases?
Sender: [email-masked]

Hi Leigh,

you wrote:

> The applications you suggested are exactly why we expanded the 
> research from the Interplanetary realm to a more general category of 
> Delay-Tolerant Networking.

Great!

Ok, if that's so, maybe it should be advertised better? :-) From the 
public documents, I got the impression that the intended applications 
are either 'bring the 'net to new kinds of environments/users' 
(snowmobile networking, underwater, space, sensor networks) or 'make 
intelligent use of future high-tech equipment' (intelligent highways, 
kiosks acting as infrared base stations in airports). I.e., "It's really 
interesting, but it doesn't apply to me."

How about including dialup connections and laptop users in the examples 
under "What is DTNRG," on dtnrg.org? (Of course, this would bring it 
'out of sync' with the group's charter, but then again, charters aren't 
necessarily the best way to introduce a group anyway...)

Part of the confusion arises from the fact that neither "extreme" nor 
"performance-challenged" (from dtnrg.org/the charter) are adjectives 
really applicable to the dialup or laptop cases-- the emphasis would be 
on, "where end-to-end connectivity cannot be assumed." (Same holds for 
snowmobile networking...) So while "extreme and performance-challenged 
environments" are the chartered research areas of the group, I think it 
would be helpful in explanations of the DTN architecture/purpose to 
mention the applicability to more 'down-to-earth' areas ;-)

> We hope to get some open-source DTN bundling code out for public 
> experimentation and tinkering very soon - I have the source and I'm 
> working all the legal business to get it cleared for public release - 
> then you and others will be able to prototype some applications and 
> see where they lead us!

I'm looking forward to it :-)

- Benja

Date: Mon, 11 Nov 2002 15:17:28 -0800
From: Mark Adler <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CHIPSat
Sender: [email-masked]

Possibly of interest to this list, the following was in a newsletter I 
just got from SpaceDev (http://spacedev.com):

"CHIPSat will be the first mission ever to use end-to-end satellite 
operations over the Internet with TCP/IP and FTP. This concept was 
analyzed and demonstrated by the NASA OMNI team via UoSat-12; however, 
SpaceDev will be the first to implement the concept as the only means of 
satellite communication."

mark

Date: Mon, 11 Nov 2002 08:41:45 -0800
To: [email-masked]
From: "J. Leigh Torgerson" <[email-masked]>
Subject: Re: [dtn-interest] Dialup and laptop as DTN cases?
Cc: Benja Fallenstein <[email-masked]>
Sender: [email-masked]

A reply to the group and to Benja:

The applications you suggested are exactly why we expanded the 
research from the Interplanetary realm to a more general category of 
Delay-Tolerant Networking.

We hope to get some open-source DTN bundling code out for public 
experimentation and tinkering very soon - I have the source and I'm 
working all the legal business to get it cleared for public release - 
then you and others will be able to prototype some applications and 
see where they lead us!

regards,
Leigh

>Hi all!
>
>I've been reading through draft-irtf-ipnrg-arch-01, and was 
>surprised that the document did not mention what I would consider 
>the most immediate-- and in the short term, most important-- uses 
>for a Bundling protocol, and I wasn't able to find much discussion 
>about this so far. Probably I'm missing something pretty basic here, 
>but I thought that asking does not hurt ;-)

><good stuff clipped>

>So anyhow, now I got myself excited over this again. :-) Why's 
>nobody talking about this? What am I missing that makes this 
>impossible/uninteresting?
>
>Thanks for replying :-),
>- Benja
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Sat, 09 Nov 2002 22:02:50 +0100
From: Benja Fallenstein <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Dialup and laptop as DTN cases?
Sender: [email-masked]

Hi all!

I've been reading through draft-irtf-ipnrg-arch-01, and was surprised 
that the document did not mention what I would consider the most 
immediate-- and in the short term, most important-- uses for a Bundling 
protocol, and I wasn't able to find much discussion about this so far. 
Probably I'm missing something pretty basic here, but I thought that 
asking does not hurt ;-)

I'm talking about travelling laptop users and users of intermittent 
dialup connections (i.e., users who only occasionally go online, because 
their dialup is charged per minute or because they're blocking their 
telephone line while they're online). Both of these cases are a 
nuisance: You can read and write email while you are offline, but you 
cannot request web pages or transfer files, or receive messages from 
other computers (you can certainly not run a server in these cases). 
This is quite a nuisance; the most annoying thing I've found to be 
staying up at night to control a lengthy download because you have to 
cut the Internet connection after the download finishes.

Wouldn't it be slick if you could tell your computer to do that download 
(or continue it) next time it goes online, possibly at midnight where 
the rates are cheapest (or when any family member goes online anyway, 
for example to browse the web)? If you could browse offline, click on 
some link you don't have offline, and tell your computer to download the 
linked page and the pages it links to when it goes online next time? 
Maybe you would like to go online just for a short moment, having this 
page and the pages it links to downloaded, go offline, read those pages, 
then decide to go online for a short moment again to download more 
linked pages.

Yes, you can do these things today-- there are HTML off-line readers and 
so on, and you can write a script that goes online at midnight and 
invokes wget or whatever. However, these are ad-hoc solutions, and for 
many applications they don't work-- I'm on a project that uses CVS, and 
I can *not* schedule a 'cvs add' or 'cvs commit' while I'm on the train 
(or at school, where my laptop also has no Internet access). When I 
arrive somewhere where I have a dialup connection, I have to do these 
things *then*.

What if Bundling where built into my computer? On train, I could tell an 
application to download a web page or large file, perform a CVS commit, 
etc. (if there are Bundling-enabled applications to do this, of course). 
The applications would call a network layer, which would make bundles 
and store them. Next time I go online (whether scheduled or ad-hoc), 
these tasks can be performed for me. (Ideally, I could even tell my 
computer to send and receive bundles, then go offline again, so I would 
just have to plug it in and run some command, and I'd be free to do 
something else. A tool to do this would be completely 
application-independent, since it would only deal with the bundles 
stored at my computer's network layer.) If I want to download a file and 
I'm on an expensive dialup, and the route from the ISP to the server is 
really slow, I could send a bundle to the server, the server would send 
back the file as a bundle, and I wouldn't have to remain online while 
it's pushed through the slow link from the server to the ISP-- I could 
go offline, and the ISP would store the bundle to me; if I later go 
online again, I could get the file as fast as my dialup allows, because 
it is stored at one of my ISP's servers.

Dialup computers would even become first-class citizens-- not of the 
Internet, but at least of the DTN: It would be possible to send messages 
to them, so they could act as servers (or p2p peers). For example, when 
I'm abroad, I could send a bundle to my computer at home requesting some 
file; if that computer runs a bundling file server, next time it goes 
online (maybe because someone in the family wants to check mail) it gets 
my bundle, processes it, and sends back the file. With delays, I could 
access my hard disk at home, even though my laptop and the computer at 
home may never be online at the same time.

If this system became only mildly poplular, users of DTNs as mentioned 
in the I-D could benefit greatly. For example, snowmobile networking is 
certainly an exciting idea-- but it probably won't have *too* many 
users, compared to the number of users on the Internet at large. If they 
can only use applications specifically written for them, the pool will 
always remain quite limited. On the other hand, the number of dialup and 
travelling laptop users is quite large-- if there's any popularity for 
this, there would probably be enough geeks with an itch to produce a 
large suite of Free Software that works with bundling.

And as far as I can see, there is no reason why those bundling 
applications couldn't be used with snowmobile networking! Some of them 
could probably even be used with deep space connections (those whose 
bandwidth demands aren't very big). If an application is delay-tolerant 
enough to run on a dialup system, it should usually be delay-tolerant 
enough to be used with snowmobile or deep space links that may not be 
available for weeks.

So anyhow, now I got myself excited over this again. :-) Why's nobody 
talking about this? What am I missing that makes this 
impossible/uninteresting?

Thanks for replying :-),
- Benja

Date: Tue, 05 Nov 2002 11:31:32 +0000
From: Stephen Farrell <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
Cc: [email-masked], Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] interplanetary IP
Sender: [email-masked]

Are any on this list going to be at the IETF in Atlanta?
If so maybe a beer's in order? (At which point we might be
in a position to start a to-do list on a napkin.)

Stephen.

Durga Prasad Pandey wrote:
> A to-do list sounds like a good step forward!
> 
> Durga
> 
> 
> On Thu, 24 Oct 2002, Stephen 
> Farrell wrote:
> 
> 
>>Scott,
>>
>>Without having read your posting in the detail it deserves,
>>(yet!), I'd echo Hans' reaction here (esp. about starting
>>from IPv6).
>>
>>I'd also point out that RTP seems to be a similar case in
>>point - its been developed and used without changing the
>>Internet and is now fairly commonly supported by firewalls
>>(in terms of them having a button to allow/block RTP streams).
>>SCTP might also provide yet another analogous protocol.
>>
>>Firewall support is the real blocking factor to new protocols
>>layered on IP these days.
>>
>>So, basically, development of an Internet friendly LTP should
>>be quite feasible.
>>
>>So, to me, developing LTP as a layer on top of IP, and
>>developing IP drivers for the IPN constrained radio that
>>we have to live with, makes enormous sense.
>>
>>Having said that there are clearly DNS issues to be
>>tackled and I don't think that the sockets API is likely
>>to be sufficient, so the applications will generally have to
>>be aware that they are IPN applications and not any old
>>IP application.
>>
>>(As an IPsec aside, we'd also need to replace IKE, but
>>ESP is ok, and IKEv2 development is under way in the
>>IETF - so this is a note to me to check how the IKEv2 proposals
>>handle DTN/IPN-like conditions, but I think they probably
>>need multiple hops in one session, so we probably have to have
>>an IKEvipn as well.)
>>
>>Wouldn't it be good if we had a to-do list for IPN/IP?
>>
>>Stephen.
>>
>>Hans Kruse wrote:
>>
>>>Scott, thanks for a very concise wite-up, which I will re-read for more 
>>>in-depth thought.  I have embedded a few comments for now:
>>>
>>>--On Wednesday, October 16, 2002 13:29 -0700 Scott Burleigh 
>>><[email-masked]> wrote:
>>>
>>>
>>>>The next question is: why not do this instead of bundling?  I polled the
>>>>DTN development team, and the consensus seems to be that this
>>>>interplanetary-IP approach is in fact technically feasible.  The
>>>>bottom-line objection is that it would involve so much modification to
>>>>the current Internet infrastructure that it would never be implemented;
>>>>the problems that originally motivated the DTN architecture would remain
>>>>unsolved.  Here is a list of DTN features that would need to be reflected
>>>>in the enhanced Internet infrastructure to enable efficient operation of
>>>>an interplanetary internet based on end-to-end IP:
>>>>
>>>>1.    Deferred transmission.  Because next-hop connectivity in deep 
>>>>space is
>>>>intermittent, transmission of outbound packets must be deferred until a
>>>>link is available; these packets need to be retained in (preferably)
>>>>non-volatile storage for minutes, hours, even days.  [Possibly this
>>>>function can be delegated to the new link-layer interfaces rather than
>>>>implemented within IP itself.]
>>>
>>>This would seem to be an implementation issue at the host/router.  IP 
>>>does not have a concept of time, only hops (the Time to Live field is a 
>>>mis-nomer).  So why not store IP packets?
>>>
>>>
>>>>2.    Contact-sensitive routing.  At each router in deep space, accurate
>>>>selection of the next hop may depend on an awareness of anticipated
>>>>contact (link availability) periods, based on known schedules and planned
>>>>data rates, stochastic analysis, whatever.  Moreover, the high cost of
>>>>contact time may additionally make it desirable to consider packet
>>>>priority, size, and timeliness constraints in next-hop selection.  New
>>>>routing protocols to support these decisions would need to be built into
>>>>routers.
>>>
>>>This is a totally separate issue.  What you are saying is that you need 
>>>a routing protocol for deep space that is more complex than those 
>>>running in the Internet.  Routing protocols operate within admin 
>>>domains, so why don't you develop the routing protocol needed based on 
>>>IP packets, and deploy it in the deep space domain.  Once a packet gets 
>>>handed to the Internet, it will be routed based on the simpler Internet 
>>>routing, but that is ok.
>>>
>>>
>>>>3.    Recantation.  During the time that a packet directed to a given
>>>>interface (based on the complex analysis described above) is waiting in
>>>>non-volatile storage for the link to come up, new information may arrive
>>>>that makes a better routing decision possible.  To take advantage of this
>>>>opportunity, IP would need to be able to retrieve the packet from its
>>>>transmission queue and redirect it; this would require new inter-layer
>>>>signaling capabilities.  And in order to have the information it would
>>>>need to do that signaling, the router would need to retain some subset of
>>>>its own state in non-volatile storage.
>>>
>>>Again, you need to add features to the routers.  Would it not make more 
>>>sense to start with an IP router and add to it, rather than start from 
>>>scratch?  IP packets do carry an ID, so they can be tracked for this 
>>>purpose.
>>>
>>>
>>>>4.    Address space and name space organization.  End-to-end IP entails
>>>>management of a single, solar-system-wide IP address space and
>>>>correspondingly a single DNS namespace.  For efficiency in routing table
>>>>construction, netmasks that are functionally analogous to DTN region IDs
>>>>would probably need to be identified; equitable assignment of address
>>>>ranges for this purpose will itself be non-trivial.  Worse, perhaps, is
>>>>the problem of maintaining cache coherency among DNS servers distributed
>>>>across interplanetary space and connected by expensive, low-capacity
>>>>radio links; zone transfers would be prohibitively costly.  Some new
>>>>method of domain name propagation, perhaps built on some sort of
>>>>subscription model, would have to be invented.  (The DTN solution to this
>>>>problem is the "tuple" notion of distinct, region-specific DNS name
>>>>spaces and late binding of names to addresses in distinct,
>>>>region-specific address spaces.)
>>>
>>>I think I would not try this with IPv4.  However, with IPv6 I could 
>>>easily see nice big address spaces assigned whereever you need them.  I 
>>>have to think about DNS some more, but I assume you would use some form 
>>>of proxy on earth and manage zone transfers to deep space assets with a 
>>>new set of procedures.
>>>
>>>
>>>>5.    Application retrieval.  End-to-end transmission across a deep space
>>>>route can take so long that the communicating application instances
>>>>(processes, tasks, objects) may routinely terminate before it concludes.
>>>>We'll need a standardized way to restart an application instance on
>>>>packet arrival, restoring it to a state in which it can properly respond
>>>>to the newly arrived data.
>>>
>>>That is again a local implementation issue.  You will need the 
>>>equivalent of INETD listening on all ports (UDP in your diagram) and 
>>>have a local mechanism to start applications.
>>>
>>>
>>>>6.    Header compression.  Every bit transmitted on a deep space link is
>>>>precious; the overhead imposed by the UDP/IP header structure would be
>>>>uncomfortably expensive.  Header compression (maybe along the lines of
>>>>RFC 2507) would likely be needed.
>>>
>>>Yup.
>>>
>>>
>>>>7.    Multi-hop retransmission (custody transfer) and flexible reply-to
>>>>selection.  These are features built into DTN to improve network
>>>>performance and operability in the face of long propagation delays and
>>>>intermittent connectivity.  They too would need to be built into IP
>>>>router implementations to match the functionality of bundling.
>>>
>>>I don't know enough about these issues yet to comment.
>>>
>>>
>>>>The Internet is not frozen, certainly.  New work on inter-layer
>>>>signaling, tunneling, routing, compression and so on is already under
>>>>way.  In the event that the usefulness of the DTN architecture convinces
>>>>the IETF of its value, maybe the new features listed above will all find
>>>>their way into the network.
>>>
>>>
>>>In your description, I could not find any changes that would need to be 
>>>implemented Internet-wide, which leads me to think that further 
>>>discussion may be in order.  There may be some confusion between "IP" 
>>>and "IP Routing";  IP as an addressing and packet formatting method 
>>>would seem to meet all of the deep space needs.  Using IP means that 
>>>some of the hardware and firmware can be off-the-shelf.  This also means 
>>>that once they get to earth, the packet can be handed to the regular 
>>>Internet without modification.
>>>
>>>It seems to me that the feature you see as missing are all concentrated 
>>>in routers and routing protocols.  As I said before, it would seem to 
>>>make sense to start with IP routers and enhance them as needed for deep 
>>>space. Since routing protocols are never used on the entire internet, 
>>>there is no reason why deep space portion of the network would/could not 
>>>use its own routing protocols.  Today, the routing protocols inside an 
>>>organization, say a University, and the routing protocols used between 
>>>proviers, are totally different.
>>>
>>>So, you could implement your diagram (using IP), and start routing and 
>>>deploying the new routing protocols needed, and remain fully compatible 
>>>with the general Internet right now, even if the IETF never adopts the 
>>>new procedures.
>>>
>>>I am sure I overlooked a bunch of details, so this will likely be an 
>>>ongoing and interesting discussion.
>>>
>>>Hans Kruse, Associate Professor
>>>J. Warren McClure School of Communication Systems Management
>>>Adjunct Associate Professor of Electrical Engineering and Computer Science
>>>Ohio University, Athens, OH, 45701
>>>740-593-4891 voice, 740-593-4889 fax
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> 
> 

Date: Mon, 4 Nov 2002 18:05:10 -0500 (EST)
From: Durga Prasad Pandey <[email-masked]>
To: Stephen Farrell <[email-masked]>
cc: [email-masked], Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] interplanetary IP
Sender: [email-masked]

A to-do list sounds like a good step forward!

Durga

On Thu, 24 Oct 2002, Stephen 
Farrell wrote:

> 
> Scott,
> 
> Without having read your posting in the detail it deserves,
> (yet!), I'd echo Hans' reaction here (esp. about starting
> from IPv6).
> 
> I'd also point out that RTP seems to be a similar case in
> point - its been developed and used without changing the
> Internet and is now fairly commonly supported by firewalls
> (in terms of them having a button to allow/block RTP streams).
> SCTP might also provide yet another analogous protocol.
> 
> Firewall support is the real blocking factor to new protocols
> layered on IP these days.
> 
> So, basically, development of an Internet friendly LTP should
> be quite feasible.
> 
> So, to me, developing LTP as a layer on top of IP, and
> developing IP drivers for the IPN constrained radio that
> we have to live with, makes enormous sense.
> 
> Having said that there are clearly DNS issues to be
> tackled and I don't think that the sockets API is likely
> to be sufficient, so the applications will generally have to
> be aware that they are IPN applications and not any old
> IP application.
> 
> (As an IPsec aside, we'd also need to replace IKE, but
> ESP is ok, and IKEv2 development is under way in the
> IETF - so this is a note to me to check how the IKEv2 proposals
> handle DTN/IPN-like conditions, but I think they probably
> need multiple hops in one session, so we probably have to have
> an IKEvipn as well.)
> 
> Wouldn't it be good if we had a to-do list for IPN/IP?
> 
> Stephen.
> 
> Hans Kruse wrote:
> > Scott, thanks for a very concise wite-up, which I will re-read for more 
> > in-depth thought.  I have embedded a few comments for now:
> > 
> > --On Wednesday, October 16, 2002 13:29 -0700 Scott Burleigh 
> > <[email-masked]> wrote:
> > 
> >> The next question is: why not do this instead of bundling?  I polled the
> >> DTN development team, and the consensus seems to be that this
> >> interplanetary-IP approach is in fact technically feasible.  The
> >> bottom-line objection is that it would involve so much modification to
> >> the current Internet infrastructure that it would never be implemented;
> >> the problems that originally motivated the DTN architecture would remain
> >> unsolved.  Here is a list of DTN features that would need to be reflected
> >> in the enhanced Internet infrastructure to enable efficient operation of
> >> an interplanetary internet based on end-to-end IP:
> >>
> >> 1.    Deferred transmission.  Because next-hop connectivity in deep 
> >> space is
> >> intermittent, transmission of outbound packets must be deferred until a
> >> link is available; these packets need to be retained in (preferably)
> >> non-volatile storage for minutes, hours, even days.  [Possibly this
> >> function can be delegated to the new link-layer interfaces rather than
> >> implemented within IP itself.]
> > 
> > This would seem to be an implementation issue at the host/router.  IP 
> > does not have a concept of time, only hops (the Time to Live field is a 
> > mis-nomer).  So why not store IP packets?
> > 
> >>
> >> 2.    Contact-sensitive routing.  At each router in deep space, accurate
> >> selection of the next hop may depend on an awareness of anticipated
> >> contact (link availability) periods, based on known schedules and planned
> >> data rates, stochastic analysis, whatever.  Moreover, the high cost of
> >> contact time may additionally make it desirable to consider packet
> >> priority, size, and timeliness constraints in next-hop selection.  New
> >> routing protocols to support these decisions would need to be built into
> >> routers.
> > 
> > This is a totally separate issue.  What you are saying is that you need 
> > a routing protocol for deep space that is more complex than those 
> > running in the Internet.  Routing protocols operate within admin 
> > domains, so why don't you develop the routing protocol needed based on 
> > IP packets, and deploy it in the deep space domain.  Once a packet gets 
> > handed to the Internet, it will be routed based on the simpler Internet 
> > routing, but that is ok.
> > 
> >>
> >> 3.    Recantation.  During the time that a packet directed to a given
> >> interface (based on the complex analysis described above) is waiting in
> >> non-volatile storage for the link to come up, new information may arrive
> >> that makes a better routing decision possible.  To take advantage of this
> >> opportunity, IP would need to be able to retrieve the packet from its
> >> transmission queue and redirect it; this would require new inter-layer
> >> signaling capabilities.  And in order to have the information it would
> >> need to do that signaling, the router would need to retain some subset of
> >> its own state in non-volatile storage.
> > 
> > Again, you need to add features to the routers.  Would it not make more 
> > sense to start with an IP router and add to it, rather than start from 
> > scratch?  IP packets do carry an ID, so they can be tracked for this 
> > purpose.
> > 
> >>
> >> 4.    Address space and name space organization.  End-to-end IP entails
> >> management of a single, solar-system-wide IP address space and
> >> correspondingly a single DNS namespace.  For efficiency in routing table
> >> construction, netmasks that are functionally analogous to DTN region IDs
> >> would probably need to be identified; equitable assignment of address
> >> ranges for this purpose will itself be non-trivial.  Worse, perhaps, is
> >> the problem of maintaining cache coherency among DNS servers distributed
> >> across interplanetary space and connected by expensive, low-capacity
> >> radio links; zone transfers would be prohibitively costly.  Some new
> >> method of domain name propagation, perhaps built on some sort of
> >> subscription model, would have to be invented.  (The DTN solution to this
> >> problem is the "tuple" notion of distinct, region-specific DNS name
> >> spaces and late binding of names to addresses in distinct,
> >> region-specific address spaces.)
> > 
> > I think I would not try this with IPv4.  However, with IPv6 I could 
> > easily see nice big address spaces assigned whereever you need them.  I 
> > have to think about DNS some more, but I assume you would use some form 
> > of proxy on earth and manage zone transfers to deep space assets with a 
> > new set of procedures.
> > 
> >>
> >> 5.    Application retrieval.  End-to-end transmission across a deep space
> >> route can take so long that the communicating application instances
> >> (processes, tasks, objects) may routinely terminate before it concludes.
> >> We'll need a standardized way to restart an application instance on
> >> packet arrival, restoring it to a state in which it can properly respond
> >> to the newly arrived data.
> > 
> > That is again a local implementation issue.  You will need the 
> > equivalent of INETD listening on all ports (UDP in your diagram) and 
> > have a local mechanism to start applications.
> > 
> >>
> >> 6.    Header compression.  Every bit transmitted on a deep space link is
> >> precious; the overhead imposed by the UDP/IP header structure would be
> >> uncomfortably expensive.  Header compression (maybe along the lines of
> >> RFC 2507) would likely be needed.
> > 
> > Yup.
> > 
> >>
> >> 7.    Multi-hop retransmission (custody transfer) and flexible reply-to
> >> selection.  These are features built into DTN to improve network
> >> performance and operability in the face of long propagation delays and
> >> intermittent connectivity.  They too would need to be built into IP
> >> router implementations to match the functionality of bundling.
> > 
> > I don't know enough about these issues yet to comment.
> > 
> >>
> >> The Internet is not frozen, certainly.  New work on inter-layer
> >> signaling, tunneling, routing, compression and so on is already under
> >> way.  In the event that the usefulness of the DTN architecture convinces
> >> the IETF of its value, maybe the new features listed above will all find
> >> their way into the network.
> > 
> > 
> > In your description, I could not find any changes that would need to be 
> > implemented Internet-wide, which leads me to think that further 
> > discussion may be in order.  There may be some confusion between "IP" 
> > and "IP Routing";  IP as an addressing and packet formatting method 
> > would seem to meet all of the deep space needs.  Using IP means that 
> > some of the hardware and firmware can be off-the-shelf.  This also means 
> > that once they get to earth, the packet can be handed to the regular 
> > Internet without modification.
> > 
> > It seems to me that the feature you see as missing are all concentrated 
> > in routers and routing protocols.  As I said before, it would seem to 
> > make sense to start with IP routers and enhance them as needed for deep 
> > space. Since routing protocols are never used on the entire internet, 
> > there is no reason why deep space portion of the network would/could not 
> > use its own routing protocols.  Today, the routing protocols inside an 
> > organization, say a University, and the routing protocols used between 
> > proviers, are totally different.
> > 
> > So, you could implement your diagram (using IP), and start routing and 
> > deploying the new routing protocols needed, and remain fully compatible 
> > with the general Internet right now, even if the IETF never adopts the 
> > new procedures.
> > 
> > I am sure I overlooked a bunch of details, so this will likely be an 
> > ongoing and interesting discussion.
> > 
> > Hans Kruse, Associate Professor
> > J. Warren McClure School of Communication Systems Management
> > Adjunct Associate Professor of Electrical Engineering and Computer Science
> > Ohio University, Athens, OH, 45701
> > 740-593-4891 voice, 740-593-4889 fax
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> > 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

-- 
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
[email-masked]