Subject: [dtn-interest] new draft...
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>, [email-masked]
Date: Fri, 30 Sep 2005 18:01:46 +0100
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

...which tries to capture some of the security discussions [1]
we've had over time - comments welcome here (probably more
apropriate just on the dtn-security list though)

Stephen.

[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sec-overview-00.txt

Date: Thu, 29 Sep 2005 07:58:29 -0400
From: Howard Weiss <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] Old dial-up uucp email headers...
Sender: [email-masked]

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

Stephen,

The way that we had things set up back in the UUCP days was that we 
peered with one other site and we called them every half hour (e.g., at 
the top of the hour) and they called us every half hour (e.g. on the 
half hour).  This was a "local" call so I'm sure those that had to place 
long distance calls were a bit more frugal so there might have been 
sites that only sent or received once a day late at night when the toll 
charges were lowest.

Howie

Stephen Farrell wrote:

>
> Hi,
>
> One of the recurring comments about DTN is that this is just like
> the way things used to work when mail went via dial-up uucp.
>
> So I was thinking: what were the actual timings on those emails? I
> remember being surprised the first time I had a multiple exchange
> conversation in a single day, but then I was in Ireland which
> wasn't exactly a connectivity hotbed back then;-)
>
> Anyway, I looked for a paper describing the average latencies or
> similar things and found nothing much, but of course, maybe I
> missed something or its not indexed on-line or whatever.
>
> So what I figured might be interesting would be if I could get my
> hands on a bunch of old dial-up uucp email headers, then I could
> figure out something about the timings and that might be a useful
> data point for DTNs which involve people communicating slooowly
> with one another.
>
> So, if you've got any old emails with such headers, or other relevant
> information, feel free to get in touch. (BTW: I don't need to see the
> mail body at all, just the "Date:" & "Received:" lines or equivalents.)
>
> I'll post a synopsis back to this list if anything substantive turns
> up.
>
> TIA,
> Stephen.
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 

Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201 || 410.872.8079 (fax)

--------------030306050705000202010407
Content-Type: text/html; charset=ISO-8859-1
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">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Stephen,<br>
<br>
The way that we had things set up back in the UUCP days was that we
peered with one other site and we called them every half hour (e.g., at
the top of the hour) and they called us every half hour (e.g. on the
half hour).&nbsp; This was a "local" call so I'm sure those that had to
place long distance calls were a bit more frugal so there might have
been sites that only sent or received once a day late at night when the
toll charges were lowest.<br>
<br>
Howie<br>
</font></font><br>
Stephen Farrell wrote:
<blockquote cite="[email-masked]" type="cite"><br>
Hi,
  <br>
  <br>
One of the recurring comments about DTN is that this is just like
  <br>
the way things used to work when mail went via dial-up uucp.
  <br>
  <br>
So I was thinking: what were the actual timings on those emails? I
  <br>
remember being surprised the first time I had a multiple exchange
  <br>
conversation in a single day, but then I was in Ireland which
  <br>
wasn't exactly a connectivity hotbed back then;-)
  <br>
  <br>
Anyway, I looked for a paper describing the average latencies or
  <br>
similar things and found nothing much, but of course, maybe I
  <br>
missed something or its not indexed on-line or whatever.
  <br>
  <br>
So what I figured might be interesting would be if I could get my
  <br>
hands on a bunch of old dial-up uucp email headers, then I could
  <br>
figure out something about the timings and that might be a useful
  <br>
data point for DTNs which involve people communicating slooowly
  <br>
with one another.
  <br>
  <br>
So, if you've got any old emails with such headers, or other relevant
  <br>
information, feel free to get in touch. (BTW: I don't need to see the
  <br>
mail body at all, just the "Date:" &amp; "Received:" lines or
equivalents.)
  <br>
  <br>
I'll post a synopsis back to this list if anything substantive turns
  <br>
up.
  <br>
  <br>
TIA,
  <br>
Stephen.
  <br>
  <br>
  <br>
_______________________________________________
  <br>
dtn-interest mailing list
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
  <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
  <br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 

Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201 || 410.872.8079 (fax)
</pre>
</body>
</html>

--------------030306050705000202010407--

Date: Thu, 29 Sep 2005 11:23:34 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] Old dial-up uucp email headers...
Sender: [email-masked]

Yep, that's how it worked here - we tried to call in twice
a day usually, but didn't always succeed. But as I recall
the main fun was with replies that arrived hours before
the originals.

Anyway I'll try that google suggestion but if anyone else
has any data feel free to send it to me and I'll see if I can
incorporate it,
Cheers,
Stephen.

Dave Crocker wrote:
> 
> 
> Fred Baker wrote:
> 
>> As I recall, the timing of the UUCP thing was driven by when the calls 
>> were actually made.
> 
> 
> 
> That was/is my impression, also, for the CSNet dial-up based service 
> that I ran.  It was pretty much single-hop relaying to the 
> Arpanet/Internet, but could demonstrate considerable delays for users 
> who could only afford once-a-day email exchange.  Folks who wanted more 
> responsive service called more frequently.
> 
> For sites with more frequent connection models, multiple exchanges 
> between correspondents in a single day was quite common.
> 
> This all suggests that performance of a DTN entirely hinges on the likely
> latency of exchanges, just as one would expect.
> 
> d/
> 

Date: Thu, 29 Sep 2005 08:22:12 +0200
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: BrandenburgWorking Internet
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Old dial-up uucp email headers...
Sender: [email-masked]

Fred Baker wrote:
> As I recall, the timing of the UUCP thing was driven by when the calls 
> were actually made.

That was/is my impression, also, for the CSNet dial-up based service that I 
ran.  It was pretty much single-hop relaying to the Arpanet/Internet, but 
could demonstrate considerable delays for users who could only afford 
once-a-day email exchange.  Folks who wanted more responsive service called 
more frequently.

For sites with more frequent connection models, multiple exchanges between 
correspondents in a single day was quite common.

This all suggests that performance of a DTN entirely hinges on the likely
latency of exchanges, just as one would expect.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Cc: DTN <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: Re: [dtn-interest] Old dial-up uucp email headers...
Date: Wed, 28 Sep 2005 09:36:05 +0400
To: Stephen Farrell <[email-masked]>
Sender: [email-masked]

As I recall, the timing of the UUCP thing was driven by when the  
calls were actually made. I ran on ultrix and IIRC had it configured  
to call in hourly to exchange files. If I got a question out at time  
X, it generally got out into IP-land by X+1 hour, and I got the reply  
sometime between X+2 and X+3.

The question would be: how many hops (each adding up to its call  
interval of DTN delay plus the transmission duration) did it take to  
get the message out and back, plus the processing time at the  
destination? If one was getting a small RFC via UUCP (and therefore  
independent of having to wait for a human reaction), that would  
likely be masked by the inter-call interval, and one could reasonably  
expect the RTT to approximate half the sum of those intervals out and  
back.

On Sep 28, 2005, at 4:26 AM, Stephen Farrell wrote:

>
> Hi,
>
> One of the recurring comments about DTN is that this is just like
> the way things used to work when mail went via dial-up uucp.
>
> So I was thinking: what were the actual timings on those emails? I
> remember being surprised the first time I had a multiple exchange
> conversation in a single day, but then I was in Ireland which
> wasn't exactly a connectivity hotbed back then;-)
>
> Anyway, I looked for a paper describing the average latencies or
> similar things and found nothing much, but of course, maybe I
> missed something or its not indexed on-line or whatever.
>
> So what I figured might be interesting would be if I could get my
> hands on a bunch of old dial-up uucp email headers, then I could
> figure out something about the timings and that might be a useful
> data point for DTNs which involve people communicating slooowly
> with one another.
>
> So, if you've got any old emails with such headers, or other relevant
> information, feel free to get in touch. (BTW: I don't need to see the
> mail body at all, just the "Date:" & "Received:" lines or  
> equivalents.)
>
> I'll post a synopsis back to this list if anything substantive turns
> up.
>
> TIA,
> Stephen.
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 27 Sep 2005 20:37:46 -0700
From: David Mercer <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: [dtn-interest] Old dial-up uucp email headers...
Sender: [email-masked]

On 9/27/05, Stephen Farrell <[email-masked]> wrote:

> So what I figured might be interesting would be if I could get my
> hands on a bunch of old dial-up uucp email headers, then I could
> figure out something about the timings and that might be a useful
> data point for DTNs which involve people communicating slooowly
> with one another.
>
> So, if you've got any old emails with such headers, or other relevant
> information, feel free to get in touch. (BTW: I don't need to see the
> mail body at all, just the "Date:" & "Received:" lines or equivalents.)

Alas, although I have none of my mail on uucp connected systems from
that era, you should be able to mine quite a lot out of usenet
archives such as Google Groups, as much (most?) of the netnews in the
80's was sent via uucp, and the headers are still intact.  You have to
click 'show options --> show original' to get the full headers in
google groups.  Doing an advanced google group search on messages
containing the string uucp in the 80's digs up tons of them.

Cheers,

David Mercer
Tucson, AZ

Date: Wed, 28 Sep 2005 01:26:02 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Old dial-up uucp email headers...
Sender: [email-masked]

Hi,

One of the recurring comments about DTN is that this is just like
the way things used to work when mail went via dial-up uucp.

So I was thinking: what were the actual timings on those emails? I
remember being surprised the first time I had a multiple exchange
conversation in a single day, but then I was in Ireland which
wasn't exactly a connectivity hotbed back then;-)

Anyway, I looked for a paper describing the average latencies or
similar things and found nothing much, but of course, maybe I
missed something or its not indexed on-line or whatever.

So what I figured might be interesting would be if I could get my
hands on a bunch of old dial-up uucp email headers, then I could
figure out something about the timings and that might be a useful
data point for DTNs which involve people communicating slooowly
with one another.

So, if you've got any old emails with such headers, or other relevant
information, feel free to get in touch. (BTW: I don't need to see the
mail body at all, just the "Date:" & "Received:" lines or equivalents.)

I'll post a synopsis back to this list if anything substantive turns
up.

TIA,
Stephen.

Date: Tue, 27 Sep 2005 15:32:17 +0200
From: =?ISO-8859-1?Q?Carlos_L=F3pez?= <[email-masked]>
Reply-To: =?ISO-8859-1?Q?Carlos_L=F3pez?= <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: Question about Mote-KIT2400
Sender: [email-masked]

------=_Part_7957_32116586.1127827937048
Content-Type: multipart/alternative; 
	boundary="----=_Part_7958_26883757.1127827937048"

------=_Part_7958_26883757.1127827937048
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello!!
 I'm a spanish student. I speak (and write) little english...sorry.
I have a problem with the kit when I try to instal into the MICAZ-MTS300/31=
0
the software provided for XBOW. I have the sensor board MIB510 and I can
install others programs like BLINK and others, but the Xbow program to data
adquisition sensors (XSensorMTS300) I can't. Appear me the library error an=
d
the platform error. I attach the code for the MTS300 sensors with the mote
micaz.
 Thank you!!!

--
Carlos L=F3pez

--
Carlos L=F3pez

--
Carlos L=F3pez

------=_Part_7958_26883757.1127827937048
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<span class=3D"gmail_quote"><br></span><span class=3D"q"><span class=3D"gma=
il_quote"><br></span>
<p>Hello!!</p>
<div>&nbsp;</div>
<div>I'm a spanish student. I speak (and write) little english...sorry.</di=
v></span>
<div>I have a problem with the kit when I try to instal into the MICAZ-MTS3=
00/310 the software provided for XBOW. I have&nbsp;the sensor board MIB510 =
and I can install others programs like BLINK and others, but the Xbow progr=
am to data adquisition sensors (XSensorMTS300) I can't. Appear me the libra=
ry error and the platform error. I attach the code for the MTS300 sensors w=
ith the mote micaz.
</div>
<div>&nbsp;</div>
<div>Thank you!!!</div>
<div><br clear=3D"all"><br>-- <br>Carlos L=F3pez </div><br clear=3D"all"><b=
r clear=3D"all"><br>-- <br><span class=3D"sg">Carlos L=F3pez </span><br cle=
ar=3D"all"><br clear=3D"all"><br>-- <br>Carlos L=F3pez=20

------=_Part_7958_26883757.1127827937048--

------=_Part_7957_32116586.1127827937048
Content-Type: application/octet-stream; name=XSensorMTS300.rar
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="XSensorMTS300.rar"

------=_Part_7957_32116586.1127827937048--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] LTP over DTN
Date: Tue, 13 Sep 2005 07:36:56 -0700
From: "Fall, Kevin" <[email-masked]>
To: "Durst,Robert C." <[email-masked]>, "Dai Stanton" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I actually think voice would be more 'interesting' for such a scenario.
Video has almost always been an "easier" problem, mostly because we're
used to such lousy video anyhow. :o

- K

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Durst,Robert C.
> Sent: Tuesday, September 13, 2005 6:26 AM
> To: Dai Stanton; [email-masked]
> Subject: RE: [dtn-interest] LTP over DTN
> 
> Dai,
> 
> We've been getting increasing interest from sponsors to provide some
> kind of support for streamed traffic, which would also dictate an
> RTP-like shim.  There's nothing that prevents adaptation of something
> like RTP, and it actually seems rather straightforward.  How to
> actually build a disruption-tolerant streamed service, well, that's
> another matter.  But the notion is that voice traffic, for example,
> would stream "normally" when connected (message size will be an issue
> here, particularly for highly compressed voice), and revert to a
> store-and-forward service more approximating voicemail in the event of
> disruption.  One could clearly do the same thing with video, which
> might be more interesting.
> 
> Durst
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dai Stanton
> Sent: Monday, September 12, 2005 8:02 PM
> To: [email-masked]
> Subject: RE: [dtn-interest] LTP over DTN
> 
> 
> Thinking about this a bit more.
> 
> OK so we're in a power limited environment with marginal and
> intermittent links. Individual links may fail at any time and
> unpredictably. Even when they're up, bandwidth is limited. However,
> link
> delays are short and, given current technology, memory is abundant.
> 
> This means that custody transfer should give e-to-e reliability
because
> congestion (which, of course, is what TCP is designed around)
shouldn't
> occur. So we don't need an e-to-e protocol in this (hypothetical)
> scenario.
> 
> The weird thing is that we now have something that isn't really
> encountered in conventional comms: a service that is complete, without
> errors but non-sequence preserving. Seems we need an RTP-like shim to
> complete the set.
> 
> Dai
> 
> 
> _______________________________________________
> 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

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] LTP over DTN
Date: Tue, 13 Sep 2005 09:25:54 -0400
From: "Durst,Robert C." <[email-masked]>
To: "Dai Stanton" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Dai,

We've been getting increasing interest from sponsors to provide some
kind of support for streamed traffic, which would also dictate an
RTP-like shim.  There's nothing that prevents adaptation of something
like RTP, and it actually seems rather straightforward.  How to
actually build a disruption-tolerant streamed service, well, that's
another matter.  But the notion is that voice traffic, for example,
would stream "normally" when connected (message size will be an issue
here, particularly for highly compressed voice), and revert to a
store-and-forward service more approximating voicemail in the event of
disruption.  One could clearly do the same thing with video, which
might be more interesting.

Durst 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dai Stanton
Sent: Monday, September 12, 2005 8:02 PM
To: [email-masked]
Subject: RE: [dtn-interest] LTP over DTN

Thinking about this a bit more.

OK so we're in a power limited environment with marginal and
intermittent links. Individual links may fail at any time and
unpredictably. Even when they're up, bandwidth is limited. However,
link
delays are short and, given current technology, memory is abundant. 

This means that custody transfer should give e-to-e reliability because
congestion (which, of course, is what TCP is designed around) shouldn't
occur. So we don't need an e-to-e protocol in this (hypothetical)
scenario.

The weird thing is that we now have something that isn't really
encountered in conventional comms: a service that is complete, without
errors but non-sequence preserving. Seems we need an RTP-like shim to
complete the set.

Dai

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

Date: Mon, 12 Sep 2005 17:41:41 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] LTP over DTN
Sender: [email-masked]

Dai Stanton wrote:

>Thinking about this a bit more.
>
>OK so we're in a power limited environment with marginal and
>intermittent links. Individual links may fail at any time and
>unpredictably. Even when they're up, bandwidth is limited. However, link
>delays are short and, given current technology, memory is abundant. 
>
>This means that custody transfer should give e-to-e reliability because
>congestion (which, of course, is what TCP is designed around) shouldn't
>occur. So we don't need an e-to-e protocol in this (hypothetical)
>scenario.
>
>The weird thing is that we now have something that isn't really
>encountered in conventional comms: a service that is complete, without
>errors but non-sequence preserving. Seems we need an RTP-like shim to
>complete the set.
>  
>
"Complete, without errors but non-sequence preserving" is exactly it; 
Acknowledged-mode CFDP has the same kinds of characteristics.  I've also 
built a "reliable UDP" implementation on the same principles -- 
concurrent acknowledgement dialogues, complete delivery without errors 
but non-sequence preserving -- on the notion that it might be good for 
managing brief conversations with extremely large numbers of peers, 
where the overhead of making and breaking lots of connections might make 
TCP unattractive.  Seems to work well enough, but I don't have any 
applications at hand to try it out on.

Scott

From: "Dai Stanton" <[email-masked]>
To: <[email-masked]>
Subject: RE: [dtn-interest] LTP over DTN
Date: Tue, 13 Sep 2005 01:02:23 +0100
Importance: Normal
Sender: [email-masked]

Thinking about this a bit more.

OK so we're in a power limited environment with marginal and
intermittent links. Individual links may fail at any time and
unpredictably. Even when they're up, bandwidth is limited. However, link
delays are short and, given current technology, memory is abundant. 

This means that custody transfer should give e-to-e reliability because
congestion (which, of course, is what TCP is designed around) shouldn't
occur. So we don't need an e-to-e protocol in this (hypothetical)
scenario.

The weird thing is that we now have something that isn't really
encountered in conventional comms: a service that is complete, without
errors but non-sequence preserving. Seems we need an RTP-like shim to
complete the set.

Dai

Date: Sun, 11 Sep 2005 21:16:23 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] LTP over DTN
Sender: [email-masked]

Dai Stanton wrote:

>I understand that LTP is meant to be used as a service underlying
>bundling However our problem is to provide end-to-end reliability in the
>absence of custody transfer (or even if custody transfer is implemented,
>concerns over whether custody transfer provides e-to-e reliability).
>
>Although we don't have long delay links, we could look upon a long
>outage as a long delay in which case we could use an e-to-e reliability
>protocol (e.g. LTP) to plug our service quality gap.
>  
>
Ah, okay; sorry it's taking me so long to catch on.  But I think in that 
case you've still got the problem of determining a reasonable value for 
the end-to-end retransmission timeout interval.  [If you ignore that, 
then you get the reransmission flurry problem you were initially asking 
about, and moreover you'll likely also have transmissions failing 
altogether due to retransmission count limits being reached.]

This is in general a pretty intractable problem over the kinds of 
networks we usually think of using DTN over, and I haven't got a ready 
answer.  Just thinking out loud, maybe you want some sort of 
connectivity probing protocol running alongside LTP (out-of-stack) that 
issues freeze/thaw link cues on the basis of periodic end-to-end probes 
to all nominally reachable DTN endpoints.  That preserves standard LTP 
behavior and prevents the timeout flurry and failure scenarios; now it's 
just a question of how you build this magic protocol.

It wouldn't be a good approach for deep space because of the long signal 
propagation times and limited data rates, but it might be okay for 
end-to-end LTP over BP in a terrestrial environment where all you're 
worrying about is connectivity disruption: you can afford to issue lots 
of probes [over the IP underneath the overlay network, not over DTN 
itself], draw conclusions from the echoes, and express those conclusions 
as link cues....

Scott

From: "Dai Stanton" <[email-masked]>
To: <[email-masked]>
Subject: RE: [dtn-interest] LTP over DTN
Date: Sun, 11 Sep 2005 18:08:46 +0100
Importance: Normal
Sender: [email-masked]

I understand that LTP is meant to be used as a service underlying
bundling However our problem is to provide end-to-end reliability in the
absence of custody transfer (or even if custody transfer is implemented,
concerns over whether custody transfer provides e-to-e reliability).

Although we don't have long delay links, we could look upon a long
outage as a long delay in which case we could use an e-to-e reliability
protocol (e.g. LTP) to plug our service quality gap.

Dai

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
Sent: 11 September 2005 16:40
To: [email-masked]
Subject: Re: [dtn-interest] LTP over DTN

Dai Stanton wrote:
> Thanks for the reply Scott.
> 
> I understand the freezing timers issue but if one were operating over
> DTN with unscheduled and unpredictable disruptions (e.g. in-theatre)
> then it will be difficult for LTP tobe informed of such disruption by
> the underlying DTN. In this case the timers won't be frozen. Or am I
> getting this wrong?

The notion would be that LTP would be operating underneath (rather than
on top of) the bundle protocol.  Weird, yes, but it's part of the
general notion of using different convergence-layer protocols on
different segments of the end-to-end path to deal with traversing a
variety of different kinds of communication environments.  In this
context, LTP isn't designed to be a TCP-replacing end-to-end transport
protocol; rather it's a single-hop [even if maybe a very long single
hop] ARQ system.  The right analog, I think, is that LTP is to the
bundle protocol as LLC (802.2?) is to IP.

So you might or might not want to use LTP in a tactical military
environment, but if you did that then the "link cues" that trigger the
freezing and thawing of the links -- and the consequent
suspension/resumption of the timers -- would come from the underlying
Ethernet or 802.11 or whatever, somehow; the bundle protocol would be
running on top of it (and possibly also on top of TCP, UDP, whatever, on
other DTN network segments) to conduct data through the end-to-end
overlay network.

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

Date: Sun, 11 Sep 2005 08:40:06 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] LTP over DTN
Sender: [email-masked]

Dai Stanton wrote:
> Thanks for the reply Scott.
> 
> I understand the freezing timers issue but if one were operating over
> DTN with unscheduled and unpredictable disruptions (e.g. in-theatre)
> then it will be difficult for LTP tobe informed of such disruption by
> the underlying DTN. In this case the timers won't be frozen. Or am I
> getting this wrong?

The notion would be that LTP would be operating underneath (rather than on top of) the bundle protocol.  Weird, yes, but it's part of the general notion of using different convergence-layer protocols on different segments of the end-to-end path to deal with traversing a variety of different kinds of communication environments.  In this context, LTP isn't designed to be a TCP-replacing end-to-end transport protocol; rather it's a single-hop [even if maybe a very long single hop] ARQ system.  The right analog, I think, is that LTP is to the bundle protocol as LLC (802.2?) is to IP.

So you might or might not want to use LTP in a tactical military environment, but if you did that then the "link cues" that trigger the freezing and thawing of the links -- and the consequent suspension/resumption of the timers -- would come from the underlying Ethernet or 802.11 or whatever, somehow; the bundle protocol would be running on top of it (and possibly also on top of TCP, UDP, whatever, on other DTN network segments) to conduct data through the end-to-end overlay network.

Scott

From: "Dai Stanton" <[email-masked]>
To: <[email-masked]>
Subject: RE: [dtn-interest] LTP over DTN
Date: Sun, 11 Sep 2005 15:18:28 +0100
Importance: Normal
Sender: [email-masked]

Thanks for the reply Scott.

I understand the freezing timers issue but if one were operating over
DTN with unscheduled and unpredictable disruptions (e.g. in-theatre)
then it will be difficult for LTP tobe informed of such disruption by
the underlying DTN. In this case the timers won't be frozen. Or am I
getting this wrong?

Dai

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
Sent: 06 September 2005 06:37
To: [email-masked]
Subject: Re: [dtn-interest] LTP over DTN

Dai Stanton wrote:
> In the absence of custody transfer in DTN2, what are the possibilities

> for end-to-end reliability?

Good question: in my mind (and I know there is disagreement on this),
even when Bundle Protocol custody transfer is implemented it's a slim
reed to lean on if you need reliable transmission end-to-end.  As a
second-order safety net it's fine, and it serves some other useful
purposes besides reliability, but I believe efficient reliable
transmission requires relatively efficient retransmission timeout
intervals, and I think the range of environments over which DTN is
designed to operate precludes using any single mechanism to compute
those intervals.  What works better, I think, is to use reliable
convergence-layer protocols that are designed to operate efficiently in
their native environments, so that you get reliable end-to-end
transmission from the concatenation of multiple reliable point-to-point
transmissions.

> LTP looks a reasonable choice but, in order to minimise a flurry of 
> repeated data segments when a disruption period ends, some form of
NACK 
> aggregation (using a fairly short timeout or integration period) would

> be nice. Is there any mechanism for this?

Right, LTP is designed to be one of those reliable convergence-layer
protocols, the one for extremely long round-trip times [or, maybe, for
extremely large bandwidth-delay products; still thinking about that].
There isn't any NACK aggregation device in the protocol, and maybe this
is something we should be planning for, but I don't yet fully understand
the need.

The retransmission system in LTP is very largely lifted from CFDP.  In
the LTP simulation work I know of to date, and in the operational
experience we've had with CFDP so far (in MESSENGER and Deep Impact),
the flurry of retransmissions you're talking about hasn't been a
problem, as far as I know.  If you "freeze" the retransmission timers
whenever a disruption period begins and "thaw" them when it ends, I
would think you shouldn't ever experience this kind of thing: you don't
have to squeeze a lot of retransmission activity into a short time,
because in effect you stretch time out.  Do you have a scenario in mind
that would break this approach?

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

Date: Thu, 8 Sep 2005 16:22:57 -0400 (EDT)
From: "Brian D. Davison" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Google hires Vint Cerf
Sender: [email-masked]

http://www.redherring.com/Article.aspx?a=13507  [and lots of other places]

Fortunately, it also says "Mr. Cerf will continue his work on the
Interplanetary Network."

-- brian

Brian D. Davison, Ph.D.                 http://www.cse.lehigh.edu/~brian/
Assistant Professor                             davison(at)cse.lehigh.edu
Department of Computer Science & Engineering
Lehigh University, 19 Memorial Drive West, Bethlehem, PA 18015   USA

Date: Mon, 05 Sep 2005 22:36:34 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] LTP over DTN
Sender: [email-masked]

Dai Stanton wrote:
> In the absence of custody transfer in DTN2, what are the possibilities 
> for end-to-end reliability?

Good question: in my mind (and I know there is disagreement on this), even when Bundle Protocol custody transfer is implemented it's a slim reed to lean on if you need reliable transmission end-to-end.  As a second-order safety net it's fine, and it serves some other useful purposes besides reliability, but I believe efficient reliable transmission requires relatively efficient retransmission timeout intervals, and I think the range of environments over which DTN is designed to operate precludes using any single mechanism to compute those intervals.  What works better, I think, is to use reliable convergence-layer protocols that are designed to operate efficiently in their native environments, so that you get reliable end-to-end transmission from the concatenation of multiple reliable point-to-point transmissions.

> LTP looks a reasonable choice but, in order to minimise a flurry of 
> repeated data segments when a disruption period ends, some form of NACK 
> aggregation (using a fairly short timeout or integration period) would 
> be nice. Is there any mechanism for this?

Right, LTP is designed to be one of those reliable convergence-layer protocols, the one for extremely long round-trip times [or, maybe, for extremely large bandwidth-delay products; still thinking about that].  There isn't any NACK aggregation device in the protocol, and maybe this is something we should be planning for, but I don't yet fully understand the need.

The retransmission system in LTP is very largely lifted from CFDP.  In the LTP simulation work I know of to date, and in the operational experience we've had with CFDP so far (in MESSENGER and Deep Impact), the flurry of retransmissions you're talking about hasn't been a problem, as far as I know.  If you "freeze" the retransmission timers whenever a disruption period begins and "thaw" them when it ends, I would think you shouldn't ever experience this kind of thing: you don't have to squeeze a lot of retransmission activity into a short time, because in effect you stretch time out.  Do you have a scenario in mind that would break this approach?

Scott

Date: Mon, 5 Sep 2005 23:57:17 +0200 (MEST)
From: Anders Lindgren <[email-masked]>
To: Mirco Musolesi <[email-masked]>
cc: [email-masked], Cecilia Mascolo <[email-masked]>
Subject: Re: [dtn-interest] Comments about PRoPHET Internet Draft
Sender: [email-masked]

Mirco and Cecilia,

Thanks for your comments on our draft.
We agree on several of your comments, and many of them are things that
have been on the todo list for quite some time...

Some comments below.

On Tue, 23 Aug 2005, Mirco Musolesi wrote:

> -2.1.1 Delivery predictability calculation: we believe the method
> suggested is a bit too approximate. Using the aging factor, the
> delivery probability is a decreasing monotonic function. It seems
> that this is not always the case.

Futher improving the estimation accuracy of the delivery predictability
calculation is one of the things we always hope to be able to do...

> We would like to suggest to have a look at our Context-aware Adaptive
> Routing (CAR) paper cited below.
>
> We have introduced a Kalman filter based forecasting mechanisms to
> find the best carriers based on the prediction of the evolution of
> the DTN scenarios. In particular, we have taken into consideration
> the changing rate of connectivity and colocation of the hosts to make
> a decision. Similar mechanisms would fit very well here and would
> offer a smoother prediction strategy in our opinion.

This mechanism looks interesting.

> -2.1.2 Forwading stategies: we are looking into this problem of
> delivering to one or more nodes. Your approach based on thresholds is
> interesting, but in our opinion it is difficult to map the desired
> reliability of the delivery process. In other words, it is difficult
> to find a metric to evaluate the correctness of the decision in terms
> of delivery ratio and of the minimal/best use of the available
> resources.

I am not sure I completely understand what your point is here though. Yes,
it is difficult to evaluate the correctness of the decisions made (and
even more so: it is difficult to determine what "correct" means here
(unless we are able to compute the optimal solution in an offline manner
and compare the decision to that, and that isn't all that useful)), but we
still need to make decisions, and we believe that not all networks are
created equal, and thus the same action might not always be appropriate
(it could even be possible that depending on the class of service
requested by a particular bundle, different bundles should be treated
differently).
One intention with not firmly specify the forwarding behaviour in the
description of the protocol itself, but to contain it in "forwarding
strategies" was to allow new strategies to be devised to fit the needs of
a particular node or scenario (while it is still important to define some
"default" forwarding strategies to choose from).

> -3. Operation: in the paper cited above we use DSDV as an underlying
> routing to disseminate information about hosts that are in the same
> island of connectivity, ie this means that a message can be given to
> a carrier which might be more than one hop away. We believe that this
> increases the probability of delivery, since it is possible to choose
> among more candidates to act as bundle carriers.  We think that a
> similar underlying routing protocol can be introduced in PRoPHET too.

I agree.
Our goal for the protocol has always been that it in some future version
should be able to better cope with larger islands of connected nodes,
possibly through some underlying routing protocol, but preferrably as a
part of the protocol itself. Ideally, the protocol should work like it
does now in scenarios where connectivity is very intermittent, but also be
able to cope with completely or partially connected networks in a good way
(hopefully with performance comparable to some "normal" ad hoc routing
protocol in the case of complete connectivity).

We look forward to continued discussions with you regarding this.

Best regards,

/Anders

From: "Dai Stanton" <[email-masked]>
To: <[email-masked]>
Date: Mon, 5 Sep 2005 15:05:49 +0100
Importance: Normal
Subject: [dtn-interest] LTP over DTN
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C5B22B.520E1680
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In the absence of custody transfer in DTN2, what are the possibilities
for end-to-end reliability? 
 
LTP looks a reasonable choice but, in order to minimise a flurry of
repeated data segments when a disruption period ends, some form of NACK
aggregation (using a fairly short timeout or integration period) would
be nice. Is there any mechanism for this?
 
Dai

------=_NextPart_000_000E_01C5B22B.520E1680
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the absence of custody transfer in DTN2, what are =
the possibilities
for end-to-end reliability? <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>LTP looks a reasonable choice but, in order to =
minimise a
flurry of repeated data segments when a disruption period ends, some =
form of
NACK aggregation (using a fairly short timeout or integration period) =
would be
nice. Is there any mechanism for this?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dai<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000E_01C5B22B.520E1680--

Date: Fri, 2 Sep 2005 19:05:36 -0400
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] Official UDP Port# assigned for LTP
Sender: [email-masked]

--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi folks,

  Just a cool FYI. I had turned in a request to IANA for having a UDP port#
assigned for LTP. My implementation operates over UDP/IP and I know that few
other implementations in progress are doing so too.=20

  Just got a mail from IANA informing that TCP/UDP port# 1113 has been
assigned for "ltp-deepspace".

- Mani.

----- Forwarded message from [email-masked] -----

Date: Fri, 2 Sep 2005 10:35:22 -0700
To: [email-masked]
Subject: Application for port-number: ltp-deepspace (Assigned-1113) [I06-05=
0817-0004]
From: [email-masked]
Reply-To: [email-masked]
CC:=20
X-Spam-Status: No, hits=3D0.8 required=3D5.0
	tests=3DNO_REAL_NAME
	version=3D2.55
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)

Dear Manikantan Ramadas,

We have assigned the following user port number with you as the point of co=
ntact:

ltp-deepspace   1113/tcp   Licklider Transmission Pr
ltp-deepspace   1113/udp   Licklider Transmission Pr
#                          Manikantan Ramadas &lt;[email-masked]=
&gt; September 2005

See: &lt;http://www.iana.org/assignments/port-numbers&gt;

Please notify the IANA if there is a change in contact information by compl=
eting the following template:

&lt;http://www.iana.org/cgi-bin/mod_portno.pl&gt;

Thank you,

Pearl Liang
IANA=20

***************************************************************
Internet Assigned Numbers Authority (IANA)
4676 Admiralty Way, Suite 330
Marina del Rey, California 90292

Voice: (310) 823-9358
FAX:   (310) 823-8649
email: [email-masked]
***************************************************************

----- End forwarded message -----

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

_______________________________________________
ltp mailing list
[email-masked]
http://irg.cs.ohiou.edu/mailman/listinfo/ltp

----- End forwarded message -----

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature
Content-Disposition: inline

--IS0zKkzwUGydFO0o--

To: [email-masked]
Date: Fri, 02 Sep 2005 08:52:57 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] cross-post
Sender: [email-masked]

got this from another list... -k

------- Forwarded Message

>
> From:  Chris Wilson <[email-masked]>
> To:    TIER <[email-masked]>
> Subject: [TIER] Loband V2 Released!
> Date:  Fri, 02 Sep 2005 16:28:21 BST
>
> Hi all,
> 
> I have been following TIER with interest for nearly a year. Am I right
> that you are testing a new WiFi stack for long range use, and running
> VoIP over that link? I hope that this announcement is relevant and
> useful to you. 
> 
> Loband is a free service, designed specifically to improve access to
> online information over slow connections. 
> 
> The newest version of the Loband service is now accessible at
> http://www.loband.org . It can reduce the time it takes for a web page
> to load by up to 10 times, making Internet access easier and less
> expensive in low bandwidth environments. 
> 
> Using the service is as simple as going to http://www.loband.org and
> typing in the address of the desired page. Loband will then present a
> simplified version of that page. Loband works by removing unnecessary
> adverts and graphics while retaining the text, links and layout of the
> site. The original page or individual images can be viewed at any time
> if desired. 
> 
> The latest version of Loband supports more websites than ever before,
> including those featuring international character sets. 
> 
> The service has been developed as an open source project by Aidworld
> (http://www.aidworld.org), an NGO specialising in the field of ICT for
> Development. Aidworld would very much welcome comments and feedback to
> further improve this service. You can contact us at [email-masked] 
> 
> Cheers, Chris.
> -- 
> (aidworld) chris wilson | chief engineer ([email-masked])
> 
> _______________________________________________
> TIER mailing list
> [email-masked]
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tier

------- End of Forwarded Message