Subject: [dtn-interest] Announcement of DTN Architecture Review
From: Kevin Fall <[email-masked]>
To: [email-masked]
Date: Sun, 30 Mar 2003 18:27:16 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Greetings dtn-interest---

A DTN Architecture peer review session is scheduled for 8-May-2003 at ISI 
in Los Angeles.  I'm hoping for an intense, technically focused session 
involving folks who have read over the documents carefully or who have 
active projects intending to use DTN technology they wish to talk about.

Owing to space constraints, we will be able to accommodate a maximum of 
approximately 20 people, so I will send out the invites on a FCFS basis. As 
I had mentioned on this list and at IETF, if you would like to attend 
please submit your (approx) 1-page set of comments on the recently issued 
Internet Drafts listed below to either the dtn-interest list or to myself 
([email-masked]) by the deadline below. In addition, if you wish to 
attend and present a project, please include that information.

Deadline:  April 18, 2003

Based on the responses submitted to the list or to me by 18-Apr-2003, and I 
will construct an attendance list and send out more detailed instructions 
at that time.

Thanks,
- Kevin

IETF References (see the 1st one, especially):

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Date: Tue, 25 Mar 2003 08:12:01 -0500
From: [email-masked]
Subject: I-D ACTION:draft-irtf-dtnrg-arch-00.txt
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directorie
s.

Title           : Delay-Tolerant Network Architecture
Author(s)       : V. Cerf et al.
Filename        : draft-irtf-dtnrg-arch-00.txt
Pages           : 24
Date            : 2003-3-24

This document describes an architecture for delay-tolerant networks,
and is a generalization of the architecture designed for the
Interplanetary Internet: a communication system to provide Internet-
like services across interplanetary distances in support of deep
space exploration.  This generalization addresses networks with
operational and performance characteristics make conventional
networking approaches either unworkable or impractical.  We define a
message-based overlay that exists above the transport layer of the
networks on which it is hosted.  The document presents an
architectural overview followed by discussions of services, topology,
routing, security, reliability and state management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-00.txt

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Date: Tue, 25 Mar 2003 08:11:51 -0500
From: [email-masked]
Subject: I-D ACTION:draft-irtf-dtnrg-bundle-spec-00.txt
Sender: [email-masked]
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directorie
s.

         Title           : Bundle Protocol Specification
         Author(s)       : K. Scott, S. Burleigh
         Filename        : draft-irtf-dtnrg-bundle-spec-00.txt
         Pages           : 30
         Date            : 2003-3-24

This document describes the end-to-end protocol, header formats, and
abstract service description for the exchange of messages (bundles)
in Delay Tolerant Networking (DTN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-00.txt

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Date: Tue, 25 Mar 2003 08:12:06 -0500
From: [email-masked]
Subject: I-D ACTION:draft-irtf-dtnrg-ipn-bundle-xfer-00.txt
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directorie
s.

         Title           : Delay-Tolerant Networking: An Example 
Interplanetary
                          Internet Bundle Transfer
         Author(s)       : R. Durst
         Filename        : draft-irtf-dtnrg-ipn-bundle-xfer-00.txt
         Pages           : 15
         Date            : 2003-3-24

This document presents an example data transfer in a delay tolerant
network.  The particular delay tolerant network is the Interplanetary
Internet, and the purpose of this document is to illustrate the key
concepts in the Delay Tolerant Network architecture [DTNRG03].  The
document describes the network and follows the progress of a bundle
as it is transferred through that network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ipn-bundle-xfer-00.txt

To: [email-masked]
Date: Sun, 30 Mar 2003 18:23:43 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] Code release!
Sender: [email-masked]

I'm pleased to announce that DTN prototype source code is now available
from www.dtnrg.org.  It includes a DTN forwarding agent, several sample
apps, and some example configuration files.  There isn't a great deal
of documentation, but I believe there is enough to get started.

Thanks to Bob Durst and Keith Scott (both at MITRE) for putting in the time to make
this possible.  Also thanks to Intel for supporting me on this effort.

The code is available from here:

	http://www.dtnrg.org/code/dtn-release-0.1.tgz

cheers,
- Kevin

PS: I'll be setting up a dtn-bugs list shortly to carry discussions on the
code (as opposed to the architecture)

To: Lloyd Wood <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] slides available 
Date: Fri, 21 Mar 2003 07:43:58 -0800
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

Done for dtnrg.org.  Thanks.  (I have no direct connection to ipnsig.org, sorry).

=- K

>
> From:  Lloyd Wood <[email-masked]>
> To:    Kevin Fall <[email-masked]>
> cc:    [email-masked]
> Subject: Re: [dtn-interest] slides available
> Date:  Fri, 21 Mar 2003 15:18:14 GMT
>
> On Thu, 20 Mar 2003, Kevin Fall wrote:
> 
> > I have slightly updated the dtnrg web site, including a copy of the slides
> > I'm presenting at IETF this evening.
> 
> Please use full (xx March 2003) or ISO dates e.g. 2003-03-20, so
> they're unambiguous and don't make the content seem
> new/improved/fresh a year from now. (What would 3/4 be?)
> 
> It would also be good if someone could give
> http://www.ipnsig.org/techinfo.htm
> a once-over tidyup to put most recently-added stuff at the top and
> everything in reverse-chronological order -- right now the first thing
> is (NEW graphic) January 2002, which isn't new at all. I've been
> saying 'and scroll halfway down the page to the new stuff...'
> 
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

To: [email-masked]
Date: Thu, 20 Mar 2003 17:34:49 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] slides available
Sender: [email-masked]

I have slightly updated the dtnrg web site, including a copy of the slides
I'm presenting at IETF this evening.

cheers,
- Kevin

Date: Thu, 20 Mar 2003 17:17:09 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] interplanetary IP
Sender: [email-masked]

Hi Bill,

Quite a late response, but FWIW:

I don't think we can use anything that involves a full
end-to-end round trip, so that using DNS based keying
would require that the keys for remote region's nodes
were in the local region's DNS.

Now, while that could be done, and given small numbers
of nodes might be quite practical, it doesn't scale to
large numbers of nodes in different regions. (However,
if the predominant scenario for years to come is that
the Internet region has 99% of all nodes and the DNS,
then this is probably fine!).

An alternative, for SA refresh at least, might be based on
the type of MAC residue keying that ATMs used to use. To
establish a brand new SA, we either take the hit on
round trips, or pre-configuration, or else maybe use an
identity based encryption scheme, with a couple of trusted
(gulp!) escrow agents (probably one in each region). I've
yet to see a nice solution here.

Stephen.

[email-masked] wrote:
> 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.
> 
> 
> 
> 	any interest in using/exploiting the oportunistic encryption
> 	work that piggybacks on DNS queries for inital key distribution?
> 
> --bill
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

To: [email-masked]
Date: Wed, 19 Mar 2003 16:41:24 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] using (bits of?) SIP for intra-region resolution
Sender: [email-masked]

Hi folks.  So, given that of late we have been considering
the possibility that an entity ID can contain either a location
or associative form of naming, this brings up the question:
what other existing systems can we examine that have features
like this.  I'm currently sitting in a SIP-related working group session
at IETF and it appears to me that several of the issues related
to name mapping are being examined.  In particular, there are
some mechanisms to register and look up name mappings to the
details one needs to make contact at the network and transport
layers

Does anyone on this list have enough experience w/SIP to
comment on my comment?

here is one link to a backgrounder on SIP; I'm sure there are more:
http://wwwtgs.ctit.utwente.nl/Docs/education/advanced/mobile/SIP-cristian/

thx,
- Kevin

Date: Mon, 17 Mar 2003 08:50:22 -0800
To: dtn-interest <[email-masked]>
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Flow control / congestion control / resource management in DTNs
Sender: [email-masked]

At 01:06 PM 3/16/2003 -0500, vinton g. cerf wrote:
>suppose the input and output rates are very high - say 1 billion bytes per 
>second.
>
>suppose that for some reason the output flow is interrupted briefly, say 
>for 1 second, and then resumes at the previous rate.
>
>that one second of delay will require 1 billion bytes of storage to 
>buffer. Unless the input queue goes to zero for a second, the buffer will 
>essentially stay full.
>
>the higher the basic throughput, the more we need to be sensitive to the 
>risks of brief output slowdowns.

Yes, with very high throughput rates you can get extremely high buffer 
utilization spikes.  You need whopping big buffers to deal with those spikes.

In financial terms, being vulnerable to spikes like these corresponds 
precisely to being undercapitalized.  One serious glitch in cash flow (a 
mismatch between input and output) and it's adios muchachos.

>If the buffer is really full we should probably react by slowing down the 
>input until we have freed up some buffer space.

Right, if your buffer is very nearly full (you're almost broke) then your 
resistance to incoming data (additional spending) should be extremely high.

Scott

Date: Mon, 17 Mar 2003 08:41:56 -0800
To: dtn-interest <[email-masked]>
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] the WalMart storage model
Sender: [email-masked]

At 01:46 PM 3/16/2003 -0800, Warthman Associates wrote:
>At 09:41 AM 3/16/2003, Scott Burleigh wrote:
>>At 02:01 PM 3/14/2003 -0500, Scott,Keith L. wrote:
>>>There's an analogy to spending money in personal finances.  When you've 
>>>got a lot of money in the bank (lots of free buffer space), you're 
>>>probably more amenable to spending money.  Then again, if your rate of 
>>>spending is large enough compared to your income, the point at which you 
>>>begin to economize is likely to be higher.  Accepting bundles for 
>>>delivery is like buying commodities (you expect to get rid of them by 
>>>'selling' them later).  Taking custody of bundles is like buying less 
>>>liquid commodities (you may have to hold onto them longer before finding 
>>>a willing buyer).
>>
>>I think we can get even more of a handle on this problem by pushing this 
>>model a little further.  The basic notion is that (a) unoccupied buffer 
>>space is like money and (b) routing traffic is analogous to the daily 
>>financial activities of a family.  [An even closer analogy might be 
>>between a router and a financier who "makes a market" in some class of 
>>securities, but I don't understand market-making well enough to want to 
>>push it.]  Accepting an inbound bundle for forwarding equates to "buying" 
>>it -- you acquire the bundle at the cost of some free space.  In Bundling 
>>we implement negative "purchasing decisions" by declining to accept 
>>custody of bundles (not sending "Custody accepted" messages) or, at the 
>>underlying convergence layer, by throttling back on the rate at which the 
>>underlying transport protocols accept data -- flow control.
>>
>>Suppose you're a wealthy and idle heir to a great fortune.  You start off 
>>with a large bank balance (lots of unoccupied buffer space) and zero net 
>>income.  You might freely spend this money until your balance is reduced 
>>to some level that makes you uneasy, and at that point you start to 
>>economize: you spend less readily on the more discretionary items (in 
>>Bundling, this would be low-priority bundles), and you also spend less 
>>readily on the more expensive items (large bundles).  [You might even 
>>still buy inexpensive luxuries but put off buying things with more 
>>practical value that will cost a lot more.]  When you start getting some 
>>income (in Bundling terms, when your outbound bundles begin to be 
>>accepted by downstream forwarding nodes, so that your buffer space can be 
>>reclaimed), your uneasiness begins to diminish even though your balance 
>>hasn't gotten any higher: you spend more freely when you've got a job.
>>
>>The three variables are current balance, spending rate, and income 
>>rate.  From these three variables you unconsciously compute a resistance 
>>(or "prudence", or "caution") level, which is one of the parameters to 
>>apply to each spending (bundle acceptance) decision.  The other 
>>parameters to each such decision include the importance of the purchase 
>>(priority of the bundle) and its cost (bundle size), and there are 
>>probably other relevant parameters that we haven't identified yet.
>
>A better model might be that of physical-goods storage. In that model, a 
>fourth variable becomes evident: *expand the storage space*. In the 
>financial model, this fourth variable would translate to *expand my 
>capacity to have money*, which is constrained only by the world money 
>supply. In a DTN, storage space must be physically added, just as with 
>computer storage, and it can be expanded at most nodes, even if the 
>installation cost is high.
>
>For example, assume you're the manager of a WalMart distribution center. 
>This is a warehouse that receives goods from many independent suppliers 
>and sends them to one or many other WalMart storage places (either 
>next-level distribution warehouses or storage attached to retail stores. 
>This models a DTN, because trucks, trains, and airplanes take time to move 
>goods, and they act as intermediate storage just as link bandwidth acts as 
>intermediate storage on long-delay DTN links.
>
>As a warehouse manager, you try to schedule inputs and outputs, but it's 
>not an accurate science; accidents happen to delivery trucks, roadways, 
>employees, storage buildings, debuggy electronic-transaction protocols, etc.
>
>Your controls are:
>
>  input rate
>  output rate
>  storage space
>
>You try to change these controls, depending on:
>
>  input demand
>  output demand

That's an interesting model, but for congestion control purposes I think 
it's less faithful and less useful than personal finance.  In that model, 
total buffer space [occupied plus unoccupied] maps to "the total amount of 
money I started off with", which a router's current bank balance can never 
exceed because nothing in the model enables the router to "make money", 
turn a profit.  Remember, the router is a hapless and indolent heir, unable 
to "earn a living"; all it can do is liquidate the things it buys, and then 
use the proceeds to buy more things.  The financial analog to expanding 
storage space (adding physical memory to the aggregate unoccupied buffer 
space) would be an arbitrary increase in bank balance -- by an additional 
inheritance or a gift or a MacArthur grant, for example.  It's constrained 
by the inclination and ability of those that have money (available memory) 
to give it to you (install it, or reallocate it from a common pool of 
spacecraft on-board memory that serves other purposes).

The nice thing about the financial "prudence" model is that it can operate 
in isolation at each node individually; there's no need to manage global 
state by negotiating schedule revisions, because each router makes its own 
decisions locally and acts on them unilaterally.  Since there's no need for 
negotiation, the model can tolerate unlimited delay.  And I think the 
resulting emergent behavior would scale up pretty well.

Scott

Date: Sun, 16 Mar 2003 13:55:10 -0800
To: "vinton g. cerf" <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] More Discussions on DTN endpoint naming.
Sender: [email-masked]

"correspondent ID" works well for the third component of "DTN name". It has 
lots of syllables, but it embodies the right idea. Let's put that on the 
candidate list, too.

Forrest

At 01:32 PM 3/16/2003, vinton g. cerf wrote:
>no -
>
>I used to say "correspondent" to try to be egalitarian.
>
>v
>
>At 12:23 PM 3/16/2003 -0800, you wrote:
> >Did Shannon's model of a communication link use a generic term that 
> included both sender and receiver?
>
>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: Sun, 16 Mar 2003 13:46:05 -0800
To: dtn-interest <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: [dtn-interest] the WalMart storage model
Sender: [email-masked]

At 09:41 AM 3/16/2003, Scott Burleigh wrote:
>At 02:01 PM 3/14/2003 -0500, Scott,Keith L. wrote:
>>There's an analogy to spending money in personal finances.  When you've 
>>got a lot of money in the bank (lots of free buffer space), you're 
>>probably more amenable to spending money.  Then again, if your rate of 
>>spending is large enough compared to your income, the point at which you 
>>begin to economize is likely to be higher.  Accepting bundles for 
>>delivery is like buying commodities (you expect to get rid of them by 
>>'selling' them later).  Taking custody of bundles is like buying less 
>>liquid commodities (you may have to hold onto them longer before finding 
>>a willing buyer).
>
>I think we can get even more of a handle on this problem by pushing this 
>model a little further.  The basic notion is that (a) unoccupied buffer 
>space is like money and (b) routing traffic is analogous to the daily 
>financial activities of a family.  [An even closer analogy might be 
>between a router and a financier who "makes a market" in some class of 
>securities, but I don't understand market-making well enough to want to 
>push it.]  Accepting an inbound bundle for forwarding equates to "buying" 
>it -- you acquire the bundle at the cost of some free space.  In Bundling 
>we implement negative "purchasing decisions" by declining to accept 
>custody of bundles (not sending "Custody accepted" messages) or, at the 
>underlying convergence layer, by throttling back on the rate at which the 
>underlying transport protocols accept data -- flow control.
>
>Suppose you're a wealthy and idle heir to a great fortune.  You start off 
>with a large bank balance (lots of unoccupied buffer space) and zero net 
>income.  You might freely spend this money until your balance is reduced 
>to some level that makes you uneasy, and at that point you start to 
>economize: you spend less readily on the more discretionary items (in 
>Bundling, this would be low-priority bundles), and you also spend less 
>readily on the more expensive items (large bundles).  [You might even 
>still buy inexpensive luxuries but put off buying things with more 
>practical value that will cost a lot more.]  When you start getting some 
>income (in Bundling terms, when your outbound bundles begin to be accepted 
>by downstream forwarding nodes, so that your buffer space can be 
>reclaimed), your uneasiness begins to diminish even though your balance 
>hasn't gotten any higher: you spend more freely when you've got a job.
>
>The three variables are current balance, spending rate, and income 
>rate.  From these three variables you unconsciously compute a resistance 
>(or "prudence", or "caution") level, which is one of the parameters to 
>apply to each spending (bundle acceptance) decision.  The other parameters 
>to each such decision include the importance of the purchase (priority of 
>the bundle) and its cost (bundle size), and there are probably other 
>relevant parameters that we haven't identified yet.

A better model might be that of physical-goods storage. In that model, a 
fourth variable becomes evident: *expand the storage space*. In the 
financial model, this fourth variable would translate to *expand my 
capacity to have money*, which is constrained only by the world money 
supply. In a DTN, storage space must be physically added, just as with 
computer storage, and it can be expanded at most nodes, even if the 
installation cost is high.

For example, assume you're the manager of a WalMart distribution center. 
This is a warehouse that receives goods from many independent suppliers and 
sends them to one or many other WalMart storage places (either next-level 
distribution warehouses or storage attached to retail stores. This models a 
DTN, because trucks, trains, and airplanes take time to move goods, and 
they act as intermediate storage just as link bandwidth acts as 
intermediate storage on long-delay DTN links.

As a warehouse manager, you try to schedule inputs and outputs, but it's 
not an accurate science; accidents happen to delivery trucks, roadways, 
employees, storage buildings, debuggy electronic-transaction protocols, etc.

Your controls are:

  input rate
  output rate
  storage space

You try to change these controls, depending on:

  input demand
  output demand

Forrest

Date: Sun, 16 Mar 2003 12:23:08 -0800
To: [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] More Discussions on DTN endpoint naming.
Sender: [email-masked]

At 09:11 PM 3/15/2003, Scott Burleigh wrote:
>At 03:01 PM 3/14/2003 -0800, Forrest Warthman wrote:
>>At 01:42 PM 3/13/2003, Scott,Keith L. wrote:
>>>More discussions on DTN concepts...
>>>
>>>There really are three components to DTN names:
>>>    Region identifier
>>>    Destination Bundle Agent Identifier
>>>    Registrant (application that registered to receive bundles via the
>>>            destination bundle agent)
>>
>>I think this distinction between the three components is very helpful. 
>>Regarding the general case of "DTN names", I assume the above naming is 
>>for a destination and that there is comparable naming for a sender.
>
>Yeah, I think this is another ambiguity we could try to head off.  Let's 
>say "DTN name" or "application entity ID", but not both.

I vote for "DTN name".

The term "application entity ID" opens a big name space: it may imply a set 
named "ID", which has subset members named "entity" and 
"<something_other_than_entity>", and the subset named "entity" may have 
members named "application" and "<something_other_than_application>".

>Anyway, "registrant" is a plausible alternative to the "resource ID" term 
>I proposed in my earlier email.

I agree that these terms work well for the first two components of a "DTN 
name":

    region ID
    bundle-agent ID

But if we call the third component "registrant ID", we may imply that only 
those things (and not bundle agents) can be "registered". (If this 
implication is true, than I agree "registrant ID" would be a good candidate.)

If we call it "resource ID", we may imply that only those things (and not 
bundle agents) are "resources".

How about calling the third component one of these:

    end ID      (as in "end-to-end"), or
    target ID   (as in "target of a message", but it implies only a 
destination), or
    tx/rx ID    (which implies the ability to both send and receive), or
    home ID

where an "ID" can be a NAME or an ADDRESS.

The postal-service model doesn't help us much. It uses terms like 
"addressee" and "addressor", or "sender" and "receiver", but to my 
knowledge lacks a generic term that includes both sender and receiver. Did 
Shannon's model of a communication link use a generic term that included 
both sender and receiver?

Forrest

Date: Sun, 16 Mar 2003 13:39:21 -0500
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

one could choose to have simultaneous assignment of a string and a numeric value - carrying the numeric in the bundle header - just the equivalent of host.txt. Both would be addresses but the numeric form would allow for less space - structure would be an issue unless the name and number have identical substructures.

v

At 09:54 AM 3/16/2003 -0800, Scott Burleigh wrote:
>I agree that region identifiers are functionally addresses.  We haven't talked much about indirectly referencing regions themselves, using some sort of region name-to-address lookup.  A possible problem with this kind of lookup is that the registry associating the names with the addresses (IDs) would need to be accessible and up-to-date throughout the delay-tolerant network, which brings us back to the same kinds of issues we'd face with an IPN-wide DNS: cache coherency, zone transfer bandwidth, etc.  On a much smaller scale, though, assuming we don't need to have a huge number of regions.

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: Sun, 16 Mar 2003 13:06:01 -0500
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] Flow control / congestion control / resource management in DTNs
To: Scott Burleigh <[email-masked]>, dtn-interest <[email-masked]>
Sender: [email-masked]

suppose the input and output rates are very high - say 1 billion bytes per second.

suppose that for some reason the output flow is interrupted briefly, say for 1 second, and then resumes at the previous rate.

that one second of delay will require 1 billion bytes of storage to buffer. Unless the input queue goes to zero for a second, the buffer will essentially stay full.

the higher the basic throughput, the more we need to be sensitive to the risks of brief output slowdowns.

If the buffer is really full we should probably react by slowing down the input until we have freed up some buffer space. 

vint

 At 09:41 AM 3/16/2003 -0800, Scott Burleigh wrote:
>I think we can get even more of a handle on this problem by pushing this model a little further.  The basic notion is that (a) unoccupied buffer space is like money and (b) routing traffic is analogous to the daily financial activities of a family.  [An even closer analogy might be between a router and a financier who "makes a market" in some class of securities, but I don't understand market-making well enough to want to push it.]  Accepting an inbound bundle for forwarding equates to "buying" it -- you acquire the bundle at the cost of some free space.  In Bundling we implement negative "purchasing decisions" by declining to accept custody of bundles (not sending "Custody accepted" messages) or, at the underlying convergence layer, by throttling back on the rate at which the underlying transport protocols accept data -- flow control.
>
>Suppose you're a wealthy and idle heir to a great fortune.  You start off with a large bank balance (lots of unoccupied buffer space) and zero net income.  You might freely spend this money until your balance is reduced to some level that makes you uneasy, and at that point you start to economize: you spend less readily on the more discretionary items (in Bundling, this would be low-priority bundles), and you also spend less readily on the more expensive items (large bundles).  [You might even still buy inexpensive luxuries but put off buying things with more practical value that will cost a lot more.]  When you start getting some income (in Bundling terms, when your outbound bundles begin to be accepted by downstream forwarding nodes, so that your buffer space can be reclaimed), your uneasiness begins to diminish even though your balance hasn't gotten any higher: you spend more freely when you've got a job.
>
>The three variables are current balance, spending rate, and income rate.  From these three variables you unconsciously compute a resistance (or "prudence", or "caution") level, which is one of the parameters to apply to each spending (bundle acceptance) decision.  The other parameters to each such decision include the importance of the purchase (priority of the bundle) and its cost (bundle size), and there are probably other relevant parameters that we haven't identified yet.
>
>The formula for computing resistance level and the exact way in which resistance level affects spending decisions look like research topics.  I strongly suspect there are weighting factors involved, and I suspect those factors vary among consumers (routers) and probably vary over time as well, so none of this is trivial.  But I think it's the sort of thing we have to figure out in order to enable DTN routers to make congestion-avoidance decisions autonomously, without relying on conversational negotiation with their peers.
>
>Scott

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: Sun, 16 Mar 2003 10:02:29 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: RE: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

At 06:30 AM 3/16/2003 -0800, Sukanta Ganguly wrote:
>Hi,
>    The distintion between the ADDRESS of a bundle agent and the NAME of a 
> bundle agent sounds identical to what an IP address and domain name is 
> and hence clarifying it at this point can reduce any confusion down the road.
>
>    Scott brings an interesting point related to the implicit meaning of a 
> "node". According to him "node" is a "bundling protocol agent", which 
> implicitly also does the protocol processing. I think it is a little to 
> much of an over committment from the nodes point of view, or perphaps an 
> "active node" and a "passive node" must be identified. A "active node" is 
> the one that Scott is implying and a "passive node" in this concept acts 
> as a bridge/repeater. It learns from one interface and broadcast it on 
> the others. It may end up doing a very basic functions but not the fully 
> loaded protocol processing, re-validating, etc.

A good point, but I think there's no inconsistency.  We can certainly 
imagine bridge or repeater devices in a DTN that don't implement Bundling 
but instead just forward data at what looks to Bundling like the link layer 
(but which looks to us like the Transport layer).  Because those devices 
would not implement Bundling and would therefore lack "bundle agent IDs" 
(or whatever) of their own, I think we would not call them DTN "nodes" in 
the same way that we don't call a bridge or repeater (which lacks an IP 
address of its own) an IP "router".

Scott

Date: Sun, 16 Mar 2003 09:54:03 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

At 07:22 AM 3/16/2003 -0500, vinton g. cerf wrote:
>At what point will we need to make a distinction between the ADDRESS of a 
>bundle agent and the NAME of a bundle agent, assuming we end up with the 
>same distinction that we use in the Internet for domain name and IP address?
>
>If we route based on the expressed region identifier, that region 
>identifier is an address. In that case, "region address" might make sense. 
>Alternatively, we might have strings that act as region names and 
>transforms that act as addresses. There can be a one-to-one mapping of 
>names to addresses.

I agree that region identifiers are functionally addresses.  We haven't 
talked much about indirectly referencing regions themselves, using some 
sort of region name-to-address lookup.  A possible problem with this kind 
of lookup is that the registry associating the names with the addresses 
(IDs) would need to be accessible and up-to-date throughout the 
delay-tolerant network, which brings us back to the same kinds of issues 
we'd face with an IPN-wide DNS: cache coherency, zone transfer bandwidth, 
etc.  On a much smaller scale, though, assuming we don't need to have a 
huge number of regions.

>when we get to the target region, we perform a transformation on the 
>NAME/Locator of the bundle agent to obtain its ADDRESS. We observed that 
>this had some of the characteristics of ARP-like behavior, didn't we? 
>Could be domain name lookup or host.txt, or ARP, or...
>
>I think that happens whether we use the URN or the URL form for the bundle 
>agent identifier.

Right, no matter whether the second component of application entity ID is a 
URL (which has the destination bundle agent's ID embedded in it) or a URN 
(which is used to look up the bundle agent's ID in a regional database of 
some sort), it's then still up to the regional protocol speaker at the 
convergence layer to map that ID to a *regional* address for intra-regional 
transmission using the regional transport protocol.

Scott

Date: Sun, 16 Mar 2003 09:41:24 -0800
To: dtn-interest <[email-masked]>
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Flow control / congestion control / resource management in DTNs
Sender: [email-masked]

At 02:01 PM 3/14/2003 -0500, Scott,Keith L. wrote:
>How do we deal with flow control and congestion control in DTNs where we 
>have really long (and possibly unpredictable) communications 
>delays.  While flow control in the internet is generally taken to be 
>end-to-end, for DTN we may never really have any contemporaneous e2e 
>association.  Plus, since we have a flavor of hop-by-hop forwarding (in 
>the overlay of bundle routers), flow control really only makes sense on a 
>hop-by-(bundle)hop basis.  Congestion corresponds here to filling up of 
>persistent storage.  So, hop by hop flow control is closely linked with 
>how the handling of this sort of congestion will work.  From history we 
>know that exerting hop by hop flow control can lead to eventual cascaded 
>lock-up, so we have to keep this in mind.

Actually even end-to-end flow control can lock up the sender: a blocked 
(for whatever reason) reader blocks the writer, in the very nature of flow 
control.

I think the real problem we're worrying about is cascaded buffer 
exhaustion, which is the form that congestion takes at the Bundling layer 
of a DTN, is triggered by cascaded flow control.  At least, it is if we use 
flow control mechanisms to respond to that congestion.

>We have a partial solution to the network being congested (by bundles 
>timing out), but this is pretty coarse.

It's actually kind of fine-grained in the sense that it operates on a 
bundle-by-bundle basis.  But if this mechanism were solely responsible for 
controlling congestion in the network we would want to give it a lot more 
design attention than we have in the past; right now it would be a wobbly 
crutch to rely on.

>Consider the following:
>
>A----->B------>C
>        ^
>        |
>        |
>        D
>
>Flow1: A--->C
>Flow2: D--->C
>
>Now assume the B-->C connection is intermittent, and maybe not even 
>predictable, so B never knows how long it's going to be before it can get 
>rid of bundles towards C.  Now A->C traffic may need to be buffered for a 
>long time.  If we allow B to fully congest, then D->A traffic via B will 
>not be possible.  This seems bad.
>
>Is this fundamentally a buffer management problem or a (transmission) rate 
>management problem [or are these isomorphic]?
>
>If the transport layer under bundling has the ability to perform flow 
>control, can we use that alone {between two guys in the same region} to 
>achieve flow control.
>This amounts to shoving flow control down onto the convergence layers 
>(since they know how to transmit data in the underlying protocols of the 
>region)?
>
>So, routing, buffer management and traffic rates all directly relate to 
>how congestion forms, and DTN custody transfer makes managing it fairly 
>challenging.
>Perhaps control theory problems in the context of flow control, rate 
>control, and buffer management of this kind would presumably be quite 
>useful.  Who knows a lot about this and would be interested in helping?
>
>=======
>
>Calculation of rate of buffer (fill/depletion) is problematic because if 
>you try to use _just_ rate of buffer fill as your discriminant of whether 
>to accept new stuff or not, you can get fooled.  Counterexample is to get 
>something, then don't get anything for a long time, causing your rate of 
>buffer fill would then be very low, making you think that you could accept 
>more (making your rate of buffer fill go up) then a long period of no 
>activity goes by and you think you can accept more (still not hiving 
>gotten rid of anything).  In this way you could still get completely 
>filled up, always thinking that you were OK.
>
>Parameters a bundle agent might want to use to determine whether or not it 
>wants to accept new bundles (for forwarding)
>     buffer occupation
>     rate of change of buffer occupancy
>
>There are two levels of willingness to accept bundles: those that a bundle 
>agent just needs to route vs. those that it takes custody of.  Taking 
>custody of a bundle
>
>There's an analogy to spending money in personal finances.  When you've 
>got a lot of money in the bank (lots of free buffer space), you're 
>probably more amenable to spending money.  Then again, if your rate of 
>spending is large enough compared to your income, the point at which you 
>begin to economize is likely to be higher.  Accepting bundles for delivery 
>is like buying commodities (you expect to get rid of them by 'selling' 
>them later).  Taking custody of bundles is like buying less liquid 
>commodities (you may have to hold onto them longer before finding a 
>willing buyer).

I think we can get even more of a handle on this problem by pushing this 
model a little further.  The basic notion is that (a) unoccupied buffer 
space is like money and (b) routing traffic is analogous to the daily 
financial activities of a family.  [An even closer analogy might be between 
a router and a financier who "makes a market" in some class of securities, 
but I don't understand market-making well enough to want to push 
it.]  Accepting an inbound bundle for forwarding equates to "buying" it -- 
you acquire the bundle at the cost of some free space.  In Bundling we 
implement negative "purchasing decisions" by declining to accept custody of 
bundles (not sending "Custody accepted" messages) or, at the underlying 
convergence layer, by throttling back on the rate at which the underlying 
transport protocols accept data -- flow control.

Suppose you're a wealthy and idle heir to a great fortune.  You start off 
with a large bank balance (lots of unoccupied buffer space) and zero net 
income.  You might freely spend this money until your balance is reduced to 
some level that makes you uneasy, and at that point you start to economize: 
you spend less readily on the more discretionary items (in Bundling, this 
would be low-priority bundles), and you also spend less readily on the more 
expensive items (large bundles).  [You might even still buy inexpensive 
luxuries but put off buying things with more practical value that will cost 
a lot more.]  When you start getting some income (in Bundling terms, when 
your outbound bundles begin to be accepted by downstream forwarding nodes, 
so that your buffer space can be reclaimed), your uneasiness begins to 
diminish even though your balance hasn't gotten any higher: you spend more 
freely when you've got a job.

The three variables are current balance, spending rate, and income 
rate.  From these three variables you unconsciously compute a resistance 
(or "prudence", or "caution") level, which is one of the parameters to 
apply to each spending (bundle acceptance) decision.  The other parameters 
to each such decision include the importance of the purchase (priority of 
the bundle) and its cost (bundle size), and there are probably other 
relevant parameters that we haven't identified yet.

The formula for computing resistance level and the exact way in which 
resistance level affects spending decisions look like research topics.  I 
strongly suspect there are weighting factors involved, and I suspect those 
factors vary among consumers (routers) and probably vary over time as well, 
so none of this is trivial.  But I think it's the sort of thing we have to 
figure out in order to enable DTN routers to make congestion-avoidance 
decisions autonomously, without relying on conversational negotiation with 
their peers.

Scott

content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Thoughts on the construction of tuples.
Date: Sun, 16 Mar 2003 06:30:25 -0800
From: "Sukanta Ganguly" <[email-masked]>
To: "vinton g. cerf" <[email-masked]>, "Scott Burleigh" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi,
   The distintion between the ADDRESS of a bundle agent and the NAME of a bundle agent sounds identical to what an IP address and domain name is and hence clarifying it at this point can reduce any confusion down the road.

   Scott brings an interesting point related to the implicit meaning of a "node". According to him "node" is a "bundling protocol agent", which implicitly also does the protocol processing. I think it is a little to much of an over committment from the nodes point of view, or perphaps an "active node" and a "passive node" must be identified. A "active node" is the one that Scott is implying and a "passive node" in this concept acts as a bridge/repeater. It learns from one interface and broadcast it on the others. It may end up doing a very basic functions but not the fully loaded protocol processing, re-validating, etc.

SG

-----Original Message-----
From:	vinton g. cerf [mailto:[email-masked]]
Sent:	Sun 3/16/2003 4:22 AM
To:	Scott Burleigh; [email-masked]
Cc:	
Subject:	Re: [dtn-interest] Thoughts on the construction of tuples.
At what point will we need to make a distinction between the ADDRESS of a bundle agent and the NAME of a bundle agent, assuming we end up with the same distinction that we use in the Internet for domain name and IP address?

If we route based on the expressed region identifier, that region identifier is an address. In that case, "region address" might make sense. Alternatively, we might have strings that act as region names and transforms that act as addresses. There can be a one-to-one mapping of names to addresses.

when we get to the target region, we perform a transformation on the NAME/Locator of the bundle agent to obtain its ADDRESS. We observed that this had some of the characteristics of ARP-like behavior, didn't we? Could be domain name lookup or host.txt, or ARP, or...

I think that happens whether we use the URN or the URL form for the bundle agent identifier.

The demultiplexing identifier is used verbatim as a clue to the demuxing API to deliver the received bundle to the entity/app that is supposed to receive it. 

vint

At 09:40 PM 3/15/2003 -0800, Scott Burleigh wrote:

>Except that, for the purposes of the DTN architecture, simply saying that something is a physical entity that may encapsulate other physical entities and might host multiple functional entities doesn't buy us a lot of cognitive leverage.  [Since the "may" in each clause suggests a given node might not do one or the other, or might not even do either, one could conceivably call a toaster a node.]
>
>The specific concept for which we need a word (for which purpose we tend to use the word "node") is essentially "something that DTN can successfully route a bundle to".  So I think we use the term "node" to mean "a Bundling protocol engine" -- with the informal understanding that it also implicitly refers to the hardware that enables operation of that protocol engine.
>
>And there's a further understanding that a single "node" might have an "interface" (or even multiple interfaces) in each of several distinct regions, and those interfaces are the things that region-specific "bundle agent identifiers" (or whatever we end up calling them) correspond to.
>
>Scott 

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

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

Date: Sun, 16 Mar 2003 07:22:11 -0500
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

At what point will we need to make a distinction between the ADDRESS of a bundle agent and the NAME of a bundle agent, assuming we end up with the same distinction that we use in the Internet for domain name and IP address?

If we route based on the expressed region identifier, that region identifier is an address. In that case, "region address" might make sense. Alternatively, we might have strings that act as region names and transforms that act as addresses. There can be a one-to-one mapping of names to addresses.

when we get to the target region, we perform a transformation on the NAME/Locator of the bundle agent to obtain its ADDRESS. We observed that this had some of the characteristics of ARP-like behavior, didn't we? Could be domain name lookup or host.txt, or ARP, or...

I think that happens whether we use the URN or the URL form for the bundle agent identifier.

The demultiplexing identifier is used verbatim as a clue to the demuxing API to deliver the received bundle to the entity/app that is supposed to receive it. 

vint

At 09:40 PM 3/15/2003 -0800, Scott Burleigh wrote:

>Except that, for the purposes of the DTN architecture, simply saying that something is a physical entity that may encapsulate other physical entities and might host multiple functional entities doesn't buy us a lot of cognitive leverage.  [Since the "may" in each clause suggests a given node might not do one or the other, or might not even do either, one could conceivably call a toaster a node.]
>
>The specific concept for which we need a word (for which purpose we tend to use the word "node") is essentially "something that DTN can successfully route a bundle to".  So I think we use the term "node" to mean "a Bundling protocol engine" -- with the informal understanding that it also implicitly refers to the hardware that enables operation of that protocol engine.
>
>And there's a further understanding that a single "node" might have an "interface" (or even multiple interfaces) in each of several distinct regions, and those interfaces are the things that region-specific "bundle agent identifiers" (or whatever we end up calling them) correspond to.
>
>Scott 

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: Sat, 15 Mar 2003 21:40:05 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

--=====================_6909254==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:48 PM 3/14/2003 -0800, Forrest Warthman wrote:
>At 03:45 PM 3/14/2003, Peter Shames wrote:
>>At 2:44 PM -0800 3/14/03, Warthman Associates wrote:
>>>
>>>>NOTE that nothing discussed so far expresses the identity of any DTN 
>>>>"node" (which I think is our term for a Bundling protocol engine); we 
>>>>only identify application entities.  Application entities produce and 
>>>>consume bundle content, not bundles.  DTN nodes encapsulate the bundle 
>>>>content that bundle content producers produce; they forward the 
>>>>resulting bundles through a delay-tolerant network; and they extract 
>>>>bundle content from bundles and somehow enable bundle content consumers 
>>>>to consume that content.  We may or may not need a way to express the 
>>>>identity of a DTN node, but so far in this discussion we haven't 
>>>>referred to or devised one.
>>>
>>>Good point. Based on the text I found in the architecture draft about 
>>>"entity ID", I said in the Tutorial , "An entity may be a host (a DTN 
>>>node), an application instance, a protocol, a URL, a port (used to find 
>>>the bundle service on a host) and potentially a token (used to find a 
>>>particular application instance that is using the bundle service), or 
>>>something else." But I think the distinction you propose between a node 
>>>and an application would help clarify things.
>>>
>>>
>>>Forrest
>>>[email-masked]
>>
>>In our work on reference architecture we refer to node as a physical 
>>entity that may encapsulate other physical entities and that may have a 
>>number of different functional entities running on it.  So from that 
>>perspective a DTN host would be a node (with possibly one or more 
>>computers, sub-nodes).  The DTN "Bundling protocol engine" is an 
>>application (functional) entity that reside on one (or more) of these 
>>computers.
>>
>>This work for you?
>>
>>Peter
>
>Yes, that works fine for me. I've always thought of a node as a physical 
>entity. And I agree that the DTN "Bundling protocol engine" is a 
>functional entity (hardware or software), although if it is named an 
>"application entity" many readers may believe it runs at the "application 
>layer", whereas I've assumed the engine runs at the "bundle layer".

Except that, for the purposes of the DTN architecture, simply saying that 
something is a physical entity that may encapsulate other physical entities 
and might host multiple functional entities doesn't buy us a lot of 
cognitive leverage.  [Since the "may" in each clause suggests a given node 
might not do one or the other, or might not even do either, one could 
conceivably call a toaster a node.]

The specific concept for which we need a word (for which purpose we tend to 
use the word "node") is essentially "something that DTN can successfully 
route a bundle to".  So I think we use the term "node" to mean "a Bundling 
protocol engine" -- with the informal understanding that it also implicitly 
refers to the hardware that enables operation of that protocol engine.

And there's a further understanding that a single "node" might have an 
"interface" (or even multiple interfaces) in each of several distinct 
regions, and those interfaces are the things that region-specific "bundle 
agent identifiers" (or whatever we end up calling them) correspond to.

Scott
--=====================_6909254==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 06:48 PM 3/14/2003 -0800, Forrest Warthman wrote:<br>
<blockquote type=cite class=cite cite>At 03:45 PM 3/14/2003, Peter Shames
wrote:<br>
<blockquote type=cite class=cite cite>At 2:44 PM -0800 3/14/03, Warthman
Associates wrote:<br>
<blockquote type=cite class=cite cite><br>
<blockquote type=cite class=cite cite>NOTE that nothing discussed so far
expresses the identity of any DTN &quot;node&quot; (which I think is our
term for a Bundling protocol engine); we only identify application
entities.&nbsp; Application entities produce and consume bundle content,
not bundles.&nbsp; DTN nodes encapsulate the bundle content that bundle
content producers produce; they forward the resulting bundles through a
delay-tolerant network; and they extract bundle content from bundles and
somehow enable bundle content consumers to consume that content.&nbsp; We
may or may not need a way to express the identity of a DTN node, but so
far in this discussion we haven't referred to or devised
one.</blockquote><br>
Good point. Based on the text I found in the architecture draft about
&quot;entity ID&quot;, I said in the Tutorial , &quot;An<i> entity</i>
may be a host (a DTN node), an application instance, a protocol, a URL, a
port (used to find the bundle service on a host) and potentially a token
(used to find a particular application instance that is using the bundle
service), or something else.&quot; But I think the distinction you
propose between a node and an application would help clarify
things.<br><br>
<br>
Forrest<br>
[email-masked]</blockquote><br>
In our work on reference architecture we refer to node as a physical
entity that may encapsulate other physical entities and that may have a
number of different functional entities running on it.&nbsp; So from that
perspective a DTN host would be a node (with possibly one or more
computers, sub-nodes).&nbsp; The DTN &quot;Bundling protocol engine&quot;
is an application (functional) entity that reside on one (or more) of
these computers.<br><br>
This work for you?<br><br>
Peter</blockquote><br>
Yes, that works fine for me. I've always thought of a node as a physical
entity. And I agree that the DTN &quot;Bundling protocol engine&quot; is
a functional entity (hardware or software), although if it is named an
&quot;application entity&quot; many readers may believe it runs at the
&quot;application layer&quot;, whereas I've assumed the engine runs at
the &quot;bundle layer&quot;.</blockquote><br>
Except that, for the purposes of the DTN architecture, simply saying that
something is a physical entity that may encapsulate other physical
entities and might host multiple functional entities doesn't buy us a lot
of cognitive leverage.&nbsp; [Since the &quot;may&quot; in each clause
suggests a given node might not do one or the other, or might not even do
either, one could conceivably call a toaster a node.]<br><br>
The specific concept for which we need a word (for which purpose we tend
to use the word &quot;node&quot;) is essentially &quot;something that DTN
can successfully route a bundle to&quot;.&nbsp; So I think we use the
term &quot;node&quot; to mean &quot;a Bundling protocol engine&quot; --
with the informal understanding that it also implicitly refers to the
hardware that enables operation of that protocol engine.<br><br>
And there's a further understanding that a single &quot;node&quot; might
have an &quot;interface&quot; (or even multiple interfaces) in each of
several distinct regions, and those interfaces are the things that
region-specific &quot;bundle agent identifiers&quot; (or whatever we end
up calling them) correspond to.<br><br>
Scott</html>

--=====================_6909254==_.ALT--

Date: Sat, 15 Mar 2003 21:06:10 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

--=====================_5357273==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:44 PM 3/14/2003 -0800, Forrest Warthman wrote:
>Scott,
>
>I applaud your desire to impose discipline on naming. Just a few thoughts:
>
>At 04:26 AM 3/13/2003, Scott Burleigh wrote:
>
>>These application entity IDs are what we have been calling "tuples", but 
>>in light of the notation we're considering it might make sense to start 
>>calling them "application entity IDs" instead.  Whether we do that or 
>>not, it is still the case that in order to be usable by Delay-Tolerant 
>>Networking each such label must have two components: one component that 
>>identifies the "region" in which the application entity resides (which we 
>>call the "region ID") and a second component that uniquely identifies the 
>>application entity within that region.
>>
>>Let's call that second component the "regional ID", a bold departure from 
>>our past practice, to differentiate it from the more comprehensive 
>>"application entity ID".
>
>I think many readers would interpret "region ID" and "regional ID" as 
>synonyms ("regional" = "pertaining to a region").

Fair enough, let's pick another name.  We're moving toward expressing that 
second component as a Universal Resource Identifier, either a URL 
(identification by locality, containing both the "demux token" of the 
application entity and the ID of the DTN node that this entity communicates 
through) or a URN (an associative identification; you'd use the URN to look 
up the node ID and demux token in a registry).  Since both of these types 
of expression pertain to "resources", maybe we could call the second 
component of application entity ID a "resource ID".

>Also, your group appears to use "tuple" to mean a "2-tuple, although many 
>readers will interpret it as meaning "n-tuple", and they may wonder how 
>many members the ordered set could potentially have.

Which may be another good reason to start edging away from that term.

>>NOTE that nothing discussed so far expresses the identity of any DTN 
>>"node" (which I think is our term for a Bundling protocol engine); we 
>>only identify application entities.  Application entities produce and 
>>consume bundle content, not bundles.  DTN nodes encapsulate the bundle 
>>content that bundle content producers produce; they forward the resulting 
>>bundles through a delay-tolerant network; and they extract bundle content 
>>from bundles and somehow enable bundle content consumers to consume that 
>>content.  We may or may not need a way to express the identity of a DTN 
>>node, but so far in this discussion we haven't referred to or devised one.
>
>Good point. Based on the text I found in the architecture draft about 
>"entity ID", I said in the Tutorial , "An entity may be a host (a DTN 
>node), an application instance, a protocol, a URL, a port (used to find 
>the bundle service on a host) and potentially a token (used to find a 
>particular application instance that is using the bundle service), or 
>something else." But I think the distinction you propose between a node 
>and an application would help clarify things.

Yes, we currently use "entity" in too many ways.  It's time to get a little 
more careful with our language.

Scott

--=====================_5357273==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 02:44 PM 3/14/2003 -0800, Forrest Warthman wrote:<br>
<blockquote type=cite class=cite cite>Scott,<br><br>
I applaud your desire to impose discipline on naming. Just a few
thoughts:<br><br>
At 04:26 AM 3/13/2003, Scott Burleigh wrote:<br><br>
<blockquote type=cite class=cite cite>These application entity IDs are
what we have been calling &quot;tuples&quot;, but in light of the
notation we're considering it might make sense to start calling them
&quot;application entity IDs&quot; instead.&nbsp; Whether we do that or
not, it is still the case that in order to be usable by Delay-Tolerant
Networking each such label must have two components: one component that
identifies the &quot;region&quot; in which the application entity resides
(which we call the &quot;region ID&quot;) and a second component that
uniquely identifies the application entity within that region.<br><br>
Let's call that second component the &quot;regional ID&quot;, a bold
departure from our past practice, to differentiate it from the more
comprehensive &quot;application entity ID&quot;.</blockquote><br>
I think many readers would interpret &quot;region ID&quot; and
&quot;regional ID&quot; as synonyms (&quot;regional&quot; =
&quot;pertaining to a region&quot;).</blockquote><br>
Fair enough, let's pick another name.&nbsp; We're moving toward
expressing that second component as a Universal Resource Identifier,
either a URL (identification by locality, containing both the &quot;demux
token&quot; of the application entity and the ID of the DTN node that
this entity communicates through) or a URN (an associative
identification; you'd use the URN to look up the node ID and demux token
in a registry).&nbsp; Since both of these types of expression pertain to
&quot;resources&quot;, maybe we could call the second component of
application entity ID a &quot;resource ID&quot;. <br><br>
<blockquote type=cite class=cite cite>Also, your group appears to use
&quot;tuple&quot; to mean a &quot;2-tuple, although many readers will
interpret it as meaning &quot;n-tuple&quot;, and they may wonder how many
members the ordered set could potentially have.</blockquote><br>
Which may be another good reason to start edging away from that
term.<br><br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>NOTE
that nothing discussed so far expresses the identity of any DTN
&quot;node&quot; (which I think is our term for a Bundling protocol
engine); we only identify application entities.&nbsp; Application
entities produce and consume bundle content, not bundles.&nbsp; DTN nodes
encapsulate the bundle content that bundle content producers produce;
they forward the resulting bundles through a delay-tolerant network; and
they extract bundle content from bundles and somehow enable bundle
content consumers to consume that content.&nbsp; We may or may not need a
way to express the identity of a DTN node, but so far in this discussion
we haven't referred to or devised one.</blockquote><br>
Good point. Based on the text I found in the architecture draft about
&quot;entity ID&quot;, I said in the Tutorial , &quot;An <i>entity
</i>may be a host (a DTN node), an application instance, a protocol, a
URL, a port (used to find the bundle service on a host) and potentially a
token (used to find a particular application instance that is using the
bundle service), or something else.&quot; But I think the distinction you
propose between a node and an application would help clarify
things.</blockquote><br>
Yes, we currently use &quot;entity&quot; in too many ways.&nbsp; It's
time to get a little more careful with our language.<br><br>
Scott<br>
</html>

--=====================_5357273==_.ALT--

Date: Sat, 15 Mar 2003 21:11:56 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] More Discussions on DTN endpoint naming.
Sender: [email-masked]

At 03:01 PM 3/14/2003 -0800, Forrest Warthman wrote:
>At 01:42 PM 3/13/2003, Scott,Keith L. wrote:
>>More discussions on DTN concepts...
>>
>>There really are three components to DTN names:
>>    Region identifier
>>    Destination Bundle Agent Identifier
>>    Registrant (application that registered to receive bundles via the
>>            destination bundle agent)
>
>I think this distinction between the three components is very helpful. 
>Regarding the general case of "DTN names", I assume the above naming is 
>for a destination and that there is comparable naming for a sender.

Yeah, I think this is another ambiguity we could try to head off.  Let's 
say "DTN name" or "application entity ID", but not both.

Anyway, "registrant" is a plausible alternative to the "resource ID" term I 
proposed in my earlier email.

Date: Fri, 14 Mar 2003 18:48:58 -0800
To: Peter Shames <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

--=====================_4289678==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:45 PM 3/14/2003, Peter Shames wrote:
>At 2:44 PM -0800 3/14/03, Warthman Associates wrote:
>>
>>>NOTE that nothing discussed so far expresses the identity of any DTN 
>>>"node" (which I think is our term for a Bundling protocol engine); we 
>>>only identify application entities.  Application entities produce and 
>>>consume bundle content, not bundles.  DTN nodes encapsulate the bundle 
>>>content that bundle content producers produce; they forward the 
>>>resulting bundles through a delay-tolerant network; and they extract 
>>>bundle content from bundles and somehow enable bundle content consumers 
>>>to consume that content.  We may or may not need a way to express the 
>>>identity of a DTN node, but so far in this discussion we haven't 
>>>referred to or devised one.
>>
>>Good point. Based on the text I found in the architecture draft about 
>>"entity ID", I said in the Tutorial , "An entity may be a host (a DTN 
>>node), an application instance, a protocol, a URL, a port (used to find 
>>the bundle service on a host) and potentially a token (used to find a 
>>particular application instance that is using the bundle service), or 
>>something else." But I think the distinction you propose between a node 
>>and an application would help clarify things.
>>
>>
>>Forrest
>>[email-masked]
>
>In our work on reference architecture we refer to node as a physical 
>entity that may encapsulate other physical entities and that may have a 
>number of different functional entities running on it.  So from that 
>perspective a DTN host would be a node (with possibly one or more 
>computers, sub-nodes).  The DTN "Bundling protocol engine" is an 
>application (functional) entity that reside on one (or more) of these 
>computers.
>
>This work for you?
>
>Peter

Yes, that works fine for me. I've always thought of a node as a physical 
entity. And I agree that the DTN "Bundling protocol engine" is a functional 
entity (hardware or software), although if it is named an "application 
entity" many readers may believe it runs at the "application layer", 
whereas I've assumed the engine runs at the "bundle layer".

Forrest

-----------------------------------------------------------------
Forrest Warthman       Warthman Associates      Technical Writers
2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
(650)494-8555          (650)857-1815 fax         www.warthman.com
--=====================_4289678==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 03:45 PM 3/14/2003, Peter Shames wrote:<br>
<blockquote type=cite class=cite cite>At 2:44 PM -0800 3/14/03, Warthman
Associates wrote:<br>
<blockquote type=cite class=cite cite><br>
<blockquote type=cite class=cite cite>NOTE that nothing discussed so far
expresses the identity of any DTN &quot;node&quot; (which I think is our
term for a Bundling protocol engine); we only identify application
entities.&nbsp; Application entities produce and consume bundle content,
not bundles.&nbsp; DTN nodes encapsulate the bundle content that bundle
content producers produce; they forward the resulting bundles through a
delay-tolerant network; and they extract bundle content from bundles and
somehow enable bundle content consumers to consume that content.&nbsp; We
may or may not need a way to express the identity of a DTN node, but so
far in this discussion we haven't referred to or devised
one.</blockquote><br>
Good point. Based on the text I found in the architecture draft about
&quot;entity ID&quot;, I said in the Tutorial , &quot;An<i> entity</i>
may be a host (a DTN node), an application instance, a protocol, a URL, a
port (used to find the bundle service on a host) and potentially a token
(used to find a particular application instance that is using the bundle
service), or something else.&quot; But I think the distinction you
propose between a node and an application would help clarify
things.<br><br>
<br>
Forrest<br>
[email-masked]</blockquote><br>
In our work on reference architecture we refer to node as a physical
entity that may encapsulate other physical entities and that may have a
number of different functional entities running on it.&nbsp; So from that
perspective a DTN host would be a node (with possibly one or more
computers, sub-nodes).&nbsp; The DTN &quot;Bundling protocol engine&quot;
is an application (functional) entity that reside on one (or more) of
these computers.<br><br>
This work for you?<br><br>
Peter</blockquote><br><br>
Yes, that works fine for me. I've always thought of a node as a physical
entity. And I agree that the DTN &quot;Bundling protocol engine&quot; is
a functional entity (hardware or software), although if it is named an
&quot;application entity&quot; many readers may believe it runs at the
&quot;application layer&quot;, whereas I've assumed the engine runs at
the &quot;bundle layer&quot;. <br><br>
Forrest<br><br>
<x-sigsep><p></x-sigsep>
-----------------------------------------------------------------<br>
Forrest Warthman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Warthman
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Technical Writers<br>
2417 Embarcadero Way&nbsp;&nbsp; Palo Alto, CA 94303&nbsp;&nbsp;
[email-masked]<br>
(650)494-8555&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(650)857-1815 fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="http://www.warthman.com/" eudora="autourl">www.warthman.com</a></html>

--=====================_4289678==_.ALT--

Date: Fri, 14 Mar 2003 15:45:09 -0800
To: Warthman Associates <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
From: Peter Shames <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

--============_-1164436985==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:44 PM -0800 3/14/03, Warthman Associates wrote:
>
>>NOTE that nothing discussed so far expresses the identity of any 
>>DTN "node" (which I think is our term for a Bundling protocol 
>>engine); we only identify application entities.  Application 
>>entities produce and consume bundle content, not bundles.  DTN 
>>nodes encapsulate the bundle content that bundle content producers 
>>produce; they forward the resulting bundles through a 
>>delay-tolerant network; and they extract bundle content from 
>>bundles and somehow enable bundle content consumers to consume that 
>>content.  We may or may not need a way to express the identity of a 
>>DTN node, but so far in this discussion we haven't referred to or 
>>devised one.
>>
>
>Good point. Based on the text I found in the architecture draft 
>about "entity ID", I said in the Tutorial , "An entity may be a host 
>(a DTN node), an application instance, a protocol, a URL, a port 
>(used to find the bundle service on a host) and potentially a token 
>(used to find a particular application instance that is using the 
>bundle service), or something else." But I think the distinction you 
>propose between a node and an application would help clarify things.
>
>
>Forrest
>[email-masked]

In our work on reference architecture we refer to node as a physical 
entity that may encapsulate other physical entities and that may have 
a number of different functional entities running on it.  So from 
that perspective a DTN host would be a node (with possibly one or 
more computers, sub-nodes).  The DTN "Bundling protocol engine" is an 
application (functional) entity that reside on one (or more) of these 
computers.

This work for you?

Peter

-- 
_______________________________________________________________

Peter Shames
Manager - JPL Information Systems Standards Program
InterPlanetary Network and Information Systems Directorate
Jet Propulsion Laboratory, MS 301-265
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-1333

Internet:  [email-masked]
_______________________________________________________________
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the first time"

T.S. Eliot
--============_-1164436985==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [dtn-interest] Thoughts on the construction of
tup</title></head><body>
<div>At 2:44 PM -0800 3/14/03, Warthman Associates wrote:</div>
<blockquote type="cite" cite><br>
<blockquote type="cite" cite>NOTE that nothing discussed so far
expresses the identity of any DTN &quot;node&quot; (which I think is
our term for a Bundling protocol engine); we only identify application
entities.&nbsp; Application entities produce and consume bundle
content, not bundles.&nbsp; DTN nodes encapsulate the bundle content
that bundle content producers produce; they forward the resulting
bundles through a delay-tolerant network; and they extract bundle
content from bundles and somehow enable bundle content consumers to
consume that content.&nbsp; We may or may not need a way to express
the identity of a DTN node, but so far in this discussion we haven't
referred to or devised one.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
Good point. Based on the text I found in the architecture draft about
&quot;entity ID&quot;, I said in the Tutorial , &quot;An<i> entity</i>
may be a host (a DTN node), an application instance, a protocol, a
URL, a port (used to find the bundle service on a host) and
potentially a token (used to find a particular application instance
that is using the bundle service), or something else.&quot; But I
think the distinction you propose between a node and an application
would help clarify things.<br>
<br>
<br>
Forrest<br>
[email-masked]</blockquote>
<div><br></div>
<div>In our work on reference architecture we refer to node as a
physical entity that may encapsulate other physical entities and that
may have a number of different functional entities running on it.&nbsp;
So from that perspective a DTN host would be a node (with possibly one
or more computers, sub-nodes).&nbsp; The DTN &quot;Bundling protocol
engine&quot; is an application (functional) entity that reside on one
(or more) of these computers.</div>
<div><br></div>
<div>This work for you?</div>
<div><br></div>
<div>Peter</div>
<div><br></div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><font face="Geneva" size="-1"
color="#000000"
>_______________________________________________________________</font
><br>
<font face="Geneva" size="-1" color="#000000"></font></div>
<div><font face="Geneva" size="-1" color="#000000">Peter
Shames</font></div>
<div><font face="Geneva" size="-1" color="#000000">Manager - JPL
Information Systems Standards Program</font></div>
<div><font face="Geneva" size="-1" color="#000000">InterPlanetary
Network and Information Systems Directorate</font></div>
<div><font face="Geneva" size="-1" color="#000000">Jet Propulsion
Laboratory, MS 301-265<br>
California Institute of Technology<br>
Pasadena, CA 91109 USA</font><br>
<font face="Geneva" size="-1" color="#000000"></font></div>
<div><font face="Geneva" size="-1" color="#000000">Telephone: +1 818
354-5740,&nbsp; Fax: +1 818 393-1333<br>
<br>
Internet:&nbsp; [email-masked]<br>
___________________________________________________________</font><font
 face="Geneva" size="+1" color="#000000">____</font></div>
<div><font face="Geneva" size="-1" color="#000000">&quot;We shall not
cease from exploration, and the end of all our exploring</font></div>
<div><font face="Geneva" size="-1" color="#000000">will be to arrive
at where we started, and know the place for the first
time&quot;</font></div>
<div><font face="Geneva" size="-1" color="#000000"><br></font></div>
<div><font face="Geneva" size="-1"
color="#000000"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; T.S. Eliot</font></div>
</body>
</html>
--============_-1164436985==_ma============--

Date: Fri, 14 Mar 2003 15:01:12 -0800
To: "Scott,Keith L." <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] More Discussions on DTN endpoint naming.
Sender: [email-masked]

At 01:42 PM 3/13/2003, Scott,Keith L. wrote:
>More discussions on DTN concepts...
>
>There really are three components to DTN names:
>    Region identifier
>    Destination Bundle Agent Identifier
>    Registrant (application that registered to receive bundles via the
>            destination bundle agent)

I think this distinction between the three components is very helpful. 
Regarding the general case of "DTN names", I assume the above naming is for 
a destination and that there is comparable naming for a sender. 

Date: Fri, 14 Mar 2003 14:44:28 -0800
To: Scott Burleigh <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

--=====================_69466387==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Scott,

I applaud your desire to impose discipline on naming. Just a few thoughts:

At 04:26 AM 3/13/2003, Scott Burleigh wrote:

>These application entity IDs are what we have been calling "tuples", but 
>in light of the notation we're considering it might make sense to start 
>calling them "application entity IDs" instead.  Whether we do that or not, 
>it is still the case that in order to be usable by Delay-Tolerant 
>Networking each such label must have two components: one component that 
>identifies the "region" in which the application entity resides (which we 
>call the "region ID") and a second component that uniquely identifies the 
>application entity within that region.
>
>Let's call that second component the "regional ID", a bold departure from 
>our past practice, to differentiate it from the more comprehensive 
>"application entity ID".

I think many readers would interpret "region ID" and "regional ID" as 
synonyms ("regional" = "pertaining to a region"). Also, your group appears 
to use "tuple" to mean a "2-tuple, although many readers will interpret it 
as meaning "n-tuple", and they may wonder how many members the ordered set 
could potentially have.

>NOTE that nothing discussed so far expresses the identity of any DTN 
>"node" (which I think is our term for a Bundling protocol engine); we only 
>identify application entities.  Application entities produce and consume 
>bundle content, not bundles.  DTN nodes encapsulate the bundle content 
>that bundle content producers produce; they forward the resulting bundles 
>through a delay-tolerant network; and they extract bundle content from 
>bundles and somehow enable bundle content consumers to consume that 
>content.  We may or may not need a way to express the identity of a DTN 
>node, but so far in this discussion we haven't referred to or devised one.

Good point. Based on the text I found in the architecture draft about 
"entity ID", I said in the Tutorial , "An entity may be a host (a DTN 
node), an application instance, a protocol, a URL, a port (used to find the 
bundle service on a host) and potentially a token (used to find a 
particular application instance that is using the bundle service), or 
something else." But I think the distinction you propose between a node and 
an application would help clarify things.

Forrest
[email-masked]

--=====================_69466387==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Scott,<br><br>
I applaud your desire to impose discipline on naming. Just a few
thoughts:<br><br>
At 04:26 AM 3/13/2003, Scott Burleigh wrote:<br><br>
<blockquote type=cite class=cite cite>These application entity IDs are
what we have been calling &quot;tuples&quot;, but in light of the
notation we're considering it might make sense to start calling them
&quot;application entity IDs&quot; instead.&nbsp; Whether we do that or
not, it is still the case that in order to be usable by Delay-Tolerant
Networking each such label must have two components: one component that
identifies the &quot;region&quot; in which the application entity resides
(which we call the &quot;region ID&quot;) and a second component that
uniquely identifies the application entity within that region.<br><br>
Let's call that second component the &quot;regional ID&quot;, a bold
departure from our past practice, to differentiate it from the more
comprehensive &quot;application entity ID&quot;.</blockquote><br>
I think many readers would interpret &quot;region ID&quot; and
&quot;regional ID&quot; as synonyms (&quot;regional&quot; =
&quot;pertaining to a region&quot;). Also, your group appears to use
&quot;tuple&quot; to mean a &quot;2-tuple, although many readers will
interpret it as meaning &quot;n-tuple&quot;, and they may wonder how many
members the ordered set could potentially have. <br><br>
<br>
<blockquote type=cite class=cite cite>NOTE that nothing discussed so far
expresses the identity of any DTN &quot;node&quot; (which I think is our
term for a Bundling protocol engine); we only identify application
entities.&nbsp; Application entities produce and consume bundle content,
not bundles.&nbsp; DTN nodes encapsulate the bundle content that bundle
content producers produce; they forward the resulting bundles through a
delay-tolerant network; and they extract bundle content from bundles and
somehow enable bundle content consumers to consume that content.&nbsp; We
may or may not need a way to express the identity of a DTN node, but so
far in this discussion we haven't referred to or devised
one.</blockquote><br>
Good point. Based on the text I found in the architecture draft about
&quot;entity ID&quot;, I said in the Tutorial , &quot;An <i>entity
</i>may be a host (a DTN node), an application instance, a protocol, a
URL, a port (used to find the bundle service on a host) and potentially a
token (used to find a particular application instance that is using the
bundle service), or something else.&quot; But I think the distinction you
propose between a node and an application would help clarify things.
<br><br>
<br>
Forrest<br>
[email-masked]<br>
</html>

--=====================_69466387==_.ALT--

Date: Fri, 14 Mar 2003 14:01:54 -0500
From: "Scott,Keith L." <[email-masked]>
To: dtn-interest <[email-masked]>
CC: Adrian Hooke <[email-masked]>
Subject: [dtn-interest] Flow control / congestion control / resource management in DTNs
Sender: [email-masked]

--------------090508010507030000090903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  How do we deal with flow control and congestion control in DTNs where 
we have really long (and possibly unpredictable) communications delays. 
 While flow control in the internet is generally taken to be end-to-end, 
for DTN we may never really have any contemporaneous e2e association. 
 Plus, since we have a flavor of hop-by-hop forwarding (in the overlay 
of bundle routers), flow control really only makes sense on a 
hop-by-(bundle)hop basis.  Congestion corresponds here to filling up of 
persistent storage.  So, hop by hop flow control is closely linked with 
how the handling of this sort of congestion will work.  From history we 
know that exerting hop by hop flow control can lead to eventual cascaded 
lock-up, so we have to keep this in mind.  We have a partial solution to 
the network being congested (by bundles timing out), but this is pretty 
coarse.

Consider the following:

A----->B------>C
       ^
       |
       |
       D

Flow1: A--->C
Flow2: D--->C

Now assume the B-->C connection is intermittent, and maybe not even 
predictable, so B never knows how long it's going to be before it can 
get rid of bundles towards C.  Now A->C traffic may need to be buffered 
for a long time.  If we allow B to fully congest, then D->A traffic via 
B will not be possible.  This seems bad.

Is this fundamentally a buffer management problem or a (transmission) 
rate management problem [or are these isomorphic]?

If the transport layer under bundling has the ability to perform flow 
control, can we use that alone {between two guys in the same region} to 
achieve flow control.
This amounts to shoving flow control down onto the convergence layers 
(since they know how to transmit data in the underlying protocols of the 
region)?

So, routing, buffer management and traffic rates all directly relate to 
how congestion forms, and DTN custody transfer makes managing it fairly 
challenging.
Perhaps control theory problems in the context of flow control, rate 
control, and buffer management of this kind would presumably be quite 
useful.  Who knows a lot about this and would be interested in helping?

=======

Calculation of rate of buffer (fill/depletion) is problematic because if 
you try to use _just_ rate of buffer fill as your discriminant of 
whether to accept new stuff or not, you can get fooled.  Counterexample 
is to get something, then don't get anything for a long time, causing 
your rate of buffer fill would then be very low, making you think that 
you could accept more (making your rate of buffer fill go up) then a 
long period of no activity goes by and you think you can accept more 
(still not hiving gotten rid of anything).  In this way you could still 
get completely filled up, always thinking that you were OK.

Parameters a bundle agent might want to use to determine whether or not 
it wants to accept new bundles (for forwarding)
    buffer occupation
    rate of change of buffer occupancy

There are two levels of willingness to accept bundles: those that a 
bundle agent just needs to route vs. those that it takes custody of. 
 Taking custody of a bundle

There's an analogy to spending money in personal finances.  When you've 
got a lot of money in the bank (lots of free buffer space), you're 
probably more amenable to spending money.  Then again, if your rate of 
spending is large enough compared to your income, the point at which you 
begin to economize is likely to be higher.  Accepting bundles for 
delivery is like buying commodities (you expect to get rid of them by 
'selling' them later).  Taking custody of bundles is like buying less 
liquid commodities (you may have to hold onto them longer before finding 
a willing buyer).

--------------090508010507030000090903
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
          <tt>How do we deal with flow control and congestion control in
DTNs where we have really long (and possibly unpredictable) communications
delays. &nbsp;While flow control in the internet is generally taken to be end-to-end,
for DTN we may never really have any contemporaneous e2e association. &nbsp;Plus,
since we have a flavor of hop-by-hop forwarding (in the overlay of bundle
routers), flow control really only makes sense on a hop-by-(bundle)hop basis.
&nbsp;Congestion corresponds here to filling up of persistent storage. &nbsp;So, hop
by hop flow control is closely linked with how the handling of this sort
of congestion will work. &nbsp;From history we know that exerting hop by hop flow
control can lead to eventual cascaded lock-up, so we have to keep this in
mind. &nbsp;We have a partial solution to the network being congested (by bundles
timing out), but this is pretty coarse.<br>
<br>
Consider the following:<br>
 <br>
 A-----&gt;B------&gt;C<br>
 &nbsp; &nbsp; &nbsp; &nbsp;^<br>
 &nbsp; &nbsp; &nbsp; &nbsp;|<br>
 &nbsp; &nbsp; &nbsp; &nbsp;|<br>
 &nbsp; &nbsp; &nbsp; &nbsp;D<br>
 <br>
 Flow1: A---&gt;C<br>
 Flow2: D---&gt;C<br>
 <br>
 Now assume the B--&gt;C connection is intermittent, and maybe not even predictable, 
so B never knows how long it's going to be before it can get rid of bundles 
towards C. &nbsp;Now A-&gt;C traffic may need to be buffered for a long time.
&nbsp;If we allow B to fully congest, then D-&gt;A traffic via B will not be possible.
&nbsp;This seems bad.<br>
 <br>
 Is this fundamentally a buffer management problem or a (transmission) rate 
management problem [or are these isomorphic]?<br>
<br>
If the transport layer under bundling has the ability to perform flow control,
can we use that alone {between two guys in the same region} to achieve flow
control.<br>
 This amounts to shoving flow control down onto the convergence layers (since 
they know how to transmit data in the underlying protocols of the region)?<br>
 <br>
So, routing, buffer management and traffic rates all directly relate to how
congestion forms, and DTN custody transfer makes managing it fairly challenging.<br>
Perhaps control theory problems in the context of flow control, rate control, 
and buffer management of this kind would presumably be quite useful. &nbsp;Who
knows a lot about this and would be interested in helping?<br>
 <br>
 =======<br>
 <br>
 Calculation of rate of buffer (fill/depletion) is problematic because if 
you try to use _just_ rate of buffer fill as your discriminant of whether 
to accept new stuff or not, you can get fooled. &nbsp;Counterexample is to get 
something, then don't get anything for a long time, causing your rate of buffer
fill would then be very low, making you think that you could accept more
(making your rate of buffer fill go up) then a long period of no activity 
goes by and you think you can accept more (still not hiving gotten rid of 
anything). &nbsp;In this way you could still get completely filled up, always thinking
that you were OK.<br>
 <br>
 Parameters a bundle agent might want to use to determine whether or not
it wants to accept new bundles (for forwarding)<br>
 &nbsp;&nbsp;&nbsp; buffer occupation<br>
 &nbsp;&nbsp;&nbsp; rate of change of buffer occupancy<br>
 <br>
There are two levels of willingness to accept bundles: those that a bundle
agent just needs to route vs. those that it takes custody of. &nbsp;Taking custody
of a bundle<br>
<br>
There's an analogy to spending money in personal finances. &nbsp;When you've got
a lot of money in the bank (lots of free buffer space), you're probably more
amenable to spending money. &nbsp;Then again, if your rate of spending is large
enough compared to your income, the point at which you begin to economize
is likely to be higher. &nbsp;Accepting bundles for delivery is like buying commodities
(you expect to get rid of them by 'selling' them later). &nbsp;Taking custody
of bundles is like buying less liquid commodities (you may have to hold onto
them longer before finding a willing buyer).<br>
<br>
<br>
 <br>
 </tt> 
</body>
</html>

--------------090508010507030000090903--

Date: Thu, 13 Mar 2003 16:42:04 -0500
From: "Scott,Keith L." <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] More Discussions on DTN endpoint naming.
Sender: [email-masked]

More discussions on DTN concepts...

There really are three components to DTN names:
    Region identifier
    Destination Bundle Agent Identifier
    Registrant (application that registered to receive bundles via the
            destination bundle agent)

In some cases it may be useful to use _fully associative_ names for the 
(destination bundle agent, registrant) pair.  In these cases, bundle 
registrants would supply some sort of key (e.g. a URN).  The URN would 
be supplied to some sort of regional registry.  Bundles destined for the 
registrant would carry the URN in what is the 'application endpoint id' 
part of the DTN tuple.  Border routers would consult the registry, using 
the URN as a key, to determine the (bundle agent identifier, registrant) 
pair.  Obviously there'd have to be some way to determine whether the 
'application endpoint id' part of the DTN tuple contains (explicitly) 
the bundle agent identifier and registrant information or if it's an 
associative key.  That's why URIs as application endpoint IDs might be a 
good thing  :)  Also assumes the existance/availability of the registry 
thing.

tuple  ---> dtn:{region, X}
   X  ---> {URN | URL}

maybe the URL format would be something like:

    inet:hostname/demux   --  hostname in the internet semantics (dns 
name or IP address)
    chort:chordname   --  chordname

Date: Thu, 13 Mar 2003 04:26:52 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

At 05:39 PM 3/12/2003 -0500, Keith Scott wrote:
>Thoughts from a meeting of DTN interested folks:
>
>
>
>How are things really named?  What _is_ the 'entity ID' part of (what is
>defined in the architecture draft as) a DTN tuple?
>
>
>URI
>  |
>  |
>  +-- URL -- stuff like foo://authority/name
>  |          (foo in the above is the URI SCHEME NAME)
>  |          Location-based names
>  |
>  +-- URN -- stuff like ISBN# or ISSN
>             example:  urn:isbn:1234-56-7890
>             associative names
>             associative names - persistent and unique
>
>URN :=   urn:<nid>:<nss>
>         nid = namepsace identifier
>         nss = namespace specific string (semantics determined by
>namespace)
>
>Can we use a 'dtn' URI scheme to express DTN tuples?  Using this, DTN
>tuples might be expressed as:
>
>dtn://REGION/URI

I think it would be excellent if we could come out of this discussion with 
some disambiguation of terminology that we use freely, and sometimes 
inconsistently, in the Architecture drafts.  It might save us some time in 
architecture and design sessions, and it might be a kindness to readers of 
our documents.

For example:

Suppose we assume that everyone already has an intuitive understanding of 
what it means to "produce" some data and to "consume" some data, and of 
what an abstract "thread of control" is.  [Okay, maybe these aren't the 
right fundamental terms.  Assume that at some time an argument will take 
place, from which mutually agreeable terms that map to these fundamental 
notions will emerge, bloodied but unbowed.]

"Thread of control" is, again, an abstraction; a thread of control might be 
instantiated by an operating system "process" or "thread" or "lightweight 
process" or "task", or by a language-supported "thread", or by a piece of 
firmware or hardware, to accomplish some purpose that we call an "application".

So a "bundle content producer" is a thread of control that produces some 
application data object which is to be encapsulated in a Bundle for 
transmission to a thread of control that is to consume that application 
data object, termed a "bundle content producer".  Let's call all bundle 
content producers and consumers "application entities".

In order for bundle transmission to succeed, the bundle in which the 
application data object is encapsulated contains (among other things) a 
label expressing the identity of the bundle content producer and another 
label expressing the identity of the bundle content consumer.  Let's call 
these labels the "source application entity ID" and the "destination 
application entity ID".

These application entity IDs are what we have been calling "tuples", but in 
light of the notation we're considering it might make sense to start 
calling them "application entity IDs" instead.  Whether we do that or not, 
it is still the case that in order to be usable by Delay-Tolerant 
Networking each such label must have two components: one component that 
identifies the "region" in which the application entity resides (which we 
call the "region ID") and a second component that uniquely identifies the 
application entity within that region.

Let's call that second component the "regional ID", a bold departure from 
our past practice, to differentiate it from the more comprehensive 
"application entity ID".

To summarize so far:

         tuple == application entity ID

         application entity ID contains:
                 region ID
                 regional ID

Given all this, I think the specific notational standard we're moving 
toward could be defined like this:

         application_entity_id =  "dtn:" region_id "/" regional_id

         region_id =  ( net_path | abs_path )    <as defined in the 
"generic URI" syntax definitions in RFC 2396>

         regional_id =  absoluteURI   <also as defined in RFC 2396>

NOTE that nothing discussed so far expresses the identity of any DTN "node" 
(which I think is our term for a Bundling protocol engine); we only 
identify application entities.  Application entities produce and consume 
bundle content, not bundles.  DTN nodes encapsulate the bundle content that 
bundle content producers produce; they forward the resulting bundles 
through a delay-tolerant network; and they extract bundle content from 
bundles and somehow enable bundle content consumers to consume that 
content.  We may or may not need a way to express the identity of a DTN 
node, but so far in this discussion we haven't referred to or devised one.

From: Keith Scott <[email-masked]>
To: [email-masked]
Organization: 
Date: 12 Mar 2003 17:39:38 -0500
Subject: [dtn-interest] Thoughts on the construction of tuples.
Sender: [email-masked]

Thoughts from a meeting of DTN interested folks:

How are things really named?  What _is_ the 'entity ID' part of (what is
defined in the architecture draft as) a DTN tuple?

URI
 |
 |
 +-- URL -- stuff like foo://authority/name
 |          (foo in the above is the URI SCHEME NAME)
 |          Location-based names
 |
 +-- URN -- stuff like ISBN# or ISSN
            example:  urn:isbn:1234-56-7890
            associative names
            associative names - persistent and unique

URN :=   urn:<nid>:<nss>
	nid = namepsace identifier
	nss = namespace specific string (semantics determined by 	     
namespace)

Can we use a 'dtn' URI scheme to express DTN tuples?  Using this, DTN
tuples might be expressed as:

dtn://REGION/URI

REGION = hierarchically structured name space using DNS semantics
URI = URI

An advantage of this would be that we might be able to reuse existing
parsers.

examples:

	dtn://internet.mars.sol//http://base1.jpl.nasa.gov/bundleThing.asp?person_who_cares
	dtn://internet.earth.sol//mailto:[email-masked]
	dtn://internet.earth.sol//ftp://HOSTNAME:port/stuff
	dtn://something.earth.sol//urn:app-assoc-name:myPager/stuff
	dth://earth..../chord:37482372358723/guy_who_cares

>From rfc2396:
   Although many URL schemes are named after protocols, this does not
   imply that the only way to access the URL's resource is via the named
   protocol.  Gateways, proxies, caches, and name resolution services
   might be used to access some resources, independent of the protocol
   of their origin, and the resolution of some URL may require the use
   of more than one protocol (e.g., both DNS and HTTP are typically used
   to access an "http" URL's resource when it can't be found in a local
   cache).

It is unclear what it might mean to send a bundle to an ISBN # (a
book...)

Should we try to register the URI scheme 'tcp' for those times when we
want to use the tcp protocol to deliver a bundle

	dtn://internet.earth.sol//tcp://HOSTNAME[:port]/otherstuff

<<For when there's a bundle agent running on 'machine.company.com'. 
otherstuff here would be some local information used to demux to a
particular registrant on that bundle agent?>>

Question: for the different URI schemes, can we parse the stuff after
the region identifier and determine a priori where is the location of
the bundle agent (thing that groks bundles)?  Careful, with the mailto
scheme a complete bundle might end up on [email-masked]'s mail queue
and several clients could check that account, consume the bundles and
demux them to their (the various clients') registrants.

Now, all of this is sort of weird, because using things like the http or
mailto schemas in a destination address is specifying a protocol used to
deliver stuff in the destination internet, something the source probably
shouldn't be doing...

----------------------

===========

xxx.asp  = Active Server Page -- like a servlet that runs on an http
server.

-- 
Keith Scott <[email-masked]>

content-class: urn:content-classes:message
Subject: RE: [dtn-interest] error
Date: Wed, 5 Mar 2003 09:55:36 -0800
From: "Fall, Kevin R" <[email-masked]>
To: "vinton g. cerf" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Yes, evidently these folks (including myself you will notice) were
registered as members of this list but under different e-mail addresses.
So, they got queued pending approval (and I hadn't handled this properly
until yesterday; my apologies).  On the bright side, I did save you from
some additional spam :)

- Kevin

-----Original Message-----
From: vinton g. cerf [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2003 4:02 AM
To: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] error

yes, somehow these messages were queued up for list moderator 
consideration I believe....

vint

At 06:43 AM 3/5/2003 -0500, [email-masked] wrote:
>I received these 6 messages yesterday. Some were sent as far back as
Oct
>2002. The dates were all jumbled up, as you can see below. Is there
some
>problem with the mailing list that's causing them to get delayed?
>
>
>Durga
>
>My inbox looks like:
>
>188 vinton g. cerf [dtn-interest] Fwd: Re: WWW comments (Forms... 01
Mar
>2003 1730K 
>
>187 Fall, Kevin R [dtn-interest] DTN announcements 4 Mar 2003  4K 
>
>186 vinton g. cerf [dtn-interest] Fwd: Re: WWW comments (Forms... 03
Dec
>2002 1730K 
>
>185 vinton g. cerf [dtn-interest] Fwd: SpaceDev Spacecraft Per... 15
Jan
>2003 62K 
>
>184 Howard Weiss Re: [dtn-interest] interplanetary IP 24 Oct 2002 6K 
>
>183 vinton g. cerf [dtn-interest] Fwd: WHY I'M NOT FEELING CON... 18
Nov
>2002 62K 
>
>
>--------------------------------------------------------------------
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>_______________________________________________
>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

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

Date: Wed, 05 Mar 2003 07:01:55 -0500
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] error
To: [email-masked], [email-masked]
Sender: [email-masked]

yes, somehow these messages were queued up for list moderator 
consideration I believe....

vint

At 06:43 AM 3/5/2003 -0500, [email-masked] wrote:
>I received these 6 messages yesterday. Some were sent as far back as Oct
>2002. The dates were all jumbled up, as you can see below. Is there some
>problem with the mailing list that's causing them to get delayed?
>
>
>Durga
>
>My inbox looks like:
>
>188 vinton g. cerf [dtn-interest] Fwd: Re: WWW comments (Forms... 01 Mar
>2003 1730K 
>
>187 Fall, Kevin R [dtn-interest] DTN announcements 4 Mar 2003  4K 
>
>186 vinton g. cerf [dtn-interest] Fwd: Re: WWW comments (Forms... 03 Dec
>2002 1730K 
>
>185 vinton g. cerf [dtn-interest] Fwd: SpaceDev Spacecraft Per... 15 Jan
>2003 62K 
>
>184 Howard Weiss Re: [dtn-interest] interplanetary IP 24 Oct 2002 6K 
>
>183 vinton g. cerf [dtn-interest] Fwd: WHY I'M NOT FEELING CON... 18 Nov
>2002 62K 
>
>
>--------------------------------------------------------------------
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>_______________________________________________
>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

From: [email-masked]
Subject: Re: [dtn-interest] interplanetary IP
To: [email-masked]
Date: Wed, 5 Mar 2003 03:46:45 -0800 (PST)
Cc: [email-masked] (Stephen Farrell), [email-masked], [email-masked] (Hans Kruse)
Sender: [email-masked]

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

	any interest in using/exploiting the oportunistic encryption
	work that piggybacks on DNS queries for inital key distribution?

--bill

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Date: Wed, 5 Mar 2003 06:43:25 -0500
Subject: [dtn-interest] error
Sender: [email-masked]

I received these 6 messages yesterday. Some were sent as far back as Oct
2002. The dates were all jumbled up, as you can see below. Is there some
problem with the mailing list that's causing them to get delayed?

Durga

My inbox looks like:

188 vinton g. cerf [dtn-interest] Fwd: Re: WWW comments (Forms... 01 Mar
2003 1730K 

187 Fall, Kevin R [dtn-interest] DTN announcements 4 Mar 2003  4K 

186 vinton g. cerf [dtn-interest] Fwd: Re: WWW comments (Forms... 03 Dec
2002 1730K 

185 vinton g. cerf [dtn-interest] Fwd: SpaceDev Spacecraft Per... 15 Jan
2003 62K 

184 Howard Weiss Re: [dtn-interest] interplanetary IP 24 Oct 2002 6K 

183 vinton g. cerf [dtn-interest] Fwd: WHY I'M NOT FEELING CON... 18 Nov
2002 62K 

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

content-class: urn:content-classes:message
Date: Tue, 4 Mar 2003 17:47:10 -0800
From: "Fall, Kevin R" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTN announcements
Sender: [email-masked]

Hello folks.  I just wanted to let everyone know that the web site
(www.dtnrg.org) has been updated with several new/revised documents,
so please have a look.  One of these is a nice tutorial by Forrest
Warthman, who generously put this together on his own time.

Also, I wanted to (pre)announce that there will be a forum held on
5/8/03
to solicit comments on the various documents, particularly the
architecture doc.  If you are interested in attending, it will be held
in the Los Angeles area, and I request anyone who comes to first send a
(roughly) 1-page set of comments on the docs prior to showing up.  We
will put these together in some form of proceedings so that we have
something concrete to work with.

Thanks,
- Kevin Fall
Intel Research, Berkeley

Date: Sat, 01 Mar 2003 11:14:17 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: Re: WWW comments (Forms submission)
Sender: [email-masked]

--Boundary_(ID_AR3QWMRpgFpHi9KAW+27CA)
Content-type: text/plain; charset=us-ascii

per recent message, see attached.

vint

>Date: Tue, 03 Dec 2002 16:58:05 -0500
>From: "Ian F. Akyildiz" <[email-masked]>
>Subject: Re: WWW comments (Forms submission)
>To: "vinton g. cerf" <[email-masked]>
>Reply-to: [email-masked]
>Organization: Georgia Tech
>X-Accept-Language: en-us, en
>User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920
> Netscape/7.0
>X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
>
>Dear Vint
>
>We just finished our work on
>
>TCP PLANET.
>
>Please find it in the attachment.
>
>Also we had a letter published IEEE Com Letters in Nov. 2002 issue
>where we point out the shortcomings of all existing TCP protocols
>in Deep Space Networks.
>
>Your feedback will greatly be appreciated.
>
>Best regards
>
>
>Ian
>
>
>
>vinton g. cerf wrote:
>>thanks!
>>At 09:09 AM 10/8/2002 -0400, Ian F. Akyildiz wrote:
>>
>>>Vint.
>>>
>>>
>>>>I'd be interestd in the proposals but even more interested
>>>>in the documentation of the protocols you have designed as
>>>>well as information about the prototypes. Are you planning
>>>>to release reference software?
>>>
>>>Yes.. We can release the software as well as all the
>>>papers/documents with our protocols.
>>
>>a pointer would be appreciated or email attachments.
>>
>>
>>>>Do you know about the SCPS version of TCP developed by
>>>>JPL for near-space applications?
>>>
>>>Yes, in fact we asked them to send their software
>>>last Friday and they did.
>>>
>>>We already have TCP Peach and extended version TCP Peach+
>>>for the same applications.
>>>These  were published in IEEE ToN and in IEEE Com Letters.
>>>If you do not have them I can send you copies.
>>>
>>>Also we have another short letter (to appear in IEEE Com
>>>Letters in Nov) where we show
>>>all existing TCP protocols fail miserably in deep space
>>>applications. I can also send it to you too.
>>
>>\yes please
>>
>>
>>>>What does RCS-Planet mean/do?
>>>
>>>RCS --> Rate Control Scheme for Real-Time applications.
>>>We have the prelim design for RCS
>>>(as described in the proposal)
>>>but our entire effort was to develop
>>>the TCP Planet the last 10 months.
>>>Once we are done with it we will move on to RCS Planet
>>>development.
>>>
>>>As I said I can keep you informed about our
>>>developments and keep you always in the loop.
>>
>>thanks
>>vint
>>
>>
>>
>>>Regards
>>>
>>>Ian
>>>
>>>
>>>
>>>>Vint
>>>>
>>>>At 08:44 AM 10/8/2002 -0400, Ian F. Akyildiz wrote:
>>>>
>>>>>Hi Vint
>>>>>
>>>>>Good to hear from you.
>>>>>
>>>>>The story is as follows:
>>>>>
>>>>>I was supported by NASA AMES, NASA GRC, DoD and NSF
>>>>>the last 5 years to conduct research on
>>>>>satellite networking (LEO/MEO/GEOs)
>>>>>(transport layer; routing, multicasting and error control).
>>>>>We produced many useful results.
>>>>>
>>>>>Based on these projects and experience
>>>>>I started this new project, DEEP SPACE NETWORKS last Fall.
>>>>>I had prepared two proposals:
>>>>>
>>>>>* Transport Layer Protocols: TCP-Planet and RCS-Planet
>>>>>
>>>>>* Routing in Deep Space Networks
>>>>>
>>>>>I was planning to send both proposals to NASA GRC.
>>>>>Unfortunately I missed the JUNE 24 deadline due to some stupid
>>>>>oversight.
>>>>>
>>>>>My team members continued the work on TCP PLANET.
>>>>>We developed the entire protocol. Very interesting solution
>>>>>in my opinion. We are in the phase of running simulations.
>>>>>
>>>>>I will be at Univ. of Maryland to present the first version of TCP
>>>>>Planet on Oct 25.
>>>>>
>>>>>
>>>>>I can keep you informed about our developments.
>>>>>
>>>>>I can send you the two proposals if you want.
>>>>>
>>>>>The bottomline is that I do not have funding
>>>>>for this particular project at this time
>>>>>but I am hoping to obtain funding and
>>>>>get into it very deeply. I am enjoying it.
>>>>>
>>>>>I look forward to hearing from you and indeed
>>>>>I am glad that we got in touch.
>>>>>
>>>>>Hope all is well with you.
>>>>>
>>>>>Best regards,
>>>>>
>>>>>Ian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>[email-masked] (vint cerf) sent the following comment:
>>>>>>
>>>>>>------------------------------------------------------------
>>>>>>ian,
>>>>>>
>>>>>>do you have funding for your deep space network
>>>>>>research and if so, from whom? how far have you
>>>>>>gotten in the work? see www.ipnsig.org for work
>>>>>>that has a 4 year history at JPL, along with
>>>>>>prototype protocols for the high level (above
>>>>>>transport). We have long base line link level
>>>>>>stuff done, but routing (which has to be
>>>>>>predictive based on celestial mechanics and
>>>>>>emphemerides as well as schedule) are still
>>>>>>sketchy.
>>>>>>
>>>>>>Vint
>>>>>>
>>>>>>------------------------------------------------------------
>>>>>> Server protocol: HTTP/1.1
>>>>>>     Remote host:
>>>>>>Remote IP address: 166.60.14.55
>>>>>> Client Software: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
>>>>Vint Cerf
>>>>SVP Architecture & Technology
>>>>WorldCom
>>>>22001 Loudoun County Parkway, F2-4115
>>>>Ashburn, VA 20147
>>>>703 886 1690 (v806 1690)
>>>>703 886 0047 fax
>>Vint Cerf
>>SVP Architecture & Technology
>>WorldCom
>>22001 Loudoun County Parkway, F2-4115
>>Ashburn, VA 20147
>>703 886 1690 (v806 1690)
>>703 886 0047 fax
>
>
>-- 
>Dr. Ian F. Akyildiz
>Ken Byers Distinguished Chair Professor in Telecommunications
>Broadband and Wireless Networking Laboratory
>School of Electrical and Computer Engineering
>Georgia Institute of Technology
>Atlanta, GA 30332
>
>Tel.: 404-894-5141
>Fax.: 404-894-7883
>E_mail: [email-masked]
>http://www.ee.gatech.edu/research/labs/bwn
>
>
>

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_AR3QWMRpgFpHi9KAW+27CA)
Content-type: application/pdf; name=TCP-Planet.pdf
Content-transfer-encoding: base64
Content-disposition: attachment; filename=TCP-Planet.pdf

--Boundary_(ID_AR3QWMRpgFpHi9KAW+27CA)
Content-type: application/pdf; name=deepspace.pdf
Content-transfer-encoding: base64
Content-disposition: attachment; filename=deepspace.pdf

--Boundary_(ID_AR3QWMRpgFpHi9KAW+27CA)--

Date: Sat, 01 Mar 2003 11:12:33 -0500
From: "vinton g. cerf" <[email-masked]>
To: "Ian F. Akyildiz" <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Re: Our work on Interplanetary Internet
Sender: [email-masked]

Ian,

your interest in this work will be appreciated by the
others who are engaged. I have copied them on this
message and will also forward the TCP Planet paper.

Vint

At 10:30 AM 3/1/2003 -0500, Ian F. Akyildiz wrote:
>Hi Vint,
>
>I have 5 people working on various aspects
>of Deep Space research.
>
>I had sent you the TCP Planet paper in December.
>Your feedback will greatly be appreciated.
>
>Also I realized that you are working
>closely with JPL people.
>Any opportunity for us to
>collaborate with you and others at JPL  would be
>excellent.
>Please let me know how we can get involved.
>
>I look forward to hearing from you.
>
>Best Regards
>
>Ian

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