Subject: Re: [dtn-interest] interplanetary IP
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Date: Thu, 24 Oct 2002 12:53:04 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

At 06:14 PM 10/24/2002 +0100, 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.

Actually, what I'm talking about is not adding a layer on top of IP, which 
is what we're already doing with Bundling in those parts of the 
delay-tolerant-network where TCP/IP works well.  I'm talking instead about 
adding some new reliable-link protocol interfaces [one of them being LTP, 
and another being TCP/IP tunnels that function as a pseudo-link] *under* IP 
so that delay-tolerant applications could simply write to standard UDP/IP 
sockets.  And I think it's kind of a cool approach, but more difficult that 
what we're doing now: you have to hack the kernel (I believe) and therefore 
you lose the easy portability that we enjoy now, which would make 
deployment of interesting test networks much harder.

>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.

Yes, the only applications that can be expected to work well on a 
delay-tolerant network will be applications that are themselves designed to 
tolerate lengthy delays.

>(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.

While I'm at it, here's a response to Hans's comments that I'm only now 
getting around to:

>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.

Right, I think this is what I was saying, though maybe not clearly 
enough.  IP as an addressing and packet formatting method might be fine for 
delay-tolerant networking; all the work would be in modifying the routers 
and adding new routing protocols.  But I would suggest that modifying the 
routers and adding new routing protocols amounts to re-implementing an 
awful lot (maybe not most, but a lot) of the IP infrastructure on any given 
computer.

And I think this means that you in fact cannot use very much hardware and 
firmware off-the-shelf at the DTN nodes.  Which leaves open the question of 
just what the benefits would be if we used IP rather than Bundling as the 
network protocol for delay-tolerant networking.  I don't (at all) say there 
wouldn't be any; I just don't know enough about the current state of 
Internet art to be able to name them.  Any thoughts from subscribers to 
this list?

>>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

Date: Thu, 24 Oct 2002 19:25:32 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] interplanetary IP
Sender: [email-masked]

Hi Howie,

> Not clear in my head how an IKE, IKEv2, or any IKE-like key exchange 
> scheme requiring multiple round-trips to set up a security association 
> could work in a long-delay DTN environment.  It would probably be OK in 
> the situation where there are long outages and then a short period of 
> end-to-end connectivity where the round-trips could occur and the SA be 
> established.  But in the long-delay environments it could take weeks for 
> the 4 IKEv2 round-trips to occur.

I agree. However, I think a scheme where some initial value is
present and can be changed/updated via some overhead bytes in
subsequent exchanges might work. For example, if we assume that
each node has a name, then we might be able to use a kind of
proxied identity based encryption (see [1] for this type of
scheme) at first and then subsequent packets/bundles between
those peers could use some simpler scheme to update the
resulting SA, e.g. binding public keys to the peer identity.

I'm not advocating the above, but just showing that there are
schemes that don't involve multiple roundtrips prior to
establishing an SA. Since its (IMO) unlikely that such schemes
will be generally adopted by the IETF, that's why I called
such a beastie IKEvipn.

Stephen.

[1] Dan Boneh has a useful site with his IBE scheme at:
http://crypto.stanford.edu/ibe/ Its all very nice, but has
the problem of a centrally trusted host that knows all
private keys, though maybe all space agencies would really
like that role:-)

Date: Thu, 24 Oct 2002 14:06:29 -0400
From: Howard Weiss <[email-masked]>
Reply-To: [email-masked]
Organization: SPARTA, Inc.
To: Stephen Farrell <[email-masked]>
CC: [email-masked], Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] interplanetary IP
Sender: [email-masked]

Stephen,

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.) 

Not clear in my head how an IKE, IKEv2, or any IKE-like key exchange 
scheme requiring multiple round-trips to set up a security association 
could work in a long-delay DTN environment.  It would probably be OK in 
the situation where there are long outages and then a short period of 
end-to-end connectivity where the round-trips could occur and the SA be 
established.  But in the long-delay environments it could take weeks for 
the 4 IKEv2 round-trips to occur.

> Wouldn't it be good if we had a to-do list for IPN/IP?
>
> Stephen.
>
Howie

Date: Thu, 24 Oct 2002 18:14:51 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] interplanetary IP
Sender: [email-masked]

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
> 

Date: Wed, 16 Oct 2002 16:24:08 -0700
Subject: Re: [dtn-interest] RE: (was [Ipn-team]) On DTN flow control
From: Mark Adler <[email-masked]>
To: [email-masked]
Sender: [email-masked]

On Monday, October 7, 2002, at 01:32  PM, Adrian J. Hooke wrote:
> Do you know if anyone has done a tradeoff to determine how much could 
> be gained by more efficient spacecraft power amplifiers?

No, I don't.  For orbiters, at least in the past, it has been the size 
of available SSPAs that limits the radiated power, not efficiency.  
Discussions of ganging multiple SSPAs usually ends with grumbling from 
the telecom folk about phase mismatches.  You might see what MRO is 
doing about this, since if I recall correctly, they plan to pump quite a 
bit more power through the antenna than previous missions.

For landers, the efficiency can matter.  We end up being thermally 
limited on how long we can leave the X-band SSPA on, due to heating in 
the warm enclosure.  Putting the SSPA outside is apparently not a good 
solution, due to the large temperature swings.  In the long run though, 
we will be using orbiters at Mars to return most of the data from 
landers, so this shouldn't be much of an issue (the UHF amplifiers tend 
to be on for short times during the orbiter passes).

mark

Date: Wed, 16 Oct 2002 17:37:03 -0400
From: Hans Kruse <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] interplanetary IP
Sender: [email-masked]

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

Date: Wed, 16 Oct 2002 13:29:26 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: [dtn-interest] interplanetary IP
Sender: [email-masked]

Hi, DTN fans.  Often in the course of telling people about the DTN 
architecture we've been asked "Why invent a new Bundling protocol instead 
of just using IP?  Sure, TCP won't work over extremely long delays, but IP 
itself -- in fact, UDP over IP -- is delay-insensitive."  I've been 
revisiting that question myself over the past few days, and Adrian has 
suggested that I send you all a summary of where that line of thinking has 
taken me.  [This summary is mostly IPN-centric.  Certainly DTN can solve 
plenty of problems beyond interplanetary communication, but the IPN 
application of DTN seems to have enough scope for the purposes of this 
discussion.]

The root of much of our argument against end-to-end IP in interplanetary 
space has been the problem of reliable transmission.  Forward error 
correction can reduce data loss and corruption to very low levels, but it 
consumes bandwidth and offers no protection against sustained loss of link; 
for optimum utilization of meager and expensive links you still want ARQ in 
addition to some level of FEC.  We agree that TCP is unsuitable for these 
very long distances.  That means applications are constrained to use UDP, 
which does no ARQ.  This leaves the problem of ARQ up to the 
applications.  But applications are involved only at the endpoints of a 
given IP route, so application-based ARQ must be end-to-end.  For a number 
of reasons, end-to-end ARQ over routes that include links with high bit 
error rates and/or extremely long propagation delays results in degraded 
link utilization.

The DTN architecture resolves this dilemma by recognizing "regions" of 
network topology characterized by different sets of constraints on 
communication.  We can imagine any number of different types of regions, 
but the two we've been giving the most attention to are (a) the Internet, 
where propagation delays are very small, bit error rates are low, and 
end-to-end connectivity is continuous, but congestion can be high, and (b) 
deep space, where propagation delays are very large, bit error rates are 
high, end-to-end connectivity is intermittent or even nonexistent, but 
congestion is virtually zero because transmissions are scheduled.  (We 
usually think of orbital communications in the vicinity of a planet as an 
Internet-like region, although it presents special challenges of its own.)

Between any two points in an Internet-like region, which may be connected 
through any number of routes by IP, you can clearly use the ARQ provided by 
TCP.  Between any two points in a deep space region, which will be 
connected through a single dedicated, directed-R/F (or laser) link, you 
instead need to use something like the parallel retransmission system in 
CFDP, the CCSDS file delivery protocol; we've been contemplating 
development of a Long-haul Transmission Protocol (LTP) that steals from the 
relevant parts of CFDP and fixes a few of the warts.  Given that LTP will 
operate only over a single link, it can best be thought of as a link-layer 
ARQ add-on [maybe at layer "2+" of the stack] rather than a transport 
protocol like TCP.

DTN introduces an overlay protocol called "bundling".  Bundling enables 
reliable communication between two points in different regions without 
end-to-end ARQ by, in effect, considering the end-to-end route as a series 
of route segments, each of which is wholly within a single region.  The 
bundling protocol serves a gateway function at the boundary between any two 
regions, and for transmission between any two gateway points -- that is, on 
any single route segment -- bundling invokes whatever ARQ facilities are 
available within the region containing that part of the route.  At the risk 
of over-simplifying, we can say that bundling routes a "bundle" (much as IP 
routes a packet) from the source onward, possibly across one or more deep 
space hops made reliable by LTP, until a node is reached that is in the 
same TCP-speaking region as the final destination; at that point it lets 
TCP/IP take the bundle the rest of the way.  The stack looks like this:

		application (7)
		|
		bundling (5? or 4`, 3`? or 7-?)
		|
	|-------+-------|
	|		TCP (4)
	|		|
	|		IP (3)
	|		|
	LTP (2+)	|
	|		|
	CCSDS TM/TC (2)	SONET, Ethernet (2)
	|		|
	R/F		fiber, cable

The problem with this picture has always been that people feel uneasy about 
adding the bundling overlay layer; they see bundling as doing more or less 
what IP does, and they wonder why one couldn't tweak IP somewhat to achieve 
the same purpose.  It has never been clear to me how this could be done, 
but over the last couple of weeks I've learned a little about how mobile IP 
works, and I now see a possible approach.

Suppose we were to build an LTP "interface" that could be plugged into the 
underside of IP ('ltp0', analogous to 'eth0').  Suppose we also invented a 
second general-purpose link-layer ARQ add-on that would be suitable for use 
within the Internet: a TCP/IP tunnel, inspired by the IP or UDP/IP tunnels 
used for mobile IP.  [Okay, maybe it's grotesque, but bear with me.]  We 
could build a TCP/IP tunnel interface that could likewise be plugged into 
the underside of IP ('tcp0').  We'd then have a stack that looks like this:

		application (7)
		|
		UDP (4)
		|
		IP (3)
		|
	|-------+-------|
	|		|
	LTP (2+)	TCP/IP tunnel (2+)
	|		|
	TM/TC (2)	SONET, Ethernet (2)
	|		|
	R/F		fiber, cable

Now our application would be able to communicate over interplanetary 
distances over familiar end-to-end UDP/IP (rather than bundling) without 
the performance problems of end-to-end retransmission, relying on ARQ 
provided at the "link layer", but retaining all the benefits of the 
end-to-end model within the terrestrial Internet.  Pretty cool.

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.]

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.

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.

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.)

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.

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.

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.

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.

But that won't happen any time soon; we need to press ahead with bundling 
in any case, if only to prove the concepts.  And in the process we'll 
provide an initial platform for developing and deploying the new 
delay-tolerant applications (non-interactive file transfer, asynchronous 
messaging, and others) that in the long run are the real point of doing all 
this stuff.

Scott

Date: Mon, 07 Oct 2002 13:32:30 -0700
To: <[email-masked]>
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] RE: (was [Ipn-team]) On DTN flow control
Sender: [email-masked]

At 01:50 PM 08/08/02, Mark Adler wrote:
>Ka-band and eventually laser communication, along with big antennas, will 
>probably be what provides the big leaps in bandwidth from Mars.  Probably 
>not power.
>(Though bigger SSPA's wouldn't hurt--we are currently quite far from 
>pumping the majority of the collected solar power out the antenna.)
--------------
Mark:

Do you know if anyone has done a tradeoff to determine how much could be 
gained by more efficient spacecraft power amplifiers?

///adrian

From: "Micah Beck" <[email-masked]>
To: <[email-masked]>, "Adrian J. Hooke" <[email-masked]>
Cc: <[email-masked]>, "Takahiro Yamada" <[email-masked]>
Subject: Re: [dtn-interest] "reference mobile architecture"
Date: Tue, 1 Oct 2002 19:18:55 -0400
Sender: [email-masked]

As long as people are looking at generalized use of technologies such as
those being considered  for delay tolerant networking, I would like to draw
your attention to our work on Logistical Networking, which is in the general
area of scalable asyncrhonous networking and network storage.

Logistical Networking can be thought of as a very generic abstraction of
storage that can be used for buffering data in highly asyncrhonous store and
forward networking.  It is as if we took the temporary storage paradigm that
underlies systems like SMTP and the "bundles" model used in Internplanetary
Networking and made it a service of its own.  Such a service basically only
does two things: store data at a node or  transfer data between nodes.  All
of the routing and other policy has to be layered on top of it, similarly to
the IP network stack.

The advantage of this layered approach is that it is possible to design it
in accordance with the end-to-end principles.  I direct the interested
reader to the paper "An End-to-End Approach to Globally Scalable Networking
Storage" by Beck, Moore and Plank which was presented at SIGCOMM 2002
(http://www.acm.org/sigcomm/sigcomm2002/papers/globalstorage.html).  As a
result, the underlying storage resoures remain very exposed to a variety of
different uses and policies, enabling application autonomy.

The charm of Logistical Networking is that storage "depots" (or servers)
that implement it are currently deployed in research networks.  The
Logistical Backbone (http://loci.cs.utk.edu/lbone) is a directory of such
depots that currently are open to public use (no access control).  The
amount of storage currently avaliable is over 3TB (this number will
fluctuate, but will generally increase over time as more depots are
deployed).  The libraries and tools required to make use of these depots,
based on the Internet Backplane Protocol, are available in open source form
for Linux/Unix and some other platforms from our Web site
(http://loci.cs.utk.edu/exnode).

If you've read this far, you may be wondering where we got the names
Logistical Networking and Internet Backplane Protocol.  "Logistical
Networking" is an analogy with logistical movement of military and industial
material, which uses not only roads (network links) but also warehouses and
depots (storage).  The name "Internet Backplane Protocol" is an appeal to
the notion that we are using the network as a computer, and the Internet is
like its system bus (backplane).

Thanks for your indulgence and I hope that this work is of interest to the
members of this list and will not be considered off-topic.

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

----- Original Message -----
From: "Adrian J. Hooke" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Takahiro Yamada" <[email-masked]>
Sent: Tuesday, October 01, 2002 6:36 PM
Subject: [dtn-interest] "reference mobile architecture"

> At 09:19 AM 10/01/02, Lee, Thomas wrote:
> >I'm Chief Technologist here at QA. QA is a training and consulting firm
in
> >the UK. The project I'm working on is to develop a reference 'mobile
> >architecture' as the basis for us to develop some consulting work as well
as
> >to guide the development of our course portfolio.
>
> Thomas: could you perhaps sketch out what you mean by a "reference mobile
> architecture"? We have a group trying to develop architectural models
> within the Consultative Commiteee for Space Data Systems who may be
> interested in collaboration. There would seem to be strong parallels
> between space and terrestrial mobility that perhaps suggest a common
model.
>
> I've CCd Peter Shames and Takahiro Yamada, who are heavily involved with
> the CCSDS "space" work.
>
> Best regards
>
> Adrian J. Hooke
> Chairman, CCSDS Subpanel-1F (Advanced Orbiting Systems)
> NASA Jet Propulsion Laboratory,
> Interplanetary Network Directorate
> M/S 303-400, 4800 Oak Grove Drive
> Pasadena, California 91109-8099, USA
> +1.818.354.3063 OFFICE
> +1.818.653.9553 MOBILE
> +1 818.354.6290 FAX
> http://www.ccsds.org
> http://www.ipnsig.org
> http://www.dtnrg.org
> http://www.ipnrg.org
> http://www.aist-ngsi.org
> http://www.scps.org
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 01 Oct 2002 15:36:54 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] "reference mobile architecture"
Cc: [email-masked], "Takahiro Yamada" <[email-masked]>
Sender: [email-masked]

At 09:19 AM 10/01/02, Lee, Thomas wrote:
>I'm Chief Technologist here at QA. QA is a training and consulting firm in
>the UK. The project I'm working on is to develop a reference 'mobile
>architecture' as the basis for us to develop some consulting work as well as
>to guide the development of our course portfolio.

Thomas: could you perhaps sketch out what you mean by a "reference mobile 
architecture"? We have a group trying to develop architectural models 
within the Consultative Commiteee for Space Data Systems who may be 
interested in collaboration. There would seem to be strong parallels 
between space and terrestrial mobility that perhaps suggest a common model.

I've CCd Peter Shames and Takahiro Yamada, who are heavily involved with 
the CCSDS "space" work.

Best regards

Adrian J. Hooke
Chairman, CCSDS Subpanel-1F (Advanced Orbiting Systems)
NASA Jet Propulsion Laboratory,
Interplanetary Network Directorate
M/S 303-400, 4800 Oak Grove Drive
Pasadena, California 91109-8099, USA
+1.818.354.3063 OFFICE
+1.818.653.9553 MOBILE
+1 818.354.6290 FAX
http://www.ccsds.org
http://www.ipnsig.org
http://www.dtnrg.org
http://www.ipnrg.org
http://www.aist-ngsi.org
http://www.scps.org

From: "Lee, Thomas" <[email-masked]>
To: [email-masked]
Subject: RE: [dtn-interest] Business usage of DTN deliverables
Date: Tue, 1 Oct 2002 17:19:24 +0100 
Sender: [email-masked]

[this is a slightly updated repost of a conversation between Keith and I
which we want to get back onto the list]

Keith,

Thanks for the email. What you say was the conclusion I'd been coming to but
I wanted to make sure I'd not missed anything!

My thinking is that there will be a variety of scenarios, particular mobile
e-commerce, where delays not only have to be tolerated but must be assumed
to exist. The reference architecture we're trying to build will need to
interoperate between both DTN and MobileIP. 

I'm Chief Technologist here at QA. QA is a training and consulting firm in
the UK. The project I'm working on is to develop a reference 'mobile
architecture' as the basis for us to develop some consulting work as well as
to guide the development of our course portfolio.

No one here really knows exactly what this is yet - but we know we don't
have it and we think we'll recognize it if we see it. I know not much help,
but it's pretty much all I've got to go on thus far.

Where is the best place to find more in DTN? The mailing list is pretty low
volume, to say the least, although maybe this post will cause it to be more
lifelike.

Finally, with respect to the availability of code - can you point me to more
details? What code will be available, against what specs, etc.

-- 
Thomas Lee ([email-masked])
Chief Technologist 
QA plc (www.qa.com)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 01 October 2002 16:23
To: [email-masked]
Subject: Re: [dtn-interest] Business usage of DTN deliverables

Thomas,

Yes, we definitely see uses for DTN technology in terrestrial wireless
situations.  This was, in fact, the realization that drove us to split off
the Interplanetary aspects from the more general Delay Tolerant aspects in
the current architecture.  For the cases where you have both a low-delay
environment and contemporaneous end-to-end connectivity, then you'll have
the choice of using either DTN or something like MobileIP.  But even if you
expect to have end-to-end connectivity, DTN may still be preferable
depending on the delay/error characteristics in different parts of the
network.  For example, if the mobile portion of the network exhibits a high
error rate, DTN's custody transfer can reduce the number of retransmissions
through that part of the network.

Of course, if you expect that there will be times when there is no
end-to-end connectivity between source and destination, then other
approaches developed for terrestrial mobility are *not* an option, and DTN
is probably the best answer.  Can you say anything more about the
architecture you're looking at?

An open  reference implementation of the DTN software should be available
soon, and an announcement will be posted to this list.  That should provide
enough functionality for you to do some testing/evaluation.

                --keith

>At 12:02 PM 10/1/2002 +0100, Lee, Thomas wrote:
>Hi,
>
>I've been looking at mobile architectures as part of a project I am doing.
>I've been thinking that some of the issues faced in DTNs and some of the
>possible solutions are not totally dissimilar to those faced in regular
>mobile networks, albeit to a lesser degree. That makes me wonder if the
>results of this DTN work might not be generally useful.
>
>Comments?

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

To: "Lee, Thomas" <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Business usage of DTN deliverables 
Date: Tue, 01 Oct 2002 08:49:53 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

I have certainly thought it should be.  For example, scheduled transmissions
(turn on at some point in time), route discovery, disconnected routing, etc.

- K

>
> From:  "Lee, Thomas" <[email-masked]>
> To:    "[email-masked]'" <[email-masked]>
> Subject: [dtn-interest] Business usage of DTN deliverables
> Date:  Tue, 01 Oct 2002 12:02:36 BST
>
> Hi,
> 
> I've been looking at mobile architectures as part of a project I am doing.
> I've been thinking that some of the issues faced in DTNs and some of the
> possible solutions are not totally dissimilar to those faced in regular
> mobile networks, albeit to a lesser degree. That makes me wonder if the
> results of this DTN work might not be generally useful.
> 
> Comments?
> 
> 
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Tue, 01 Oct 2002 11:48:35 -0400
To: [email-masked] (Lee, Thomas)
From: [email-masked] (Keith Scott)
Subject: RE: [dtn-interest] Business usage of DTN deliverables
cc: [email-masked] ([email-masked])
Sender: [email-masked]

Thomas,

I'd like to take this back to the list, if I could.  My reply to you mistakenly did not include the dtnrg list (I just reposted it), and as you noted, it would be good to have some more open discussions on the list.

At 04:22 PM 10/1/2002 +0100, you wrote:
>Keith,
>
>Thanks for the email. What you say was the conclusion I'd been coming to but
>I wanted to make sure I'd not missed anything!
>
>My thinking is that there will be a variety of scenarios, particular mobile
>e-commerce, delays not only have to be tolerated but must be assumed. The
>reference architecture we're trying to build will need to interoperate
>between both DTN and MobileIP. 

Great!

>Where is the best place to find more in DTN - the mailing list is pretty low
>volume, to say the least.

The dtnrg web site (http://www.dtnrg.org) is a pretty good source of information.  It has some presentations and links that eventually lead to the current architecture draft (http://www.ipnrg.org/documents/draft_irtf_ipnrg_arch_01.pdf), and houses the current draft protocol specification (http://www.dtnrg.org/specs/blps-0.4.pdf).  The IPN special interest group of the Internet Society (http://www.ipnsig.org) also has a lot of information, more skewed towards the interplanetary applications of DTN but still pretty generally useful if you read it with the broader DTN context in mind.  Finally the ipnrg web site (http://www.ipnrg.org/) is being phased out but has some information that hasn't made it to the dtnrg site yet.

>Finally, with respect to the availability of code - can you point me to more
>details? What code will be available, against what specs, etc.

The reference implementation (RI) will include the 'bundle daemon' (the basic software daemon that performs routing within the DTN), some utilities to allow modification of some routing information, and some test applications to exercise various DTN functions.  The draft protocol spec above is the basis for the RI.

At its current stage, the reference implementation suited to experimentation and proof-of-concept applications, not deployment.  There is no DTN routing protocol yet, for example.  When we finally do make the code available (delays are legal, not technical) we're hoping to generate some interest from possible user communities and to get feedback on both the spec and the code itself.

                --keith

>Thanks in advance.
>
>Thomas Lee
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: 01 October 2002 16:00
>To: [email-masked]
>Subject: Re: [dtn-interest] Business usage of DTN deliverables
>
>Thomas,
>
>Yes, we definitely see uses for DTN technology in terrestrial wireless
>situations.  This was, in fact, the realization that drove us to split off
>the Interplanetary aspects from the more general Delay Tolerant aspects in
>the current architecture.  For the cases where you have both a low-delay
>environment and contemporaneous end-to-end connectivity, then you'll have
>the choice of using either DTN or something like MobileIP.  But even if you
>expect to have end-to-end connectivity, DTN may still be preferable
>depending on the delay/error characteristics in different parts of the
>network.  For example, if the mobile portion of the network exhibits a high
>error rate, DTN's custody transfer can reduce the number of retransmissions
>through that part of the network.
>
>Of course, if you expect that there will be times when there is no
>end-to-end connectivity between source and destination, then other
>approaches developed for terrestrial mobility are *not* an option, and DTN
>is probably the best answer.  Can you say anything more about the
>architecture you're looking at?
>
>An open reference implementation of the DTN software should be available
>soon, and an announcement will be posted to this list.  That should provide
>enough functionality for you to do some testing/evaluation.
>
>                --keith
>
>At 12:02 PM 10/1/2002 +0100, Lee, Thomas wrote:
>>Hi,
>>
>>I've been looking at mobile architectures as part of a project I am doing.
>>I've been thinking that some of the issues faced in DTNs and some of the
>>possible solutions are not totally dissimilar to those faced in regular
>>mobile networks, albeit to a lesser degree. That makes me wonder if the
>>results of this DTN work might not be generally useful.
>>
>>Comments?

Date: Tue, 01 Oct 2002 11:22:42 -0400
To: [email-masked] ([email-masked])
From: [email-masked] (Keith Scott)
Subject: Re: [dtn-interest] Business usage of DTN deliverables
Sender: [email-masked]

Thomas,

Yes, we definitely see uses for DTN technology in terrestrial wireless situations.  This was, in fact, the realization that drove us to split off the Interplanetary aspects from the more general Delay Tolerant aspects in the current architecture.  For the cases where you have both a low-delay environment and contemporaneous end-to-end connectivity, then you'll have the choice of using either DTN or something like MobileIP.  But even if you expect to have end-to-end connectivity, DTN may still be preferable depending on the delay/error characteristics in different parts of the network.  For example, if the mobile portion of the network exhibits a high error rate, DTN's custody transfer can reduce the number of retransmissions through that part of the network.

Of course, if you expect that there will be times when there is no end-to-end connectivity between source and destination, then other approaches developed for terrestrial mobility are *not* an option, and DTN is probably the best answer.  Can you say anything more about the architecture you're looking at?

An open  reference implementation of the DTN software should be available soon, and an announcement will be posted to this list.  That should provide enough functionality for you to do some testing/evaluation.

                --keith

>At 12:02 PM 10/1/2002 +0100, Lee, Thomas wrote:
>Hi,
>
>I've been looking at mobile architectures as part of a project I am doing.
>I've been thinking that some of the issues faced in DTNs and some of the
>possible solutions are not totally dissimilar to those faced in regular
>mobile networks, albeit to a lesser degree. That makes me wonder if the
>results of this DTN work might not be generally useful.
>
>Comments?

From: "Lee, Thomas" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 1 Oct 2002 12:02:36 +0100 
Subject: [dtn-interest] Business usage of DTN deliverables
Sender: [email-masked]

Hi,

I've been looking at mobile architectures as part of a project I am doing.
I've been thinking that some of the issues faced in DTNs and some of the
possible solutions are not totally dissimilar to those faced in regular
mobile networks, albeit to a lesser degree. That makes me wonder if the
results of this DTN work might not be generally useful.

Comments?

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________