Subject: [dtn-interest] Wizzy Digital Courier
From: Andy Rabagliati <[email-masked]>
To: [email-masked]
Date: Sun, 29 Feb 2004 12:12:43 +0200
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Folks,

  Here after your Slashdot publicity :-)

  We have an Internet-content delivery system that works in a
  high-latency environment, to deliver mail and web content to South
  African schools.

  	http://wizzy.org.za/

  The problem it is designed to overcome is the high cost of local
  telephone calls in a monopoly wireline provider regulatory
  environment.

  We use cheap-rate overnight phone calls and a UUCP delivery system in
  conjunction with a local mailserver and wwwoffle web cache.

  UUCP can also be used via a USB memory stick, similar to the DataMule
  paper referenced on your website. Carrying the memory stick (the Courier)
  is identical to one UUCP hop.

  The website gives more information.

Cheers,    Andy!

Date: Mon, 23 Feb 2004 12:24:28 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: Fwd: Re: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Sender: [email-masked]

At 12:55 PM 2/21/2004 -0800, Durga Prasad Pandey wrote:

>--- Scott Burleigh <[email-masked]> wrote:
> > Reposting:
> > >The congestee, however, does have some chance of making useful
> > predictions
> > >about its own level of congestion, and particularly in a delay-tolerant
> >
> > >network I think this kind of prediction is vital.  It is not trivial,
> > >though; this is where the machine-learning-based or RED-like
> > computation
> > >we've been talking about comes in.  I would say that the congestee
> > needs
> > >to compute a measure of its own congestion distress or peril -- a
> > >prediction of its own congestion future, for which I think "data
> > >abandonment rate" is the right kind of number -- as a function of the
> > >other three parameters you referred to earlier, perhaps augmented by
> > some
> > >historical trending or whatever.  What I have no idea about is the
> > nature
> > >of that function, but I figure you're on the right track to work that
> > out.
>
>
>Scott,
>
>I feel that the relationship (or function) that we are looking for may not
>be something well defined as in an equation, but rather some sort of "rule
>of thumb" which can only be defined by simulations. My knowledge of the
>mathematical modelling of such systems is very primitive though; I suppose
>if we can mathematically model such a system, then we can have a well
>defined function, though my intuition suggests otherwise.
>
>If characterizing it mathematically actually turns out to be very
>difficult, then a simulation would be the best(and only?) approach to find
>out how the prediction mechanism works with different values/combinations
>of the parameters.

Sure, Durga, that seems entirely plausible.  In using the term "function" I 
meant (but may have failed) to suggest some sort of computational device 
that consumes these elements of information and -- by some magic, TBD -- 
deterministically emits a numerical result that indicates the congestee's 
level of congestion distress.  The requisite magic may very well be a model 
that operates by simulation rather than simple calculation, but I've got no 
clue.  I'm hoping you're on the right track with a machine-learning-based 
approach.

Scott 

Date: Mon, 23 Feb 2004 11:25:50 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Resilient Overlay Networks
Sender: [email-masked]

At 12:43 PM 2/21/2004 -0500, [email-masked] wrote:
>The 'Resilient Overlay Networks' project at MIT Lab for Computer Science
>looks relevant to Delay Tolerant Networking. I suspect we share some common
>concerns:
>
>http://nms.lcs.mit.edu/ron/

I agree, this really does seem relevant, especially with regard to 
routing.  There may be some routing protocols and algorithms here that DTN 
shouldn't try to reinvent.

>Overview
>"Because, sometimes, the Internet doesn't quite work..."
>
>The MIT RON (Resilient Overlay Networks) project is a DARPA-funded effort
>motivated by the desire to improve the robustness and availability of
>Internet paths between hosts by an order of magnitude over today's
>wide-area Internet routing infrastructure.  The key design goal in RON is
>to develop techniques to allow end-hosts and applications to cooperatively
>gain improved reliability and performance from the Internet. At a glance,
>RON nodes examine the condition of the Internet between themselves and the
>other nodes, and, based upon how the network looks, decide if they should
>let packets flow directly to other nodes, or if they should send them
>indirectly via other RON nodes.  For instance, the group of cooperating
>systems below can mutually provide a more available and better-performing
>routing service than what vanilla Internet routing can provide.
>
>RON is an architecture that allows a small group of distributed Internet
>applications to detect and recover from path outages and periods of
>degraded performance within several seconds, improving over today's
>wide-area routing protocols that take at least several minutes to recover.
>A RON is an application-layer overlay on top of the existing Internet
>routing substrate. The RON nodes monitor the functioning and quality of the
>Internet paths among themselves, and use this information to decide whether
>to route packets directly over the Internet or by way of other RON nodes,
>optimizing application-specific routing metrics.

Date: Mon, 23 Feb 2004 08:51:48 -0800
To: (Recipient list suppressed)
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] [FYI] The trouble with Rover is revealed
Sender: [email-masked]

http://www.eetimes.com/sys/news/OEG20040220S0046

The trouble with Rover is revealed

By Ron Wilson
EE Times
February 20, 2004 (6:32 p.m. ET) 	

SAN MATEO, Calif.  When the Mars rover Spirit went dark on Jan.21 a Jet 
Propulsion Laboratory team undertook to reprogram the craft's computer only 
to find themselves introducing an unpredictable sequences of events.

The trouble with the Mars rover Spirit started much earlier in the mission 
than the day the craft stopped communicating with ground controllers.

"It was recognized just after [the June 2003] launch that there were some 
serious shortcomings in the code that had been put into the launch load of 
software," said JPL data management engineer Roger Klemm. "The code was 
reworked, and a complete new memory image was uploaded to the spacecraft 
and installed on the rover shortly after launch."

That appeared to fix the problems that had been identified with the initial 
load. But what no one at JPL could have anticipated was that the new load 
also made possible a totally implausible sequence of events that would, 
many months later, silence Spirit.

The Spirit rover has a radiation-hardened R6000 CPU from Lockheed-Martin 
Federal Systems at the heart of the system. The processor accesses 120 
Mbytes of RAM and 256 Mbytes of flash. Mounted in a 6U VME chassis, the 
processor board also has access to custom cards that interface to systems 
on the rover.

The operating system is Wind River Systems' Vx-Works version 5.3.1, used 
with its flash file system extension. In operation, the real-time OS and 
all other executable code are RAM-resident.

The flash memory stores executable images that are loaded into RAM at 
system boot. Separately, about 230 Mbytes are used to implement a flash 
file system that stores "data products," or data files that are created by 
the rover's subsystems and held for transmission to Earth.

Among the data products are the images created by the rover's cameras.

"Part of my responsibility in the data management team is to keep track of 
the data files that are created, transmitted and deleted on the rover 
during the mission," Klemm explained. "We recognized early in the planning 
process that the flash file system had a limited capacity for files. It is 
not just a limitation in the flash itself but also in the directory structure."

Klemm explained that as data is collected by Spirit, files are created and 
stored in the flash file system until a communications window opens an 
opportunity to transmit the data either directly to Earth or to one of the 
two orbiters circling the Red Planet. Then the files are transmitted. They 
are still held in the flash system until retrieved and error-corrected on 
Earth. If data is missing, requests are sent for retransmission. If the 
data is intact, a command is sent to delete the received files.

"But there were also directories of files already placed into the file 
system in the launch load," Klemm said. "When we uploaded a new image to 
the rover, we recognized that those files would have to be deleted, because 
they were being replaced by a new set using different directories."

Accordingly, on Martian day 15 (or sol 15) of rover operation, a utility 
was uploaded to the rover to find and delete the old directories.

But the transmission that uploaded the utility was a partial failure: Only 
one of the utility program's two parts was received successfully. The 
second part was not received, and so in accordance with the communications 
protocol it was scheduled for retransmission on sol 19.

Thus was the fuse lit on a software hand grenade.

The data management team's calculations had not made any provision for 
leftover directories from a previous load still sitting in the flash file 
system.

As Murphy would have it, earlier, sol 19 Spirit attempted to allocate more 
files than the RAM-based directory structure could accommodate. That caused 
an exception, which caused the task that had attempted the allocation to be 
suspended. That in turn led to a reboot, which attempted to mount the flash 
file system. But the utility software was unable to allocate enough memory 
for the directory structure in RAM, causing it to terminate, and so on.

Spirit fell silent, alone on the emptiness of Mars, trying and trying to 
reboot. And its human handlers at JPL seemed at a loss to help, unable to 
diagnose a system they could not see.

Luckily, early in the process of proposing failure scenarios, someone 
remembered the earlier failure to upload the second piece of the utility. 
The scenario was modeled, and it was discovered that a VxWorks flag that 
causes a task to be suspended on a memory allocation failure was set in the 
existing image.

"The irony of it was that the operating system was doing exactly what we'd 
told it to do," Klemm lamented.Working on the theory that the rover was in 
fact listening and rebooting, the team commanded Spirit to reboot without 
mounting the flash file system.

The team then uploaded a script of low-level file manipulation commands 
that worked directly on the flash memory without mounting the volume or 
building the directory table in RAM. Using the low- level commands, about a 
thousand files and their directories - the leftovers from the initial 
launch load - were removed.

"At that point we mounted the flash file system and ran a checkdisk 
utility," Klemm said. To everyone's enormous relief, the mount was successful.

"As we had anticipated, there was some corruption from the event, so that 
was corrected," Klemm added. "In the process of going through the contents 
of the file system, we discovered a system log in which the problem was 
documented, step by step, right up to the allocation request that failed."

Klemm said that with the leftover directories and their files removed, the 
system is now functioning well. But just in case, the team is working on an 
exception-handler routine that will more gracefully recover from an 
allocation failure.

As a postscript, Klemm noted that the other day he heard a car commercial 
on the radio that made reference to the Mars rover, comparing, for example, 
the car's speed over the ground to Spirit's. In the process of touting the 
car's extended-warranty program, the ad noted that the Mars rover came with 
"interplanetary roadside assistance." "That phrase just stuck in my mind," 
Klemm said. "love it." 

Date: Sat, 21 Feb 2004 12:55:02 -0800 (PST)
From: Durga Prasad Pandey <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Fwd: Re: [dtn-interest] Recent thinking on Congestion/flow  control in IPN/DTN
To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

--- Scott Burleigh <[email-masked]> wrote:
> Reposting:
> >The congestee, however, does have some chance of making useful
> predictions 
> >about its own level of congestion, and particularly in a delay-tolerant
> 
> >network I think this kind of prediction is vital.  It is not trivial, 
> >though; this is where the machine-learning-based or RED-like
> computation 
> >we've been talking about comes in.  I would say that the congestee
> needs 
> >to compute a measure of its own congestion distress or peril -- a 
> >prediction of its own congestion future, for which I think "data 
> >abandonment rate" is the right kind of number -- as a function of the 
> >other three parameters you referred to earlier, perhaps augmented by
> some 
> >historical trending or whatever.  What I have no idea about is the
> nature 
> >of that function, but I figure you're on the right track to work that
> out.

Scott,

I feel that the relationship (or function) that we are looking for may not
be something well defined as in an equation, but rather some sort of "rule
of thumb" which can only be defined by simulations. My knowledge of the
mathematical modelling of such systems is very primitive though; I suppose
if we can mathematically model such a system, then we can have a well
defined function, though my intuition suggests otherwise.

If characterizing it mathematically actually turns out to be very
difficult, then a simulation would be the best(and only?) approach to find
out how the prediction mechanism works with different values/combinations
of the parameters. 

Durga

=====
Tata Srijan - Passion for Creation 
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Date: Sat, 21 Feb 2004 12:43:38 -0500
Subject: [dtn-interest] Resilient Overlay Networks
Sender: [email-masked]

The 'Resilient Overlay Networks' project at MIT Lab for Computer Science
looks relevant to Delay Tolerant Networking. I suspect we share some common
concerns:

http://nms.lcs.mit.edu/ron/ 

Overview
"Because, sometimes, the Internet doesn't quite work..."

The MIT RON (Resilient Overlay Networks) project is a DARPA-funded effort
motivated by the desire to improve the robustness and availability of
Internet paths between hosts by an order of magnitude over today's
wide-area Internet routing infrastructure.  The key design goal in RON is
to develop techniques to allow end-hosts and applications to cooperatively
gain improved reliability and performance from the Internet. At a glance,
RON nodes examine the condition of the Internet between themselves and the
other nodes, and, based upon how the network looks, decide if they should
let packets flow directly to other nodes, or if they should send them
indirectly via other RON nodes.  For instance, the group of cooperating
systems below can mutually provide a more available and better-performing
routing service than what vanilla Internet routing can provide.

RON is an architecture that allows a small group of distributed Internet
applications to detect and recover from path outages and periods of
degraded performance within several seconds, improving over today's
wide-area routing protocols that take at least several minutes to recover.
A RON is an application-layer overlay on top of the existing Internet
routing substrate. The RON nodes monitor the functioning and quality of the
Internet paths among themselves, and use this information to decide whether
to route packets directly over the Internet or by way of other RON nodes,
optimizing application-specific routing metrics. 

-Durga

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

From: "Durga Prasad Pandey" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Re: custody transfer
Date: Thu, 19 Feb 2004 20:44:16 +0530
Sender: [email-masked]

>From: Scott Burleigh <[email-masked]>
>>Prof Kleinrock had suggested that bundles could
>>carry info about congestion and buffer status and network parameters
>>regarding all nodes it has passed through on it way to its destination.
>>There will probably be some overhead, but a knowledge of these parameters
>>for at least some of the nodes might be of good help.
>
>I think this is certainly worth exploring.  My inclination is to use 
>separate and relatively low-volume routing protocol traffic to accomplish 
>this rather than load this information onto all ordinary bundles, but the 
>issues need to be discussed.

Something like BGP?

D.

www.Srijan-ism.org

_________________________________________________________________
Access Hotmail from your mobile now. 
http://server1.msn.co.in/sp03/mobilesms/ Click here.

Date: Wed, 18 Feb 2004 10:15:15 -0800 (PST)
From: Durga Prasad Pandey <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [dtn-interest] Re: custody transfer
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--- Scott Burleigh <[email-masked]> wrote:
> At 03:51 AM 2/18/2004 +0530, DP Pandey wrote:
> >Prof Kleinrock had suggested that bundles could
> >carry info about congestion and buffer status and network parameters
> >regarding all nodes it has passed through on it way to its destination.
> >There will probably be some overhead, but a knowledge of these
> parameters
> >for at least some of the nodes might be of good help.
> 
> I think this is certainly worth exploring.  My inclination is to use 
> separate and relatively low-volume routing protocol traffic to
> accomplish 
> this rather than load this information onto all ordinary bundles, but
> the 
> issues need to be discussed.

Scott, I'm a little apprehensive about using 'special' bundles to
accomplish this. Since we are going to use bundles of relatively large
sizes(undefined as of today), it might not be too bad an idea to make the
header a little longer -- though DTNs like sensor networks(that I assume
would carry smaller size bundles) might not be able to afford large
headers.

Having said that, I must admit that the routing protocol traffic(bundles?)
that you have suggested sound novel, and certainly deserve thoughtful
consideration -- they could possibly be a significant aid in congestion
avoidance/detection/control. Is there any precedent in routing that could
throw some light on this idea?

Durga

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Date: Wed, 18 Feb 2004 09:24:35 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Re: custody transfer
Sender: [email-masked]

At 03:51 AM 2/18/2004 +0530, DP Pandey wrote:
>Hi Scott,
>
>This is an excellent suggestion; dead ends(subjectively speaking..) are a
>very real possibility and though I am not a header kind of guy ;) , the
>flags look appropriate to me.
>
>This brings to mind another point; the issue of using 'local only'  versus
>'local + non-local' information in DTNs. From the discussion we had with
>Chris Ramming (that I had subsequently forwarded to dtn-interest), some
>non-local information like for instance, topology of the network, or an
>approximate knowledge of portions of the network which are down (for any
>reason) could certainly be incorporated in the 'structural flow control'
>mechanism that you had suggested.
>
>My point is: perhaps the availability of such information could also help us
>avoid events like sending bundles to dead ends, though it cannot entirely be
>avoided as there will be a finite delay between a node(s) going down, and
>the information propagating to other nodes(if the node is considered
>important enough).

As I understand it, DTN routing at a given bundle agent will have to entail 
at least five distinct activities:

1.      Continuously acquiring (by communication and/or by computation, 
including inference) information about current and upcoming "contacts" that 
will enable direct transmission to "neighboring" bundle agents.

2.      Continuously acquiring information about network topology, so that 
routing tables can be built.  The routing table entries for neighbors can 
be inferred from contact information, but entries for non-neighboring 
bundle agents -- that is, which neighbors to forward to in order to reach 
which non-neighbors -- need to come from elsewhere.

3.      For each bundle:

         a.      Computing the possible routes to the destination bundle 
agent.  (Which is fairly trivial, given good routing tables.)

         b.      Ranking the possible routes in order of preference, using 
algorithms yet to be defined.

         c.      Selecting the most preferred route -- or routes (by some 
algorithm TBD), in the event that we don't have perfect confidence that any 
single route will ultimately succeed -- and transmitting the bundle to the 
neighboring agent at the start of that route or those routes.

I think item (2) above is the non-local information you're talking about, 
and I certainly agree that it could help us avoid sending bundles to dead 
ends: good routing tables are a precondition to successful route 
computation.  But as you point out, we will still need to be able to deal 
with unexpected dead ends due to changes in topology that have not yet been 
locally acquired, because of potentially lengthy delays in the network.  As 
in everything else, we have to be delay-tolerant.

>Prof Kleinrock had suggested that bundles could
>carry info about congestion and buffer status and network parameters
>regarding all nodes it has passed through on it way to its destination.
>There will probably be some overhead, but a knowledge of these parameters
>for at least some of the nodes might be of good help.

I think this is certainly worth exploring.  My inclination is to use 
separate and relatively low-volume routing protocol traffic to accomplish 
this rather than load this information onto all ordinary bundles, but the 
issues need to be discussed.

Scott 

From: "DP Pandey" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 18 Feb 2004 03:51:32 +0530
Subject: [dtn-interest] Re: custody transfer
Sender: [email-masked]

Hi Scott,

This is an excellent suggestion; dead ends(subjectively speaking..) are a
very real possibility and though I am not a header kind of guy ;) , the
flags look appropriate to me.

This brings to mind another point; the issue of using 'local only'  versus
'local + non-local' information in DTNs. From the discussion we had with
Chris Ramming (that I had subsequently forwarded to dtn-interest), some
non-local information like for instance, topology of the network, or an
approximate knowledge of portions of the network which are down (for any
reason) could certainly be incorporated in the 'structural flow control'
mechanism that you had suggested.

My point is: perhaps the availability of such information could also help us
avoid events like sending bundles to dead ends, though it cannot entirely be
avoided as there will be a finite delay between a node(s) going down, and
the information propagating to other nodes(if the node is considered
important enough). Prof Kleinrock had suggested that bundles could
carry info about congestion and buffer status and network parameters
regarding all nodes it has passed through on it way to its destination.
There will probably be some overhead, but a knowledge of these parameters
for at least some of the nodes might be of good help.

Durga

----- Original Message -----
From: "Scott Burleigh" <[email-masked]>:
Lately I've been thinking about custody transfer in Bundling and have
persuaded myself that, if we're going to support it at all, we need to do a
little more.  I'm concerned about what happens when custody transfer fails.

Suppose a bundle agent receives a custodial bundle whose destination is a
node to which this agent has no route at all.  Currently, all that can
happen is that the agent discards the bundle and declines to send a custody
ack to the current custodian.  The current custodian's custodial timer
eventually expires, and all that the custodian can then do [being clueless
about the nature of the custodial failure] is retransmit the bundle to the
same agent, with the same result.  Finally, after N retransmissions, the
bundle's TTL runs out and the custodian discards the bundle and is able to
reuse the space it occupied -- but the source endpoint of the bundle, who
cared enough about it to ask for custodial transmission in the first place,
receives no notification that it has disappeared from the network.  We've
wasted a lot of bandwidth and a lot of byte-seconds of buffer space at the
custodian without effecting any data delivery and without even reporting on
what went wrong.

So I propose two changes to the protocol:

1.	Our current custody acknowledgement mechanism (the custodial ack status
report) can only be used to affirm acceptance of custody.  I suggest that
we establish a separate type of administrative record for these messages:
"custodial signals" that go to custodial bundle agent administrative
endpoints, as distinguished from "bundle status reports" that go to
"report-to" application endpoints.  On receiving a bundle for which custody
transfer is requested, the receiving bundle agent would *always* issue a
custodial signal record to the current custodian, whether or not it was
accepting custody.  The custodial signal record would include:
-	Two bundle disposition flags:
	-	"Node will forward as necessary", set to zero if the node issuing the
record is simply discarding the bundle.
	-	"Node accepts custody", which might be zero even if the "will-forward"
flag is 1: this would indicate that the receiving node will do best-effort
-- rather than custodial -- forwarding of the bundle.
-	Several non-mutually-exclusive informational flags commenting on the
disposition, including:
	-	"Redundant transmission", meaning the bundle had previously been
received; a hint to the custodian to use longer timeout intervals.
	-	"Depleted storage"
	-	"No known route to destination"
	-	"No timely contact with next node on route"

We would expect a custodial signal in most [not all] cases to arrive at a
bundle's current custodian before the bundle's custodial timeout expires --
because otherwise we've made the timeout interval too short, risking
degraded bandwidth utilization due to unnecessary retransmission.  In those
cases, a negative custodial signal would be a more timely and more
informative notice to the current custodian than the custodial timeout
would be.  This doesn't necessarily simplify procedures at the custodian,
but it might make them more effective.  For example, if the "no known
route" flag in the record is set, the custodial agent probably should
retransmit the bundle on a different route; if custody was refused but
best-effort forwarding was promised, the custodian should probably just
re-set its timer and wait to see what happens; etc.

2.	We currently have no way to tell the source of a custodially-transferred
bundle that we gave up on trying to deliver it.  I suggest that we add
another flag to the bundle status report for "Reporting node has discarded
the bundle", plus a time of deletion.  A report with this flag set would be
issued only when a bundle was discarded by its current custodian, which (I
think) can only happen when the bundle's TTL expires while the bundle is in
this node's custody.

Unfortunately we're already using all eight bits in the status flags byte
of the bundle status report record.  We could add a second flags byte, but
I'm wondering if maybe we could instead remove the three Time-of-____
flags, letting the bundle status flags imply the presence of the time
values, and reassign those bits: that is, maybe we carry time-of-receipt in
the record if and only if the "Reporting node correctly received bundle
flag" is turned on, and so on.

Scott

From: "Durga Prasad Pandey" <[email-masked]>
To: [email-masked]
Date: Mon, 16 Feb 2004 23:30:55 +0530
Subject: [dtn-interest] IPN Access technologies/protocols
Sender: [email-masked]

I have recently been thinking of the access technologies that could be used 
for the InterPlanetary Internet.

I am aware of at least one study, that was done at Univ of Maryland College 
Park on adapting HTTP for satellite connections. James Sternbenz's team at 
BBN has also done some work on hypertext IPN access. He has proposed using 
links of different colors for different latencies involved in fetching the 
appropriate file.

It appears to me that clicking on a link to a remote IPN location 
effectively means requesting a file transfer by an FTP  like program(CFDP?) 
. How does HTTP cope with the deep space communications constraints, and 
does it role change(vis-a-vis eg., CFDP) in such an environment?

I would welcome a discussion on this.

Durga

Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

_________________________________________________________________
Contact brides & grooms FREE! http://www.shaadi.com/ptnr.php?ptnr=hmltag 
Only on www.shaadi.com. Register now!

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 16 Feb 2004 05:17:16 -0500
Subject: [dtn-interest] E-mail from Mars: Plans for an interplanetary Internet are taking shape
Sender: [email-masked]

This article is probably not archived on ipnsig.org; makes for a good read.
http://www.eurescom.de/message/messageMar2002/mars.asp

Durga

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

To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Fwd: Re: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Sender: [email-masked]
Date: Fri, 13 Feb 2004 07:32:14 -0800

Reposting:

>Date: Wed, 11 Feb 2004 14:08:33 -0800
>To: [email-masked]
>From: Scott Burleigh <[email-masked]>
>Subject: Re: [dtn-interest] Recent thinking on Congestion/flow control in 
>IPN/DTN
>
>At 05:05 PM 2/10/2004 -0500, Hans Kruse wrote:
>>I think I have temporarily caught up with this thread, so here are some 
>>thoughts on the various topic that have come up:
>>
>>1.) Durga's work on congestion predictions:
>>I look at this effort as an evolution of RED.  In other words, rather 
>>than waiting for buffer exhaustion, we try to predict congestion using 
>>more sophisticated methods.  Given that the cost of congestion in DTNs is 
>>much higher than in the Internet, that is a required step and I applaud 
>>the work that is underway towards that.
>>
>>2.) Durga/Fred on policies
>>I think both of you are right here.  I can certainly try and predict 
>>congestion based on a well-chosen set of parameters without policy input. 
>>However, once I need to react to a predicted congestion event, I need a 
>>set of rules, aka policies, to decide what data to drop, which bundle to 
>>refuse, and what information to send to which up/downstream node.  These 
>>policies could be tied to class of service, service level agreements, 
>>etc. They could change over time...
>
>Exactly.
>
>>3.) Scott on congestion control requirements
>>I don't think you are missing anything here in that a predicted 
>>congestion event can only be handled by dropping excess data, and only 
>>resolved (if it persists) by back-pressure.  Your analysis seems correct to me.
>>
>>----
>>
>>My 2 cents worth:
>>
>>I worry that even a well-implemented control loop as we are discussing 
>>here will neither be stable nor inherently efficient in all DTN 
>>environments. That is not to say that it is not needed, I just think that 
>>it is insufficient by itself.
>>
>>I am starting to think that we need, in addition to congestion prediction 
>>and congestion control, a concept of congestion avoidance.  I have NOT 
>>had the time to sit down and really work this out, but I am tempted to 
>>borrow from Frame Relay (and to a lesser extent ATM) in this regard.
>>
>>In general, in the DTN scenarios we are discussing such as tactical 
>>sensor nets and interplanetary probes, data comes with different values 
>>attached. The data that has to be transmitted reliably over the largest 
>>delay is the most valuable, since its loss in congestion "costs" us the 
>>most in wasted resources and possibly lost opportunities when controlling 
>>remote sensor probes.  We also know that the potentially huge control 
>>loop lengths will force us into deploying very large and expensive 
>>buffers (expensive more so in terms of weight and power consumption than 
>>monetary cost).  So preventing congestion by massive over-provisioning is 
>>probably not realistic.
>>
>>There is some good news.  The nodes that will present us with the most 
>>expensive data will also be somewhat predictable.  I suspect that it will 
>>be many decades before a Mars probe joins the Interplanetary Network 
>>ad-hoc, without everyone having had advance notice months and years in 
>>advance.  The most unpredictable nodes such as tactical sensor nets also 
>>have much shorter control loops.
>>
>>Can we therefore think about introducing the concept of a Committed 
>>Information Rate (CIR; borrowed from Frame Relay)?  What I envision is 
>>that if node A is going to forward bundles to node B, there exists an 
>>agreed-upon CIR that A can count on being able to send to node B without 
>>bundles being rejected.  The CIR would come from one of (a) local policy, 
>>(b) negotiation between A and B, or (c) prior arrangement.
>>
>>For example, an earth-orbit data relay would be programmed to expect 
>>transmissions from a Mars probe starting on some date, and be told to 
>>reserve a certain CIR for that probe.  The probe counts on that CIR being 
>>available.
>>
>>A drone relay over a battle field might have a local policy to grant a 
>>pre-determined CIR to sensors looking for nerve gas, and that sensor 
>>would be programmed to expect that CIR.
>>
>>A truly ad-hoc connection would start with a 0 CIR; node A (say a 
>>wildlife monitoring station) would include in its first bundle to B some 
>>information about its intent, such as "I am trying to send x bundles 
>>totaling y Mbytes over the next z minutes".  B would then consult local 
>>policy and congestion predictions, and in the first acknowledgement send 
>>a CIR back to A.
>>
>>In all cases the sending node can assume that a certain amount of data 
>>will be accepted.  Presumably the node would fit critical data under that 
>>rate ceiling, and send additional data with a "Discard Eligible" bit set.
>>
>>Note that we still need to do all the congestion control stuff we have 
>>been discussing.  However, I think there is a limit on how good a control 
>>loop we can create; when the loop does not work well we will end up 
>>discarding data.  I would like to protect critical data from that process.
>
>This is really interesting, Hans.  I think what you're talking about here 
>is sort of a generalization and formalization of the "structural flow 
>control" idea I've been brooding over for a while, which is lifted from 
>current deep space operations: we don't worry about congestion in 
>interplanetary links because we have already decided who's going to be 
>transmitting to whom when and at what rate, and the only way to increase 
>data transmission rate is to renegotiate agreements with the Deep Space 
>Network.
>
>I personally am not yet fully sold on the concept of bandwidth reservation 
>in other settings, but maybe I just need to work a little harder on liking it.
>
>Scott

To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Fwd: Re: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
Sender: [email-masked]
Date: Fri, 13 Feb 2004 07:31:37 -0800

Reposting:

>Date: Wed, 11 Feb 2004 13:55:46 -0800
>To: [email-masked]
>From: Scott Burleigh <[email-masked]>
>Subject: Re: [dtn-interest] Recent thinking on Congestion/flow control  in 
>IPN/DTN
>Cc: [email-masked], "[email-masked]" <[email-masked]>, [email-masked]
>
>At 11:41 PM 2/9/2004 -0600, Matt Bradbury wrote:
>>>Specifically, I think failure of custody transfer -- either implicit 
>>>(custody timer expires) or explicit (receiver sends a custody transfer 
>>>ack refusing custody, as I proposed in an email here a couple of weeks 
>>>ago) -- is a darn good signal of possible congestion.  On detection of 
>>>such a signal, I think the sender should locally and autonomously decide 
>>>how severe the congestion is (the problem Durga has been working on) and 
>>>what to do about it (a separate and equally thorny problem).
>>
>>What percentage of traffic do we think will be requesting custody 
>>transfer versus those just wanting to get sent and hope they survive.  I 
>>can see a model where the cost of custody transfer is high enough that 
>>network providers would charge higher rates for custody transfers, 
>>essentially making them the exception and not the norm.  We'd still have 
>>plenty of congestion, but how much would go unnoticed since in this 
>>model, the routers would be programmed to forward the custody requesting 
>>bundles since they paid more in the first place.
>
>Who knows how this will work out in practice, but it seems to me that 
>we're looking at two different kinds of service differentials that are 
>orthogonal and could be charged-for separately.
>
>One is custody transfer (or not), a guarantee of reliability that may be 
>worth paying for regardless of the priority of the bundle.  For example, 
>the transcript of a test session may be very important to retain in the 
>records of an experiment, but the sender doesn't really care when it 
>arrives so long as it does arrive eventually.
>
>The other is priority, an accelerator of transmission that may be worth 
>paying for regardless of whether or not custody transfer is in 
>effect.  For example, a highly time-critical bundle might be sent with 
>high priority but no custody transfer because there's no point in 
>retransmitting it if it gets dropped -- it will arrive too late to do any good.
>
>In this model, refusing to take custody of a low-priority bundle doesn't 
>hurt the user much, since eventually the bundle will be retransmitted and 
>proceed on to its destination.  The sender is still getting the value that 
>was paid for, and Bundling gets a helpful hint of downstream congestion.
>
>Scott

To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Fwd: Re: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Sender: [email-masked]
Date: Fri, 13 Feb 2004 07:30:43 -0800

Reposting:

>Date: Wed, 11 Feb 2004 13:41:59 -0800
>To: [email-masked], [email-masked]
>From: Scott Burleigh <[email-masked]>
>Subject: Re: [dtn-interest] Recent thinking on Congestion/flow control in 
>IPN/DTN
>Cc: "[email-masked]" <[email-masked]>, [email-masked]
>
>At 08:22 PM 2/9/2004 -0800, Durga Prasad Pandey wrote:
>
>>--- Scott Burleigh <[email-masked]> wrote:
>> >....... Here I disagree.  I think using source-quench-like signals to
>>effect
>> > explicit congestion control is not a good idea; I like the TCP/IP model
>> > better (okay, my understanding of it may be shaky; bear with me), that
>> > acknowledgement failure is interpreted as loss of data due to congestion
>> >
>> > and the sender responds by reducing the rate of transmission to that
>> > receiver.
>> > Specifically, I think failure of custody transfer -- either implicit
>> > (custody timer expires) or explicit (receiver sends a custody transfer
>> > ack
>> > refusing custody, as I proposed in an email here a couple of weeks ago)
>> > --
>> > is a darn good signal of possible congestion.
>>
>>Scott, I am not sure I am completely convinced of 'custody refusals' being
>>capable enough to characterize congestion in a DTN. At this point, I am
>>also not sure if custody transfer is intended for bundles of all COS, or
>>only for the top priority ones. What do you think about sending the values
>>of the 4 parameters we have been discussing(which includes data
>>abandonment rate) and letting the sender decide at what rate it should
>>send. It would probably make things more complex, but the benefit in
>>congestion detection might be worth the complexity.
>>
>>  On detection of such a
>> > signal, I think the sender should locally and autonomously decide how
>> > severe the congestion is (the problem Durga has been working on) and
>> > what
>> > to do about it (a separate and equally thorny problem).
>>
>>I think a simple 'custody refusal' might not give me enough information to
>>decide the extent of congestion. Some sort of numeric parameter(s)
>>feedback -- essentially indicators of congestion which would be
>>interpreted by the sender --  (I am open to 'radical' ideas on this :) )
>>will, I suppose,  make things a lot more easier for the sender.
>>
>> > information that it might in some circumstances never get, and it
>> > minimizes
>> > the need for Bundling to predict the future anywhere; it relies on
>> > emergent
>> > behavior, which (provided we've got as much margin as possible) is
>> > something I trust more than second-guessing the state of nodes that
>> > might
>> > be twenty light-minutes away.
>>
>>This is a basic question; could you clarify how 'prediction' is different
>>from 'emergent behaviour'?
>
>A good question.  I think I'm actually arguing for a combination of the 
>two, sort of.
>
>It seems to me that congestion control comprises very different kinds of 
>activities at the two different kinds of entities involved in the 
>problem.  On the one hand we have the router that is experiencing -- or, 
>importantly, anticipates experiencing -- congestion, which I will call the 
>"congestee".  On the other hand we have the congestee's routing neighbors, 
>from which arrive the bundles that result in the congestion; call them the 
>"congestors".
>
>I think the congestee is in a far, far better position to detect and 
>anticipate the congestion it is (or will be) experiencing than any 
>congestor ever is.  It alone knows exactly what its buffer occupancy and 
>current inbound and outbound data rates are at the moment of 
>congestion-level computation; it alone might plausibly retain aggregate 
>data rate fluctuation history that might enable it to guess at future 
>rates.  None of its congestors have got good enough information to predict 
>the congestee's current or future level of congestion with any confidence; 
>this is the kind of prediction that I think we should set aside.
>
>The congestee, however, does have some chance of making useful predictions 
>about its own level of congestion, and particularly in a delay-tolerant 
>network I think this kind of prediction is vital.  It is not trivial, 
>though; this is where the machine-learning-based or RED-like computation 
>we've been talking about comes in.  I would say that the congestee needs 
>to compute a measure of its own congestion distress or peril -- a 
>prediction of its own congestion future, for which I think "data 
>abandonment rate" is the right kind of number -- as a function of the 
>other three parameters you referred to earlier, perhaps augmented by some 
>historical trending or whatever.  What I have no idea about is the nature 
>of that function, but I figure you're on the right track to work that out.
>
>Having computed a measure of its own congestion distress, the congestee 
>then needs to take some action to relieve that distress.  I see that 
>mitigating action as a separate computation, a function of (a) the level 
>of distress and (b) the congestion declaration policy established for the 
>congestee.  I've been thinking in terms of a very simple, unilateral 
>policy, something like:
>
>         Compute priority level N as a function of the level of distress.
>         Now discard all incoming bundles of priority N or below, whether 
> they are custodial or not.  (I.e., the more congested I am, the higher a 
> bundle's priority will have to be for me to accept it.)
>
>But I can see an argument for a more proactive policy, which might 
>minimize actual data abandonment at the cost of some additional 
>communication: for example, the congestee might transmit time-tagged 
>messages indicating its own level of congestion distress to all of its 
>congestors.
>
>The congestor, as I see it, need not and should not try to compute the 
>level of congestion distress at the congestee; all that is indicated is 
>that it take some action in response to the mitigating action taken by the 
>congestee.  That action will be a function of (a) the nature of the action 
>taken by the congestee and (b) the congestion relief policy established at 
>the congestor.  For example, if the congestee responded to distress by 
>simply discarding bundles, the congestor would eventually detect custody 
>refusals and might then start retarding applications' bundle transmission 
>requests; as congestion refusal increased, the congestor's own buffer 
>occupancy would start to increase and the congestor would itself become a 
>congestee, propagating congestion distress toward the edges of the network 
>(which is what I meant by "emergent behavior").
>
>Alternatively, if the congestee transmitted time-tagged congestion 
>distress messages, then the congestor might be able to start retarding new 
>bundle transmission even before custody refusals began to show up.  I'm 
>less sanguine about our ability to do this kind of thing effectively, though.
>
>Scott

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked], [email-masked]
Subject: [dtn-interest] Wi-Fi Enters the Space Race
Sender: [email-masked]
Date: Fri, 13 Feb 2004 05:28:23 -0500

FYI. 

http://www.wired.com/news/wireless/0,1382,62183,00.html

Durga

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

From: Durga Prasad Pandey <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
To: Matt Bradbury <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Date: Thu, 12 Feb 2004 20:02:59 -0800 (PST)

--- Matt Bradbury <[email-masked]> wrote:

> I have no intention of  having any kind of global knowledge when dealing
> 
> with congestion.  But we should be able to chat with our neighbors and 
> find out their condition.

Yes, as far as possible. Even a 'neighbour', in an IPN, could be very far
-- so we'd need to keep that in mind.

> If we can agree on simple metrics to implement at the bundle layer, then
> 
> those can be implemented by everyone and we can leave congestion control
> 
> to the PhD candidates.

Yes, I agree completely. Once we have simple metrics for DTNs in general,
we can go ahead and implement them for specific environments and cases.

> 
> >Coming to your point now, you have suggested a sound set of metrics.
> But
> >the question is, with the kind of delay that we expect in a DTN, can we
> >afford to think that we'll have all this information available at  a
> node?
> >Perhaps you might like to look up at the 3 metrics I mentioned in my
> first
> >email, and give your opinion on their (un)suitability. 
> >  
> >
> We'll never have enough information for perfect congestion control.  You
> 
> mention this in your paper.  I see nothing wrong with you're paper on 
> the surface, but we won't know until it gets into a running network with
> 
> real-life problems.  Let's just make sure when we get there we're not 
> tied too tightly to any one algorithm so that when we do have to tweak 
> the congestion control  it won't kill us with incompatibilities.

Yes. The question now is -- how do we model such a network, keeping in
mind that we don't have access to a real-life network for quite some
time(years?), and all we have to work on, is imagination? :-)

Durga

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] Press Release: International Interplanetary Networking Succeeds
Sender: [email-masked]
Date: Thu, 12 Feb 2004 13:56:43 -0800

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

At 11:47 AM 2/12/2004, Bob Braden wrote:
>And technically, the protocols that allowed this interoperation were the 
>CCCDS international standards?

Bob: yes, 100% CCSDS. A simplified technical configuration of the 
internationally-standardized space Link layer protocols is attached. 
Basically, spacecraft applications create CCSDS Packets that then get 
switched into either Proximity or Long-Haul frames. In the relay orbiters, 
the Proximity data are usually handled as bitstreams, which get 
re-encapsulated into the Long-Haul frames for transfer to Earth. At the DSN 
station, received Long-Haul frames are handled by a "Space Link Extension" 
application, which moves them over TCP/IP into the control center, where 
they are unpacked.

It's all pretty basic at present but we are moving along an evolutionary 
path towards the IPN. The next step (2005+) is to introduce the CCSDS File 
Delivery Protocol (CFDP), which has underlying custodial, store-and-forward 
services built-in to it that have a strong resemblance to elements of 
Bundling. Eventually, we want to move CFDP up to be a stable file handling 
application, and slide-in Bundling to do all of the disconnected 
store-and-forward routing. So the strategy is little steps, with each 
mission contributing new increments of re-usable capability, until we have 
accreted a lot of internationally-interoperable networking infrastructure.

///adrian

--=====================_24904343==_
Content-Type: application/zip; name="Mars-Comm-12Feb03.zip";
 x-mac-type="705A4950"; x-mac-creator="705A4950"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Mars-Comm-12Feb03.zip"

--=====================_24904343==_--

To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] Press Release: International Interplanetary Networking Succeeds
Sender: [email-masked]
Date: Thu, 12 Feb 2004 12:21:07 -0800

--=====================_19211484==_.REL
Content-Type: multipart/alternative;
	boundary="=====================_19211484==_.ALT"

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

At 11:47 AM 2/12/2004, Bob Braden wrote:
>And technically, the protocols that allowed this interoperation were the 
>CCCDS international standards?

Bob: yes, 100% CCSDS. A simplified technical configuration of the 
internationally-standardized space Link layer protocols is shown below. 
Basically, spacecraft applications create CCSDS Packets that then get 
switched into either Proximity or Long-Haul frames. In the relay orbiters, 
the Proximity data are usually handled as bitstreams, which get 
re-encapsulated into the Long-Haul frames for transfer to Earth. At the DSN 
station, received Long-Haul frames are handled by a "Space Link Extension" 
application, which moves them over TCP/IP into the control center, where 
they are unpacked.

It's all pretty basic at present but we are moving along an evolutionary 
path towards the IPN. The next step (2005+) is to introduce the CCSDS File 
Delivery Protocol (CFDP), which has underlying custodial, store-and-forward 
services built-in to it that have a strong resemblance to elements of 
DTN-Bundling. Eventually, we want to move CFDP up to be a stable file 
handling application, and slide-in Bundling to do all of the disconnected 
store-and-forward routing. So the strategy is little steps, with each 
mission contributing new increments of re-usable capability, until we have 
accreted a lot of internationally-interoperable networking infrastructure.

///adrian

12456be.jpg

Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group (CESG)
NASA Jet Propulsion Laboratory,
Interplanetary Network Directorate
M/S 303-400, 4800 Oak Grove Drive
Pasadena, California 91109-8099, USA
+1.818.354.3063 OFFICE
+1.818.653.9553 MOBILE
+1 818.393.6228 FAX
http://www.ccsds.org

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

<html>
At 11:47 AM 2/12/2004, Bob Braden wrote:<br>
<blockquote type=cite class=cite cite>And technically, the protocols that
allowed this interoperation were the CCCDS international
standards?</blockquote><br>
Bob: yes, 100% CCSDS. A simplified technical configuration of the
internationally-standardized space Link layer protocols is shown below.
Basically, spacecraft applications create CCSDS Packets that then get
switched into either Proximity or Long-Haul frames. In the relay
orbiters, the Proximity data are usually handled as bitstreams, which get
re-encapsulated into the Long-Haul frames for transfer to Earth. At the
DSN station, received Long-Haul frames are handled by a &quot;Space Link
Extension&quot; application, which moves them over TCP/IP into the
control center, where they are unpacked. <br><br>
It's all pretty basic at present but we are moving along an evolutionary
path towards the IPN. The next step (2005+) is to introduce the CCSDS
File Delivery Protocol (CFDP), which has underlying custodial,
store-and-forward services built-in to it that have a strong resemblance
to elements of DTN-Bundling. Eventually, we want to move CFDP up to be a
stable file handling application, and slide-in Bundling to do all of the
disconnected store-and-forward routing. So the strategy is little steps,
with each mission contributing new increments of re-usable capability,
until we have accreted a lot of internationally-interoperable networking
infrastructure.<br><br>
///adrian<br><br>
<img src="cid:.0" width=720 height=540 alt="12456be.jpg"><br>
<x-sigsep><p></x-sigsep>
Adrian J. Hooke<br>
Chairman, CCSDS Engineering Steering Group (CESG)<br>
NASA Jet Propulsion Laboratory, <br>
Interplanetary Network Directorate<br>
M/S 303-400, 4800 Oak Grove Drive<br>
Pasadena, California 91109-8099, USA<br>
+1.818.354.3063 OFFICE<br>
+1.818.653.9553 MOBILE<br>
+1 818.393.6228 FAX<br>
<a href="http://www.ccsds.org/" eudora="autourl">http://www.ccsds.org<br>
</a></html>

--=====================_19211484==_.ALT--

--=====================_19211484==_.REL
Content-Type: image/jpeg; name="12456be.jpg";
 x-mac-type="4A504547"; x-mac-creator="4A565752"
Content-ID: <.0>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="12456be.jpg"

--=====================_19211484==_.REL--

Date: Thu, 12 Feb 2004 12:09:43 -0800
To: Bob Braden <[email-masked]>, [email-masked]
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] Press Release: International Interplanetary  Networking Succeeds
Sender: [email-masked]

Good question Bob - Yes indeed, all comm protocols are CCSDS 
standards - CCSDS TM/TC on the long haul links, Proximity Link on the 
orbiter to Mars surface links. These standards were worked out with 
international participation over the years for exactly this purpose.

At 11:47 AM -0800 2/12/04, Bob Braden wrote:
>And technically, the protocols that allowed this interoperation were
>the CCCDS international standards?
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------

Date: Thu, 12 Feb 2004 11:59:47 -0800
To: Bob Braden <[email-masked]>, [email-masked], [email-masked]
From: Peter Shames <[email-masked]>
Subject: Re: [dtn-interest] Press Release: International Interplanetary  Networking Succeeds
Sender: [email-masked]

At 11:47 AM -0800 2/12/04, Bob Braden wrote:
>And technically, the protocols that allowed this interoperation were
>the CCCDS international standards?
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Yes, of course.  I have suggested to the authors that they mention 
this fact during some up-coming articles.  Perhaps that will help get 
us some recognition.

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

From: Bob Braden <[email-masked]>
Date: Thu, 12 Feb 2004 11:47:02 -0800 (PST)
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Press Release: International Interplanetary Networking Succeeds
Sender: [email-masked]

And technically, the protocols that allowed this interoperation were
the CCCDS international standards?

Date: Thu, 12 Feb 2004 09:35:41 -0800
To: [email-masked]
From: Leigh Torgerson <[email-masked]>
Subject: [dtn-interest] Press Release: International Interplanetary Networking Succeeds
Sender: [email-masked]

Donald Savage
Headquarters, Washington                     February 12, 2004
(Phone: 202/358-1547)

Jocelyne Landeau-Constantin
ESA/EASOC Communication Office
(Intl. Phone: 49/ 6151 90 26 96)

Guy Webster
Jet Propulsion Laboratory, Pasadena, Calif.
(Phone: 818/354-5011)

RELEASE: 04-060

INTERNATIONAL INTERPLANETARY NETWORKING SUCCEEDS

      A pioneering demonstration of communications between
NASA's Mars Exploration Rover Spirit and the European Space
Agency (ESA) Mars Express orbiter succeeded.

On February 6, while Mars Express was flying over the area
Spirit was examining, the orbiter transferred commands from
Earth to the rover and relayed data from the robotic explorer
back to Earth.

"This is the first time we have had an in-orbit communication
between ESA and NASA spacecraft, and also the first working
international communications network around another planet,"
said Rudolf Schmidt, ESA's project manager for Mars Express.
"Both are significant achievements, two more 'firsts' for Mars
Express and the Mars Exploration Rovers."

Jennifer Trosper, Spirit mission manager at NASA's Jet
Propulsion Laboratory (JPL), Pasadena, Calif., said, "We have
an international interplanetary communications network
established at Mars."

ESA and NASA planned this demonstration as part of continuing
efforts to cooperate in space and to enable plans to use joint
communications assets to support future missions to the surface
of Mars.

The commands for the rover were transferred from Spirit's
operations team at JPL to ESA's European Space Operations
Centre in Darmstadt, Germany, where they were translated into
commands for Mars Express.

The translated commands were transmitted to Mars Express, which
used them to successfully command Spirit. Spirit used its
ultra-high frequency antenna to transmit telemetry information
to Mars Express. The orbiter relayed the data back to JPL, via
the European Space Operations Centre.

"This is excellent news," said JPL's Richard Horttor, project
manager for NASA's role in Mars Express. "The communication
sessions between Mars Express and Spirit were pristine. Not a
single bit of data was missing or added, and there were no
duplications."

This exercise demonstrated the increased flexibility and
capabilities of interagency cooperation and highlighted the
spirit of close support essential in undertaking international
space exploration.

Spirit and its twin Mars Exploration Rover, Opportunity,
frequently use two NASA orbiters, Mars Odyssey and Mars Global
Surveyor, for relaying communications. The rovers also can
communicate directly with the Earth-based antennas of NASA's
Deep Space Network in California, Spain and Australia, another
layer of international cooperation.

JPL, a division of the California Institute of Technology in
Pasadena, manages the Mars Exploration Rover Project and NASA
participation in Mars Express for NASA's Office of Space
Science, Washington.

For information about NASA and Mars programs on the Internet,
visit:

http://www.nasa.gov

For images and information about the Mars Exploration Rover
project on the Internet, visit:

http://marsrovers.jpl.nasa.gov

http://athena.cornell.edu

For images and information about Mars Express on the Internet,
visit:

http://www.esa.int/science/marsexpress

http://marsprogram.jpl.nasa.gov/express

-end-
-- 

Date: Wed, 11 Feb 2004 14:48:20 -0800
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] Canadian satellite to be a mailman in the sky
Sender: [email-masked]

At 11:03 AM 2/9/2004, Srinivasan Keshav wrote:
>Here are some pointers to an interesting news article about a LEO satellite
>that will carry between 50 to 500 GB of data from point to point over the
>globe.

Keshav: there's more information here:

http://www.space.gc.ca/asc/eng/media/press_room/news_releases/2004/040206.asp

"Initially, one Low Earth Orbit satellite will orbit above the Earth at an 
altitude of 300 to 1,500 km once every 1.5 hours, providing multiple 
opportunities each day for the pick-up and delivery of data anywhere on 
Earth. With the success of the CASSIOPE mission, as demand increases, 
capacity could be expanded by adding additional satellites. "

I've asked some of our colleagues in the Canadian Space Agency to keep an 
eye on CASSIOPE for us.

///adrian

To: [email-masked]
Date: Wed, 11 Feb 2004 12:09:37 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] test message - pls ignore
Sender: [email-masked]

testing mailing list functions and archiving. -- please ignore

Date: Wed, 11 Feb 2004 08:48:17 -0800
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] How to Wind a Martian Watch
Sender: [email-masked]

Dave - FYI:

http://www.astrobio.net/news/article826.html

"Summary:  Time keeping on two sides of another planet turns out to be a 
challenge, at least when calibrated from our own rhythms. On Earth, it took 
thousands of years for navigators to get terrestrial time on some reliable 
global standards. But when not on our globe, the familiar clock ticks need 
a sun calibration. Some of the first interplanetary clocks started during 
the 1976 Viking Mars mission, but since then interplanetary time-keeping 
has moved on. NASA's Michael Allison describes how to wind a Martian watch."

From: [email-masked] (Durga Prasad Pandey)
Date: Wed, 11 Feb 2004 02:27:56 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

--- Durga Prasad Pandey <[email-masked]> wrote:
> Micah, this assumption makes the analysis much simpler. I am still not 

Hans, I was writing a separate email to Micah while typing this one, and
got the names mixed up. Many apologies for the oversight.

Durga

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Durga Prasad Pandey)
Date: Wed, 11 Feb 2004 15:01:38 +0530
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Message-ID: <[email-masked]>

Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

>From: Hans Kruse <[email-masked]>
>.......2.) Durga/Fred on policies
>I think both of you are right here.  I can certainly try and predict 
>congestion based on a well-chosen set of parameters without policy input. 
>However, once I need to react to a predicted congestion event, I need a set 
>of rules, aka policies, to decide what data to drop, which bundle to 
>refuse, and what information to send to which up/downstream node.  These 
>policies could be tied to class of service, service level agreements, etc. 
>They could change over time...

Agreed. So effectively, we need to frame a general set of parameters that 
could help us predict congesion and take action on it. Once this is done, we 
can move to the next step, i.e. framing the policy, which would be specific 
for a given case of a DTN?

>My 2 cents worth:
>....  So preventing congestion by massive over-provisioning is probably not 
>realistic.

Exactly. Besides, even if I am able to store a very large amount of data, it 
will all be wasted if I'm not able to forward it to the successive nodes in 
a timely manner. I remember an RFC where an analysis was done assuming 
infinite buffer space; the result  -- it would only make congestion worse.
So the point is to make sure there is *enough* buffer space; and large 
amounts of extra space isn't going to help in preventing congestion.

>
>There is some good news.  The nodes that will present us with the most 
>expensive data will also be somewhat predictable.  I suspect that it will 
>be many decades before a Mars probe joins the Interplanetary Network 
>ad-hoc, without everyone having had advance notice months and years in 
>advance.  The most unpredictable nodes such as tactical sensor nets also 
>have much shorter control loops.
>
>Can we therefore think about introducing the concept of a Committed 
>Information Rate (CIR; borrowed from Frame Relay)?

Micah, this assumption makes the analysis much simpler. I am still not 
confident with it though, because we are currently looking at a set of 
parameters which we can apply to DTNs in general. Your analysis looks 
excellent, and I think it would be immensely valuable once we start talking 
of specific DTN environments.

>Note that we still need to do all the congestion control stuff we have been 
>discussing.  However, I think there is a limit on how good a control loop 
>we can create; when the loop does not work well we will end up discarding 
>data.  I would like to protect critical data from that process.

I think we must start getting a little familiar with imperfection. Data 
(including valuable data at times) is going to be lost occasionally. IMO, 
what we need to build is a system that can work with such mistakes, and 
possibly even learn from them. That, of course, doesn't mean though that we 
will refrain from analysing possible problems, and devising solutions for 
them in advance.

Philosophically speaking, I believe in putting in some 'intelligence' in the 
network, so that it can learn to deal with unexpected failures itself, as 
far as possible. It probably sounds somewhat futuristic, but I strongly 
believe it is worth the try. What do you think?

_________________________________________________________________
Easiest Money Transfer to India. Send Money To 6000 Indian Towns. 
http://go.msnserver.com/IN/42198.asp Easiest Way To Send Money Home!

From: [email-masked] (Michael Welzl)
Date: 11 Feb 2004 08:45:30 +0100
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <679205265.1076432728@hkruse2003a>
References: <[email-masked]> <679205265.1076432728@hkruse2003a>
Message-ID: <[email-masked]>

Hi all,

All that sounds very interesting.

Here's what I dream of:

A network of nodes which know the state of congestion
between each other ... they exchange the state just
like routing updates. At the edges of the network,
the nodes know all they need to know - just as with
routing, it is not a true end2end issue - the end
points do not have to be aware of the individual
control loops / message updates in between the
interior nodes. The edge nodes inform the end nodes
about the CIR.

Can we realize this for the Internet?
I don't think so.

Can we realize this for special scenarios, where
the overhead may be justified, provided that it
is still scalable (at least to a certain degree)?
I think so.

How? Not sure - but I think that the interior
congestion state updates should should not rely
on packet loss or delay but explicit congestion
states in order to make the system proactive.

This idea came about when working on my ph.d.
thesis - I actually think that something like
my PTP protocol could be used for these internal
state updates: http://www.welzl.at/ptp/

Cheers,
Michael

On Tue, 2004-02-10 at 23:05, Hans Kruse wrote:
> I think I have temporarily caught up with this thread, so here are some 
> thoughts on the various topic that have come up:
> 
> 1.) Durga's work on congestion predictions:
> I look at this effort as an evolution of RED.  In other words, rather than 
> waiting for buffer exhaustion, we try to predict congestion using more 
> sophisticated methods.  Given that the cost of congestion in DTNs is much 
> higher than in the Internet, that is a required step and I applaud the work 
> that is underway towards that.
> 
> 2.) Durga/Fred on policies
> I think both of you are right here.  I can certainly try and predict 
> congestion based on a well-chosen set of parameters without policy input. 
> However, once I need to react to a predicted congestion event, I need a set 
> of rules, aka policies, to decide what data to drop, which bundle to 
> refuse, and what information to send to which up/downstream node.  These 
> policies could be tied to class of service, service level agreements, etc. 
> They could change over time...
> 
> 3.) Scott on congestion control requirements
> I don't think you are missing anything here in that a predicted congestion 
> event can only be handled by dropping excess data, and only resolved (if it 
> persists) by back-pressure.  Your analysis seems correct to me.
> 
> ----
> 
> My 2 cents worth:
> 
> I worry that even a well-implemented control loop as we are discussing here 
> will neither be stable nor inherently efficient in all DTN environments. 
> That is not to say that it is not needed, I just think that it is 
> insufficient by itself.
> 
> I am starting to think that we need, in addition to congestion prediction 
> and congestion control, a concept of congestion avoidance.  I have NOT had 
> the time to sit down and really work this out, but I am tempted to borrow 
> from Frame Relay (and to a lesser extent ATM) in this regard.
> 
> In general, in the DTN scenarios we are discussing such as tactical sensor 
> nets and interplanetary probes, data comes with different values attached. 
> The data that has to be transmitted reliably over the largest delay is the 
> most valuable, since its loss in congestion "costs" us the most in wasted 
> resources and possibly lost opportunities when controlling remote sensor 
> probes.  We also know that the potentially huge control loop lengths will 
> force us into deploying very large and expensive buffers (expensive more so 
> in terms of weight and power consumption than monetary cost).  So 
> preventing congestion by massive over-provisioning is probably not 
> realistic.
> 
> There is some good news.  The nodes that will present us with the most 
> expensive data will also be somewhat predictable.  I suspect that it will 
> be many decades before a Mars probe joins the Interplanetary Network 
> ad-hoc, without everyone having had advance notice months and years in 
> advance.  The most unpredictable nodes such as tactical sensor nets also 
> have much shorter control loops.
> 
> Can we therefore think about introducing the concept of a Committed 
> Information Rate (CIR; borrowed from Frame Relay)?  What I envision is that 
> if node A is going to forward bundles to node B, there exists an 
> agreed-upon CIR that A can count on being able to send to node B without 
> bundles being rejected.  The CIR would come from one of (a) local policy, 
> (b) negotiation between A and B, or (c) prior arrangement.
> 
> For example, an earth-orbit data relay would be programmed to expect 
> transmissions from a Mars probe starting on some date, and be told to 
> reserve a certain CIR for that probe.  The probe counts on that CIR being 
> available.
> 
> A drone relay over a battle field might have a local policy to grant a 
> pre-determined CIR to sensors looking for nerve gas, and that sensor would 
> be programmed to expect that CIR.
> 
> A truly ad-hoc connection would start with a 0 CIR; node A (say a wildlife 
> monitoring station) would include in its first bundle to B some information 
> about its intent, such as "I am trying to send x bundles totaling y Mbytes 
> over the next z minutes".  B would then consult local policy and congestion 
> predictions, and in the first acknowledgement send a CIR back to A.
> 
> In all cases the sending node can assume that a certain amount of data will 
> be accepted.  Presumably the node would fit critical data under that rate 
> ceiling, and send additional data with a "Discard Eligible" bit set.
> 
> Note that we still need to do all the congestion control stuff we have been 
> discussing.  However, I think there is a limit on how good a control loop 
> we can create; when the loop does not work well we will end up discarding 
> data.  I would like to protect critical data from that process.
> 
> Thoughts and flames welcome ;)....
> 
> Hans Kruse, Associate Professor
> J. Warren McClure School of Communication Systems Management
> Adjunct Associate Professor of Electrical Engineering and Computer Science
> Ohio University, Athens, OH, 45701
> 740-593-4891 voice, 740-593-4889 fax
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
-- 
Michael Welzl <[email-masked]>
University of Innsbruck

From: [email-masked] (Hans Kruse)
Date: Tue, 10 Feb 2004 17:05:28 -0500
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <679205265.1076432728@hkruse2003a>

I think I have temporarily caught up with this thread, so here are some 
thoughts on the various topic that have come up:

1.) Durga's work on congestion predictions:
I look at this effort as an evolution of RED.  In other words, rather than 
waiting for buffer exhaustion, we try to predict congestion using more 
sophisticated methods.  Given that the cost of congestion in DTNs is much 
higher than in the Internet, that is a required step and I applaud the work 
that is underway towards that.

2.) Durga/Fred on policies
I think both of you are right here.  I can certainly try and predict 
congestion based on a well-chosen set of parameters without policy input. 
However, once I need to react to a predicted congestion event, I need a set 
of rules, aka policies, to decide what data to drop, which bundle to 
refuse, and what information to send to which up/downstream node.  These 
policies could be tied to class of service, service level agreements, etc. 
They could change over time...

3.) Scott on congestion control requirements
I don't think you are missing anything here in that a predicted congestion 
event can only be handled by dropping excess data, and only resolved (if it 
persists) by back-pressure.  Your analysis seems correct to me.

----

My 2 cents worth:

I worry that even a well-implemented control loop as we are discussing here 
will neither be stable nor inherently efficient in all DTN environments. 
That is not to say that it is not needed, I just think that it is 
insufficient by itself.

I am starting to think that we need, in addition to congestion prediction 
and congestion control, a concept of congestion avoidance.  I have NOT had 
the time to sit down and really work this out, but I am tempted to borrow 
from Frame Relay (and to a lesser extent ATM) in this regard.

In general, in the DTN scenarios we are discussing such as tactical sensor 
nets and interplanetary probes, data comes with different values attached. 
The data that has to be transmitted reliably over the largest delay is the 
most valuable, since its loss in congestion "costs" us the most in wasted 
resources and possibly lost opportunities when controlling remote sensor 
probes.  We also know that the potentially huge control loop lengths will 
force us into deploying very large and expensive buffers (expensive more so 
in terms of weight and power consumption than monetary cost).  So 
preventing congestion by massive over-provisioning is probably not 
realistic.

There is some good news.  The nodes that will present us with the most 
expensive data will also be somewhat predictable.  I suspect that it will 
be many decades before a Mars probe joins the Interplanetary Network 
ad-hoc, without everyone having had advance notice months and years in 
advance.  The most unpredictable nodes such as tactical sensor nets also 
have much shorter control loops.

Can we therefore think about introducing the concept of a Committed 
Information Rate (CIR; borrowed from Frame Relay)?  What I envision is that 
if node A is going to forward bundles to node B, there exists an 
agreed-upon CIR that A can count on being able to send to node B without 
bundles being rejected.  The CIR would come from one of (a) local policy, 
(b) negotiation between A and B, or (c) prior arrangement.

For example, an earth-orbit data relay would be programmed to expect 
transmissions from a Mars probe starting on some date, and be told to 
reserve a certain CIR for that probe.  The probe counts on that CIR being 
available.

A drone relay over a battle field might have a local policy to grant a 
pre-determined CIR to sensors looking for nerve gas, and that sensor would 
be programmed to expect that CIR.

A truly ad-hoc connection would start with a 0 CIR; node A (say a wildlife 
monitoring station) would include in its first bundle to B some information 
about its intent, such as "I am trying to send x bundles totaling y Mbytes 
over the next z minutes".  B would then consult local policy and congestion 
predictions, and in the first acknowledgement send a CIR back to A.

In all cases the sending node can assume that a certain amount of data will 
be accepted.  Presumably the node would fit critical data under that rate 
ceiling, and send additional data with a "Discard Eligible" bit set.

Note that we still need to do all the congestion control stuff we have been 
discussing.  However, I think there is a limit on how good a control loop 
we can create; when the loop does not work well we will end up discarding 
data.  I would like to protect critical data from that process.

Thoughts and flames welcome ;)....

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

From: [email-masked] (Durga Prasad Pandey)
Date: Tue, 10 Feb 2004 10:35:07 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control     in IPN/DTN
In-Reply-To: <[email-masked] >
Message-ID: <[email-masked]>

--- Fred Baker <[email-masked]> wrote:
> At 11:26 PM 2/8/2004, Durga Prasad Pandey wrote:
> >Our concern right now is: are these parameters independent of each
> other,
> >and are they sufficient? And how exactly should a node interpret them
> in
> >taking real world congestion/flow control decisions?
> 
> I don't think we know, unless we also know the policy by which they are 
> used. I didn't see anything in that note about policy. Did I miss
> something? 

Fred, I don't think I'd need to know the policy in order to decide if
certain parameters are independent of each other? I don't think we have a
'policy' as such for DTNs, as yet. Perhaps we will keep defining it for
different DTNs, such as an IPN or a battlefield DTN, as we keep pushing to
solve the problem of identifying and characterizing congestion. I'd admit
that 'policy' still sounds confusing to me -- I can't figure out how it is
related to our root question.

Durga

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Durga Prasad Pandey)
Date: Tue, 10 Feb 2004 10:07:35 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

hi Alex,

I think we would be looking at both proactive and reactive strategies. We
can't really ignore signals and 'not react' when we need to. But we would
like to have some sort of predictive mechanism, as you pointed out, that
gives us an approximate expectation of congestion.

Durga

--- Alex Audu <[email-masked]> wrote:
> I also don't think the TCP/IP model is  better because it is a reactive 
> mecahnism: you react
> to congestion only after dropping packets (or bundles).  It will be 
> better if some action could
> be taken proactively, based on a prediction of congestion before it 
> actually sets in, or before
> it leads to packet drops. It makes for better throughput and 
> reliability. I believe that is the essence
> of Durga's proposal.
> 
> Regards,
> Alex.
> 
> Matt Bradbury wrote:
> 
> > In case anyone thought they were getting ahead of the mail deluge, 
> > here's another one.
> >
> > Scott Burleigh wrote:
> >
> >>
> >>> But when we do implement congestion control, I think one of the 
> >>> things to consider is that routers should be hefty enough to handle 
> >>> the sum of traffic coming in on all links for the time it would take
> 
> >>> to send a message back out to the sources of the congestion telling 
> >>> them to slow down.  And I think the slow down messages should be as 
> >>> simple as "Your sending data at 2 mbit/s  please throttle to 1 
> >>> mbit/s"   Where 1 mbit/s is a number that the router thinks it can 
> >>> handle in the time before another round-trip of control messages 
> >>> could be exchanged to slow the rate down even more.
> >>
> >>
> >>
> >> Here I disagree.  I think using source-quench-like signals to effect 
> >> explicit congestion control is not a good idea; I like the TCP/IP 
> >> model better (okay, my understanding of it may be shaky; bear with 
> >> me), that acknowledgement failure is interpreted as loss of data due 
> >> to congestion and the sender responds by reducing the rate of 
> >> transmission to that receiver.
> >
> >
> > Aren't ack failures in TCP measured in seconds?  What amount of time 
> > would we measure as an ack failure for DTN?
> > Remember since this is a store-and-forward network, we're going to be 
> > able to handle full data streams for a while before we'll drop a 
> > Bundle.  Let me see if I can use a warehouse as an analogy.  The 
> > warehouse is always shipping and receiving goods.  Outgoing rates are 
> > controlled by how much stores can put on their shelves.  And if the 
> > stores start telling you to not ship so much to them in the next 
> > truckload, you're going to have less floor space for the incoming 
> > goods from the factory.  So what do you do, you ride it out for a bit 
> > and see if the stores will start moving the product more quickly, but 
> > if the warehouse fills up because you never told the factory to back 
> > off, you've just been fired because you left the widgets out in the 
> > rain on the loading dock.  At some point you have to tell you're 
> > upstream suppliers to slow down cause you don't want to throw away 
> > bundles.  Since we have the ability to store bundles, we can't wait 
> > until the thunderstorm hits to let everyone know we've got a full 
> > warehouse.
> >
> > Dell is right up the road from me, maybe I should see how there 
> > shipping guys maintain the highest throughput possible in their 
> > warehouses!!  ;)
> >
> >>
> >> Specifically, I think failure of custody transfer -- either implicit 
> >> (custody timer expires) or explicit (receiver sends a custody 
> >> transfer ack refusing custody, as I proposed in an email here a 
> >> couple of weeks ago) -- is a darn good signal of possible 
> >> congestion.  On detection of such a signal, I think the sender should
> 
> >> locally and autonomously decide how severe the congestion is (the 
> >> problem Durga has been working on) and what to do about it (a 
> >> separate and equally thorny problem).
> >
> >
> > What percentage of traffic do we think will be requesting custody 
> > transfer versus those just wanting to get sent and hope they survive. 
> 
> > I can see a model where the cost of custody transfer is high enough 
> > that network providers would charge higher rates for custody 
> > transfers, essentially making them the exception and not the norm.  
> > We'd still have plenty of congestion, but how much would go unnoticed 
> > since in this model, the routers would be programmed to forward the 
> > custody requesting bundles since they paid more in the first place.
> >
> >>>
> >>> p.s.  I'm working on a Java implementation of the internet-draft 
> >>> that Scott Burleigh put out in January.  It has some work to go 
> >>> before I open it up to everyone, but I hope that combined with the 
> >>> existing C code, we can have a couple of test platforms to start 
> >>> testing our ideas on.
> >>
> >>
> >>
> >> Wow, this is outstanding, Matt.
> >
> >
> > Thanks, wouldn't have been possible without my beaten up and dogeared 
> > copy of your bundle-spec.
> >
> > -Matt Bradbury
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Alex Audu)
Date: Tue, 10 Feb 2004 11:59:50 -0600
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked]>
References: <40247C96.00001D.85911@shulabh> <40247C96.00001D.85911@shulabh> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I also don't think the TCP/IP model is  better because it is a reactive 
mecahnism: you react
to congestion only after dropping packets (or bundles).  It will be 
better if some action could
be taken proactively, based on a prediction of congestion before it 
actually sets in, or before
it leads to packet drops. It makes for better throughput and 
reliability. I believe that is the essence
of Durga's proposal.

Regards,
Alex.

Matt Bradbury wrote:

> In case anyone thought they were getting ahead of the mail deluge, 
> here's another one.
>
> Scott Burleigh wrote:
>
>>
>>> But when we do implement congestion control, I think one of the 
>>> things to consider is that routers should be hefty enough to handle 
>>> the sum of traffic coming in on all links for the time it would take 
>>> to send a message back out to the sources of the congestion telling 
>>> them to slow down.  And I think the slow down messages should be as 
>>> simple as "Your sending data at 2 mbit/s  please throttle to 1 
>>> mbit/s"   Where 1 mbit/s is a number that the router thinks it can 
>>> handle in the time before another round-trip of control messages 
>>> could be exchanged to slow the rate down even more.
>>
>>
>>
>> Here I disagree.  I think using source-quench-like signals to effect 
>> explicit congestion control is not a good idea; I like the TCP/IP 
>> model better (okay, my understanding of it may be shaky; bear with 
>> me), that acknowledgement failure is interpreted as loss of data due 
>> to congestion and the sender responds by reducing the rate of 
>> transmission to that receiver.
>
>
> Aren't ack failures in TCP measured in seconds?  What amount of time 
> would we measure as an ack failure for DTN?
> Remember since this is a store-and-forward network, we're going to be 
> able to handle full data streams for a while before we'll drop a 
> Bundle.  Let me see if I can use a warehouse as an analogy.  The 
> warehouse is always shipping and receiving goods.  Outgoing rates are 
> controlled by how much stores can put on their shelves.  And if the 
> stores start telling you to not ship so much to them in the next 
> truckload, you're going to have less floor space for the incoming 
> goods from the factory.  So what do you do, you ride it out for a bit 
> and see if the stores will start moving the product more quickly, but 
> if the warehouse fills up because you never told the factory to back 
> off, you've just been fired because you left the widgets out in the 
> rain on the loading dock.  At some point you have to tell you're 
> upstream suppliers to slow down cause you don't want to throw away 
> bundles.  Since we have the ability to store bundles, we can't wait 
> until the thunderstorm hits to let everyone know we've got a full 
> warehouse.
>
> Dell is right up the road from me, maybe I should see how there 
> shipping guys maintain the highest throughput possible in their 
> warehouses!!  ;)
>
>>
>> Specifically, I think failure of custody transfer -- either implicit 
>> (custody timer expires) or explicit (receiver sends a custody 
>> transfer ack refusing custody, as I proposed in an email here a 
>> couple of weeks ago) -- is a darn good signal of possible 
>> congestion.  On detection of such a signal, I think the sender should 
>> locally and autonomously decide how severe the congestion is (the 
>> problem Durga has been working on) and what to do about it (a 
>> separate and equally thorny problem).
>
>
> What percentage of traffic do we think will be requesting custody 
> transfer versus those just wanting to get sent and hope they survive.  
> I can see a model where the cost of custody transfer is high enough 
> that network providers would charge higher rates for custody 
> transfers, essentially making them the exception and not the norm.  
> We'd still have plenty of congestion, but how much would go unnoticed 
> since in this model, the routers would be programmed to forward the 
> custody requesting bundles since they paid more in the first place.
>
>>>
>>> p.s.  I'm working on a Java implementation of the internet-draft 
>>> that Scott Burleigh put out in January.  It has some work to go 
>>> before I open it up to everyone, but I hope that combined with the 
>>> existing C code, we can have a couple of test platforms to start 
>>> testing our ideas on.
>>
>>
>>
>> Wow, this is outstanding, Matt.
>
>
> Thanks, wouldn't have been possible without my beaten up and dogeared 
> copy of your bundle-spec.
>
> -Matt Bradbury
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Tue, 10 Feb 2004 10:02:13 -0800 (PST)
From: Durga Prasad Pandey <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] test, pls ignore
Sender: [email-masked]

test, to see if the list ID works, and archives.

Durga

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Date: Tue, 10 Feb 2004 07:00:18 -0800 (PST)
From: Durga Prasad Pandey <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> At 10:14 AM 2/9/2004 -0600, Matt Bradbury wrote:
> >find out their condition.  If we know that our neighbor has gigabytes
> of 
> >data that it needs to offload to me, I'd like to know.  

Matt, I have a slightly different view on this. I think a receiver needn't
know that a sender has so much of data to send. IMO, it is sufficiant for
the receiver to indicate that it can only receive at *this particular
rate*. The sender will then have to figure out what it is going to do with
the data it has/going to have. Perhaps it can exert backpressure on its
own sender, backwards.

Durga
PS: I have changed the mailing list address above from
[email-masked] to [email-masked] as the
former is apparently not getting archived, though the message does get
delivered to subscribers.

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Scott Burleigh)
Date: Mon, 09 Feb 2004 21:43:15 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 10:14 AM 2/9/2004 -0600, Matt Bradbury wrote:
>Durga Prasad Pandey wrote:
>
>>Matt,
>>
>>Your mail is interesting.
>>
>>One of the assumptions I started with, is that we'd like each node to take
>>autonomous decisions regarding congestion. I hope you appreciate the fact
>>that we cannot really keep a 'global knowledge' of the state of each node
>>in the network, esp considering the fact the network itself is a set of
>>constantly changing p2p links. What we could possibly have is some
>>approximate knowledge of the topology etc.
>>
>I have no intention of  having any kind of global knowledge when dealing 
>with congestion.  But we should be able to chat with our neighbors and 
>find out their condition.  If we know that our neighbor has gigabytes of 
>data that it needs to offload to me, I'd like to know.  Especially if it's 
>going to be tying up my resources for any period of time.  And vice-versa, 
>if I've told my nextHop node that I've got a large queue for him and he 
>doesn't ask me to back off, I have a confidence that that node can receive 
>them.
>
>>In an IPN type of DTN, the nodes would be more or less in contact with
>>each other periodically, so it would be easier to have a 'sense' of what
>>nodes the network consists of. But in a military battlefield network, it's
>>all going to be random. But then again, the network could be told
>>manually, perhaps, to expect soldier-nodes in particular areas.
>>
>These are definitely opposite ends of the congestion issue.  One is 
>well-ordered, with planned connections theoretically years in the future 
>because of Newton and his Laws, whereas a battle will have a rapidly 
>changing topology that needs constant rediscovery, retransmission and 
>redundancy.  I would propose that these two situations could require 
>completely different congestion control algorithms.
>Let's keep congestion control above the bundling layer, that way different 
>algorithms can be used in different environments and to keep life easier 
>with simple protocol stacks on all devices, and congestion control on the 
>devices that need it.  You've already made this easy by requiring that 
>each node make it's own decisions, how it makes decisions should not be 
>for others to understand.

I agree with one major point that I believe you're making here: I think 
part of the beauty of the everybody-minds-his-own-business model of 
autonomous congestion control is that different nodes might well be running 
different implementations and exercising different congestion detection and 
disposition algorithms, so that the network forms a population of competing 
entities.  Perhaps over time the more successful algorithms will confer 
advantages on their nodes, and as new nodes are deployed with those 
algorithms the character of the network will evolve toward greater efficiency.

But I'm not convinced that the principles these algorithms are based on are 
necessarily situational.  A few weeks ago, when Mani and I were talking 
about flow control in LTP, I found myself working out the beginnings of 
what I hoped might be a general, systematic notion of congestion and flow 
control that works for both low-delay and high-delay networks.  I suspect 
it is naive.  However, at the risk of looking perhaps surprisingly dumb, 
here's what I've got so far.

Let me try to distinguish between congestion control and flow control this way:

-       Congestion control is something you do to protect routers, in order 
to keep a network functioning.  The basic problem ("congestion") is excess 
aggregate demand for buffer space at a router, from any number of upstream 
sources and/or other routers; the symptom is data loss due to inadequate 
resources for inbound message reception.  There are two fundamental causes: 
some subset of the upstream sources and/or routers are transmitting too 
quickly (input rate too high) and/or some subset of the downstream 
destinations and/or routers are receiving too slowly (output rate too 
low).  The input and output data flow that produces the problem is 
"horizontal", i.e., between peers at the same layer of protocol.  Since you 
typically can't count on being able to make the downstream guys run faster, 
the remedy -- "congestion control" -- is to somehow slow down the upstream 
guys; ideally you don't slow them all down, but only the ones that are 
currently "too fast" (however you determine this).  The mechanism we use to 
accomplish this remedy is typically some sort of signalling between the 
peers, embedded into the horizontal data flows.

-       Flow control is actually something you do to protect a protocol 
implementation instance at some layer of the protocol stack.  [I've just 
spent a couple of months wrestling with some high-speed pipe-like 
structures that have given me an acute appreciation of this sort of 
problem.]  Again the basic problem is excess demand for buffer space, but 
the demand is local: it is experienced at the subject protocol 
implementation, and it is exerted by the other protocols -- at the 
immediately higher and lower layers of the stack -- to which it offers 
services.  There are two input and output data flows: input from and output 
to the layer above ("application" or whatever), and input from and output 
to the layer below ("link" or whatever); these data flows are 
"vertical".  Therefore there are *four* fundamental causes of distress:
         a)      The "application" is requesting transmission too rapidly.
         b)      The "application" is accepting inbound data too slowly.
         c)      The "link" is accepting outbound data too slowly.
         d)      The "link" is delivering inbound data too rapidly.

Normally the remedy -- "flow control" -- again is to somehow slow down 
whoever is too fast.  The mechanism we use to accomplish this is typically 
twofold:
         -       To reduce the rate of input from the upper layer, we 
"block" the writing function in the API that we expose to the "application" 
(e.g., blocking writes on sockets).
         -       To reduce the rate of input from the lower layer, we don't 
try to retard the "link" protocol: it doesn't originate any transmissions, 
so it really can't slow down.  Instead we use the link to signal peer 
endpoints that they should likewise slow down the input from *their* upper 
layers.

The network protocol (where congestion is experienced) is one of those 
protocols that actually doesn't originate any transmissions.  When a router 
or other network protocol traffic source reduces the rate at which it 
transmits (i.e., effects congestion control), it creates a flow control 
problem for itself: buffer occupancy tends to increase because rate of 
outbound flow drops.  The router solves that flow control problem by 
propagating it upward, ultimately to the top-level applications that do 
originate all the traffic in the network.

Coming back to DTN: Bundling is essentially a network protocol, so it has 
to solve congestion problems.  I think it has to do so by selectively 
discarding inbound data, thereby failing to take custody, thereby 
implicitly increasing the congestion at upstream custodial nodes, thereby 
producing further back-propagation of distress that ultimately reaches the 
source bundle agents, which respond to it by exerting flow control on their 
local applications.  That is, in practice we do finally control congestion 
by invoking flow control remotely, whether in the Internet (by blocking at 
sockets) or in a DTN (by blocking at the Bundling API).

If so, then I think there's plenty of room for lots of clever congestion 
anticipation algorithms in bundle nodes but really only one mechanism for 
DTN congestion control: back-propagation of flow control distress by 
custody refusal.

What parts have I got wrong?

Scott

From: [email-masked] (Matt Bradbury)
Date: Mon, 09 Feb 2004 23:41:30 -0600
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked]>
References: <40247C96.00001D.85911@shulabh> <40247C96.00001D.85911@shulabh> <[email-masked]>
Message-ID: <[email-masked]>

In case anyone thought they were getting ahead of the mail deluge, 
here's another one.

Scott Burleigh wrote:

>
>> But when we do implement congestion control, I think one of the 
>> things to consider is that routers should be hefty enough to handle 
>> the sum of traffic coming in on all links for the time it would take 
>> to send a message back out to the sources of the congestion telling 
>> them to slow down.  And I think the slow down messages should be as 
>> simple as "Your sending data at 2 mbit/s  please throttle to 1 
>> mbit/s"   Where 1 mbit/s is a number that the router thinks it can 
>> handle in the time before another round-trip of control messages 
>> could be exchanged to slow the rate down even more.
>
>
> Here I disagree.  I think using source-quench-like signals to effect 
> explicit congestion control is not a good idea; I like the TCP/IP 
> model better (okay, my understanding of it may be shaky; bear with 
> me), that acknowledgement failure is interpreted as loss of data due 
> to congestion and the sender responds by reducing the rate of 
> transmission to that receiver.

Aren't ack failures in TCP measured in seconds?  What amount of time 
would we measure as an ack failure for DTN? 

Remember since this is a store-and-forward network, we're going to be 
able to handle full data streams for a while before we'll drop a 
Bundle.  Let me see if I can use a warehouse as an analogy.  The 
warehouse is always shipping and receiving goods.  Outgoing rates are 
controlled by how much stores can put on their shelves.  And if the 
stores start telling you to not ship so much to them in the next 
truckload, you're going to have less floor space for the incoming goods 
from the factory.  So what do you do, you ride it out for a bit and see 
if the stores will start moving the product more quickly, but if the 
warehouse fills up because you never told the factory to back off, 
you've just been fired because you left the widgets out in the rain on 
the loading dock.  At some point you have to tell you're upstream 
suppliers to slow down cause you don't want to throw away bundles.  
Since we have the ability to store bundles, we can't wait until the 
thunderstorm hits to let everyone know we've got a full warehouse.

Dell is right up the road from me, maybe I should see how there shipping 
guys maintain the highest throughput possible in their warehouses!!  ;)

>
> Specifically, I think failure of custody transfer -- either implicit 
> (custody timer expires) or explicit (receiver sends a custody transfer 
> ack refusing custody, as I proposed in an email here a couple of weeks 
> ago) -- is a darn good signal of possible congestion.  On detection of 
> such a signal, I think the sender should locally and autonomously 
> decide how severe the congestion is (the problem Durga has been 
> working on) and what to do about it (a separate and equally thorny 
> problem).

What percentage of traffic do we think will be requesting custody 
transfer versus those just wanting to get sent and hope they survive.  I 
can see a model where the cost of custody transfer is high enough that 
network providers would charge higher rates for custody transfers, 
essentially making them the exception and not the norm.  We'd still have 
plenty of congestion, but how much would go unnoticed since in this 
model, the routers would be programmed to forward the custody requesting 
bundles since they paid more in the first place.

>>
>> p.s.  I'm working on a Java implementation of the internet-draft that 
>> Scott Burleigh put out in January.  It has some work to go before I 
>> open it up to everyone, but I hope that combined with the existing C 
>> code, we can have a couple of test platforms to start testing our 
>> ideas on.
>
>
> Wow, this is outstanding, Matt.

Thanks, wouldn't have been possible without my beaten up and dogeared 
copy of your bundle-spec.

-Matt Bradbury

From: [email-masked] (Scott Burleigh)
Date: Mon, 09 Feb 2004 20:59:00 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Message-ID: <[email-masked]>

At 10:55 PM 2/8/2004 -0800, Fred Baker wrote:
>At 10:31 PM 2/8/2004, Durga Prasad Pandey wrote:
>The crucial difference between this mechanism and what we use in the 
>Internet is that in the latter, we do not store copies of packets at 
>intermediate nodes -- they are retransmitted(as and when required) from 
>the source itself. So, yes, I do think this increases reliability, though 
>as Keith has pointed out, there are other mechanisms for reliability as well.
>
>
>Well, correct me if I am wrong, but I think you're a layer above TCP. TCP 
>might be used within a network to ensure that a message gets from one 
>custodian to another; if not TCP, then some other transport would be used. 
>But TCP (if it is used) then delivers the mesage to someone, and that 
>someone decides (a) that it is now the custodian and (b) what to do with 
>the message, often deciding to forward it to another custodian.
>
>The obvious analogy isn't to TCP-as-a-special-case-of-a-transport, it is 
>to SMTP-as-a-special-case-of-a-relay. The thing with SMTP is that it 
>doesn't do what you said above - reliability is always the province of the 
>custodian (one of potentially many MTAs en route) as opposed to the 
>originator. The originator has a reliability role, I suppose, but it is 
>not in the mail protocol. Rather, if the user doesn't get a response 
>within a few days and wanted one, he sends a follow-up email.
>
>If what we are discussing is a relay layer that accepts interesting 
>delays, in the sense that SMTP implements such a layer, for such 
>applications as file transfer and so on, it seems to me that a similar 
>model has value. You decide that the probability of a catastrophe 
>happening to one of the relays is acceptably low, and put the relays into 
>the position of being responsible for the delivery of their traffic to the 
>next relay.

You're right, in many ways SMTP is an excellent model for bundling.  The 
relay is responsible for getting the message to the next relay, and for its 
own convenience it uses the most reliable underlying mechanism it can to 
make this happen -- but if that mechanism fails it has to try again.

>As to congestion, it seems to me that the question here might be the 
>availability and capability of the relay. If a relaying custodian can 
>advise the previous custodian that it has accepted custodial 
>responsibilities, it seems that it should be able to also indicate (in the 
>same message) how much capacity it has remaining under its policy with 
>respect to this previous hop. If, for example, it is a dedicated relay for 
>that previous hop (it is orbiting the Earth and is a relay point for a 
>specific Mars mission, for example), that might be as simple as "I have 12 
>Terabytes of space left". If it has several possible previous hops, it has 
>a more complicated statement to make, but it seems that it should boil 
>down to "as long as you don't send me more than ____, I will receive it, 
>store it, and relay it on when I have the opportunity". The question after 
>that might be "what policy does the sender have for that information" and 
>"what capabilities might it have to effect that policy". If its policy is 
>"overwrite old stuff even if it is unforwarded", it might want to be able 
>to command its next custodian  to "delete enough of my oldest stuff to 
>allow me to send you a new file of size <...>". If it believes that older 
>stuff is sacrosanct, then it might need to push back itself.

My worry here is that by passing information like this around we may think 
that we are enabling nodes to understand conditions on other nodes and make 
transmission decisions based on that understanding.  In a low-delay 
environment, where it's possible to receive this sort of information and 
act on it before conditions are likely to have changed significantly, this 
is a very reasonable approach.  But I think it is inherently delay-intolerant.

These kinds of messages can certainly be time-tagged, so at least you know 
how obsolete the information might be, and you can certainly apply 
stochastic methods based on processing history, weighting the results by 
confidence levels that decline with the age of the data you're working 
from; all doable, but you still run a significant risk of committing to 
dubious guesses about the future.  I think if we go this way we risk 
convincing ourselves that we've got things more under control than we 
possibly can.

Scott

From: [email-masked] (Scott Burleigh)
Date: Mon, 09 Feb 2004 20:39:11 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 03:58 PM 2/8/2004 -0500, Scott,Keith L. wrote:
>There are really three levels at which reliability can be imposed.  They 
>are (from the bottom up)
>
>1) At the 'convergence layer' (the transport layer used between bundle 
>routers).  This may be TCP, UDP, UDP+FEC, etc.  Generally speaking, we'd 
>like convergence layers to be as reliable as possible, but even a 'fully 
>reliable' convergence layer like TCP isn't as good as a bundle-layer 
>acknowledgemnt.  A question remains as to what are the actual requirements 
>(if any) on a convergence layer wrt reliability.  I tend to think that 
>there can't be any, since I'd like to admit the possibility of 
>unacknowledged UDP (or something like it) for situations when the next hop 
>can't transmit (policy, broken transmitter, etc.)

This is an issue I think we still haven't reached complete agreement 
on.  The problem with relying on custody transfer at the bundling layer as 
the 'main' reliability mechanism is that retransmission must be at least 
partially driven by timeouts (absence of acknowledgement), and in a 
delay-tolerant network there is no general solution to the problem of 
computing a suitable timeout interval for transmission between custodial 
bundle agents.  Bundling can't reasonably be expected to understand all the 
possible variations in delay, due to orbital movement, policy, tactical 
constraints and so on in all possible types of subnetwork, to predict 
accurately the length of time that will elapse between transmission of a 
bundle and reception of its acknowledgement from a custodial agent who 
might be three subnetworks away.

Absent reliability at the convergence layer, all retransmission must be 
performed by the custodian [or by the source, end-to-end, an even worse 
case].  It will be triggered by timeouts occurring at computed 
intervals.  If the computed timeout intervals are too brief, the timeouts 
will occur prematurely and result in degraded network utilization due to 
unnecessary retransmission.  If they are too long, the lengthened occupancy 
of retransmission buffers will result in congestion.

Custody transfer is great as a retransmission safety net, and I have 
belatedly learned to celebrate its value as a congestion signaling medium, 
but without generally reliable protocols at the convergence layer I think 
it is a pretty thin reed for communication reliability.

Scott 

From: [email-masked] (Durga Prasad Pandey)
Date: Mon, 9 Feb 2004 20:22:37 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

--- Scott Burleigh <[email-masked]> wrote:
>....... Here I disagree.  I think using source-quench-like signals to
effect 
> explicit congestion control is not a good idea; I like the TCP/IP model 
> better (okay, my understanding of it may be shaky; bear with me), that 
> acknowledgement failure is interpreted as loss of data due to congestion
> 
> and the sender responds by reducing the rate of transmission to that
> receiver.
> Specifically, I think failure of custody transfer -- either implicit 
> (custody timer expires) or explicit (receiver sends a custody transfer
> ack 
> refusing custody, as I proposed in an email here a couple of weeks ago)
> -- 
> is a darn good signal of possible congestion. 

Scott, I am not sure I am completely convinced of 'custody refusals' being
capable enough to characterize congestion in a DTN. At this point, I am
also not sure if custody transfer is intended for bundles of all COS, or
only for the top priority ones. What do you think about sending the values
of the 4 parameters we have been discussing(which includes data
abandonment rate) and letting the sender decide at what rate it should
send. It would probably make things more complex, but the benefit in
congestion detection might be worth the complexity.

 On detection of such a 
> signal, I think the sender should locally and autonomously decide how 
> severe the congestion is (the problem Durga has been working on) and
> what 
> to do about it (a separate and equally thorny problem).

I think a simple 'custody refusal' might not give me enough information to
decide the extent of congestion. Some sort of numeric parameter(s)
feedback -- essentially indicators of congestion which would be
interpreted by the sender --  (I am open to 'radical' ideas on this :) )  
will, I suppose,  make things a lot more easier for the sender.

> information that it might in some circumstances never get, and it
> minimizes 
> the need for Bundling to predict the future anywhere; it relies on
> emergent 
> behavior, which (provided we've got as much margin as possible) is 
> something I trust more than second-guessing the state of nodes that
> might 
> be twenty light-minutes away.

This is a basic question; could you clarify how 'prediction' is different
from 'emergent behaviour'?

Durga

=====
Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (SCOTT C BURLEIGH)
Date: Mon, 09 Feb 2004 18:41:14 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Message-ID: <[email-masked]>

----- Original Message -----
From: Scott Burleigh <[email-masked]>
Date: Monday, February 9, 2004 5:23 pm
Subject: Re: [dtn-interest] Recent thinking on
Congestion/flow control  in IPN/DTN

> I think using source-quench-like signals to 
> effect 
> explicit congestion control is not a good idea; I
like the TCP/IP 
> model 
> better (okay, my understanding of it may be shaky;
bear with me), 
> that 
> acknowledgement failure is interpreted as loss of
data due to 
> congestion 
> and the sender responds by reducing the rate of
transmission to 
> that receiver.
> 
> Specifically, I think failure of custody transfer
-- either 
> implicit 
> (custody timer expires) or explicit (receiver
sends a custody 
> transfer ack 
> refusing custody, as I proposed in an email here a
couple of weeks 
> ago) -- 
> is a darn good signal of possible congestion.  On
detection of such 
> a 
> signal, I think the sender should locally and
autonomously decide 
> how 
> severe the congestion is (the problem Durga has
been working on)

(As I was running out of my office I realized that
this is wrong, but it took me a while to get to a
computer.  The problem Durga has actually been
working on is how to detect and characterize
congestion locally, at the node that is experiencing
it, so that the node can start dropping bundles
proactively to defend itself from buffer exhaustion.
 A tricky business in itself, but an altogether
different problem from the one faced by the sender
whose custody timers start going off.)

From: [email-masked] (Scott Burleigh)
Date: Mon, 09 Feb 2004 17:23:53 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <40247C96.00001D.85911@shulabh> <40247C96.00001D.85911@shulabh>
Message-ID: <[email-masked]>

At 02:13 PM 2/7/2004 -0600, Matt Bradbury wrote:
>Is it even appropriate to be talking about congestion control at the DTN 
>layer?  I think congestion control needs to be implemented in a layer 
>above the pure DTN network.  Analogous to the way TCP is implemented over 
>IP.  IP will flat out drop packets in a congested network.  If you want 
>reliability you have to have the TCP overhead.

[Sorry, I missed this thread over the weekend and was too swamped this 
morning to contribute, and I'm now running out of time today.  I'll start 
here and respond to some of the later postings tomorrow.]

I agree that DTN congestion control needs to be implemented "above the pure 
DTN network" -- that is, above the forwarding in Bundling.  This would 
still be within Bundling though, because the DTN analogs to TCP are custody 
transfer and (optional) end-to-end retransmission, and these are services 
provided by Bundling itself.  They are notionally "above" the forwarding 
service of Bundling, but still part of the same protocol.  (We spent a long 
time discussing whether or not to split them out into a separate layer and 
the final decision was to be more modern and not so strictly and 
obsessively layered about everything.)

I'm also coming to believe that Bundling should drop bundles in a congested 
DTN the same way IP drops packets in a congested network.  This is not a 
good thing, of course, and we really want to configure DTN routers with 
enough buffer margin to minimize it (this is part of what I've been calling 
"structural flow control").  But it will under some circumstances be 
unavoidable, so we'd better understand what those circumstances are and how 
we're going to respond to them.

>But when we do implement congestion control, I think one of the things to 
>consider is that routers should be hefty enough to handle the sum of 
>traffic coming in on all links for the time it would take to send a 
>message back out to the sources of the congestion telling them to slow 
>down.  And I think the slow down messages should be as simple as "Your 
>sending data at 2 mbit/s  please throttle to 1 mbit/s"   Where 1 mbit/s is 
>a number that the router thinks it can handle in the time before another 
>round-trip of control messages could be exchanged to slow the rate down 
>even more.

Here I disagree.  I think using source-quench-like signals to effect 
explicit congestion control is not a good idea; I like the TCP/IP model 
better (okay, my understanding of it may be shaky; bear with me), that 
acknowledgement failure is interpreted as loss of data due to congestion 
and the sender responds by reducing the rate of transmission to that receiver.

Specifically, I think failure of custody transfer -- either implicit 
(custody timer expires) or explicit (receiver sends a custody transfer ack 
refusing custody, as I proposed in an email here a couple of weeks ago) -- 
is a darn good signal of possible congestion.  On detection of such a 
signal, I think the sender should locally and autonomously decide how 
severe the congestion is (the problem Durga has been working on) and what 
to do about it (a separate and equally thorny problem).

The advantage of developing and relying on this capability is that it is in 
any case necessary, and I think it's also sufficient.  It doesn't depend on 
information that it might in some circumstances never get, and it minimizes 
the need for Bundling to predict the future anywhere; it relies on emergent 
behavior, which (provided we've got as much margin as possible) is 
something I trust more than second-guessing the state of nodes that might 
be twenty light-minutes away.

>And then to make sure that UDP equivalent bundles don't still cause 
>congestion, I'd make those be the first to get dropped before dropping 
>bundles conforming to traffic congestion standards (TCP equivalent 
>bundles).  Inherent Quality of Service depending on what types of Bundles 
>you're sending.
>
>-Matt Bradbury
>
>p.s.  I'm working on a Java implementation of the internet-draft that 
>Scott Burleigh put out in January.  It has some work to go before I open 
>it up to everyone, but I hope that combined with the existing C code, we 
>can have a couple of test platforms to start testing our ideas on.

Wow, this is outstanding, Matt.

>p.p.s.  Has there been any discussion of the protocols for any of the 
>Convergence Layers?  Specifically over TCP sockets?

Both Keith Scott and I have implemented convergence-layer wrappers for TCP 
but they are unfortunately not yet interoperable.  Keith's may be somewhat 
documented, though.

Scott 

From: [email-masked] (Durga Prasad Pandey)
Date: Tue, 10 Feb 2004 00:06:08 +0530
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Message-ID: <[email-masked]>

'policy' meaning?

Srijan - The Ultimate Technical and Cultural Festival
www.srijan-ism.org

>From: Fred Baker <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked]
>Subject: Re: [dtn-interest] Recent thinking on Congestion/flow control     
>in IPN/DTN
>Date: Mon, 09 Feb 2004 04:37:01 -0800
>
>At 11:26 PM 2/8/2004, Durga Prasad Pandey wrote:
>>Our concern right now is: are these parameters independent of each other,
>>and are they sufficient? And how exactly should a node interpret them in
>>taking real world congestion/flow control decisions?
>
>I don't think we know, unless we also know the policy by which they are 
>used. I didn't see anything in that note about policy. Did I miss 
>something?
><< attach3 >>

_________________________________________________________________
Play the prediction game on MEZ. Win Sehwag’s autographed T-shirts. 
http://go.msnserver.com/IN/41491.asp Predict and win on myenjoyzone.com.

From: [email-masked] (Matt Bradbury)
Date: Mon, 09 Feb 2004 10:14:57 -0600
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Durga Prasad Pandey wrote:

>Matt,
>
>Your mail is interesting.
>
>One of the assumptions I started with, is that we'd like each node to take
>autonomous decisions regarding congestion. I hope you appreciate the fact
>that we cannot really keep a 'global knowledge' of the state of each node
>in the network, esp considering the fact the network itself is a set of
>constantly changing p2p links. What we could possibly have is some
>approximate knowledge of the topology etc.
>  
>
I have no intention of  having any kind of global knowledge when dealing 
with congestion.  But we should be able to chat with our neighbors and 
find out their condition.  If we know that our neighbor has gigabytes of 
data that it needs to offload to me, I'd like to know.  Especially if 
it's going to be tying up my resources for any period of time.  And 
vice-versa, if I've told my nextHop node that I've got a large queue for 
him and he doesn't ask me to back off, I have a confidence that that 
node can receive them.

>In an IPN type of DTN, the nodes would be more or less in contact with
>each other periodically, so it would be easier to have a 'sense' of what
>nodes the network consists of. But in a military battlefield network, it's
>all going to be random. But then again, the network could be told
>manually, perhaps, to expect soldier-nodes in particular areas.
>  
>
These are definitely opposite ends of the congestion issue.  One is 
well-ordered, with planned connections theoretically years in the future 
because of Newton and his Laws, whereas a battle will have a rapidly 
changing topology that needs constant rediscovery, retransmission and 
redundancy.  I would propose that these two situations could require 
completely different congestion control algorithms. 

Let's keep congestion control above the bundling layer, that way 
different algorithms can be used in different environments and to keep 
life easier with simple protocol stacks on all devices, and congestion 
control on the devices that need it.  You've already made this easy by 
requiring that each node make it's own decisions, how it makes decisions 
should not be for others to understand.

If we can agree on simple metrics to implement at the bundle layer, then 
those can be implemented by everyone and we can leave congestion control 
to the PhD candidates.

>Coming to your point now, you have suggested a sound set of metrics. But
>the question is, with the kind of delay that we expect in a DTN, can we
>afford to think that we'll have all this information available at  a node?
>Perhaps you might like to look up at the 3 metrics I mentioned in my first
>email, and give your opinion on their (un)suitability. 
>  
>
We'll never have enough information for perfect congestion control.  You 
mention this in your paper.  I see nothing wrong with you're paper on 
the surface, but we won't know until it gets into a running network with 
real-life problems.  Let's just make sure when we get there we're not 
tied too tightly to any one algorithm so that when we do have to tweak 
the congestion control  it won't kill us with incompatibilities.

I guess I've been network admin too long that I'm already getting bitter 
about small protocol tweaks wreaking havoc.

-Matt Bradbury

p.s.  I've implemented static routes in my router project and am able to 
get bundles to bounce between several nodes.  I hope to be releasing it 
on sourceforge in the next month or two.

From: [email-masked] (Fred Baker)
Date: Mon, 09 Feb 2004 04:37:01 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked] > <[email-masked]>
Message-ID: <[email-masked] >

--==-==-==-=-=-==-=-=====-=--===-=-=-=-=--=---=-=-
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:26 PM 2/8/2004, Durga Prasad Pandey wrote:
>Our concern right now is: are these parameters independent of each other,
>and are they sufficient? And how exactly should a node interpret them in
>taking real world congestion/flow control decisions?

I don't think we know, unless we also know the policy by which they are 
used. I didn't see anything in that note about policy. Did I miss something? 
--==-==-==-=-=-==-=-=====-=--===-=-=-=-=--=---=-=-
Content-Type: application/pgp-signature

--==-==-==-=-=-==-=-=====-=--===-=-=-=-=--=---=-=---

From: "Micah Beck" <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Feb 2004 14:13:21 -0500
Subject: [dtn-interest] CFP: 2nd  Intelligent Storage Workshop
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_2269_01C3EF16.DF787BC0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_226A_01C3EF16.DF787BC0"

------=_NextPart_001_226A_01C3EF16.DF787BC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Since the DTN architecture requires both mass storage and intelligence =
at forwarding nodes that might be embedded in a variety of extreme =
environments, could be interesting as an area of application for =
intelligent storage technologies, which is the topic of the upcoming 2nd =
Intelligent Storage Workshop (CFP attached).

Micah Beck
Associate Prof, Computer Science
University of Tennessee
---------------------------------------------------------

Call for Papers
Second Intelligent Storage Workshop
May 18-19, 2004

University of Minnesota
Digital Technology Center
Minneapolis, Minnesota
http://www.dtc.umn.edu

Sponsored by
IEEE Mass Storage Systems Technical Committee (pending)
University of Minnesota Digital Technology Center Intelligent Storage
Consortium (DISC)
SNIA Object-based Storage Technical Working Group

Submissions Due:                 February 28, 2004
Notification of Acceptance:  March 31, 2004
Final papers due:                  April 20, 2004
Papers submitted to:             [email-masked]

------=_NextPart_001_226A_01C3EF16.DF787BC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Since the DTN architecture requires =
both mass=20
storage and intelligence at forwarding nodes that might be embedded in a =
variety=20
of extreme environments, could be interesting&nbsp;as an area of =
application for=20
intelligent storage technologies, which is the topic of the =
upcoming&nbsp;2nd=20
Intelligent Storage Workshop (CFP attached).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Micah Beck</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Associate Prof, Computer =
Science</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>University of Tennessee</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>---------------------------------------------------------</FONT>=
</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Call for=20
Papers<BR>Second Intelligent Storage Workshop<BR>May 18-19,=20
2004<BR><BR>University of Minnesota<BR>Digital Technology =
Center<BR>Minneapolis,=20
Minnesota<BR></FONT><A href=3D"http://www.dtc.umn.edu"><FONT=20
face=3D"Times New Roman" =
size=3D3>http://www.dtc.umn.edu</FONT></A><BR><BR><FONT=20
face=3D"Times New Roman" size=3D3>Sponsored by<BR>IEEE Mass Storage =
Systems=20
Technical Committee (pending)<BR>University of Minnesota Digital =
Technology=20
Center Intelligent Storage<BR>Consortium (DISC)<BR>SNIA Object-based =
Storage=20
Technical Working Group<BR><BR>Submissions=20
Due:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
February 28, 2004<BR>Notification of Acceptance:&nbsp; March 31, =
2004<BR>Final=20
papers=20
due:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
April 20, 2004<BR>Papers submitted=20
to:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
</FONT><A href=3D"mailto:[email-masked]"><FONT face=3D"Times New =
Roman"=20
size=3D3>[email-masked]</FONT></A><BR></FONT></DIV></BODY></HTML>

------=_NextPart_001_226A_01C3EF16.DF787BC0--

------=_NextPart_000_2269_01C3EF16.DF787BC0
Content-Type: application/pdf;
	name="2-ISW.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="2-ISW.pdf"

------=_NextPart_000_2269_01C3EF16.DF787BC0--

Date: Mon, 09 Feb 2004 14:03:37 -0500
From: Srinivasan Keshav <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Canadian satellite to be a mailman in the sky
Sender: [email-masked]

Here are some pointers to an interesting news article about a LEO satellite
that will carry between 50 to 500 GB of data from point to point over the
globe.

http://www.globetechnology.com/servlet/ArticleNews/TPStory/LAC/20040207/SATE
LLITE07/TPTechnology/?query=satellite

http://www.canada.com/vancouver/vancouversun/news/business/story.html?id=604
8e8a7-09b9-4a97-8e61-fc60f146acf6

keshav

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 8 Feb 2004 23:41:32 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

--- Manikantan Ramadas <[email-masked]> wrote:

> I was wondering if it would be simpler (conceptually at least) to have 
> "Change in output rate" as the (3) parameter. One could come up with 
> scenarios where the acknowledgments from your peer node are coming in,
> but are
> are slower, bringing down your output rate. What do you think? 

> 
>   I also tend to think that data-abandonment-rate could be a useful 4th
> parameter to have. I see it as a way of keeping a history of our past
> congestion control decisions.
> 

Mani, "Change in input rate" is important because it could give us a
warning of a burst coming into a node. I think parameter 3 is independent
of 2, and it is a significant parameter, for reasons I have outlined in my
first mail. I think the output rate is itself incorporated in parameter 3,
and therefore, we do not need to consider "change of output rate" as a
separate parameter. 

I think "Data abandonment rate" can simply be interpreted from a negative
value of "time for buffer fill". But I am not completely sure if the two
parameters are orthogonal, or if parameter 3 is sufficient enough to
justify the exclusion of "Data abandonment rate" as a 4th parameter. Your
suggestion of adding it as a 4th parameter could very much be justified.
Let's see what other think of it.

> I figured people in the list were wondering about work on convergence
> layers. I have been working with Mr.Burleigh on updating the Licklider
> Transmission Protocol (aka Long-haul Transmission Protocol) draft. It
> is almost done and should probably be done pretty soon. While working
> on this draft, we were wondering about using a RED (Random Early
> Detection) based scheme for DTN congestion control.

RED(or a customised version of it) looks like a good idea to me, and I
have also been thinking along these lines for a while. Perhaps the kind of
congestion alert system we are trying to develop with the above 3/4
parameters could very much turn out to be some form of RED.

> 
> Well, the parameters we discussed above solve the problem of
> buffer-space over-run. But they don't address the problem of one flow
> monopolizing the buffer space in a router. I was wondering about the
> applicability of RED based schemes being used in IP routers in the
> Internet that probabilistically drop packets when the buffer-space
> utilization crosses the upper water-mark, based on the percentage of
> buffer-space being used by a particular flow. In other words, the
> greater the percentage of buffer space used by a flow, the greater
> is the probability of it losing packets (whenever the buffer-space
> utliziation crosses an upper threshold). The above argument for a
> per-flow
> scheme can also be extended to per-link basis if we are worried about
> 5 links feeding into our border DTN router and we were interested in
> keeping one link from monopolizing the single outbound queue.

The idea of multiple source and destinations linked to a DTN node makes
the problems much much complex. I am trying to figure out an analysis of
such a system. Prof Kleinrock of UCLA has, I believe, done some analysis
of such systems, and I am trying to see if we could use it to develop a
model in the DTN-domain.

Durga

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 8 Feb 2004 23:26:21 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control    in IPN/DTN
In-Reply-To: <[email-masked] >
Message-ID: <[email-masked]>

Yes, that makes a lot of sense. In fact, we are trying to come up with a
set of independent parameters(that includes available buffer space -- see
the first email in this thread) that could be used for taking such
decisions.

Our concern right now is: are these parameters independent of each other,
and are they sufficient? And how exactly should a node interpret them in
taking real world congestion/flow control decisions?

Durga

--- Fred Baker <[email-masked]> wrote:
> At 11:12 PM 2/8/2004, Durga Prasad Pandey wrote:
> >>that might be as simple as "I have 12 Terabytes of space left".
> >
> >And  in case there are multiple senders?
> 
> At that point I need to understand the policies involved. An obvious
> policy 
> would be "I have <> for each of my neighbors to fill with what they send
> 
> me", and the comment here becomes "I have <> left for you". Or, perhaps
> (as 
> is done in email systems) "I have <> of space for each of my neighbors
> for 
> waiting data", and the message becomes "I could not accept custodial 
> responsibility for the message you just sent me because I lacked memory
> to 
> store it", or some such. If it is a more complex policy, it may need a
> more 
> complex statement.
> 
> We need to understand the policies in view before we can go very far
> down 
> that path. 

> ATTACHMENT part 2 application/pgp-signature 

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Fred Baker)
Date: Sun, 08 Feb 2004 23:21:04 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked] > <[email-masked]>
Message-ID: <[email-masked] >

---=----==-=--==--=--=-====---=--==--=-=-===-=-=--
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:12 PM 2/8/2004, Durga Prasad Pandey wrote:
>>that might be as simple as "I have 12 Terabytes of space left".
>
>And  in case there are multiple senders?

At that point I need to understand the policies involved. An obvious policy 
would be "I have <> for each of my neighbors to fill with what they send 
me", and the comment here becomes "I have <> left for you". Or, perhaps (as 
is done in email systems) "I have <> of space for each of my neighbors for 
waiting data", and the message becomes "I could not accept custodial 
responsibility for the message you just sent me because I lacked memory to 
store it", or some such. If it is a more complex policy, it may need a more 
complex statement.

We need to understand the policies in view before we can go very far down 
that path. 
---=----==-=--==--=--=-====---=--==--=-=-===-=-=--
Content-Type: application/pgp-signature

---=----==-=--==--=--=-====---=--==--=-=-===-=-=----

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 8 Feb 2004 23:19:48 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Bob,

This idea appeals to me very much. The idea of having a node to
share/offload data at critical times had occured to me before, but because
I tend to think in terms of IPN whenever I am thinking of DTN, I had
always felt unsure about voicing it. IPN would have constrained resources,
and I wasn't sure if we could have the privelege of considering this idea.

Rolling custodians sounds like a very good idea, though the catastrophe
could hit the current custodian itself. But I suppose it might, with
proper design, have a good probability of escaping catastrophes(I like the
word ;) ). 

Durga

--- "Robert C. Durst" <[email-masked]> wrote:
> 
> >
> >  2) A node that is the custodian for a bundle suffers a catastrophic 
> > failure.  This could be mitigated by keeping 'rolling custodians', 
> > something I've thought of a bit but haven't fully worked out.  The 
> > notion would be that there are at any given time n custodians, and 
> > when a new node takes custody, it releases the 'furthest back'
> custodian.
> 
> I recall that we discussed this before, briefly.  I think when we 
> floated the idea before, the notion was to maintain two ordered 
> custodians (but it could be "n" custodians), and a prospective custodian
> 
> would accept custody from the one that was first in the list (had 
> accepted custody earliest).  This would make the chain of custody "one 
> catastrophe tolerant," assuming adequate routing flexibility to detect 
> and route around the catastrophic loss of what had been previously the 
> "next hop" custodian.  I believe that we decided not to pursue it based 
> on the marginal percieved utility, the added complexity to the bundle 
> header, and the availability of an end-to-end ack/retransmission.  Just 
> not enough bang for the buck.  If there's a compelling case, it's still 
> an option, but it makes the bundle header bigger and more complex.
> 
> Regards,
> Bob Durst
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 8 Feb 2004 23:12:03 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control   in IPN/DTN
In-Reply-To: <[email-masked] >
Message-ID: <[email-masked]>

--- Fred Baker <[email-masked]> wrote:
>that might be as simple as "I have
> 12 
> Terabytes of space left". 

And  in case there are multiple senders?

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 8 Feb 2004 23:06:36 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

--- "Scott,Keith L." <[email-masked]> wrote:
> There are really three levels at which reliability can be imposed.  They
> 
> are (from the bottom up)
> 
> 1) At the 'convergence layer' (the transport layer used between bundle 
> routers).  This may be TCP, UDP, UDP+FEC, etc.  Generally speaking, we'd
> 
> like convergence layers to be as reliable as possible, but even a 'fully
> 
> reliable' convergence layer like TCP isn't as good as a bundle-layer 
> acknowledgemnt.  A question remains as to what are the actual 
> requirements (if any) on a convergence layer wrt reliability.  I tend to
> 
> think that there can't be any, since I'd like to admit the possibility 
> of unacknowledged UDP (or something like it) for situations when the 
> next hop can't transmit (policy, broken transmitter, etc.)

Keith, I am not sure if the convergence layer is the lowest layer at which
we should have reliability. I suppose it is the link layer at which we
should have strong reliability mechanisms.

Now, consider the IPN backbone. Can you have reliability *at all* at the
convergence layer in this case? In such a scenario, IMO, bundling doesn't
complement TCP/UDP, it replaces them. If TCP was good enough, we wouldn't
need bundling in the first place, right?

I actually just do not understand the need for UDP in an IPN-like DTN when
we have bundling. 

> 
> 2) Custody tranfser.  Custody transfer involves bundle 
> (application)-layer acknowledgemnts that data have been received.  In 
> addition, a node receiving a bundle with the custody bit set doesn't 
> have to take custody (say if it doesn't have the resources to do so).  
> It may simply forward the bundle (leaving the custody bit set) in the 
> hopes that somebody downstream can take custody (and inform the bundle's
> 
> current custodian).  Because of this, simply transmitting a bundle with 
> the custody bit set via a reliable convergence layer isn't the same as 
> passing the custody buck.
> 
> The only ways custody transfer should be able to fail should be:
>   1) The bundle times out before reaching its destination (danger of 
> routing loops causing this)
>   2) A node that is the custodian for a bundle suffers a catastrophic 
> failure.  This could be mitigated by keeping 'rolling custodians', 
> something I've thought of a bit but haven't fully worked out.  The 
> notion would be that there are at any given time n custodians, and when 
> a new node takes custody, it releases the 'furthest back' custodian.

I Agree.

> 
> 3) End-to-end acknowledgements.  One of the things an application can 
> request is an end-to-end acknowledgement that a bundle has actually been
> 
> delivered to a peer application on the other end.  This is a slightly 
> stronger indication that data has been passed than is available via TCP,
> 
> though still not as good as an acknowledgement generated by the 
> receiving application.  It also requires a large commitment of resources
> 
> at the source to buffer the data.

Exactly. And as you pointed out, it is more of a special reliability
mechanism that a regular one.

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Fred Baker)
Date: Sun, 08 Feb 2004 22:55:30 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked] > <[email-masked]>
Message-ID: <[email-masked] >

--=-=--==-===-==-=-==-=-==---====-=-=--=-----=-=-=
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:31 PM 2/8/2004, Durga Prasad Pandey wrote:
>The crucial difference between this mechanism and what we use in the 
>Internet is that in the latter, we do not store copies of packets at 
>intermediate nodes -- they are retransmitted(as and when required) from 
>the source itself. So, yes, I do think this increases reliability, though 
>as Keith has pointed out, there are other mechanisms for reliability as well.

Well, correct me if I am wrong, but I think you're a layer above TCP. TCP 
might be used within a network to ensure that a message gets from one 
custodian to another; if not TCP, then some other transport would be used. 
But TCP (if it is used) then delivers the mesage to someone, and that 
someone decides (a) that it is now the custodian and (b) what to do with 
the message, often deciding to forward it to another custodian.

The obvious analogy isn't to TCP-as-a-special-case-of-a-transport, it is to 
SMTP-as-a-special-case-of-a-relay. The thing with SMTP is that it doesn't 
do what you said above - reliability is always the province of the 
custodian (one of potentially many MTAs en route) as opposed to the 
originator. The originator has a reliability role, I suppose, but it is not 
in the mail protocol. Rather, if the user doesn't get a response within a 
few days and wanted one, he sends a follow-up email.

If what we are discussing is a relay layer that accepts interesting delays, 
in the sense that SMTP implements such a layer, for such applications as 
file transfer and so on, it seems to me that a similar model has value. You 
decide that the probability of a catastrophe happening to one of the relays 
is acceptably low, and put the relays into the position of being 
responsible for the delivery of their traffic to the next relay.

As to congestion, it seems to me that the question here might be the 
availability and capability of the relay. If a relaying custodian can 
advise the previous custodian that it has accepted custodial 
responsibilities, it seems that it should be able to also indicate (in the 
same message) how much capacity it has remaining under its policy with 
respect to this previous hop. If, for example, it is a dedicated relay for 
that previous hop (it is orbiting the Earth and is a relay point for a 
specific Mars mission, for example), that might be as simple as "I have 12 
Terabytes of space left". If it has several possible previous hops, it has 
a more complicated statement to make, but it seems that it should boil down 
to "as long as you don't send me more than ____, I will receive it, store 
it, and relay it on when I have the opportunity". The question after that 
might be "what policy does the sender have for that information" and "what 
capabilities might it have to effect that policy". If its policy is 
"overwrite old stuff even if it is unforwarded", it might want to be able 
to command its next custodian  to "delete enough of my oldest stuff to 
allow me to send you a new file of size <...>". If it believes that older 
stuff is sacrosanct, then it might need to push back itself. Or, it might 
be able to re-route. 
--=-=--==-===-==-=-==-=-==---====-=-=--=-----=-=-=
Content-Type: application/pgp-signature

--=-=--==-===-==-=-==-=-==---====-=-=--=-----=-=-=--

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 8 Feb 2004 22:43:06 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Matt,

Your mail is interesting.

One of the assumptions I started with, is that we'd like each node to take
autonomous decisions regarding congestion. I hope you appreciate the fact
that we cannot really keep a 'global knowledge' of the state of each node
in the network, esp considering the fact the network itself is a set of
constantly changing p2p links. What we could possibly have is some
approximate knowledge of the topology etc.

In an IPN type of DTN, the nodes would be more or less in contact with
each other periodically, so it would be easier to have a 'sense' of what
nodes the network consists of. But in a military battlefield network, it's
all going to be random. But then again, the network could be told
manually, perhaps, to expect soldier-nodes in particular areas.

Coming to your point now, you have suggested a sound set of metrics. But
the question is, with the kind of delay that we expect in a DTN, can we
afford to think that we'll have all this information available at  a node?
Perhaps you might like to look up at the 3 metrics I mentioned in my first
email, and give your opinion on their (un)suitability. 

Durga
PS: You might like to look at www.geocities.com/dpsmiles/Report4.1.pdf for
a brief overview of the basic ideas and assumptions I have been working
on.

--- Matt Bradbury <[email-masked]> wrote:
> Durga Prasad Pandey wrote:
> 
> >
> > Yes, one would need to throttle sometimes. And the throttle will have 
> > to be hop by hop for obvious reasons. That raises the possibility of 
> > deadlock. Besides, from the experience of Internet pioneers, we know 
> > that flow control can be an extremely tricky problem, and there can 
> > be, and I strongly believe, will be, many unexpected complications. 
> > Particularly in a network such as DTN. Also, the decision to throttle 
> > and the rate at which data reception is allowed at a node may have to 
> > be calculated in advance, based on expectations, and that complicates 
> > the problem a lot more. As I pointed out in my last mail, it can't be 
> > a yes/no boolean. We need to use something like fuzzy logic for this.
> >
> > So, as you must have realised, we are looking at a complex bunch of 
> > sources sending data at rates which has to be figured out and 
> > decisions taken. As Scott has pointed out, mistakes are going to be 
> > inevitable. That's one of the biggest reasons why we are determined to
> 
> > push machine-learning based mechanisms for congestion 
> > detection/control. That way, at least the network gets one benefit 
> > from mistakes -- it learns from them. That looks like one big benefit 
> > to me.
> >
> Alright, I agree on most of your points, I may have wrote that mail in a
> 
> bit of naive haste.  But maybe what we should focus on now is 
> determining a good set of metrics that should be passed between nodes 
> that will help the congestion control engines.  If we can standardize on
> 
> the metrics and basic commands early, then the congestion control 
> methodologies can evolve above the DTN/Bundling standard.
> 
> Here's a few thoughts on the types of messaging that could be useful to 
> the congestion control engines.
> 
> Things I'd like to know from other nodes:
>   Current queue size coming towards me.
>   Current rate that the queue is growing or shrinking 
>   Requests to send at higher rates -- steady and burst
>   Expected unavailability ( bleeding over to dynamic routing land )
> 
> Things I'd like to command other nodes to do:
>   Set connection speed
>   Set burst speed/duration
> 
> Things I'd like to command the admin for the node to do:
>   Get me more buffer space!!
>   Get me faster connections!!
> 
> 
> Have a good Sunday everyone.
> 
> -Matt Bradbury
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 8 Feb 2004 22:31:21 -0800 (PST)
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked] >
Message-ID: <[email-masked]>

Fred,

I suspect I used 'reliability' in a somewhat liberal way. Taking custody
in a DTN implies a custodial node storing a copy of the bundle, and
sending a message to the last custodian to free its resources(storage) by
deleting the copy of this bundle it's holding on to. 

Does it push the point of retransmission forward? -- Yes, without doubt.
The crucial difference between this mechanism and what we use in the
Internet is that in the latter, we do not store copies of packets at
intermediate nodes -- they are retransmitted(as and when required) from
the source itself. So, yes, I do think this increases reliability, though
as Keith has pointed out, there are other mechanisms for reliability as
well.

I prefer to refrain from making comparisions with TCP/SMTP because it
leads to discussions without no visible conclusion. But I would be happy
to clarify my statement further if you have any doubts.

Durga

--- Fred Baker <[email-masked]> wrote:
> At 08:33 PM 2/7/2004, Durga Prasad Pandey wrote:
> >Custody transfer provides reliability for packets that really need it,
> and 
> >pushes the point of retransmission towards the destination.
> 
> I'm not convinced I believe that. Perhaps I don't understand it?
> 
> When we talk about "custody" in other contexts, it refers to someone
> taking 
> responsibility for delivering something, taking care of something, or
> doing 
> something. If I take custody of a child, I am responsible for the
> child's 
> well-being. If I take custody of a prisoner, I am responsible that the 
> prisoner is treated in a lawful manner and remains a prisoner.
> 
> If I take custody of your transmission, I think I am responsible to
> ensure 
> that it safely arrives at the next custody point, and to pass custody to
> 
> that transfer point explicitly. I no longer have custody of the 
> transmission when the next transfer point informs me that it has taken 
> custody of it.
> 
> There is an end to end issue, of course. If I hand custody of your 
> transmission to someone else, they assume it, and then they are
> destroyed 
> or otherwise rendered inoperative, the original sender may need to 
> retransmit; I'm not going to. I'll argue that this sort of end to end 
> function is not greatly different than the end to end function provided
> by 
> the application that uses TCP in today's internet, which may open or 
> attempt to open successive TCP sessions until it gets its work
> accomplished.
> 
> But if I am thinking of custody transfer in the sense that an SMTP
> mailgram 
> works, at minimum I use a reliable transport (TCP) and take every
> rational 
> precaution to ensure that TCP and the SMTP application believe that the 
> email was in fact delivered to the next custody holder. I should think
> the 
> same reasoning would apply to any such communication function.
> 
> It sounds like you disagree. Please advise? 

> ATTACHMENT part 2 application/pgp-signature 

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

From: [email-masked] (Manikantan Ramadas)
Date: Sun, 8 Feb 2004 23:17:07 -0500
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <40247C96.00001D.85911@shulabh>
References: <40247C96.00001D.85911@shulabh>
Message-ID: <[email-masked]>

Hi Durga,

  Nice to read on your ideas on congestion control. Well, I see that 
you propose 3 basic parameters for the cognition based congestion ctrl. 
engine algorithm :

  (1) Available buffer space
  (2) Change in input rate
  (3) Time for buffer fill = Available buffer space / 
    	     	           (Current input rate - Current output rate)

  I find that (3) is dependent on (1) and (2) besides the current output rate.
I was wondering if it would be simpler (conceptually at least) to have 
"Change in output rate" as the (3) parameter. One could come up with 
scenarios where the acknowledgments from your peer node are coming in, but are
are slower, bringing down your output rate. What do you think? 

  I also tend to think that data-abandonment-rate could be a useful 4th
parameter to have. I see it as a way of keeping a history of our past
congestion control decisions.

I figured people in the list were wondering about work on convergence
layers. I have been working with Mr.Burleigh on updating the Licklider
Transmission Protocol (aka Long-haul Transmission Protocol) draft. It
is almost done and should probably be done pretty soon. While working
on this draft, we were wondering about using a RED (Random Early
Detection) based scheme for DTN congestion control.

Well, the parameters we discussed above solve the problem of
buffer-space over-run. But they don't address the problem of one flow
monopolizing the buffer space in a router. I was wondering about the
applicability of RED based schemes being used in IP routers in the
Internet that probabilistically drop packets when the buffer-space
utilization crosses the upper water-mark, based on the percentage of
buffer-space being used by a particular flow. In other words, the
greater the percentage of buffer space used by a flow, the greater
is the probability of it losing packets (whenever the buffer-space
utliziation crosses an upper threshold). The above argument for a per-flow
scheme can also be extended to per-link basis if we are worried about
5 links feeding into our border DTN router and we were interested in
keeping one link from monopolizing the single outbound queue.

- Mani.

-- 
"All you have to decide is what to do
with the time that is given to you" - Gandalf, Lord of the Rings.
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

From: [email-masked] (Robert C. Durst)
Date: Sun, 08 Feb 2004 16:49:07 -0500
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked] > <[email-masked]>
Message-ID: <[email-masked]>

>
>  2) A node that is the custodian for a bundle suffers a catastrophic 
> failure.  This could be mitigated by keeping 'rolling custodians', 
> something I've thought of a bit but haven't fully worked out.  The 
> notion would be that there are at any given time n custodians, and 
> when a new node takes custody, it releases the 'furthest back' custodian.

I recall that we discussed this before, briefly.  I think when we 
floated the idea before, the notion was to maintain two ordered 
custodians (but it could be "n" custodians), and a prospective custodian 
would accept custody from the one that was first in the list (had 
accepted custody earliest).  This would make the chain of custody "one 
catastrophe tolerant," assuming adequate routing flexibility to detect 
and route around the catastrophic loss of what had been previously the 
"next hop" custodian.  I believe that we decided not to pursue it based 
on the marginal percieved utility, the added complexity to the bundle 
header, and the availability of an end-to-end ack/retransmission.  Just 
not enough bang for the buck.  If there's a compelling case, it's still 
an option, but it makes the bundle header bigger and more complex.

Regards,
Bob Durst

From: [email-masked] (Scott,Keith L.)
Date: Sun, 08 Feb 2004 15:58:45 -0500
Subject: [dtn-interest] Recent thinking on Congestion/flow control  in IPN/DTN
In-Reply-To: <[email-masked] >
References: <[email-masked]> <[email-masked] >
Message-ID: <[email-masked]>

There are really three levels at which reliability can be imposed.  They 
are (from the bottom up)

1) At the 'convergence layer' (the transport layer used between bundle 
routers).  This may be TCP, UDP, UDP+FEC, etc.  Generally speaking, we'd 
like convergence layers to be as reliable as possible, but even a 'fully 
reliable' convergence layer like TCP isn't as good as a bundle-layer 
acknowledgemnt.  A question remains as to what are the actual 
requirements (if any) on a convergence layer wrt reliability.  I tend to 
think that there can't be any, since I'd like to admit the possibility 
of unacknowledged UDP (or something like it) for situations when the 
next hop can't transmit (policy, broken transmitter, etc.)

2) Custody tranfser.  Custody transfer involves bundle 
(application)-layer acknowledgemnts that data have been received.  In 
addition, a node receiving a bundle with the custody bit set doesn't 
have to take custody (say if it doesn't have the resources to do so).  
It may simply forward the bundle (leaving the custody bit set) in the 
hopes that somebody downstream can take custody (and inform the bundle's 
current custodian).  Because of this, simply transmitting a bundle with 
the custody bit set via a reliable convergence layer isn't the same as 
passing the custody buck.

The only ways custody transfer should be able to fail should be:
  1) The bundle times out before reaching its destination (danger of 
routing loops causing this)
  2) A node that is the custodian for a bundle suffers a catastrophic 
failure.  This could be mitigated by keeping 'rolling custodians', 
something I've thought of a bit but haven't fully worked out.  The 
notion would be that there are at any given time n custodians, and when 
a new node takes custody, it releases the 'furthest back' custodian.

3) End-to-end acknowledgements.  One of the things an application can 
request is an end-to-end acknowledgement that a bundle has actually been 
delivered to a peer application on the other end.  This is a slightly 
stronger indication that data has been passed than is available via TCP, 
though still not as good as an acknowledgement generated by the 
receiving application.  It also requires a large commitment of resources 
at the source to buffer the data.

I generally think of custody transfer as the 'main' reliability 
mechanism within bundling, with end-to-end acknowledgements a fallback 
for really critical data.

The above doesn't really have much to do with flow/congestion control.  
I liked Matt's lists of information / control signals he'd like; I'm 
just not currently spun up on control theory enough to know what the 
communications requirements would be in order to make such a system stable.

       --keith

Fred Baker wrote:

> At 08:33 PM 2/7/2004, Durga Prasad Pandey wrote:
>
>> Custody transfer provides reliability for packets that really need 
>> it, and pushes the point of retransmission towards the destination.
>
>
> I'm not convinced I believe that. Perhaps I don't understand it?
>
> When we talk about "custody" in other contexts, it refers to someone 
> taking responsibility for delivering something, taking care of 
> something, or doing something. If I take custody of a child, I am 
> responsible for the child's well-being. If I take custody of a 
> prisoner, I am responsible that the prisoner is treated in a lawful 
> manner and remains a prisoner.
>
> If I take custody of your transmission, I think I am responsible to 
> ensure that it safely arrives at the next custody point, and to pass 
> custody to that transfer point explicitly. I no longer have custody of 
> the transmission when the next transfer point informs me that it has 
> taken custody of it.
>
> There is an end to end issue, of course. If I hand custody of your 
> transmission to someone else, they assume it, and then they are 
> destroyed or otherwise rendered inoperative, the original sender may 
> need to retransmit; I'm not going to. I'll argue that this sort of end 
> to end function is not greatly different than the end to end function 
> provided by the application that uses TCP in today's internet, which 
> may open or attempt to open successive TCP sessions until it gets its 
> work accomplished.
>
> But if I am thinking of custody transfer in the sense that an SMTP 
> mailgram works, at minimum I use a reliable transport (TCP) and take 
> every rational precaution to ensure that TCP and the SMTP application 
> believe that the email was in fact delivered to the next custody 
> holder. I should think the same reasoning would apply to any such 
> communication function.
>
> It sounds like you disagree. Please advise? 

From: [email-masked] ([email-masked])
Date: Mon, 9 Feb 2004 00:37:24 +0900
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked] >
References: <[email-masked]> <[email-masked] >
Message-ID: <[email-masked]>

This matches my understanding.  Once custody is passed, the old custody 
holder is relieved of the re-transmission responsibility.

a.

On 8 feb 2004, at 17.02, Fred Baker wrote:

> At 08:33 PM 2/7/2004, Durga Prasad Pandey wrote:
>> Custody transfer provides reliability for packets that really need 
>> it, and pushes the point of retransmission towards the destination.
>
> I'm not convinced I believe that. Perhaps I don't understand it?
>
> When we talk about "custody" in other contexts, it refers to someone 
> taking responsibility for delivering something, taking care of 
> something, or doing something. If I take custody of a child, I am 
> responsible for the child's well-being. If I take custody of a 
> prisoner, I am responsible that the prisoner is treated in a lawful 
> manner and remains a prisoner.
>
> If I take custody of your transmission, I think I am responsible to 
> ensure that it safely arrives at the next custody point, and to pass 
> custody to that transfer point explicitly. I no longer have custody of 
> the transmission when the next transfer point informs me that it has 
> taken custody of it.
>
> There is an end to end issue, of course. If I hand custody of your 
> transmission to someone else, they assume it, and then they are 
> destroyed or otherwise rendered inoperative, the original sender may 
> need to retransmit; I'm not going to. I'll argue that this sort of end 
> to end function is not greatly different than the end to end function 
> provided by the application that uses TCP in today's internet, which 
> may open or attempt to open successive TCP sessions until it gets its 
> work accomplished.
>
> But if I am thinking of custody transfer in the sense that an SMTP 
> mailgram works, at minimum I use a reliable transport (TCP) and take 
> every rational precaution to ensure that TCP and the SMTP application 
> believe that the email was in fact delivered to the next custody 
> holder. I should think the same reasoning would apply to any such 
> communication function.
>
> It sounds like you disagree. Please advise? 

From: [email-masked] (Matt Bradbury)
Date: Sun, 08 Feb 2004 02:06:40 -0600
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Durga Prasad Pandey wrote:

>
> Yes, one would need to throttle sometimes. And the throttle will have 
> to be hop by hop for obvious reasons. That raises the possibility of 
> deadlock. Besides, from the experience of Internet pioneers, we know 
> that flow control can be an extremely tricky problem, and there can 
> be, and I strongly believe, will be, many unexpected complications. 
> Particularly in a network such as DTN. Also, the decision to throttle 
> and the rate at which data reception is allowed at a node may have to 
> be calculated in advance, based on expectations, and that complicates 
> the problem a lot more. As I pointed out in my last mail, it can't be 
> a yes/no boolean. We need to use something like fuzzy logic for this.
>
> So, as you must have realised, we are looking at a complex bunch of 
> sources sending data at rates which has to be figured out and 
> decisions taken. As Scott has pointed out, mistakes are going to be 
> inevitable. That's one of the biggest reasons why we are determined to 
> push machine-learning based mechanisms for congestion 
> detection/control. That way, at least the network gets one benefit 
> from mistakes -- it learns from them. That looks like one big benefit 
> to me.
>
Alright, I agree on most of your points, I may have wrote that mail in a 
bit of naive haste.  But maybe what we should focus on now is 
determining a good set of metrics that should be passed between nodes 
that will help the congestion control engines.  If we can standardize on 
the metrics and basic commands early, then the congestion control 
methodologies can evolve above the DTN/Bundling standard.

Here's a few thoughts on the types of messaging that could be useful to 
the congestion control engines.

Things I'd like to know from other nodes:
  Current queue size coming towards me.
  Current rate that the queue is growing or shrinking 
  Requests to send at higher rates -- steady and burst
  Expected unavailability ( bleeding over to dynamic routing land )

Things I'd like to command other nodes to do:
  Set connection speed
  Set burst speed/duration

Things I'd like to command the admin for the node to do:
  Get me more buffer space!!
  Get me faster connections!!

Have a good Sunday everyone.

-Matt Bradbury

From: [email-masked] (Fred Baker)
Date: Sun, 08 Feb 2004 00:02:37 -0800
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked] >

--==---=-=-=--===--==-----====--==-==-===--------=
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:33 PM 2/7/2004, Durga Prasad Pandey wrote:
>Custody transfer provides reliability for packets that really need it, and 
>pushes the point of retransmission towards the destination.

I'm not convinced I believe that. Perhaps I don't understand it?

When we talk about "custody" in other contexts, it refers to someone taking 
responsibility for delivering something, taking care of something, or doing 
something. If I take custody of a child, I am responsible for the child's 
well-being. If I take custody of a prisoner, I am responsible that the 
prisoner is treated in a lawful manner and remains a prisoner.

If I take custody of your transmission, I think I am responsible to ensure 
that it safely arrives at the next custody point, and to pass custody to 
that transfer point explicitly. I no longer have custody of the 
transmission when the next transfer point informs me that it has taken 
custody of it.

There is an end to end issue, of course. If I hand custody of your 
transmission to someone else, they assume it, and then they are destroyed 
or otherwise rendered inoperative, the original sender may need to 
retransmit; I'm not going to. I'll argue that this sort of end to end 
function is not greatly different than the end to end function provided by 
the application that uses TCP in today's internet, which may open or 
attempt to open successive TCP sessions until it gets its work accomplished.

But if I am thinking of custody transfer in the sense that an SMTP mailgram 
works, at minimum I use a reliable transport (TCP) and take every rational 
precaution to ensure that TCP and the SMTP application believe that the 
email was in fact delivered to the next custody holder. I should think the 
same reasoning would apply to any such communication function.

It sounds like you disagree. Please advise? 
--==---=-=-=--===--==-----====--==-==-===--------=
Content-Type: application/pgp-signature

--==---=-=-=--===--==-----====--==-==-===--------=--

From: [email-masked] (Durga Prasad Pandey)
Date: Sun, 08 Feb 2004 10:03:03 +0530
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Message-ID: <[email-masked]>

>From: Matt Bradbury <[email-masked]>

>Is it even appropriate to be talking about congestion control at the DTN 
>layer?

By DTN layer, do you mean the 'bundling layer'?

 >I think congestion control needs to be implemented in a
>layer above the pure DTN network.  Analogous to the way TCP is implemented 
>over IP.  IP will flat out drop packets in a congested network.  If you 
>want reliability you have to have the TCP overhead.

Custody transfer provides reliability for packets that really need it, and 
pushes the point of retransmission towards the destination.

>
>But when we do implement congestion control, I think one of the things to 
>consider is that routers should be hefty enough to handle the sum of 
>traffic coming in on all links for the time it would take to send a message 
>back out to the sources of the congestion telling them to slow down.  And I 
>think the slow down messages should be as simple as "Your sending data at 2 
>mbit/s  please throttle to 1 mbit/s"   Where 1 mbit/s is a number that the 
>router thinks it can handle in the time before another round-trip of 
>control messages could be exchanged to slow the rate down even more.

Yes, one would need to throttle sometimes. And the throttle will have to be 
hop by hop for obvious reasons. That raises the possibility of deadlock. 
Besides, from the experience of Internet pioneers, we know that flow control 
can be an extremely tricky problem, and there can be, and I strongly 
believe, will be, many unexpected complications. Particularly in a network 
such as DTN. Also, the decision to throttle and the rate at which data 
reception is allowed at a node may have to be calculated in advance, based 
on expectations, and that complicates the problem a lot more. As I pointed 
out in my last mail, it can't be a yes/no boolean. We need to use something 
like fuzzy logic for this.

So, as you must have realised, we are looking at a complex bunch of sources 
sending data at rates which has to be figured out and decisions taken. As 
Scott has pointed out, mistakes are going to be inevitable. That's one of 
the biggest reasons why we are determined to push machine-learning based 
mechanisms for congestion detection/control. That way, at least the network 
gets one benefit from mistakes -- it learns from them. That looks like one 
big benefit to me.

>
>And then to make sure that UDP equivalent bundles don't still cause 
>congestion, I'd make those be the first to get dropped before dropping 
>bundles conforming to traffic congestion standards (TCP equivalent 
>bundles).  Inherent Quality of Service depending on what types of Bundles 
>you're sending.

Exactly. COS takes care of that, though I can think of possible conflicts 
even there. For instance, should a newly arrived bundle with higher COS be 
dropped giving preference to a lower COS bundle that has stayed on longer 
and whose TTL is much lower. Such decisions are, I presume, not going to be 
easy. If a bundle doesn't demand custody, it might still be important in 
other ways. Besides, it cannot be retransmitted from the last 
custodian--there is no last custodian for it-- unlike the custody seeking 
bundles.

>
>p.p.s.  Has there been any discussion of the protocols for any of the 
>Convergence Layers?  Specifically over TCP sockets?

>From what I know, there hasn't been any significant discussion on the 
convergence layer. Good that you mentioned it; perhaps it's time we started 
thinking of it.

_________________________________________________________________
Gifts for Him & Her. Valentine’s Day.  http://go.msnserver.com/IN/42197.asp 
At MSN Shopping.

From: [email-masked] (Matt Bradbury)
Date: Sat, 07 Feb 2004 14:13:55 -0600
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
In-Reply-To: <40247C96.00001D.85911@shulabh>
References: <40247C96.00001D.85911@shulabh>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------070405080500010305060006
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Is it even appropriate to be talking about congestion control at the DTN 
layer?  I think congestion control needs to be implemented in a layer 
above the pure DTN network.  Analogous to the way TCP is implemented 
over IP.  IP will flat out drop packets in a congested network.  If you 
want reliability you have to have the TCP overhead.

But when we do implement congestion control, I think one of the things 
to consider is that routers should be hefty enough to handle the sum of 
traffic coming in on all links for the time it would take to send a 
message back out to the sources of the congestion telling them to slow 
down.  And I think the slow down messages should be as simple as "Your 
sending data at 2 mbit/s  please throttle to 1 mbit/s"   Where 1 mbit/s 
is a number that the router thinks it can handle in the time before 
another round-trip of control messages could be exchanged to slow the 
rate down even more.

And then to make sure that UDP equivalent bundles don't still cause 
congestion, I'd make those be the first to get dropped before dropping 
bundles conforming to traffic congestion standards (TCP equivalent 
bundles).  Inherent Quality of Service depending on what types of 
Bundles you're sending.

-Matt Bradbury

p.s.  I'm working on a Java implementation of the internet-draft that 
Scott Burleigh put out in January.  It has some work to go before I open 
it up to everyone, but I hope that combined with the existing C code, we 
can have a couple of test platforms to start testing our ideas on.

p.p.s.  Has there been any discussion of the protocols for any of the 
Convergence Layers?  Specifically over TCP sockets?

Durga Prasad Pandey wrote:

> Hi DTN-fans,
>
>  
>
> I have had some interesting discussions with Scott Burleigh, Chris 
> Ramming, and Prof Len Kleinrock recently, and I felt (rather 
> thoughtfully..) that it was time I gave an update to this group. Since 
> the list has been pretty silent for a while, I suppose it won't be 
> cruel of me to feed you all the harvest from our celestial 
> ruminations(how's that?  ;)
>
>  
>
> *Extracts from an older mail:*
>
>  
>
> Our approach entails that every node takes flow control decisions 
> based on
> its local information - the input rate, output rate and available buffer
> space at the node. The possibility of congestion is indicated by the
> cognition based congestion detection daemon on a scale from 1 to 10 (or
> some other appropriate scale) -- where 1 and 10 could indicate the least
> and most likelihood of impending congestion.
>
> In this context, three parameters look distinct and important to me, in
> deciding the level of congestion warning :
>
> 1. Available buffer space. The congestion level indicated by the daemon
> will depend on the available buffer space. Why? : Let us assume that 
> there
> are 5 senders, and the bandwidth-delay product for each of these links is
> 200 Mb. This means that if there is a data burst on all these links
> simultaneously (worst-case scenario), then a minimum of 200*5 = 1000Mb
> will be used up before the flow control command becomes effective in
> throttling the flow of data from the senders. Now a very cautious 
> approach
> might be to always keep 1000Mb free, keeping the worst case scenario in
> mind. But a worst case scenario is never really likely, its 
> probability is
> generally too low. This could mean that we could keep lesser amount of
> buffer free (say 500 Mb). The particular value will be particular to the
> specific conditions in a network. We will of course be taking a risk; but
> we will be gaining because the link bandwidth will be more efficiently
> utilised.
>
> Effectively, the ratio of the Max BW-Delay product of all sources to the
> buffer space at a node should be a key factor in determining the 
> different
> warning levels at different levels of buffer occupancy.
>
> 2. Change in Input rate: The change in input rate, over fixed 
> intervals of
> time(the slope of the input rate v/s time curve, effectively -- though
> scaled down) could give a warning of a burst. Suppose that the i/p rate
> suddenly goes up by 64 Kbps on a link where the maximum data rate is 128
> Kbps. Now, if this is unusual, it could mean that a burst is coming in.
> Similarly, a sudden decrease could mean that the node can 'relax' and
> reduce the congestion warning level.
>
> 3. Time for available buffer space to fill up, at the present rate of
> consumption: This is given by:
>
> Time_for_buffer_fill = Available_buffer_space/(Present_Input_rate -
> Present_Output_rate)
>
> This looks like an important parameter, because it could indicate how
> imminent the threat of buffer exhaustion is. For example, if a node
> realises that the buffer fill up time is less that the RTT to its sender,
> it could mean an imminent loss of bundles. Again, the node may find from
> simple calculations that its buffer will be exhausted before the next
> contact to a node that accepts bundles from it is scheduled, in which 
> case
> it would have to send a command to its sender to reduce the sending rate
> by a particular factor/amount.
>
> The question I am trying to answer is:
> What should be the manner in which these 3 parameters be linked to the
> congestion scale? Should we, for example, decide a 1 - 10 scale for each
> parameter and take the average, or the weighted average of the three, or
> use some other formula?
>
>  
> *-----End_of_Extract---------*
>  
> I must confess that the problem we are dealing with here seems to be 
> much more complex that what I had started with in mind. I have been 
> testing the performance of some machine learning algorithms in 
> detecting levels of congestion based on the abovementioned 
> parameters (implementation available as Weka - open source ), and the 
> results have turned out to be pretty good. I generate the data myself 
> using a simple program. But the ultimate question always is, do these 
> results represent an approximate(if not ideal) of what an IPN/DTN 
> would give. Backtracking, the question becomes: Are our assumptions 
> acceptable in the first place?
>  
> Scott recently suggested using the data abandonment rate at a node as 
> a parameter to measure the level of congestion -- which appeals to me 
> too, though I think we would still need to normalise it as the 
> same 'data abandonment rate' may imply different levels of congestion 
> in varying environments.
>  
> I suppose I am confused at this point.
>  
> Do we need an analytical approach, or a simulation? Should we use 
> fuzzy logic, or a Bayesian approach in marking levels of congestion( a 
> boolean, or even discrete levels of congestion, eg., 1 to 10,  does 
> not seem to be the right approach)?  And how really do we go about 
> modelling a network that exists only in our minds?
>  
> I am looking for directions..
>  
> Durga
> PS: Here is a presentation I gave sometime back on this project:
> www.geocities.com/dpsmiles/EE_pres.ppt 
> <http://www.geocities.com/dpsmiles/EE_pres.ppt>
>  
> Durga Prasad Pandey
> Editorial Consultant, PennScience Journal of Undergraduate Research
> www.pennscience.org <http://www.pennscience.org>
> [email-masked] <mailto:[email-masked]> | 
> www.geocities.com/dpsmiles <http://www.geocities.com/dpsmiles> | 
> www.acm.org/crossroads <http://www.acm.org/crossroads>
>
> 	
> 	
>
> ____________________________________________________
> <http://www.incredimail.com/redir.asp?ad_id=309&lang=9>  /IncrediMail/ 
> - *Email has finally evolved* - *_Click Here_* 
> <http://www.incredimail.com/redir.asp?ad_id=309&lang=9> 

--------------070405080500010305060006
Content-Type: multipart/related;
 boundary="------------050808020107000401070302"

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body>
Is it even appropriate to be talking about congestion control at the
DTN layer?&nbsp; I think congestion control needs to be implemented in a
layer above the pure DTN network.&nbsp; Analogous to the way TCP is
implemented over IP.&nbsp; IP will flat out drop packets in a congested
network.&nbsp; If you want reliability you have to have the TCP overhead.<br>
<br>
But when we do implement congestion control, I think one of the things
to consider is that routers should be hefty enough to handle the sum of
traffic coming in on all links for the time it would take to send a
message back out to the sources of the congestion telling them to slow
down.&nbsp; And I think the slow down messages should be as simple as "Your
sending data at 2 mbit/s&nbsp; please throttle to 1 mbit/s"&nbsp;&nbsp; Where 1 mbit/s
is a number that the router thinks it can handle in the time before
another round-trip of control messages could be exchanged to slow the
rate down even more.<br>
<br>
And then to make sure that UDP equivalent bundles don't still cause
congestion, I'd make those be the first to get dropped before dropping
bundles conforming to traffic congestion standards (TCP equivalent
bundles).&nbsp; Inherent Quality of Service depending on what types of
Bundles you're sending.<br>
<br>
-Matt Bradbury<br>
<br>
p.s.&nbsp; I'm working on a Java implementation of the internet-draft that
Scott Burleigh put out in January.&nbsp; It has some work to go before I
open it up to everyone, but I hope that combined with the existing C
code, we can have a couple of test platforms to start testing our ideas
on.<br>
<br>
p.p.s.&nbsp; Has there been any discussion of the protocols for any of the
Convergence Layers?&nbsp; Specifically over TCP sockets?<br>
<br>
Durga Prasad Pandey wrote:
<blockquote cite="mid40247C96.00001D.85911@shulabh" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="GENERATOR" content="IncrediMail 1.0">
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>FLAVOR00-NONE-0000-0000-000000000000</X-FID>
<X-FVER>2.0</X-FVER>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd-->
  <table border="0" cellpadding="0" cellspacing="0"
 id="INCREDIMAINTABLE" width="95%">
    <tbody>
      <tr>
        <td id="INCREDITEXTREGION" width="100%"
 style="padding-right: 7px; padding-left: 7px; font-size: 10pt; font-family: Arial;">
        <div>
        <p class="MsoNormal" style="margin: 0in 0in 0pt;"><span
 style="font-size: 10pt; font-family: Arial;">Hi DTN-fans,</span></p>
        <p class="MsoNormal" style="margin: 0in 0in 0pt;"><span
 style="font-size: 10pt; font-family: Arial;"></span>&nbsp;</p>
        <p class="MsoNormal" style="margin: 0in 0in 0pt;"><span
 style="font-size: 10pt; font-family: Arial;">I have had some
interesting discussions with Scott Burleigh, Chris Ramming, and Prof
Len Kleinrock recently, and I felt (rather thoughtfully..) that&nbsp;it was
time I gave an update to this group. Since the list has been pretty
silent for a while, I suppose it won't be cruel of me to feed you all
the harvest from our celestial ruminations(how's that? &nbsp;;)</span></p>
        <p class="MsoNormal" style="margin: 0in 0in 0pt;"><span
 style="font-size: 10pt; font-family: Arial;"></span>&nbsp;</p>
        <p class="MsoNormal" style="margin: 0in 0in 0pt;"><span
 style="font-size: 10pt; font-family: Arial;"><strong>Extracts from an
older mail:</strong></span></p>
        <p class="MsoNormal" style="margin: 0in 0in 0pt;"><span
 style="font-size: 10pt; font-family: Arial;"></span>&nbsp;</p>
        <p class="MsoNormal" style="margin: 0in 0in 0pt;"><span
 style="font-size: 10pt; font-family: Arial;">Our approach entails that
every node takes flow control decisions based on <br>
its local information - the input rate, output rate and available
buffer <br>
space at the node. The possibility of congestion is indicated by the <br>
cognition based congestion detection daemon on a scale from 1 to 10 (or
        <br>
some other appropriate scale) -- where 1 and 10 could indicate the
least <br>
and most likelihood of impending congestion.<br>
        <br>
In this context, three parameters look distinct and important to me, in
        <br>
deciding the level of congestion warning :<br>
        <br>
1. Available buffer space. The congestion level indicated by the daemon
        <br>
will depend on the available buffer space. Why? : Let us assume that
there <br>
are 5 senders, and the bandwidth-delay product for each of these links
is <br>
200 Mb. This means that if there is a data burst on all these links <br>
simultaneously (worst-case scenario), then a minimum of 200*5 = 1000Mb <br>
will be used up before the flow control command becomes effective in <br>
throttling the flow of data from the senders. Now a very cautious
approach <br>
might be to always keep 1000Mb free, keeping the worst case scenario in
        <br>
mind. But a worst case scenario is never really likely, its probability
is <br>
generally too low. This could mean that we could keep lesser amount of <br>
buffer free (say 500 Mb). The particular value will be particular to
the <br>
specific conditions in a network. We will of course be taking a risk;
but <br>
we will be gaining because the link bandwidth will be more efficiently <br>
utilised.<br>
        <br>
Effectively, the ratio of the Max BW-Delay product of all sources to
the <br>
buffer space at a node should be a key factor in determining the
different <br>
warning levels at different levels of buffer occupancy.<br>
        <br>
2. Change in Input rate: The change in input rate, over fixed intervals
of <br>
time(the slope of the input rate v/s time curve, effectively -- though <br>
scaled down) could give a warning of a burst. Suppose that the i/p rate
        <br>
suddenly goes up by 64 Kbps on a link where the maximum data rate is
128 <br>
Kbps. Now, if this is unusual, it could mean that a burst is coming in.
        <br>
Similarly, a sudden decrease could mean that the node can 'relax' and <br>
reduce the congestion warning level.<br>
        <br>
3. Time for available buffer space to fill up, at the present rate of <br>
consumption: This is given by:<br>
        <br>
Time_for_buffer_fill = Available_buffer_space/(Present_Input_rate - <br>
Present_Output_rate)<br>
        <br>
This looks like an important parameter, because it could indicate how <br>
imminent the threat of buffer exhaustion is. For example, if a node <br>
realises that the buffer fill up time is less that the RTT to its
sender, <br>
it could mean an imminent loss of bundles. Again, the node may find
from <br>
simple calculations that its buffer will be exhausted before the next <br>
contact to a node that accepts bundles from it is scheduled, in which
case <br>
it would have to send a command to its sender to reduce the sending
rate <br>
by a particular factor/amount.<br>
        <br>
The question I am trying to answer is:<br>
What should be the manner in which these 3 parameters be linked to the <br>
congestion scale? Should we, for example, decide a 1 - 10 scale for
each <br>
parameter and take the average, or the weighted average of the three,
or <br>
use some other formula?</span></p>
        </div>
        <div>&nbsp;</div>
        <div><strong>-----End_of_Extract---------</strong></div>
        <div>&nbsp;</div>
        <div>I must confess that the problem we are dealing with here
seems to be much more complex that what I had started with in mind. I
have been testing the performance of some machine learning algorithms
in detecting levels of congestion based on the abovementioned
parameters&nbsp;(implementation available as Weka - open source ), and the
results have turned out to be pretty good. I generate the data myself
using a simple program. But the ultimate question always is, do these
results represent an approximate(if not ideal) of what an IPN/DTN would
give. Backtracking, the question becomes: Are our assumptions
acceptable in the first place?</div>
        <div>&nbsp;</div>
        <div>Scott recently suggested using the data abandonment rate
at a node as a parameter to measure the level of congestion -- which
appeals to me too, though I think we would still need to normalise it
as the same&nbsp;'data abandonment rate' may imply different levels of
congestion in varying environments. </div>
        <div>&nbsp;</div>
        <div>I suppose I am&nbsp;confused at this point. </div>
        <div>&nbsp;</div>
        <div>Do we need an analytical approach, or a simulation? Should
we use fuzzy logic, or a Bayesian approach in marking levels of
congestion( a boolean, or even discrete levels of congestion, eg.,&nbsp;1 to
10, &nbsp;does not seem to be the right approach)?&nbsp; And how really do we go
about modelling a network that exists only in our minds?</div>
        <div>&nbsp;</div>
        <div>I am looking for directions..</div>
        <div>&nbsp;</div>
        <div>Durga</div>
        <div>PS: Here is a presentation I gave sometime back on this
project:</div>
        <div><a href="http://www.geocities.com/dpsmiles/EE_pres.ppt">www.geocities.com/dpsmiles/EE_pres.ppt</a></div>
        <div>&nbsp;</div>
        <div>Durga Prasad Pandey</div>
        <div>Editorial Consultant, PennScience Journal of Undergraduate
Research</div>
        <div><a href="http://www.pennscience.org">www.pennscience.org</a>
        </div>
        <div><a href="mailto:[email-masked]">[email-masked]</a> | <a
 href="http://www.geocities.com/dpsmiles">www.geocities.com/dpsmiles</a>&nbsp;|
        <a href="http://www.acm.org/crossroads">www.acm.org/crossroads</a>
        </div>
        </td>
      </tr>
      <tr>
        <td id="INCREDIFOOTER" width="100%">
        <table cellpadding="0" cellspacing="0" width="100%">
          <tbody>
            <tr>
              <td width="100%"><br>
              </td>
              <td align="middle" id="INCREDISOUND" valign="bottom"><br>
              </td>
              <td align="middle" id="INCREDIANIM" valign="bottom"><br>
              </td>
            </tr>
          </tbody>
        </table>
        </td>
      </tr>
    </tbody>
  </table>
  <span id="IncrediStamp"><span dir="ltr"><font
 face="Arial, Helvetica, sans-serif" size="2">____________________________________________________<br>
  <font face="Comic Sans MS" size="2"><a
 href="http://www.incredimail.com/redir.asp?ad_id=309&amp;lang=9"><img
 alt="" hspace="0" src="cid:[email-masked]"
 align="bottom" border="0"></a>&nbsp; <i>IncrediMail</i> - <b>Email has
finally evolved</b> - </font><a
 href="http://www.incredimail.com/redir.asp?ad_id=309&amp;lang=9"><font
 face="Times New Roman" size="3"><b><u>Click Here</u></b></font></a></font></span></span>
</blockquote>
<br>
</body>
</html>

--------------050808020107000401070302
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>

--------------050808020107000401070302--

--------------070405080500010305060006--

From: [email-masked] (Durga Prasad Pandey)
Date: Sat, 7 Feb 2004 11:20:15 +0530 (India Standard Time)
Subject: [dtn-interest] Recent thinking on Congestion/flow control in IPN/DTN
Message-ID: <40247C96.00001D.85911@shulabh>

--------------Boundary-00=_RJ9PUUF1VA4000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_SJ9PP4J1VA4000000000"

--------------Boundary-00=_SJ9PP4J1VA4000000000
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi DTN-fans,=0D
=0D
I have had some interesting discussions with Scott Burleigh, Chris Rammin=
g,
and Prof Len Kleinrock recently, and I felt (rather thoughtfully..) that =
it
was time I gave an update to this group. Since the list has been pretty
silent for a while, I suppose it won't be cruel of me to feed you all the
harvest from our celestial ruminations(how's that?  ;)=0D
=0D
Extracts from an older mail:=0D
=0D
Our approach entails that every node takes flow control decisions based o=
n =0D
its local information - the input rate, output rate and available buffer =
=0D
space at the node. The possibility of congestion is indicated by the =0D
cognition based congestion detection daemon on a scale from 1 to 10 (or =0D
some other appropriate scale) -- where 1 and 10 could indicate the least =
=0D
and most likelihood of impending congestion.=0D
=0D
In this context, three parameters look distinct and important to me, in =0D
deciding the level of congestion warning :=0D
=0D
1. Available buffer space. The congestion level indicated by the daemon =0D
will depend on the available buffer space. Why? : Let us assume that ther=
e =0D
are 5 senders, and the bandwidth-delay product for each of these links is=
 =0D
200 Mb. This means that if there is a data burst on all these links =0D
simultaneously (worst-case scenario), then a minimum of 200*5 =3D 1000Mb =
=0D
will be used up before the flow control command becomes effective in =0D
throttling the flow of data from the senders. Now a very cautious approac=
h =0D
might be to always keep 1000Mb free, keeping the worst case scenario in =0D
mind. But a worst case scenario is never really likely, its probability i=
s =0D
generally too low. This could mean that we could keep lesser amount of =0D
buffer free (say 500 Mb). The particular value will be particular to the =
=0D
specific conditions in a network. We will of course be taking a risk; but=
 =0D
we will be gaining because the link bandwidth will be more efficiently =0D
utilised.=0D
=0D
Effectively, the ratio of the Max BW-Delay product of all sources to the =
=0D
buffer space at a node should be a key factor in determining the differen=
t =0D
warning levels at different levels of buffer occupancy.=0D
=0D
2. Change in Input rate: The change in input rate, over fixed intervals o=
f =0D
time(the slope of the input rate v/s time curve, effectively -- though =0D
scaled down) could give a warning of a burst. Suppose that the i/p rate =0D
suddenly goes up by 64 Kbps on a link where the maximum data rate is 128 =
=0D
Kbps. Now, if this is unusual, it could mean that a burst is coming in. =0D
Similarly, a sudden decrease could mean that the node can 'relax' and =0D
reduce the congestion warning level.=0D
=0D
3. Time for available buffer space to fill up, at the present rate of =0D
consumption: This is given by:=0D
=0D
Time_for_buffer_fill =3D Available_buffer_space/(Present_Input_rate - =0D
Present_Output_rate)=0D
=0D
This looks like an important parameter, because it could indicate how =0D
imminent the threat of buffer exhaustion is. For example, if a node =0D
realises that the buffer fill up time is less that the RTT to its sender,=
 =0D
it could mean an imminent loss of bundles. Again, the node may find from =
=0D
simple calculations that its buffer will be exhausted before the next =0D
contact to a node that accepts bundles from it is scheduled, in which cas=
e =0D
it would have to send a command to its sender to reduce the sending rate =
=0D
by a particular factor/amount.=0D
=0D
The question I am trying to answer is:=0D
What should be the manner in which these 3 parameters be linked to the =0D
congestion scale? Should we, for example, decide a 1 - 10 scale for each =
=0D
parameter and take the average, or the weighted average of the three, or =
=0D
use some other formula?=0D
=0D
-----End_of_Extract---------=0D
=0D
I must confess that the problem we are dealing with here seems to be much
more complex that what I had started with in mind. I have been testing th=
e
performance of some machine learning algorithms in detecting levels of
congestion based on the abovementioned parameters (implementation availab=
le
as Weka - open source ), and the results have turned out to be pretty goo=
d.
I generate the data myself using a simple program. But the ultimate quest=
ion
always is, do these results represent an approximate(if not ideal) of wha=
t
an IPN/DTN would give. Backtracking, the question becomes: Are our
assumptions acceptable in the first place?=0D
=0D
Scott recently suggested using the data abandonment rate at a node as a
parameter to measure the level of congestion -- which appeals to me too,
though I think we would still need to normalise it as the same 'data
abandonment rate' may imply different levels of congestion in varying
environments. =0D
=0D
I suppose I am confused at this point. =0D
=0D
Do we need an analytical approach, or a simulation? Should we use fuzzy
logic, or a Bayesian approach in marking levels of congestion( a boolean,=
 or
even discrete levels of congestion, eg., 1 to 10,  does not seem to be th=
e
right approach)?  And how really do we go about modelling a network that
exists only in our minds?=0D
=0D
I am looking for directions..=0D
=0D
Durga=0D
PS: Here is a presentation I gave sometime back on this project:=0D
www.geocities.com/dpsmiles/EE_pres.ppt=0D
=0D
Durga Prasad Pandey=0D
Editorial Consultant, PennScience Journal of Undergraduate Research=0D
www.pennscience.org =0D
[email-masked] | www.geocities.com/dpsmiles | www.acm.org/crossroads=20=

--------------Boundary-00=_SJ9PP4J1VA4000000000
Content-Type: Text/HTML;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-885=
9-1"><html>
<head>
<meta name=3D"GENERATOR" content=3D"IncrediMail 1.0">=0D
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>FLAVOR00-NONE-0000-0000-000000000000</X-FID>
<X-FVER>2.0</X-FVER>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd-->
=0A</head>

<BODY background=3D"" bgColor=3D#ffffff style=3D"BACKGROUND-POSITION: 0px=
 0px; FONT-SIZE: 10pt; MARGIN: 1px; FONT-FAMILY: Arial" scroll=3Dyes ORGY=
POS=3D"0" X-FVER=3D"2.0">
<TABLE border=3D0 cellPadding=3D0 cellSpacing=3D0 id=3DINCREDIMAINTABLE w=
idth=3D"95%">
<TR>

<TD id=3DINCREDITEXTREGION width=3D"100%" style=3D"PADDING-RIGHT: 7px; PA=
DDING-LEFT: 7px; FONT-SIZE: 10pt; FONT-FAMILY: Arial"=20
   >
      <DIV>
      <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi DTN-fans,</SPAN></=
P>
      <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN>&nbsp;</P>
      <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I have had some inter=
esting=20
      discussions with Scott Burleigh, Chris Ramming, and Prof Len Kleinr=
ock=20
      recently, and I felt (rather thoughtfully..) that&nbsp;it was time =
I gave=20
      an update to this group. Since the list has been pretty silent for =
a=20
      while, I suppose it won't be cruel of me to feed you all the harves=
t from=20
      our celestial ruminations(how's that? &nbsp;;)</SPAN></P>
      <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN>&nbsp;</P>
      <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><STRONG>Extracts from=
 an older=20
      mail:</STRONG></SPAN></P>
      <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN>&nbsp;</P>
      <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Our approach entails =
that=20
      every node takes flow control decisions based on <BR>its local info=
rmation=20
      - the input rate, output rate and available buffer <BR>space at the=
 node.=20
      The possibility of congestion is indicated by the <BR>cognition bas=
ed=20
      congestion detection daemon on a scale from 1 to 10 (or <BR>some ot=
her=20
      appropriate scale) -- where 1 and 10 could indicate the least <BR>a=
nd most=20
      likelihood of impending congestion.<BR><BR>In this context, three=20
      parameters look distinct and important to me, in <BR>deciding the l=
evel of=20
      congestion warning :<BR><BR>1. Available buffer space. The congesti=
on=20
      level indicated by the daemon <BR>will depend on the available buff=
er=20
      space. Why? : Let us assume that there <BR>are 5 senders, and the=20
      bandwidth-delay product for each of these links is <BR>200 Mb. This=
 means=20
      that if there is a data burst on all these links <BR>simultaneously=
=20
      (worst-case scenario), then a minimum of 200*5 =3D 1000Mb <BR>will =
be used=20
      up before the flow control command becomes effective in <BR>throttl=
ing the=20
      flow of data from the senders. Now a very cautious approach <BR>mig=
ht be=20
      to always keep 1000Mb free, keeping the worst case scenario in <BR>=
mind.=20
      But a worst case scenario is never really likely, its probability i=
s=20
      <BR>generally too low. This could mean that we could keep lesser am=
ount of=20
      <BR>buffer free (say 500 Mb). The particular value will be particul=
ar to=20
      the <BR>specific conditions in a network. We will of course be taki=
ng a=20
      risk; but <BR>we will be gaining because the link bandwidth will be=
 more=20
      efficiently <BR>utilised.<BR><BR>Effectively, the ratio of the Max=20
      BW-Delay product of all sources to the <BR>buffer space at a node s=
hould=20
      be a key factor in determining the different <BR>warning levels at=20
      different levels of buffer occupancy.<BR><BR>2. Change in Input rat=
e: The=20
      change in input rate, over fixed intervals of <BR>time(the slope of=
 the=20
      input rate v/s time curve, effectively -- though <BR>scaled down) c=
ould=20
      give a warning of a burst. Suppose that the i/p rate <BR>suddenly g=
oes up=20
      by 64 Kbps on a link where the maximum data rate is 128 <BR>Kbps. N=
ow, if=20
      this is unusual, it could mean that a burst is coming in. <BR>Simil=
arly, a=20
      sudden decrease could mean that the node can 'relax' and <BR>reduce=
 the=20
      congestion warning level.<BR><BR>3. Time for available buffer space=
 to=20
      fill up, at the present rate of <BR>consumption: This is given=20
      by:<BR><BR>Time_for_buffer_fill =3D=20
      Available_buffer_space/(Present_Input_rate -=20
      <BR>Present_Output_rate)<BR><BR>This looks like an important parame=
ter,=20
      because it could indicate how <BR>imminent the threat of buffer exh=
austion=20
      is. For example, if a node <BR>realises that the buffer fill up tim=
e is=20
      less that the RTT to its sender, <BR>it could mean an imminent loss=
 of=20
      bundles. Again, the node may find from <BR>simple calculations that=
 its=20
      buffer will be exhausted before the next <BR>contact to a node that=
=20
      accepts bundles from it is scheduled, in which case <BR>it would ha=
ve to=20
      send a command to its sender to reduce the sending rate <BR>by a=20
      particular factor/amount.<BR><BR>The question I am trying to answer=
=20
      is:<BR>What should be the manner in which these 3 parameters be lin=
ked to=20
      the <BR>congestion scale? Should we, for example, decide a 1 - 10 s=
cale=20
      for each <BR>parameter and take the average, or the weighted averag=
e of=20
      the three, or <BR>use some other formula?</SPAN></P></DIV>
      <DIV>&nbsp;</DIV>
      <DIV><STRONG>-----End_of_Extract---------</STRONG></DIV>
      <DIV>&nbsp;</DIV>
      <DIV>I must confess that the problem we are dealing with here seems=
 to be=20
      much more complex that what I had started with in mind. I have been=
=20
      testing the performance of some machine learning algorithms in dete=
cting=20
      levels of congestion based on the abovementioned=20
      parameters&nbsp;(implementation available as Weka - open source ), =
and the=20
      results have turned out to be pretty good. I generate the data myse=
lf=20
      using a simple program. But the ultimate question always is, do the=
se=20
      results represent an approximate(if not ideal) of what an IPN/DTN w=
ould=20
      give. Backtracking, the question becomes: Are our assumptions accep=
table=20
      in the first place?</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Scott recently suggested using the data abandonment rate at a =
node as=20
      a parameter to measure the level of congestion -- which appeals to =
me too,=20
      though I think we would still need to normalise it as the same&nbsp=
;'data=20
      abandonment rate' may imply different levels of congestion in varyi=
ng=20
      environments. </DIV>
      <DIV>&nbsp;</DIV>
      <DIV>I suppose I am&nbsp;confused at this point. </DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Do we need an analytical approach, or a simulation? Should we =
use=20
      fuzzy logic, or a Bayesian approach in marking levels of congestion=
( a=20
      boolean, or even discrete levels of congestion, eg.,&nbsp;1 to 10,=20
      &nbsp;does not seem to be the right approach)?&nbsp; And how really=
 do we=20
      go about modelling a network that exists only in our minds?</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>I am looking for directions..</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Durga</DIV>
      <DIV>PS: Here is a presentation I gave sometime back on this=20
project:</DIV>
      <DIV><A=20
      href=3D"http://www.geocities.com/dpsmiles/EE_pres.ppt">www.geocitie=
s.com/dpsmiles/EE_pres.ppt</A></DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Durga Prasad Pandey</DIV>
      <DIV>Editorial Consultant, PennScience Journal of Undergraduate=20
      Research</DIV>
      <DIV><A href=3D"http://www.pennscience.org">www.pennscience.org</A>=
 </DIV>
      <DIV><A href=3D"mailto:[email-masked]">[email-masked]</A> | <A=20
      href=3D"http://www.geocities.com/dpsmiles">www.geocities.com/dpsmil=
es</A>&nbsp;|=20
      <A href=3D"http://www.acm.org/crossroads">www.acm.org/crossroads</A=
>=20
    </DIV></TD>
</TR>

<TR>
<TD id=3DINCREDIFOOTER width=3D"100%">

=09<TABLE cellPadding=3D0 cellSpacing=3D0 width=3D"100%">
=09<TR>
=09<TD width=3D"100%"></TD>
=09<TD align=3Dmiddle id=3DINCREDISOUND vAlign=3Dbottom></TD>
=09<TD align=3Dmiddle id=3DINCREDIANIM vAlign=3Dbottom></TD>
=09</TR>
=09</TABLE>

</TD>
</TR>

</TABLE><SPAN=20
id=3DIncrediStamp><SPAN dir=3Dltr><FONT face=3D"Arial, Helvetica, sans-se=
rif"=20
size=3D2>____________________________________________________<BR><FONT=20
face=3D"Comic Sans MS" size=3D2><A=20
href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;lang=3D9"><I=
MG alt=3D""=20
hspace=3D0 src=3D"cid:D1DC0626-F7E0-4D8A-B688-235B489A27B7" align=3Dbasel=
ine=20
border=3D0></A>&nbsp; <I>IncrediMail</I> - <B>Email has finally evolved</=
B> -=20
</FONT><A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;la=
ng=3D9"><FONT=20
face=3D"Times New Roman" size=3D3><B><U>Click=20
Here</U></B></FONT></A></SPAN></SPAN></FONT>
</BODY>
</html>
--------------Boundary-00=_SJ9PP4J1VA4000000000--

--------------Boundary-00=_RJ9PUUF1VA4000000000
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <D1DC0626-F7E0-4D8A-B688-235B489A27B7>

--------------Boundary-00=_RJ9PUUF1VA4000000000--

Date: Fri,  6 Feb 2004 23:04:31 -0500
From: [email-masked]
To: [email-masked]
Subject: [dtn-interest] ZebraNet introduction and deployment experience
Sender: [email-masked]

Greetings to all DTN members! I work with Professor Margaret Martonosi on the 
ZebraNet wildlife tracking project in Princeton University. Thanks to Kevin 
who introduced me to the DTN interest group. It's a great opportunity to share 
our experience on ZebraNet with DTN researchers and talk about interesting 
issues in this area.

ZebraNet is a mobile, wireless sensor network aimed at improving tracking 
technology for wildlife tracking [1]. While ZebraNet’s most immediate focus is 
to track african zebras across large regions with little communication 
infrastructure, its broader goals concern the deployment, management, and 
communication issues for large numbers of both static and mobile sensors.

To achieve a sensor network system for real deployment, we built energy-
efficient hardware nodes, developed a lightweight operating system, and 
implemented application-level peer-to-peer protocols for data communication 
[2] [3]. At the hardware level, a ZebraNet node includes a global positioning 
system (GPS) unit to gather position data, a 16-bit microcontroller CPU, a 1W 
900MHz radio with 5-mile range as wireless transceiver, 4Mbits of non-volatile 
FLASH memory to hold logged data, and solar arrays for energy supply. At the 
middleware level, Impala, ZebraNet's middleware layer, acts as a lightweight 
operating system, but also has been designed to encourage application 
modularity, simplicity, adaptivity, and repairability. It schedules regular 
operations, handles irregular asynchronous events, and provides a networking 
interface which unifies media access control and transport control into an 
efficient network protocol that supports a range of message models: reliable 
and unreliable, unicast and multicast, tailored to ZebraNet’s application 
needs. At the application-level, ZebraNet does not count on constant 
communication access to a base station, but instead uses periodic node 
discovery and peer-to-peer communication to communicate data towards the base 
station by using other peer nodes for store-and-forward routing. Rather than a 
connection-oriented scheme in which a node identifies a full route to the 
base, the data is instead transmitted to base hop by hop via other nodes, with 
heuristics that guide the data to where the base was last seen. Since the 
zebras form a sparse network over a very large area, disconnections is common 
and data homing latency is potentially long. Therefore, ZebraNet has some 
typical attributes of delay-tolerant networks.

During January 4 to 23, 2004, our ZebraNet group headed to Kenya for its first 
test deployment. We stayed at the Mpala Research Centre and deployed seven 
nodes on zebras at the 24,000-acre Sweetwaters Reserve. Several issues arised 
during the deployment which gave us lots of input on improving the system and 
are discussed here and hopefully will also be useful to the DTN-interest group.

First, the network connectivity was unexpectedly poor, which imposed design 
optimizations on the middleware and application-level network protocols. When 
we put the tracking devices on animals, we found that the radio range was 
reduced by a magnitude to several hundred meters as the radiation was 
substantially absorbed by the animal body. This greatly degraded the network 
connectiviy and the radio channel quality. Disconnection and packet loss 
became more common. As a result, the performance of our network protocols and 
therefore our design choices were affected in several aspects.
(1) Retransmission was frequent, in some cases, due to lost acknowledgements. 
This was because the ACK packets were always the first ones to transmit, 
followed by the data packets, and therefore were easier to lose due to the 
signal synchronization between the sender's radio and the receiver's radio. 
This caused our valuable communication time, which was already minimal given 
our tight energy budget, used up by transmitting duplicate data. To address 
this problem, we changed to use duplicate acknowledgements and are considering 
switching to unreliable data transmission that performs continuous data 
forwarding without requiring portion acknowledgements or retransmissions.
(2) In some other cases, retransmission was caused by the heterogeneous 
communication range and channel quality across different nodes. For example, 
when one node was multicasting to a bunch of neighors, some neighbors might be 
hard to reach and cause repeated retransmissions, while others were easy to 
reach but still had to stay idle for the retransmissions to finish before more 
data could proceed. Therefore, it would be interesting to find an appropriate 
timeout point to cut off retransmissions and balance between sending more data 
to less destinations and sending less data to more destinations in terms of 
achieving the goal of efficiently delivering all the data to the base station 
eventually.
(3) Nearby nodes sometimes could not find each other due to lost peer 
discovery messages. Even worse, after the short peer discovery period without 
hearing from any network neighbor, the nodes gave up the effort of finding 
neighbors and remained silent during the subsequent long data transfer period. 
This meant the valuable communication opportunities in the sparse network were 
not fully explored. To address this problem, we changed to use a series of 
duplicate peer discovery messages and are considering performing peer 
discovery over time rather than only in a limited period.
(4) Sometimes, the base station ignored valid incoming data packets simply 
because those packets were not addressed to it. Therefore, to maximize the 
chance of data collection, we decided that eavesdropping should be performed 
by the base station in addition to participating in the actual conversations.

The second issue that came to us was that the Impala middleware should add in 
more operating system support for several emerging application needs.
(1) In the original ZebraNet design, communcations between different nodes 
could be performed only at regular times, for example, the first five minutes 
of every two hours, and only in the assigned timeslots. However, it became 
evident that irregular, opportunistic, and long-lasting communications were 
also desired under some circumstances. For example, the base station might 
want to interrogate a node and download its full FLASH content immediately 
after they encountered, rather than waiting until the regular talk time came. 
Therefore, Impala should have support for a variety of communication patterns. 
(2) It was pointed out by our biologist collaborators that it was desirable to 
have an adjustable system which, for example, allowed the time schedule of 
device operations to change. This can be achieved by receiving a set of new 
parameters from the base station and applying to the local system. For 
example, the current GPS position sampling interval is eight minutes, however, 
based on the analysis of sampling efficiency and energy consumption, switching 
to 16-minute intervals may be better for energy-efficiency. Therefore, Impala 
should have support for parameterized adjustable system configurations.
(3) As the tracking devices were collared on zebras and were not easy to 
retrieve for diagnostic and debugging purposes, it was of high interests to 
have a remote diagnostic mechanism that could show at the base station the 
runtime system state of a deployed node. For example, this mechanism should be 
able to tell the base station that a node was not responding because it was 
having low battery voltage and hibernating. It should also respond to base 
station queries about how much data was currently stored in the FLASH and how 
many peer-to-peer communications had happened before.

Finally, some existing hardware constraints which were not realized as 
critical issues became more evident during the deployment time. The radio 
range problem mentioned before was one example. Another example was related to 
the hardware clock signal. Since each node had constant access to the GPS 
signal which provided global time synchronization across different nodes, we 
adopted a TDMA-mannered timeslot mechanism for media access control. Each 
timeslot was two seconds long. This implied that a reasonable time variance 
among the nodes should be within a hundred milliseconds. However, the clock 
signal on the hardware nodes was not as accurate. As was measured, it skewed 
on different nodes up to +/-200ms in 8 minutes which was the interval between 
two closest time synchronizations with the GPS time. If the GPS signal was not 
available in an extended period, the time variance would grow even bigger. To 
accommodate the big time variance, we chose to use non-consecutive timeslots 
for radio transmissions to prevent collision. More efficient solutions are 
still under study. For yet another example, we found that the GPS unit 
dominated the energy consumption compared with the radio unit. Therefore, 
switching to a lower-power GPS chip would effectively yield more radio 
communication time and was also included in our to-do list.

At this point, I hope the introduction to our ZebraNet project and the stories 
about our deployment trip to Kenya can give you some useful information. For 
more details, please refer to our project homepage at 
http://www.ee.princeton.edu/~mrm/zebranet.html. We will be very glad to hear 
your comments. Thanks.

Ting

[1] Philo Juang, Hidekazu Oki, Yong Wang, Margaret Martonosi, Li-Shiuan Peh, 
and Daniel Rubenstein. "Energy-Efficient Computing forWildlife Tracking: 
Design Tradeoffs and Early Experiences with ZebraNet". the Tenth International 
Conference on Architectural Support for Programming Languages and Operating 
Systems. October, 2002. 

[2] Ting Liu and Margaret Martonosi. "Impala: A Middleware System for Managing 
Autonomic, Parallel Sensor Systems". ACM SIGPLAN Symposium on Principles and 
Practice of Parallel Programming (PPoPP'03), June 2003.

[3] Ting Liu, Christopher Sadler, Pei Zhang, and Margaret 
Martonosi. "Implementing Software on Resource-Constrained Mobile Sensors: 
Experiences with Impala and ZebraNet". To appear in the Second International 
Conference on Mobile Systems, Applications, and Services (MobiSys 2004), June 
2004.

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

From: "Durga Prasad Pandey" <[email-masked]>
To: [email-masked]
Date: Fri, 06 Feb 2004 20:50:41 +0530
Subject: [dtn-interest] Re: nomadic computing, DTN
Sender: [email-masked]

Hi Folks,

I came across a fascinating discussion with Prof Len leinrock on the Early 
Internet, and nomadic computing:

http://www.computer.org/internet/v1n3/kleinrock9702.htm

The nomadic computing he describes in this interview looks relevant to our 
idea of DTN.

Durga

Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
www.acm.org/crossroads/

_________________________________________________________________
Contact brides & grooms FREE! http://www.shaadi.com/ptnr.php?ptnr=hmltag 
Only on www.shaadi.com. Register now!

Date: Fri, 06 Feb 2004 09:33:50 -0500
From: "Robert C. Durst" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [Fwd: Call for Papers: SenSys 2004]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060802070201080307010508
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

FYI. 

-------- Original Message --------
Subject: 	Call for Papers: SenSys 2004
Date: 	Thu, 5 Feb 2004 18:13:30 -0600
From: 	Chenyang Lu <[email-masked]>
To: 	'Chenyang Lu' <[email-masked]>

PRELIMINARY CALL FOR PAPERS
	
The Second ACM Conference on Embedded Networked Sensor Systems (SenSys
2004)
November 3-5, 2004, 
Baltimore, Maryland, USA (tentative)
http://www.cis.ohio-state.edu/sensys04

Sponsored by: ACM (SIGCOMM, SIGMOBILE, SIGARCH, SIGMETRICS, SIGOPS) and
NSF

SenSys 2004 introduces a high caliber forum for research on systems
issues in the emerging area of embedded, networked sensors.  These
distributed systems of numerous smart sensors and actuators will
revolutionize a wide array of application areas by providing an
unprecedented density and fidelity of instrumentation. They also present
novel systems challenges because of resource constraints, uncertainty,
irregularity, and scale.  SenSys design issues span multiple
disciplines, including wireless communication, networking, operating
systems, architecture, low-power circuits, distributed algorithms, data
processing, scheduling, sensors, energy harvesting, and signal
processing. SenSys seeks to provide a cross-disciplinary venue for
researchers addressing these networked sensor system design issues.
SenSys 2004 is the second in a series of annual meetings with a highly
selective single-track technical program and a hands-on research
exhibition.

PAPERS:

Technical papers describing original, previously unpublished research
are solicited. In general this conference is interested in papers that
address system issues in embedded networked systems. Specific topics of
interest include the following:

- Network protocols for sensor networks			
- Operating system and middleware for sensor networks
- Applications of distributed sensor networks			
- Sensor network testbed measurements and benchmarks
- Distributed database processing in sensor networks		
- Distributed algorithms for sensor networks
- Novel sensor node hardware and software platforms		
- Sensor network planning and deployment
- Energy management in sensor networks			
- Adaptive topology management
- In-network processing and aggregation			
- Data storage in sensor networks
- Distributed and collaborative signal processing		
- Distributed actuation, control, and coordination
- Localization in time and space				
- Distributed calibration in sensor networks
- Simulation and optimization tools				
- Security					
- Fundamental limits and tradeoffs				
- Robustness	
- Algorithms for self-configuration, maintenance, stabilization	
- Programming and validation methodology
	
Please consult the program chairs at [email-masked] for
more information about the scope of the conference.
	
PAPER SUBMISSION INSTRUCTIONS

All submissions will be handled electronically and must be in PDF or
PostScript. Papers must not exceed 15 pages (US "Letter" size, 8.5 x 11
inches) including text, figures and references in single-column,
single-space format. The font size must be at least 10 points. Accepted
papers will be published in the conference proceedings. We will adopt a
double-blind process for paper review, where the identities of the
authors are withheld from reviewers. Authors' names and their
affiliations must not be revealed or mentioned anywhere in the paper or
in the Postscript or PDF file. Submitted papers should be original,
unpublished work and not currently under review for any other conference
or journal. Papers not following these guidelines will be rejected.
Questions about the submission process should be directed to the Program
Co-Chairs at [email-masked]. More detailed submission
instructions will be available at the conference website soon. Selected
papers from the conference will be fast-tracked to the new ACM
Transactions on Sensor Networks.

RESEARCH EXHIBITS & POSTERS

There will be a research exhibition and poster session.  Submission
details will be available on the website soon. 

IMPORTANT DATES

Paper Registration & Abstract: April 2, 2004 		
Paper Submission Deadline: April 9, 2004 
Notification of Acceptance: June 29, 2004		
Camera Ready Copy: August 15, 2004

CONFERENCE COMMITTEE

General Chair:         John A. Stankovic (University of Virginia)
Program Co-Chairs:     Anish Arora (Ohio State Univ.) Ramesh Govindan
(USC)
Publicity Co-Chairs:   Phillippe Bonnet (University of Copenhagen)
                       Chenyang Lu (Washington University in St. Louis)
Finance Chair:         Sang Son (University of Virginia)
Local Arrangements:    Anupam Joshi (Univ. of Maryland, Baltimore
County)
Exhibits Co-Chairs:    Akos Ledeczi (Vanderbilt) Mark Yarvis (Intel)	
Student Travel Awards: John Regehr (University of Utah)
Sponsorships Chair:    Badri Nath (Rutgers University)
Posters Co-Chairs:     Wendi Heinzelman (Univ. of Rochester)
                       Sandeep Kulkarni (Mich. State)

Program Committee:	
Tarek Abdelzaher (University of Virginia)		
Gul Agha (Univ. of Illinois, Urbana/Champaign)
Phillippe Bonnet (Univ. of Copenhagen)		
Gaetano Borriello (University of Washington)
David Culler (University of California/Berkeley)  	
Hugh Durrant-Whyte (Univ. of Sydney, Australia)
Deborah Estrin (Univ.of California/Los Angeles) 	
Mohamed Gouda (University of Texas, Austin)
Rajesh Gupta (Univ. of California, San Diego)	
John Heidemann (USC/ISI)
Lakshman Krishnamurthy (Intel)			
P.R. Kumar (Univ. of Illinois, Urbana/Champaign)
Koen Langendoen (Delft University of Technology)	
Mike Lemmon (Univ. of Notre Dame)
Urbashi Mitra (USC)				
Ulrich Schmid (Technische Universität Wien)	
Dawn Song  (Carnegie-Mellon University)		
Feng Zhao (PARC)

STEERING COMMITTEE

Ian Akyildiz (Georgia Tech., Co-chair)
Deborah Estrin (UCLA, Co-chair), 
Victor Bahl (Microsoft, Sigmobile Representative)
Craig Partridge (BBN, Sigcomm Representative)
Taieb Znati (NSF)

--------------060802070201080307010508
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 text="#000000" bgcolor="#ffffff">
FYI.&nbsp; <br>
<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
  <tbody>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
      <td>Call for Papers: SenSys 2004</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Date: </th>
      <td>Thu, 5 Feb 2004 18:13:30 -0600</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">From: </th>
      <td>Chenyang Lu <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">To: </th>
      <td>'Chenyang Lu' <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>PRELIMINARY CALL FOR PAPERS
	
The Second ACM Conference on Embedded Networked Sensor Systems (SenSys
2004)
November 3-5, 2004, 
Baltimore, Maryland, USA (tentative)
<a class="moz-txt-link-freetext" href="http://www.cis.ohio-state.edu/sensys04">http://www.cis.ohio-state.edu/sensys04</a>

Sponsored by: ACM (SIGCOMM, SIGMOBILE, SIGARCH, SIGMETRICS, SIGOPS) and
NSF

SenSys 2004 introduces a high caliber forum for research on systems
issues in the emerging area of embedded, networked sensors.  These
distributed systems of numerous smart sensors and actuators will
revolutionize a wide array of application areas by providing an
unprecedented density and fidelity of instrumentation. They also present
novel systems challenges because of resource constraints, uncertainty,
irregularity, and scale.  SenSys design issues span multiple
disciplines, including wireless communication, networking, operating
systems, architecture, low-power circuits, distributed algorithms, data
processing, scheduling, sensors, energy harvesting, and signal
processing. SenSys seeks to provide a cross-disciplinary venue for
researchers addressing these networked sensor system design issues.
SenSys 2004 is the second in a series of annual meetings with a highly
selective single-track technical program and a hands-on research
exhibition.

PAPERS:

Technical papers describing original, previously unpublished research
are solicited. In general this conference is interested in papers that
address system issues in embedded networked systems. Specific topics of
interest include the following:

- Network protocols for sensor networks			
- Operating system and middleware for sensor networks
- Applications of distributed sensor networks			
- Sensor network testbed measurements and benchmarks
- Distributed database processing in sensor networks		
- Distributed algorithms for sensor networks
- Novel sensor node hardware and software platforms		
- Sensor network planning and deployment
- Energy management in sensor networks			
- Adaptive topology management
- In-network processing and aggregation			
- Data storage in sensor networks
- Distributed and collaborative signal processing		
- Distributed actuation, control, and coordination
- Localization in time and space				
- Distributed calibration in sensor networks
- Simulation and optimization tools				
- Security					
- Fundamental limits and tradeoffs				
- Robustness	
- Algorithms for self-configuration, maintenance, stabilization	
- Programming and validation methodology
	
Please consult the program chairs at <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> for
more information about the scope of the conference.
	
PAPER SUBMISSION INSTRUCTIONS

All submissions will be handled electronically and must be in PDF or
PostScript. Papers must not exceed 15 pages (US "Letter" size, 8.5 x 11
inches) including text, figures and references in single-column,
single-space format. The font size must be at least 10 points. Accepted
papers will be published in the conference proceedings. We will adopt a
double-blind process for paper review, where the identities of the
authors are withheld from reviewers. Authors' names and their
affiliations must not be revealed or mentioned anywhere in the paper or
in the Postscript or PDF file. Submitted papers should be original,
unpublished work and not currently under review for any other conference
or journal. Papers not following these guidelines will be rejected.
Questions about the submission process should be directed to the Program
Co-Chairs at <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>. More detailed submission
instructions will be available at the conference website soon. Selected
papers from the conference will be fast-tracked to the new ACM
Transactions on Sensor Networks.

RESEARCH EXHIBITS &amp; POSTERS

There will be a research exhibition and poster session.  Submission
details will be available on the website soon. 

IMPORTANT DATES

Paper Registration &amp; Abstract: April 2, 2004 		
Paper Submission Deadline: April 9, 2004 
Notification of Acceptance: June 29, 2004		
Camera Ready Copy: August 15, 2004

CONFERENCE COMMITTEE

General Chair:         John A. Stankovic (University of Virginia)
Program Co-Chairs:     Anish Arora (Ohio State Univ.) Ramesh Govindan
(USC)
Publicity Co-Chairs:   Phillippe Bonnet (University of Copenhagen)
                       Chenyang Lu (Washington University in St. Louis)
Finance Chair:         Sang Son (University of Virginia)
Local Arrangements:    Anupam Joshi (Univ. of Maryland, Baltimore
County)
Exhibits Co-Chairs:    Akos Ledeczi (Vanderbilt) Mark Yarvis (Intel)	
Student Travel Awards: John Regehr (University of Utah)
Sponsorships Chair:    Badri Nath (Rutgers University)
Posters Co-Chairs:     Wendi Heinzelman (Univ. of Rochester)
                       Sandeep Kulkarni (Mich. State)

Program Committee:	
Tarek Abdelzaher (University of Virginia)		
Gul Agha (Univ. of Illinois, Urbana/Champaign)
Phillippe Bonnet (Univ. of Copenhagen)		
Gaetano Borriello (University of Washington)
David Culler (University of California/Berkeley)  	
Hugh Durrant-Whyte (Univ. of Sydney, Australia)
Deborah Estrin (Univ.of California/Los Angeles) 	
Mohamed Gouda (University of Texas, Austin)
Rajesh Gupta (Univ. of California, San Diego)	
John Heidemann (USC/ISI)
Lakshman Krishnamurthy (Intel)			
P.R. Kumar (Univ. of Illinois, Urbana/Champaign)
Koen Langendoen (Delft University of Technology)	
Mike Lemmon (Univ. of Notre Dame)
Urbashi Mitra (USC)				
Ulrich Schmid (Technische Universit&auml;t Wien)	
Dawn Song  (Carnegie-Mellon University)		
Feng Zhao (PARC)

STEERING COMMITTEE

Ian Akyildiz (Georgia Tech., Co-chair)
Deborah Estrin (UCLA, Co-chair), 
Victor Bahl (Microsoft, Sigmobile Representative)
Craig Partridge (BBN, Sigcomm Representative)
Taieb Znati (NSF)

</pre>
</body>
</html>

--------------060802070201080307010508--

Date: Wed, 4 Feb 2004 00:36:07 -0800 (PST)
From: Durga Prasad Pandey <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Whose law governs the International Space Station and outer space?
Sender: [email-masked]

Check out:

http://ask.yahoo.com/ask/20040203.html

Durga

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
http://www.acm.org/crossroads/
Indian School of Mines
47 Emerald Hostel
Dhanbad 826004 India
[email-masked]
DP's inn: http://geocities.com/dpsmiles/

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

To: [email-masked]
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] dtn-interest mailing list migrated
Sender: [email-masked]
Date: Mon, 02 Feb 2004 18:58:34 -0800

We have just completed a migration of the dtn-interest list from a server at GST
to Berkeley.  As far as we can tell, the list is functioning as expected.
If, however, you come across any strange behavior, please let me know.
{assuming, of course, that you received this message :P}

cheers,
- Kevin

Date: Mon, 02 Feb 2004 07:06:31 -0500
From: "Vinton G. Cerf" <[email-masked]>
Subject: RE: [dtn-interest] Delay tolerant networking (of sorts) in action
To: "'Durga Prasad Pandey'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_8hd4l/7qM7F2rZ5y2rAYpA)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_9nO4SzuzTCVrHqLzrrdUsg)"

--Boundary_(ID_9nO4SzuzTCVrHqLzrrdUsg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

that's really neat!
 
v

 

Vinton Cerf, SVP Technology Strategy, MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
+1 703 886 1690, +1 703 886 0047 fax
[email-masked] 

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Durga Prasad
Pandey
Sent: Monday, February 02, 2004 2:07 AM
To: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking (of sorts) in action

A related link would be www.daknet.net .
 
-------Original Message-------
 
From: Matt Bradbury <mailto:[email-masked]> 
Date: Monday, February 02, 2004 12:32:44 AM
To: [email-masked]
Subject: [dtn-interest] Delay tolerant networking (of sorts) in action
 
http://slashdot.org/article.pl?sid=04/01/30/2144225
<http://slashdot.org/article.pl?sid=04/01/30/2144225&mode=thread&tid=137&tid
=193> &mode=thread&tid=137&tid=193

NYTimes google link: 
http://www.nytimes.com/2004/01/26/technology/26oxcart.html?ex=1075784400
<http://www.nytimes.com/2004/01/26/technology/26oxcart.html?ex=1075784400&en
=9a7cad3b2f64a297&ei=5062&partner=GOOGLE>
&en=9a7cad3b2f64a297&ei=5062&partner=GOOGLE

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

____________________________________________________
 <http://www.incredimail.com/redir.asp?ad_id=309&lang=9>   IncrediMail -
Email has finally evolved -
<http://www.incredimail.com/redir.asp?ad_id=309&lang=9> Click Here 

--Boundary_(ID_9nO4SzuzTCVrHqLzrrdUsg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1276" =
name=3DGENERATOR><!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>FLAVOR00-NONE-0000-0000-000000000000</X-FID>
<X-FVER></X-FVER>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd--></HEAD>
<BODY=20
style=3D"BACKGROUND-POSITION: 0px 0px; FONT-SIZE: 10pt; MARGIN: 1px; =
FONT-FAMILY: Arial"=20
bgColor=3D#ffffff background=3D"" scroll=3Dyes X-FVER=3D"2.0" =
ORGYPOS=3D"0">
<DIV dir=3Dltr align=3Dleft><SPAN class=3D958120012-02022004>that's =
really=20
neat!</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D958120012-02022004></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D958120012-02022004><FONT =
color=3D#0000ff=20
size=3D3>v</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D958120012-02022004><FONT =
color=3D#0000ff=20
size=3D3></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D958120012-02022004></SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV><!-- Converted from text/plain format -->
<P>Vinton Cerf, SVP Technology Strategy, MCI<BR>22001 Loudoun County =
Parkway,=20
F2-4115<BR>Ashburn, VA 20147<BR>+1 703 886 1690, +1 703 886 0047=20
fax<BR>[email-masked] </P>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Durga Prasad=20
  Pandey<BR><B>Sent:</B> Monday, February 02, 2004 2:07 AM<BR><B>To:</B> =

  [email-masked]; [email-masked]<BR><B>Subject:</B> Re:=20
  [dtn-interest] Delay tolerant networking (of sorts) in=20
  action<BR></FONT><BR></DIV>
  <DIV></DIV>
  <TABLE id=3DINCREDIMAINTABLE cellSpacing=3D0 cellPadding=3D0 =
width=3D"95%" border=3D0>
    <TBODY>
    <TR>
      <TD id=3DINCREDITEXTREGION=20
      style=3D"PADDING-RIGHT: 7px; PADDING-LEFT: 7px; FONT-SIZE: 10pt; =
FONT-FAMILY: Arial"=20
      width=3D"100%">
        <DIV>A related link would be <A=20
        href=3D"http://www.daknet.net">www.daknet.net</A>&nbsp;.</DIV>
        <DIV>&nbsp;</DIV>
        <DIV id=3DIncrediOriginalMessage><I>-------Original=20
        Message-------</I></DIV>
        <DIV>&nbsp;</DIV>
        <DIV id=3Dreceivestrings>
        <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>From:</B></I> <A=20
        href=3D"mailto:[email-masked]">Matt Bradbury</A></DIV>
        <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Date:</B></I> =
Monday,=20
        February 02, 2004 12:32:44 AM</DIV>
        <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>To:</B></I> <A=20
        =
href=3D"mailto:[email-masked]">[email-masked]=
.org</A></DIV>
        <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Subject:</B></I>=20
        [dtn-interest] Delay tolerant networking (of sorts) in=20
action</DIV></DIV>
        <DIV>&nbsp;</DIV><A=20
        =
href=3D"http://slashdot.org/article.pl?sid=3D04/01/30/2144225&amp;mode=3D=
thread&amp;tid=3D137&amp;tid=3D193">http://slashdot.org/article.pl?sid=3D=
04/01/30/2144225&amp;mode=3Dthread&amp;tid=3D137&amp;tid=3D193</A><BR><BR=
>NYTimes=20
        google link: <BR><A=20
        =
href=3D"http://www.nytimes.com/2004/01/26/technology/26oxcart.html?ex=3D1=
075784400&amp;en=3D9a7cad3b2f64a297&amp;ei=3D5062&amp;partner=3DGOOGLE">h=
ttp://www.nytimes.com/2004/01/26/technology/26oxcart.html?ex=3D1075784400=
&amp;en=3D9a7cad3b2f64a297&amp;ei=3D5062&amp;partner=3DGOOGLE</A><BR><BR>=
-Matt<BR>_______________________________________________<BR>dtn-interest =

        mailing list<BR><A=20
        =
href=3D"mailto:[email-masked]">[email-masked]=
.org</A><BR><A=20
        =
href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://ma=
ilman.dtnrg.org/mailman/listinfo/dtn-interest</A></TD></TR>
    <TR>
      <TD id=3DINCREDIFOOTER width=3D"100%">
        <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%">
          <TBODY>
          <TR>
            <TD width=3D"100%"></TD>
            <TD id=3DINCREDISOUND vAlign=3Dbottom align=3Dmiddle></TD>
            <TD id=3DINCREDIANIM vAlign=3Dbottom=20
      =
align=3Dmiddle></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><SPAN =

  id=3DIncrediStamp><SPAN dir=3Dltr><FONT face=3D"Arial, Helvetica, =
sans-serif"=20
  size=3D2>____________________________________________________<BR><FONT =

  face=3D"Comic Sans MS" size=3D2><A=20
  =
href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;lang=3D9"><I=
MG alt=3D""=20
  hspace=3D0 src=3D"cid:958120012@02022004-0D45" align=3Dbaseline =
border=3D0></A>&nbsp;=20
  <I>IncrediMail</I> - <B>Email has finally evolved</B> - </FONT><A=20
  =
href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;lang=3D9"><F=
ONT=20
  face=3D"Times New Roman" size=3D3><B><U>Click=20
  Here</U></B></FONT></A></SPAN></SPAN></FONT> =
</BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_9nO4SzuzTCVrHqLzrrdUsg)--

--Boundary_(ID_8hd4l/7qM7F2rZ5y2rAYpA)
Content-id: <958120012@02022004-0D45>
Content-type: image/gif; name=ATT00152.gif
Content-transfer-encoding: base64
Content-disposition: attachment; filename=ATT00152.gif

--Boundary_(ID_8hd4l/7qM7F2rZ5y2rAYpA)--

Date: Mon, 2 Feb 2004 12:37:01 +0530 (India Standard Time)
From: "Durga Prasad Pandey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Delay tolerant networking (of sorts) in action
Sender: [email-masked]

--------------Boundary-00=_PR3GQL80000000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_PR3GLVC0000000000000"

--------------Boundary-00=_PR3GLVC0000000000000
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A related link would be www.daknet.net .=0D
=0D
-------Original Message-------=0D
=0D
From: Matt Bradbury=0D
Date: Monday, February 02, 2004 12:32:44 AM=0D
To: [email-masked]=0D
Subject: [dtn-interest] Delay tolerant networking (of sorts) in action=0D
=0D
http://slashdot.org/article
pl?sid=3D04/01/30/2144225&mode=3Dthread&tid=3D137&tid=3D193=0D
=0D
NYTimes google link: =0D
http://www.nytimes.com/2004/01/26/technology/26oxcart
html?ex=3D1075784400&en=3D9a7cad3b2f64a297&ei=3D5062&partner=3DGOOGLE=0D
=0D
-Matt=0D
_______________________________________________=0D
dtn-interest mailing list=0D
[email-masked]=0D
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
--------------Boundary-00=_PR3GLVC0000000000000
Content-Type: Text/HTML;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-885=
9-1"><html>
<head>
<meta name=3D"GENERATOR" content=3D"IncrediMail 1.0">=0D
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>FLAVOR00-NONE-0000-0000-000000000000</X-FID>
<X-FVER></X-FVER>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd-->
=0A</head>

<BODY background=3D"" bgColor=3D#ffffff style=3D"BACKGROUND-POSITION: 0px=
 0px; FONT-SIZE: 10pt; MARGIN: 1px; FONT-FAMILY: Arial" scroll=3Dyes ORGY=
POS=3D"0" X-FVER=3D"2.0">
<TABLE border=3D0 cellPadding=3D0 cellSpacing=3D0 id=3DINCREDIMAINTABLE w=
idth=3D"95%">
<TR>

<TD id=3DINCREDITEXTREGION width=3D"100%" style=3D"PADDING-RIGHT: 7px; PA=
DDING-LEFT: 7px; FONT-SIZE: 10pt; FONT-FAMILY: Arial"=20
   >
      <DIV>A related link would be <A=20
      href=3D"http://www.daknet.net">www.daknet.net</A>&nbsp;.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV id=3DIncrediOriginalMessage><I>-------Original Message-------<=
/I></DIV>
      <DIV>&nbsp;</DIV>
      <DIV id=3Dreceivestrings>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>From:</B></I> <A=20
      href=3D"mailto:[email-masked]">Matt Bradbury</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Date:</B></I> Monday=
, February=20
      02, 2004 12:32:44 AM</DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>To:</B></I> <A=20
      href=3D"mailto:[email-masked]">dtn-interest@mailman=
=2Eipnrg.org</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Subject:</B></I> [dt=
n-interest]=20
      Delay tolerant networking (of sorts) in action</DIV></DIV>
      <DIV>&nbsp;</DIV><A=20
      href=3D"http://slashdot.org/article.pl?sid=3D04/01/30/2144225&amp;m=
ode=3Dthread&amp;tid=3D137&amp;tid=3D193">http://slashdot.org/article.pl?=
sid=3D04/01/30/2144225&amp;mode=3Dthread&amp;tid=3D137&amp;tid=3D193</A><=
BR><BR>NYTimes=20
      google link: <BR><A=20
      href=3D"http://www.nytimes.com/2004/01/26/technology/26oxcart.html?=
ex=3D1075784400&amp;en=3D9a7cad3b2f64a297&amp;ei=3D5062&amp;partner=3DGOO=
GLE">http://www.nytimes.com/2004/01/26/technology/26oxcart.html?ex=3D1075=
784400&amp;en=3D9a7cad3b2f64a297&amp;ei=3D5062&amp;partner=3DGOOGLE</A><B=
R><BR>-Matt<BR>_______________________________________________<BR>dtn-int=
erest=20
      mailing list<BR><A=20
      href=3D"mailto:[email-masked]">dtn-interest@mailman=
=2Edtnrg.org</A><BR><A=20
      href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">htt=
p://mailman.dtnrg.org/mailman/listinfo/dtn-interest</A></TD>
</TR>

<TR>
<TD id=3DINCREDIFOOTER width=3D"100%">

=09<TABLE cellPadding=3D0 cellSpacing=3D0 width=3D"100%">
=09<TR>
=09<TD width=3D"100%"></TD>
=09<TD align=3Dmiddle id=3DINCREDISOUND vAlign=3Dbottom></TD>
=09<TD align=3Dmiddle id=3DINCREDIANIM vAlign=3Dbottom></TD>
=09</TR>
=09</TABLE>

</TD>
</TR>

</TABLE><SPAN=20
id=3DIncrediStamp><SPAN dir=3Dltr><FONT face=3D"Arial, Helvetica, sans-se=
rif"=20
size=3D2>____________________________________________________<BR><FONT=20
face=3D"Comic Sans MS" size=3D2><A=20
href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;lang=3D9"><I=
MG alt=3D""=20
hspace=3D0 src=3D"cid:8A2C9252-D7D9-4148-8860-ADF86E8C51CF" align=3Dbasel=
ine=20
border=3D0></A>&nbsp; <I>IncrediMail</I> - <B>Email has finally evolved</=
B> -=20
</FONT><A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;la=
ng=3D9"><FONT=20
face=3D"Times New Roman" size=3D3><B><U>Click=20
Here</U></B></FONT></A></SPAN></SPAN></FONT>
</BODY>
</html>
--------------Boundary-00=_PR3GLVC0000000000000--

--------------Boundary-00=_PR3GQL80000000000000
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <8A2C9252-D7D9-4148-8860-ADF86E8C51CF>

--------------Boundary-00=_PR3GQL80000000000000--

Date: Sun, 01 Feb 2004 12:57:52 -0600
From: Matt Bradbury <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Delay tolerant networking (of sorts) in action
Sender: [email-masked]

http://slashdot.org/article.pl?sid=04/01/30/2144225&mode=thread&tid=137&tid=193

NYTimes google link:   
http://www.nytimes.com/2004/01/26/technology/26oxcart.html?ex=1075784400&en=9a7cad3b2f64a297&ei=5062&partner=GOOGLE

-Matt