Subject: Re: [dtn-interest] Calling for Peer review and Comments: DTN summer research report
From: Stephen Farrell <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 Oct 2003 12:50:43 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Durga,

 > I did not follow what you meant by "the dutycycles of the various nodes
 > and layers are out of whack."
 > Yes, what Scott had pointed out were the types of contacts; thanks for
 > pointing out. I am however not clear about the notion of different types
 > of schedules, though. Could you elaborate a bit?

Sure.

My rather basic schedules consist of a sequence of relatively
timed transmitter events, like  "t=261,es=0,l=0,sc=1,connup"
which means at 261 seconds start earthstation zero
trasmitting up to spacecraft 1 in locale (aka region) 0.
(An artefact of the simulation ensures that a receiver
state change happens one ltt later). The last string ("connup")
says "make a connection upwards", the other commands are fairly
obvious ("discup" - disconnect upwards connection, "conndn",
"discdn").

Since the times are relative, I need to repeat the sequence,
at a period which I call the dutycycle. (Even if I'd used
absolute times, there'd almost certainly be cycles involved
in any case.)

There are also cycle times involved with the sensors, for example
a sensor may take a measure periodically. Similarly, sink
nodes send commands periodically (though I may introduce some
random jitter there). Whenever I add visibility considerations
to the simulation, then there'll be orbit related cycles too.

These cycles can make life difficult (i.e. introduce delays
or even packet loss) if they're out of whack. Say if a sink node
always sends its commands when there's no upwards connection
then those commands will have worse latency than if they didn't
need buffering.

In terms of different types of schedule, I guess I should have
said different algorithms for generating schedules. To give a
simple example, I've just added an option to my basic schedule
generation algorithm which attempts to fill in all gaps it
can in order to keep the earthstations busy. Another option (not
yet implemented) would take account of SC power usage, etc. etc.
So I'll end up with lots of ways to generate schedules and each
will produce a different metric for the set of nodes, sensors
and sinks involved (when/if I figure out a metric).

Hope that helps,
Stephen.

Durga Prasad Pandey wrote:
> 
>  

>  
> Durga
>  
> /-------Original Message-------/
>  
> /*From:*/ Stephen Farrell <mailto:[email-masked]>
> /*Date:*/ Wednesday, October 29, 2003 06:36:45 PM
> /*To:*/ Durga Prasad Pandey <mailto:[email-masked]>
> /*Cc:*/ [email-masked] 
> <mailto:[email-masked]>
> /*Subject:*/ Re: [dtn-interest] Calling for Peer review and Comments: 
> DTN summer research report
>  
> 
> Durga,
> 
>  > If we talk of comparing the efficiency of two networks, we need to
>  > define what we mean by efficiency in the first place (perhaps you
>  > already have some definition in your mind). Secondly, when you say two
>  > DTNs, do you mean two DTNs of the same kind(such as two sensor networks)
>  > or DTNs of different kinds(such as a sensor network and a military
>  > battlefield network)? I presume it is the first; perhaps you will 
> clarify.
> 
> Currently I'm looking at comparisons where everything's the same
> other than the scheduling. And so far I've played with IPN-like
> simulations and it can make a big difference if the dutycycles
> of the various nodes and layers are out of whack (which tends to
> argue that app/transport/network or whatever layering may be
> problematic here unless there's feedback from the lower layers
> to the higher layers as to what's happening - mind you the same's
> true of the Internet in some ways - it'd often be nice to know
> if a packet is really going via a VPN tunnel or some QoS'd up
> link or whatever).
> 
> If I knew how to make a good comparison (which I don't), then
> I guess you might be able to extend it to cover cases where there's
> less in common between the networks. OTOH, in the DTN/IPN case the
> scheduling more or less defines a network topology, so I'm
> already trying to compare potentially fairly different networks.
> 
> In terms of what measurements I'm making so far, I've got the
> simulations recording lots of stuff (rtt, uptimes, downtimes,
> sensor delays, channel delays, ltt, etc. as well as counting
> the bits that get back to the sinks). Nothing you could stand
> over as a metric yet though, as I said, but I continue to
> play about with it.
> 
>  > I think it might be worthwhile to experiment with different **kinds** of
>  > schedules as well. Scott had articulated 5 types of schedules in a late
>  > April posting on this list.
> 
> Weren't they different types of contact? If so, I'd expect that
> a single schedule could use all types as appropriate. Must check
> back though.
> 
> Stephen.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked] <mailto:[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* - *_Click Here_* 
> <http://www.incredimail.com/redir.asp?ad_id=309&lang=9>

Date: Thu, 30 Oct 2003 15:17:11 +0530 (India Standard Time)
From: "Durga Prasad Pandey" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [dtn-interest] Calling for Peer review and Comments: DTN summer research report
Sender: [email-masked]

--------------Boundary-00=_NUDKWCW0000000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_NUDKRN00000000000000"

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

=0D
I did not follow what you meant by "the dutycycles of the various nodes a=
nd
layers are out of whack."=0D
Yes, what Scott had pointed out were the types of contacts; thanks for
pointing out. I am however not clear about the notion of different types =
of
schedules, though. Could you elaborate a bit?=0D
=0D
Durga=0D
=0D
-------Original Message-------=0D
=0D
From: Stephen Farrell=0D
Date: Wednesday, October 29, 2003 06:36:45 PM=0D
To: Durga Prasad Pandey=0D
Cc: [email-masked]=0D
Subject: Re: [dtn-interest] Calling for Peer review and Comments: DTN sum=
mer
research report=0D
=0D
Durga,=0D
=0D
> If we talk of comparing the efficiency of two networks, we need to =0D
> define what we mean by efficiency in the first place (perhaps you =0D
> already have some definition in your mind). Secondly, when you say two =
=0D
> DTNs, do you mean two DTNs of the same kind(such as two sensor networks=
) =0D
> or DTNs of different kinds(such as a sensor network and a military =0D
> battlefield network)? I presume it is the first; perhaps you will clari=
fy.=0D
=0D
Currently I'm looking at comparisons where everything's the same=0D
other than the scheduling. And so far I've played with IPN-like=0D
simulations and it can make a big difference if the dutycycles=0D
of the various nodes and layers are out of whack (which tends to=0D
argue that app/transport/network or whatever layering may be=0D
problematic here unless there's feedback from the lower layers=0D
to the higher layers as to what's happening - mind you the same's=0D
true of the Internet in some ways - it'd often be nice to know=0D
if a packet is really going via a VPN tunnel or some QoS'd up=0D
link or whatever).=0D
=0D
If I knew how to make a good comparison (which I don't), then=0D
I guess you might be able to extend it to cover cases where there's=0D
less in common between the networks. OTOH, in the DTN/IPN case the=0D
scheduling more or less defines a network topology, so I'm=0D
already trying to compare potentially fairly different networks.=0D
=0D
In terms of what measurements I'm making so far, I've got the=0D
simulations recording lots of stuff (rtt, uptimes, downtimes,=0D
sensor delays, channel delays, ltt, etc. as well as counting=0D
the bits that get back to the sinks). Nothing you could stand=0D
over as a metric yet though, as I said, but I continue to=0D
play about with it.=0D
=0D
> I think it might be worthwhile to experiment with different **kinds** o=
f =0D
> schedules as well. Scott had articulated 5 types of schedules in a late=
 =0D
> April posting on this list.=0D
=0D
Weren't they different types of contact? If so, I'd expect that=0D
a single schedule could use all types as appropriate. Must check=0D
back though.=0D
=0D
Stephen.=0D
=0D
_______________________________________________=0D
dtn-interest mailing list=0D
[email-masked]=0D
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
--------------Boundary-00=_NUDKRN00000000000000
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 X-FV=
ER=3D"2.0" ORGYPOS=3D"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>&nbsp;</DIV>
      <DIV>I did not follow what you meant by "the dutycycles of the vari=
ous=20
      nodes and layers are out of whack."</DIV>
      <DIV>Yes, what Scott had pointed out were the types of contacts; th=
anks=20
      for pointing out.&nbsp;I am however not clear about the notion of=20
      different types of schedules, though. Could you elaborate a bit?</D=
IV>
      <DIV>&nbsp;</DIV>
      <DIV>Durga</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]">Stephen Farrell</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Date:</B></I> Wednes=
day,=20
      October 29, 2003 06:36:45 PM</DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>To:</B></I> <A=20
      href=3D"mailto:[email-masked]">Durga Prasad Pandey</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Cc:</B></I> <A=20
      href=3D"mailto:[email-masked]">dtn-interest@mailman=
=2Edtnrg.org</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Subject:</B></I> Re:=
=20
      [dtn-interest] Calling for Peer review and Comments: DTN summer res=
earch=20
      report</DIV></DIV>
      <DIV>&nbsp;</DIV>
      <P>Durga,<BR><BR>&gt; If we talk of comparing the efficiency of two=
=20
      networks, we need to <BR>&gt; define what we mean by efficiency in =
the=20
      first place (perhaps you <BR>&gt; already have some definition in y=
our=20
      mind). Secondly, when you say two <BR>&gt; DTNs, do you mean two DT=
Ns of=20
      the same kind(such as two sensor networks) <BR>&gt; or DTNs of diff=
erent=20
      kinds(such as a sensor network and a military <BR>&gt; battlefield=20
      network)? I presume it is the first; perhaps you will=20
      clarify.<BR><BR>Currently I'm looking at comparisons where everythi=
ng's=20
      the same<BR>other than the scheduling. And so far I've played with=20
      IPN-like<BR>simulations and it can make a big difference if the=20
      dutycycles<BR>of the various nodes and layers are out of whack (whi=
ch=20
      tends to<BR>argue that app/transport/network or whatever layering m=
ay=20
      be<BR>problematic here unless there's feedback from the lower layer=
s<BR>to=20
      the higher layers as to what's happening - mind you the same's<BR>t=
rue of=20
      the Internet in some ways - it'd often be nice to know<BR>if a pack=
et is=20
      really going via a VPN tunnel or some QoS'd up<BR>link or=20
      whatever).<BR><BR>If I knew how to make a good comparison (which I =
don't),=20
      then<BR>I guess you might be able to extend it to cover cases where=
=20
      there's<BR>less in common between the networks. OTOH, in the DTN/IP=
N case=20
      the<BR>scheduling more or less defines a network topology, so=20
      I'm<BR>already trying to compare potentially fairly different=20
      networks.<BR><BR>In terms of what measurements I'm making so far, I=
've got=20
      the<BR>simulations recording lots of stuff (rtt, uptimes,=20
      downtimes,<BR>sensor delays, channel delays, ltt, etc. as well as=20
      counting<BR>the bits that get back to the sinks). Nothing you could=
=20
      stand<BR>over as a metric yet though, as I said, but I continue to<=
BR>play=20
      about with it.<BR><BR>&gt; I think it might be worthwhile to experi=
ment=20
      with different **kinds** of <BR>&gt; schedules as well. Scott had=20
      articulated 5 types of schedules in a late <BR>&gt; April posting o=
n this=20
      list.<BR><BR>Weren't they different types of contact? If so, I'd ex=
pect=20
      that<BR>a single schedule could use all types as appropriate. Must=20
      check<BR>back=20
      though.<BR><BR>Stephen.<BR><BR>____________________________________=
___________<BR>dtn-interest=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></P></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:FAEDCB67-F671-4172-B958-D9682799C623" 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=_NUDKRN00000000000000--

--------------Boundary-00=_NUDKWCW0000000000000
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <FAEDCB67-F671-4172-B958-D9682799C623>

--------------Boundary-00=_NUDKWCW0000000000000--

To: [email-masked]
Date: Wed, 29 Oct 2003 18:28:28 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] some announcements
Sender: [email-masked]

Greetings dtn-interest people:

I have updated the web page (http://www.dtnrg.org) with links to a few new things:

	updated Internet Drafts
	instructions on how to obtain CVS-based "bleeding edge" code snapshots
	link to a BugZilla server used for tracking DTN reference code bugs
	a few other links to papers and project sites

Go ahead and have a look.  Please let me know if you have any problems, or
if there are other links you would like to have added.

- Kevin

Date: Wed, 29 Oct 2003 13:11:09 +0000
From: Stephen Farrell <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Calling for Peer review and Comments: DTN summer research report
Sender: [email-masked]

Durga,

> If we talk of comparing the efficiency of two networks, we need to 
> define what we mean by efficiency in the first place (perhaps you 
> already have some definition in your mind). Secondly, when you say two 
> DTNs, do you mean two DTNs of the same kind(such as two sensor networks) 
> or DTNs of different kinds(such as a sensor network and a military 
> battlefield network)? I presume it is the first; perhaps you will clarify.

Currently I'm looking at comparisons where everything's the same
other than the scheduling. And so far I've played with IPN-like
simulations and it can make a big difference if the dutycycles
of the various nodes and layers are out of whack (which tends to
argue that app/transport/network or whatever layering may be
problematic here unless there's feedback from the lower layers
to the higher layers as to what's happening - mind you the same's
true of the Internet in some ways - it'd often be nice to know
if a packet is really going via a VPN tunnel or some QoS'd up
link or whatever).

If I knew how to make a good comparison (which I don't), then
I guess you might be able to extend it to cover cases where there's
less in common between the networks. OTOH, in the DTN/IPN case the
scheduling more or less defines a network topology, so I'm
already trying to compare potentially fairly different networks.

In terms of what measurements I'm making so far, I've got the
simulations recording lots of stuff (rtt, uptimes, downtimes,
sensor delays, channel delays, ltt, etc. as well as counting
the bits that get back to the sinks). Nothing you could stand
over as a metric yet though, as I said, but I continue to
play about with it.

> I think it might be worthwhile to experiment with different **kinds** of 
> schedules as well. Scott had articulated 5 types of schedules in a late 
> April posting on this list.

Weren't they different types of contact? If so, I'd expect that
a single schedule could use all types as appropriate. Must check
back though.

Stephen.

Date: Tue, 28 Oct 2003 23:02:18 +0530 (India Standard Time)
From: "Durga Prasad Pandey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Calling for Peer review and Comments: DTN summer research report
Sender: [email-masked]

--------------Boundary-00=_U1AHQL80000000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_U1AHLVC0000000000000"

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

Hi, Stephen:=0D
=0D
You have raised an interesting question.=0D
=0D
When I talked about an _efficient IPN_ in my report, I mainly meant to sa=
y
that IPN network shouldn't get held up, which could be due to different
causes, but my main concern was congestion. I was mainly thinking in term=
s
of the InterPlanetary Internet, since that is the place where humans aren=
't
present(at least in the foreseeable future) to identify and fix problems.=
 My
ultimate vision of the IPN is that of a self managing network which handl=
es
troubleshooting automatically. Once we have a sizeable IPN network in pla=
ce,
making the computer say "Houston, we have a problem" everytime there is a
glitch might not be a good idea. It would be preferable to let the networ=
k
take care of itself as far as possible.=0D
=0D
If we talk of comparing the efficiency of two networks, we need to define
what we mean by efficiency in the first place (perhaps you already have s=
ome
definition in your mind). Secondly, when you say two DTNs, do you mean tw=
o
DTNs of the same kind(such as two sensor networks) or DTNs of different
kinds(such as a sensor network and a military battlefield network)? I
presume it is the first; perhaps you will clarify.=0D
=0D
I think it might be worthwhile to experiment with different **kinds** of
schedules as well. Scott had articulated 5 types of schedules in a late
April posting on this list.=0D
=0D
I will look at your paper shortly. Thanks for sparing your time for the
review.=0D
=0D
Durga=0D
=0D
-------Original Message-------=0D
=0D
From: Stephen Farrell=0D
Date: Tuesday, October 28, 2003 06:30:08 PM=0D
To: Durga Prasad Pandey=0D
Cc: [email-masked]=0D
Subject: Re: [dtn-interest] Calling for Peer review and Comments: DTN sum=
mer
research report=0D
=0D
Hi Durga,=0D
=0D
Nice report. (Let me know if the simulation stuff I sent links=0D
for is any help to you - I'd be happy to munge it about a bit=0D
for you if you wanted.)=0D
=0D
You mention an issue I also came across and for which I haven't=0D
been able to find a good answer: how to compare the efficiency=0D
of two (DTN) networks?=0D
=0D
In my case I'm interested in how different schedules impact on=0D
the overall efficiency of an IPN, so I'd like to be able to=0D
use the same base configuration (of nodes, traffic patterns...)=0D
and run simulations with different schedules and then rank the=0D
results according to some well-defined measure of the efficiency=0D
of a network. (Currently, I'm just measuring how many bits get=0D
back to each sink node - which does give a number, but not a=0D
very satisfactory one.)=0D
=0D
Cheers,=0D
Stephen.=0D
=0D
=0D
Durga Prasad Pandey wrote:=0D
> Hi DTN Fans:=0D
> =0D
> Last summer, I performed research on congestion issues in DTNs, as a =0D
> result of which we have come up with a proposal for an experiment to =0D
> test the effectiveness of a cognition based congestion detection daemon=
=2E=0D
> =0D
> Could I invite you to go through the report, which is available at:=0D
> http://www.geocities.com/dpsmiles/Report4.1.pdf=0D
> and post in your comments to this list. =0D
> =0D
> Thanks for your time. I look forward to a lively discussion and many =0D
> comments and suggestions.=0D
> =0D
> Best regards,=0D
> Durga=0D
> =0D
> =0D
> =0D
> =0D
> Durga Prasad Pandey=0D
> Assistant Online Editor, ACM Crossroads=0D
> http://www.acm.org/crossroads/=0D
> Indian School of Mines=0D
> 47 Emerald Hostel=0D
> Dhanbad 826004 India=0D
> [email-masked]=0D
> DP's inn: http://geocities.com/dpsmiles/=0D
>=20
--------------Boundary-00=_U1AHLVC0000000000000
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"><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dis=
o-8859-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=3D"yes" X-=
FVER=3D"2.0" ORGYPOS=3D"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>Hi, Stephen:</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>You have raised&nbsp;an interesting question.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>When I talked about an _efficient IPN_&nbsp;in my report, I ma=
inly=20
      meant to say that&nbsp;IPN network shouldn't get held up, which cou=
ld be=20
      due to different causes, but my main concern was congestion.&nbsp;I=
 was=20
      mainly thinking&nbsp;in terms of the&nbsp;InterPlanetary Internet, =
since=20
      that is the place where humans aren't present(at least in the fores=
eeable=20
      future) to identify and fix problems. My ultimate vision of the IPN=
=20
      is&nbsp;that of a&nbsp;self managing network which handles troubles=
hooting=20
      automatically. Once we have a sizeable IPN network in place, making=
 the=20
      computer say "Houston, we have a problem" everytime there is a glit=
ch=20
      might not be a good idea. It would be preferable to&nbsp;let the ne=
twork=20
      take care of itself as far as possible.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>If we talk of comparing the efficiency of two networks, we nee=
d to=20
      define what we mean by&nbsp;efficiency in the first place (perhaps =
you=20
      already have some definition in your mind). Secondly, when you say =
two=20
      DTNs, do you mean two DTNs of the same kind(such as two sensor netw=
orks)=20
      or DTNs of different kinds(such as a sensor network and a military=20
      battlefield network)? I presume it is the first; perhaps you will=20
      clarify.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>I think it might be worthwhile to experiment with different **=
kinds**=20
      of schedules as well.&nbsp;Scott had articulated 5 types of schedul=
es in a=20
      late April posting on this list.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>I will look at your paper shortly. Thanks for sparing your=20
      time&nbsp;for the review.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Durga</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]">Stephen Farrell</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Date:</B></I> Tuesda=
y, October=20
      28, 2003 06:30:08 PM</DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>To:</B></I> <A=20
      href=3D"mailto:[email-masked]">Durga Prasad Pandey</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Cc:</B></I> <A=20
      href=3D"mailto:[email-masked]">dtn-interest@mailman=
=2Edtnrg.org</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Subject:</B></I> Re:=
=20
      [dtn-interest] Calling for Peer review and Comments: DTN summer res=
earch=20
      report</DIV></DIV>
      <DIV>&nbsp;</DIV>Hi Durga,<BR><BR>Nice report. (Let me know if the=20
      simulation stuff I sent links<BR>for is any help to you - I'd be ha=
ppy to=20
      munge it about a bit<BR>for you if you wanted.)<BR><BR>You mention =
an=20
      issue I also came across and for which I haven't<BR>been able to fi=
nd a=20
      good answer: how to compare the efficiency<BR>of two (DTN)=20
      networks?<BR><BR>In my case I'm interested in how different schedul=
es=20
      impact on<BR>the overall efficiency of an IPN, so I'd like to be ab=
le=20
      to<BR>use the same base configuration (of nodes, traffic=20
      patterns...)<BR>and run simulations with different schedules and th=
en rank=20
      the<BR>results according to some well-defined measure of the=20
      efficiency<BR>of a network. (Currently, I'm just measuring how many=
 bits=20
      get<BR>back to each sink node - which does give a number, but not=20
      a<BR>very satisfactory one.)<BR><BR>Cheers,<BR>Stephen.<BR><BR><BR>=
Durga=20
      Prasad Pandey wrote:<BR>&gt; Hi DTN Fans:<BR>&gt; <BR>&gt; Last sum=
mer, I=20
      performed research on congestion issues in DTNs, as a <BR>&gt; resu=
lt of=20
      which we have come up with a proposal for an experiment to <BR>&gt;=
 test=20
      the effectiveness of a cognition based congestion detection=20
      daemon.<BR>&gt; <BR>&gt; Could I invite you to go through the repor=
t,=20
      which is available at:<BR>&gt; <A=20
      href=3D"http://www.geocities.com/dpsmiles/Report4.1.pdf">http://www=
=2Egeocities.com/dpsmiles/Report4.1.pdf</A><BR>&gt;=20
      and post in your comments to this list. <BR>&gt; <BR>&gt; Thanks fo=
r your=20
      time. I look forward to a lively discussion and many <BR>&gt; comme=
nts and=20
      suggestions.<BR>&gt; <BR>&gt; Best regards,<BR>&gt; Durga<BR>&gt; <=
BR>&gt;=20
      <BR>&gt; <BR>&gt; <BR>&gt; Durga Prasad Pandey<BR>&gt; Assistant On=
line=20
      Editor, ACM Crossroads<BR>&gt; <A=20
      href=3D"http://www.acm.org/crossroads/">http://www.acm.org/crossroa=
ds/</A><BR>&gt;=20
      Indian School of Mines<BR>&gt; 47 Emerald Hostel<BR>&gt; Dhanbad 82=
6004=20
      India<BR>&gt; <A=20
      href=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt; DP's =
inn: <A=20
      href=3D"http://geocities.com/dpsmiles/">http://geocities.com/dpsmil=
es/</A><BR>&gt;=20
      <BR></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><FONT face=3D"Arial, Helvetica, sans-serif"=20
size=3D2></FONT> <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:626B4A99-CEC3-433D-8787-8395607D9384" 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=_U1AHLVC0000000000000--

--------------Boundary-00=_U1AHQL80000000000000
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <626B4A99-CEC3-433D-8787-8395607D9384>

--------------Boundary-00=_U1AHQL80000000000000--

Date: Tue, 28 Oct 2003 12:52:30 +0000
From: Stephen Farrell <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Calling for Peer review and Comments: DTN summer research report
Sender: [email-masked]

Hi Durga,

Nice report. (Let me know if the simulation stuff I sent links
for is any help to you - I'd be happy to munge it about a bit
for you if you wanted.)

You mention an issue I also came across and for which I haven't
been able to find a good answer: how to compare the efficiency
of two (DTN) networks?

In my case I'm interested in how different schedules impact on
the overall efficiency of an IPN, so I'd like to be able to
use the same base configuration (of nodes, traffic patterns...)
and run simulations with different schedules and then rank the
results according to some well-defined measure of the efficiency
of a network. (Currently, I'm just measuring how many bits get
back to each sink node - which does give a number, but not a
very satisfactory one.)

Cheers,
Stephen.

Durga Prasad Pandey wrote:
> Hi DTN Fans:
>  
> Last summer, I performed research on congestion issues in DTNs, as a 
> result of which we have come up with a proposal for an experiment to 
> test the effectiveness of a cognition based congestion detection daemon.
>  
> Could I invite you to go through the report, which is available at:
> http://www.geocities.com/dpsmiles/Report4.1.pdf
> and post in your comments to this list. 
>  
> Thanks for your time. I look forward to a lively discussion and many 
> comments and suggestions.
>  
> Best regards,
> 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!?
> The New Yahoo! Shopping 
> <http://shopping.yahoo.com/?__yltc=s%3A150000443%2Cd%3A22708228%2Cslk%3Atext%2Csec%3Amail> 
> - with improved product search

Date: Tue, 28 Oct 2003 12:40:44 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] some simulation stuff
Sender: [email-masked]

Since I've just complained about the recent meta-discussion,
I guess the onus is on me to paint a target on my forehead.

So, here's a paper [1] about some DTN/IPN simulation stuff
I've been working on (code etc. at [2] if you want to play).
Not ground breaking stuff, but I hope it'll turn out
interesting in the end.

All comments welcome,

Cheers,
Stephen.

PS: I highly recommend the OMNET simulation package [3], seems
way better that what I've heard about ns-2.

[1] http://down.dsg.cs.tcd.ie/rast2003/sf-rast-paper-FINAL.pdf
[2] http://down.dsg.cs.tcd.ie/rast2003/rast.tgz (20Mb!, code,
     output etc.)
[3] http://www.omnetpp.org/

Date: Tue, 28 Oct 2003 12:31:08 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Folks,

Does all this dicussion of analogies and the fact that
analogies are good for explaining but often useless or
misleading when developing something mean that we're
finished developing the DTN architecture and protocols?

Be nice if it were the case. It isn't. So how about
saving the big discussions of analogies 'till we've
some more concrete stuff to explain? (Or a marketing
department, whichever:-)

Regards,
Stephen.

Date: Tue, 28 Oct 2003 08:40:24 +0530 (India Standard Time)
From: "Durga Prasad Pandey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

--------------Boundary-00=_C56GQL80000000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_C56GLVC0000000000000"

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

I fully agree with Lloyd. The postal system appears to be the best analog=
y
to me, and we have been using it with good success(eg., see Kevin's lates=
t
paper on DTN).=0D
=0D
Calling DTN "email" is somewhat like calling a bus a car.  Yes, both are
automobiles; one could go on debating that there are similarities, so "in
essence" a bus is also a car; but we don't do that, do we ? Perhaps the
automotive guys are wiser at resolving such conflicts :-)=0D
=0D
Durga=0D
=0D
-------Original Message-------=0D
=0D
From: Lloyd Wood=0D
Date: Monday, October 27, 2003 11:33:25 PM=0D
To: Charlie Younghusband=0D
Cc: Warthman Associates; Fall, Kevin R; Scott Burleigh; dtn-interest@mail=
man
ipnrg.org=0D
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone=0D
=0D
On Mon, 27 Oct 2003, Charlie Younghusband wrote:=0D
=0D
> It seems to me that using terms that don't require history lessons woul=
d=0D
> make more sense.=0D
=0D
DTN. It's a bit like a bunch of postal services relaying mail and=0D
packages internationally. The packages sit around waiting to be moved,=0D
and get there eventually, because the postal services are cooperating=0D
in taking responsibility for their 'store and forward' bits.=0D
=0D
L.=0D
=0D
<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>=0D
_______________________________________________=0D
dtn-interest mailing list=0D
[email-masked]=0D
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
--------------Boundary-00=_C56GLVC0000000000000
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"><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dis=
o-8859-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=3D"yes" X-=
FVER=3D"2.0" ORGYPOS=3D"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>I fully agree with Lloyd.&nbsp;The postal system appears to be=
 the=20
      best analogy to me, and we have been using it with good success(eg.=
, see=20
      Kevin's latest paper on DTN).</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Calling DTN "email" is somewhat like calling a&nbsp;bus a car.=
=20
      &nbsp;Yes, both are automobiles; one could go on debating that ther=
e are=20
      similarities, so "in essence" a bus is also a car; but we don't do =
that,=20
      do we ? Perhaps the automotive guys are wiser at resolving such con=
flicts=20
      :-)</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Durga</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]">Lloyd Wood</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Date:</B></I> Monday=
, October=20
      27, 2003 11:33:25 PM</DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>To:</B></I> <A=20
      href=3D"mailto:[email-masked]">Charlie Younghusband</A></DIV>
      <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Cc:</B></I> <A=20
      href=3D"mailto:[email-masked]">Warthman Associates</A>; <A=20
      href=3D"mailto:[email-masked]">Fall, Kevin R</A>; <A=20
      href=3D"mailto:[email-masked]">Scott Burleigh</A>; <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> RE:=
=20
      [dtn-interest] Protocol layering in the IPN backbone</DIV></DIV>
      <DIV>&nbsp;</DIV>On Mon, 27 Oct 2003, Charlie Younghusband=20
      wrote:<BR><BR>&gt; It seems to me that using terms that don't requi=
re=20
      history lessons would<BR>&gt; make more sense.<BR><BR>DTN. It's a b=
it like=20
      a bunch of postal services relaying mail and<BR>packages internatio=
nally.=20
      The packages sit around waiting to be moved,<BR>and get there event=
ually,=20
      because the postal services are cooperating<BR>in taking responsibi=
lity=20
      for their 'store and forward' bits.<BR><BR>L.<BR><BR>&lt;<A=20
      href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.=
surrey.ac.uk/Personal/L.Wood/</A>&gt;&lt;<A=20
      href=3D"mailto:[email-masked]">[email-masked]</A>&g=
t;<BR>_______________________________________________<BR>dtn-interest=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><FONT face=3D"Arial, Helvetica, sans-serif"=20
size=3D2></FONT> <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:4C715ABA-449C-4510-A68D-B8F5D3B5410F" 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=_C56GLVC0000000000000--

--------------Boundary-00=_C56GQL80000000000000
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <4C715ABA-449C-4510-A68D-B8F5D3B5410F>

--------------Boundary-00=_C56GQL80000000000000--

Date: Mon, 27 Oct 2003 17:45:06 -0500
From: Eric Travis <[email-masked]>
To: Micah Beck <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Micah Beck wrote:

>How about "asyncrhonous messaging" or "asynchronous networking"?
>
>  
>
I too had initially included the "asynchronous" qualifier, but it
seemed like an unneccessary restriction on the service model.
My 'inner editor' was terribly pleased when I dropped it.

In the case of a DTN, my feeling is that 'messaging' is the more
appropriate descriptor - and will more rapidly lead folks to the
appropriate related works and prior art.

The "like the postal system with ..." and "like e-mail with ..."
analogies are good, but both are merely example instantiations
of messaging (and even within those two there are many
variations on the theme, each of which brings its own set
of baggage).

Analogies like 'e-mail' (or my favorite - the postal system)
work great until they break-down and lots of time, effort
and e-mails are expended explaining away the inevitable
air-gaps.

Date: Mon, 27 Oct 2003 12:18:05 -0800
To: Craig Partridge <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Cc: [email-masked]
Sender: [email-masked]

At 11:22 AM 10/27/2003, Craig Partridge wrote:

>In message <[email-masked]>, Warthman 
>Associa
>tes writes:
>
> >Yes, getting email between servers is often a multihop activity, but so is
> >getting *any* kind of data across an Internet, email data or other data. I
> >think most email users will regard the multihop path not as the essential
> >characteristic of email but as the "in between stuff" that connects their
> >respective email servers (the centers of their respective star topologies).
>
>Perhaps I'm tired but I view that as an uninformed comment.
>
>There's a huge distinction between:
>
>     * an application layer protocol that is multi-hop (which email is); and
>
>     * an underlying layer (e.g. IP) which is multi-hop.
>
>Most Internet applications (file transfer, remote login, web, etc.) are
>point-to-point applications layered on a multi-hop layer.
>
>Email is a multi-hop application layered on a multi-hop layer.

You are right; I was not aware of this layering. I appreciate your 
clarification, but I would guess that most people not familiar with 
network-protocol development will also be unaware of it. It's not obvious 
from an end-user's perspective. The store-and-forward workings of the 
postal system, by contrast, are well known to the general population.

>There's a big difference and if you go back and look at network designs
>from the 1970s and 1980s you'll see some of them (e.g. USENET vs. BITNET
>vs. CSNET vs. Internet).
>
>One of the nice things is that we've managed to hide much of the multi-hop
>complexity from users (not all -- see Received lines and email returned
>from Postmasters at wierd places).  But we should not forget that the
>complexit is there and that we had to engineer around it.
>
>Craig

From: "Micah Beck" <[email-masked]>
To: "Craig Partridge" <[email-masked]>, "Warthman Associates" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Date: Mon, 27 Oct 2003 14:40:34 -0500
Sender: [email-masked]

I guess I'd have to agree that the analogy with the logistics of (physical,
as opposed to electronic) postal delivery services is very apt in describing
DTN.  That is because the user is aware of the store-and-forward nature of
the delivery system, whereas in IP-based e-mail service it has been fairly
effectively hidden.

/micah

----- Original Message ----- 
From: "Warthman Associates" <[email-masked]>
To: "Craig Partridge" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 27, 2003 1:51 PM
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone

> At 10:08 AM 10/27/2003, Craig Partridge wrote:
>
> >In message <[email-masked]>, Warthman
> >Associa
> >tes writes:
> >
> > >Is it not true that, from the perspective of most email users today
(about
> > >whom I sense Leigh is concerned), their email is handled by a single
> > >server, and thus incoming and outgoing messages are handled in a star
> > >topology? This differs from the hop-by-hop store-and-forward topology
of
> > >DTNs. There is no central server handling all messaging in a DTN.
> >
> >No that's not true at all.  You have a host on which you place mail and
> >receive it (your local server).
> >
> >However, getting email between servers is often a multihop activity and
> >the internet email routing standards were designed with this kind of
> >multihop delivery in mind.
> >
> >Craig
>
> Yes, getting email between servers is often a multihop activity, but so is
> getting *any* kind of data across an Internet, email data or other data. I
> think most email users will regard the multihop path not as the essential
> characteristic of email but as the "in between stuff" that connects their
> respective email servers (the centers of their respective star
topologies).
>
> The postal system provides a DTN analogy that does not generate the
> controversy we are having and that is much more widely understood than
> email systems.
>
> Forrest
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

To: Warthman Associates <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Date: Mon, 27 Oct 2003 14:22:58 -0500
From: Craig Partridge <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Warthman Associa
tes writes:

>Yes, getting email between servers is often a multihop activity, but so is 
>getting *any* kind of data across an Internet, email data or other data. I 
>think most email users will regard the multihop path not as the essential 
>characteristic of email but as the "in between stuff" that connects their 
>respective email servers (the centers of their respective star topologies).

Perhaps I'm tired but I view that as an uninformed comment.

There's a huge distinction between:

    * an application layer protocol that is multi-hop (which email is); and

    * an underlying layer (e.g. IP) which is multi-hop.

Most Internet applications (file transfer, remote login, web, etc.) are
point-to-point applications layered on a multi-hop layer.

Email is a multi-hop application layered on a multi-hop layer.

There's a big difference and if you go back and look at network designs
from the 1970s and 1980s you'll see some of them (e.g. USENET vs. BITNET
vs. CSNET vs. Internet).

One of the nice things is that we've managed to hide much of the multi-hop
complexity from users (not all -- see Received lines and email returned
from Postmasters at wierd places).  But we should not forget that the
complexit is there and that we had to engineer around it.

Craig

Date: Mon, 27 Oct 2003 10:51:24 -0800
To: Craig Partridge <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Cc: [email-masked]
Sender: [email-masked]

At 10:08 AM 10/27/2003, Craig Partridge wrote:

>In message <[email-masked]>, Warthman 
>Associa
>tes writes:
>
> >Is it not true that, from the perspective of most email users today (about
> >whom I sense Leigh is concerned), their email is handled by a single
> >server, and thus incoming and outgoing messages are handled in a star
> >topology? This differs from the hop-by-hop store-and-forward topology of
> >DTNs. There is no central server handling all messaging in a DTN.
>
>No that's not true at all.  You have a host on which you place mail and
>receive it (your local server).
>
>However, getting email between servers is often a multihop activity and
>the internet email routing standards were designed with this kind of
>multihop delivery in mind.
>
>Craig

Yes, getting email between servers is often a multihop activity, but so is 
getting *any* kind of data across an Internet, email data or other data. I 
think most email users will regard the multihop path not as the essential 
characteristic of email but as the "in between stuff" that connects their 
respective email servers (the centers of their respective star topologies).

The postal system provides a DTN analogy that does not generate the 
controversy we are having and that is much more widely understood than 
email systems.

Forrest 

Date: Mon, 27 Oct 2003 10:10:58 -0800
To: Lloyd Wood <[email-masked]>, Charlie Younghusband <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Cc: "Fall, Kevin R" <[email-masked]>, Scott Burleigh <[email-masked]>, "" <[email-masked]>
Sender: [email-masked]

I agree with Lloyd. The postal-system analogy is clearer and more widely 
understood than the email analogy. The postal system implements a 
hop-by-hop (daisy-chain) store-and-forward topology, with no central point 
of storage (as in an individual's email service).

Forrest

At 09:59 AM 10/27/2003, Lloyd Wood wrote:
>On Mon, 27 Oct 2003, Charlie Younghusband wrote:
>
> > It seems to me that using terms that don't require history lessons would
> > make more sense.
>
>DTN. It's a bit like a bunch of postal services relaying mail and
>packages internationally. The packages sit around waiting to be moved,
>and get there eventually, because the postal services are cooperating
>in taking responsibility for their 'store and forward' bits.
>
>L.
>
><http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

To: Warthman Associates <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Date: Mon, 27 Oct 2003 13:08:38 -0500
From: Craig Partridge <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Warthman Associa
tes writes:

>Is it not true that, from the perspective of most email users today (about 
>whom I sense Leigh is concerned), their email is handled by a single 
>server, and thus incoming and outgoing messages are handled in a star 
>topology? This differs from the hop-by-hop store-and-forward topology of 
>DTNs. There is no central server handling all messaging in a DTN.

No that's not true at all.  You have a host on which you place mail and
receive it (your local server).

However, getting email between servers is often a multihop activity and
the internet email routing standards were designed with this kind of
multihop delivery in mind.

Craig

From: "Micah Beck" <[email-masked]>
To: "Kevin Fall" <[email-masked]>, "Warthman Associates" <[email-masked]>
Cc: "Scott Burleigh" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Date: Mon, 27 Oct 2003 12:55:14 -0500
Sender: [email-masked]

What DTN and e-mail have in common is that they are both asynchronous
protocols.  Lumping all asynchronous protocols together as "forms of e-mail"
obscures the fact that asynchronous commnication is an important and quite
ubiquitous aspect of wide area systems.  You might as well call all
synchronous protocols "forms of telnet."

/micah

----- Original Message ----- 
From: "Warthman Associates" <[email-masked]>
To: "Kevin Fall" <[email-masked]>
Cc: "Scott Burleigh" <[email-masked]>;
<[email-masked]>
Sent: Monday, October 27, 2003 12:36 PM
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone

> At 09:27 AM 10/27/2003, Kevin Fall wrote:
> > >
> > > From:  Warthman Associates <[email-masked]>
> > > To:    "Fall, Kevin R" <[email-masked]>,
> >         "Scott Burleigh" <[email-masked]>,
> >         <[email-masked]>
> > > Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
> > > Date:  Mon, 27 Oct 2003 08:55:23 PST
> > >
> > > The analogy with email confuses me. Email store-and-forwarding assumes
a
> > > star-topology, with each correspondent's email server at the center,
> > > whereas DTN store-and-forwarding assumes a daisy-chain topology, with
no
> > > central server.
> >
> >why do you say that about e-mail?
>
> Is it not true that, from the perspective of most email users today (about
> whom I sense Leigh is concerned), their email is handled by a single
> server, and thus incoming and outgoing messages are handled in a star
> topology? This differs from the hop-by-hop store-and-forward topology of
> DTNs. There is no central server handling all messaging in a DTN.
>
> Forrest
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

From: "Charlie Younghusband" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, "Warthman Associates" <[email-masked]>
Cc: "Fall, Kevin R" <[email-masked]>, "Scott Burleigh" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Date: Mon, 27 Oct 2003 12:52:11 -0500
Importance: Normal
Sender: [email-masked]

It seems to me that using terms that don't require history lessons would
make more sense.  'Email' as it exists now would suggest to newcomers a
similar markup, protocol system, purpose etc.  While they may be
functionally similar, why intentionally confuse them?

Charlie

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Lloyd Wood
Sent: Monday, October 27, 2003 12:22 PM
To: Warthman Associates
Cc: Fall, Kevin R; Scott Burleigh; [email-masked]
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone

On Mon, 27 Oct 2003, Warthman Associates wrote:

> The analogy with email confuses me. Email store-and-forwarding assumes a
> star-topology, with each correspondent's email server at the center,
> whereas DTN store-and-forwarding assumes a daisy-chain topology, with no
> central server.

You just haven't been using email long enough. Originally, before
unauthorised relaying and spoofing of spam close down relaying, you'd
relay email through gateways across very very different networks.

(in 1991, at the tail-end of that era, I was relaying mail to the US
through a gateway at Imperial College - JANET was still using its
coloured book protocols.)

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Mon, 27 Oct 2003 09:36:22 -0800
To: Kevin Fall <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Cc: "Scott Burleigh" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:27 AM 10/27/2003, Kevin Fall wrote:
> >
> > From:  Warthman Associates <[email-masked]>
> > To:    "Fall, Kevin R" <[email-masked]>,
>         "Scott Burleigh" <[email-masked]>,
>         <[email-masked]>
> > Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
> > Date:  Mon, 27 Oct 2003 08:55:23 PST
> >
> > The analogy with email confuses me. Email store-and-forwarding assumes a
> > star-topology, with each correspondent's email server at the center,
> > whereas DTN store-and-forwarding assumes a daisy-chain topology, with no
> > central server.
>
>why do you say that about e-mail?

Is it not true that, from the perspective of most email users today (about 
whom I sense Leigh is concerned), their email is handled by a single 
server, and thus incoming and outgoing messages are handled in a star 
topology? This differs from the hop-by-hop store-and-forward topology of 
DTNs. There is no central server handling all messaging in a DTN.

Forrest

Date: Mon, 27 Oct 2003 09:34:18 -0800
From: Joe Touch <[email-masked]>
To: "J. Leigh Torgerson" <[email-masked]>
CC: Warthman Associates <[email-masked]>, "Fall, Kevin R" <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Perhaps the purpose of Kevin's suggestion is being lost. The goal is to 
see if at least a simple aspect of DTN can be described in terms of 
existing systems.

For sales pitches, coined terms are great. For explaining things, 
analogies are more useful. I.e., email WITH ... - e.g., a dynamic, 
scheduled routing protocol that includes orbital mechanics isn't exactly 
trivial, but it does help newbies hang the ideas on something.

Joe

J. Leigh Torgerson wrote:

> IMHO, while an analogy may or may not help communicate salient features 
> of a technology, the association of the term "e-mail" with the 
> asynchronous networking capabilities (thanks Micah) of DTN may be doing 
> it a disservice - as Forrest points out, DTN != email, and if it gets 
> saddled with the email moniker, people may get an incorrect perception 
> (especially if we're not around to explain it to them.)
> 
> At 8:55 AM -0800 10/27/03, Warthman Associates wrote:
> 
>> The analogy with email confuses me. Email store-and-forwarding assumes 
>> a star-topology, with each correspondent's email server at the center, 
>> whereas DTN store-and-forwarding assumes a daisy-chain topology, with 
>> no central server.
>>
>> Forrest
>>
>>
>> At 09:39 AM 10/22/2003, Fall, Kevin R wrote:
>>
>>> I'm still curious if anyone has a reponse to my calling this stuff, to
>>> first order,
>>>         'email with fancy routing and an API'
>>>
>>> - K
>>>
>>> _______________________________________________
>>> 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
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

To: Warthman Associates <[email-masked]>
cc: "Scott Burleigh" <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone 
Date: Mon, 27 Oct 2003 09:27:13 -0800
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Warthman Associates <[email-masked]>
> To:    "Fall, Kevin R" <[email-masked]>,
	 "Scott Burleigh" <[email-masked]>,
	 <[email-masked]>
> Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
> Date:  Mon, 27 Oct 2003 08:55:23 PST
>
> The analogy with email confuses me. Email store-and-forwarding assumes a 
> star-topology, with each correspondent's email server at the center, 
> whereas DTN store-and-forwarding assumes a daisy-chain topology, with no 
> central server.

why do you say that about e-mail?

- K

Date: Mon, 27 Oct 2003 09:22:25 -0800
To: Warthman Associates <[email-masked]>, "Fall, Kevin R" <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
From: "J. Leigh Torgerson" <[email-masked]>
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

IMHO, while an analogy may or may not help communicate salient 
features of a technology, the association of the term "e-mail" with 
the asynchronous networking capabilities (thanks Micah) of DTN may be 
doing it a disservice - as Forrest points out, DTN != email, and if 
it gets saddled with the email moniker, people may get an incorrect 
perception (especially if we're not around to explain it to them.)

At 8:55 AM -0800 10/27/03, Warthman Associates wrote:
>The analogy with email confuses me. Email store-and-forwarding 
>assumes a star-topology, with each correspondent's email server at 
>the center, whereas DTN store-and-forwarding assumes a daisy-chain 
>topology, with no central server.
>
>Forrest
>
>
>At 09:39 AM 10/22/2003, Fall, Kevin R wrote:
>
>>I'm still curious if anyone has a reponse to my calling this stuff, to
>>first order,
>>         'email with fancy routing and an API'
>>
>>- K
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Mon, 27 Oct 2003 08:55:23 -0800
To: "Fall, Kevin R" <[email-masked]>, "Scott Burleigh" <[email-masked]>, <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

The analogy with email confuses me. Email store-and-forwarding assumes a 
star-topology, with each correspondent's email server at the center, 
whereas DTN store-and-forwarding assumes a daisy-chain topology, with no 
central server.

Forrest

At 09:39 AM 10/22/2003, Fall, Kevin R wrote:

>I'm still curious if anyone has a reponse to my calling this stuff, to
>first order,
>         'email with fancy routing and an API'
>
>- K
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Mon, 27 Oct 2003 09:43:41 -0400
From: Keith Hogie <[email-masked]>
Reply-To: [email-masked]
To: "Fall, Kevin R" <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Kevin,

   I agree with the email (store-and-forward) with a modified API and
various forwarding options.  This sounds alot like what we used over
10 years ago when we managed to forward messages between various
email systems.  I had an old chart with the proper combinations of
#, !, :, etc. to get messages passed between Internet, Bitnet, DECnet,
etc.

   My vote goes for an email type description.

Fall, Kevin R wrote:
> I'm still curious if anyone has a reponse to my calling this stuff, to
> first order,
> 	'email with fancy routing and an API' 
> 
> - K

----------------------------------------------------------------------
   Keith Hogie                   e-mail: [email-masked]
   Computer Sciences Corp.       office: 301-794-2999  fax: 301-794-9480
   7700 Hubble Dr.
   Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
----------------------------------------------------------------------

From: "Micah Beck" <[email-masked]>
To: "Eric Travis" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Date: Mon, 27 Oct 2003 07:06:37 -0500
Sender: [email-masked]

How about "asyncrhonous messaging" or "asynchronous networking"?

----- Original Message ----- 
From: "Eric Travis" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 27, 2003 1:55 AM
Subject: re: [dtn-interest] Protocol layering in the IPN backbone

> At 10:39 AM 10/22/2003 -0700, Fall, Kevin R wrote:
> 
> 
> >I'm still curious if anyone has a reponse to my calling this stuff, to
> >first order,
> > 'email with fancy routing and an API' 
> >  
> >
> 
> Perhaps I've been out in the woods a bit too long,
> but what would be wrong in simply calling this stuff
> 
>          'messaging'
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Mon, 27 Oct 2003 01:55:31 -0500
From: Eric Travis <[email-masked]>
To: [email-masked]
Subject: re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 10:39 AM 10/22/2003 -0700, Fall, Kevin R wrote:

>I'm still curious if anyone has a reponse to my calling this stuff, to
>first order,
>	'email with fancy routing and an API' 
>  
>

Perhaps I've been out in the woods a bit too long,
but what would be wrong in simply calling this stuff

         'messaging'

 

Date: Fri, 24 Oct 2003 10:48:26 -0700
To: "Fall, Kevin R" <[email-masked]>
From: "J. Leigh Torgerson" <[email-masked]>
Subject: Fancy E-mail (was RE: [dtn-interest] Protocol layering in the IPN backbone)
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

Kevin,

While I fully appreciate the parallels and the accuracy of your 
analogy, my immediate response to that terminology is that it makes 
the DTN work sound rather mundane, uninteresting, and in some cases, 
limiting. If I'm trying to convince a project of the glories of DTN, 
and I start talking about e-mail, I may risk being invited out of the 
meeting.. Everyone "knows" e-mail can't handle stream data...e-mail 
has spam in it....etc..

(When I tell the USAF why DTN will help them win battles, I have to 
look at the choice of explaining to Col. Umptifratz how fancy e-mail 
is the answer to his prayers versus starting fresh with a succint 
analogy-free explanation of what the new technology will allow him to 
accomplish.)

Your analogy is useful in explaining DTN to protocol specialists who 
know how e-mail works; but I'd just not use it in any of our formal 
documentation or in presentations to potential funding 
sources...prejudices and non-technical concepts / negative feelings 
about e-mail take too much time to explain away..

(Now, if we're talking to Qualcomm about bundle-enabled Eudora....)

Leigh

>I'm still curious if anyone has a reponse to my calling this stuff, to
>first order,
>	'email with fancy routing and an API'
>
>- K
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 23 Oct 2003 14:45:52 -0700
From: Joe Touch <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Lloyd Wood wrote:

> On Thu, 23 Oct 2003, Joe Touch wrote:
> 
> 
>>Lloyd Wood wrote:
>>
>>
>>>On Thu, 23 Oct 2003, Joe Touch wrote:
>>>
>>>
>>>>What I'm dismissing is use per se. Use describes an interpretation
>>>>of a subset of currently implemented capabilities.
>>>>
>>>>Use can be a factor in updating the capabilities, but by itself
>>>>presents only a partial view.
>>>
>>>[..]
>>>
>>>
>>>>>You need to use tools to envisage new tools, or changing the tool that
>>>>>you have, and it only takes a couple of tool users to do that.
>>>>
>>>>I certainly agree with that - i.e., we could start to want something
>>>>that sorts in different languages/charsets. But until we actually change
>>>>the protocol itself, merely 'wanting' to use it for something different
>>>>doesn't change the capabilities - and thus the system. It's the
>>>>capabilities that then limit use.
>>>>
>>>>That's why capabilities are a better defining characteristic than use.
>>>
>>>
>>>I have a screwdriver and a can of paint I want to open.
>>>
>>>But, gee, I'm limited by the designed-in capabilities of my
>>>screwdriver-based system.
>>
>>Actually, you're not limited by its capabilities -
>>
>>	- it has a flat blade
>>	- it as a length of steel
>>	- it has a handle
> 
> 
> those are properties.
> 
> unscrewing a suitable screw would be a capability.
> the ability to be held by its handle is a capability.
> the ability to conduct along the length of steel is a capability.
> the ability for the handle to insulate from electric shocks might be
> useful capability.
> 
> your standard denotational semantics appear weak here.

They're not denotational. They're behavioral, also known as operational. ;-)

Some of the definitions above are capabilites, some are uses. Defining a 
capability in terms of a use is the issue; it certainly can be 
challenging, but the idea is not what it DOES but what it CAN do.

>>It sounds like you're limited by it's intended USE, precisely, not its
>>capabilities. Its capaibilities, and your recognition thereof, are
>>exactly what end up letting you use it for other uses.
> 
> you mean its properties, and how I exploit them to define its
> capabilities for myself in use.

The semantics of properties, capabilities, etc. are muddled here. I 
thought I had a clear view of them, but I see that yours is equally 
clear and different. What matters is whether we define these systems by 
  how they're currently used, or by the aspects that define how they CAN 
be used.

Joe

Date: Thu, 23 Oct 2003 11:29:28 -0700
From: Joe Touch <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Lloyd Wood wrote:

> On Thu, 23 Oct 2003, Joe Touch wrote:
> 
>>What I'm dismissing is use per se. Use describes an interpretation
>>of a subset of currently implemented capabilities.
>>
>>Use can be a factor in updating the capabilities, but by itself
>>presents only a partial view.
> 
> [..]
> 
>>>You need to use tools to envisage new tools, or changing the tool that
>>>you have, and it only takes a couple of tool users to do that.
>>
>>I certainly agree with that - i.e., we could start to want something
>>that sorts in different languages/charsets. But until we actually change
>>the protocol itself, merely 'wanting' to use it for something different
>>doesn't change the capabilities - and thus the system. It's the
>>capabilities that then limit use.
>>
>>That's why capabilities are a better defining characteristic than use.
> 
> 
> I have a screwdriver and a can of paint I want to open.
> 
> But, gee, I'm limited by the designed-in capabilities of my
> screwdriver-based system.

Actually, you're not limited by its capabilities -

	- it has a flat blade
	- it as a length of steel
	- it has a handle

It sounds like you're limited by it's intended USE, precisely, not its 
capabilities. Its capaibilities, and your recognition thereof, are 
exactly what end up letting you use it for other uses.

> thankyou for neatly illustrating the fundamental difference in
> thinking between computer scientists and engineers.

CS is where we learn about operational semantics, which is where this 
gets clarified.

Joe

Date: Thu, 23 Oct 2003 08:18:37 -0700
From: Joe Touch <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Lloyd Wood wrote:

> On Thu, 23 Oct 2003, Joe Touch wrote:
> 
> 
>>Lloyd Wood wrote:
>>
>>>On Wed, 22 Oct 2003, Joe Touch wrote:
>>>
>>>
>>>>Email started as support for human-human communication, but often
>>>>supports automation, as well as higher-level protocols (e.g., file
>>>>transfer using email).
>>>>
>>>>Capabilities are what define a protocol. How it's used is an artifact.
>>>
>>>There's a very close relationship between the two, and back-and-forth
>>>feedback from users demanding capability enhancements. Look at, oh,
>>>the 'evolution' of L2TP through v3.
>>
>>Agreed. This is how the capabilities, and thus the protocol, change.
> 
> Right. So dismissing all use as an artefact is a little short-sighted.

What I'm dismissing is use per se. Use describes an interpretation of a 
subset of currently implemented capabilities.

Use can be a factor in updating the capabilities, but by itself presents 
only a partial view.

I.e., there are two conventional interpretations for defining systems:
	- behavioral	
		externally visible capabilities
	- procedural
		how those capabilities are achieved, in particular.

Consider two sorts - quicksort and selection sort. If the capability of 
the system is "sorts", then they're behaviorally equivalent. But they're 
procedurally implemented in different ways.

As you note, capability can change as use changes. I.e., when we start 
measuring the speed of the sort, the two sorts cease to be equivalent.

However, if all we ever _use_ either system for is to sort numbers, we 
might be under the mistaken impression that this was a fundamental limit 
of the system.

> You need to use tools to envisage new tools, or changing the tool that
> you have, and it only takes a couple of tool users to do that.

I certainly agree with that - i.e., we could start to want something 
that sorts in different languages/charsets. But until we actually change 
the protocol itself, merely 'wanting' to use it for something different 
doesn't change the capabilities - and thus the system. It's the 
capabilities that then limit use.

That's why capabilities are a better defining characteristic than use.

---

Back to the point of email. If we look at it from 'use', then we're 
limited to thinking of it as user-based. But then it's not user-based 
anymore anyway, so that's already changed. However, that 'use' change is 
substantial (if we used 'person-based' vs. machine-based as a 
descriminator), but it didn't change the protocol or system at all.

Joe

Date: Thu, 23 Oct 2003 07:37:35 -0700
From: Joe Touch <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Lloyd Wood wrote:

> On Wed, 22 Oct 2003, Joe Touch wrote:
> 
> 
>>Email started as support for human-human communication, but often
>>supports automation, as well as higher-level protocols (e.g., file
>>transfer using email).
>>
>>Capabilities are what define a protocol. How it's used is an artifact.
> 
> 
> There's a very close relationship between the two, and back-and-forth
> feedback from users demanding capability enhancements. Look at, oh,
> the 'evolution' of L2TP through v3.

Agreed. This is how the capabilities, and thus the protocol, change.

Joe

Date: Wed, 22 Oct 2003 17:34:33 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 05:14 PM 10/22/2003 -0700, Joe Touch wrote:

>Scott Burleigh wrote:
>>At 12:54 PM 10/22/2003 -0700, Joe Touch wrote:
>>
>>>Scott Burleigh wrote:
>>>
>>>>At 10:39 AM 10/22/2003 -0700, Fall, Kevin R wrote:
>>>>
>>>>>I'm still curious if anyone has a reponse to my calling this stuff, to
>>>>>first order,
>>>>>         'email with fancy routing and an API'
>>>>
>>>>It seems to me that the appellations we hang on protocols are more 
>>>>useful if they're chosen to indicate what the protocols are used for 
>>>>rather than how they operate. Since Bundling is designed to be used for
>>>>implementing a network (it does routing and forwarding) rather than for 
>>>>conveying text messages between humans, given a choice of calling it a 
>>>>network protocol or calling it an email system I would be inclined 
>>>>toward the former.
>>>>Scott
>>>
>>>
>>>Email started as support for human-human communication, but often 
>>>supports automation, as well as higher-level protocols (e.g., file 
>>>transfer using email).
>>>
>>>Capabilities are what define a protocol. How it's used is an artifact.
>>
>>Now I'm confused.  I thought you were arguing for calling Bundling a 
>>network protocol because it performs the functions that network protocols 
>>perform (routing and forwarding), and I thought I was agreeing with 
>>you.  Are you now arguing for calling Bundling an email system instead, 
>>because it has the store-and-forward capability of email?
>
>Actually, I thought that both I and perhaps Kevin were wondering whether 
>email was also a network, for the purposes of this discussion.

Okay, there's my confusion.  I thought Kevin was proposing to identify 
Bundling as an email system; so long as we're all thinking about possibly 
characterizing email as a network protocol then I believe I'm with you.

>>What was wrong with the case you were making before?
>
>Nothing. Email has been added as another example of a message network. 
>FYI, the DNS is also a message network - with its own routing, forwarding, etc.
>
>The key question from these comparisons is:
>
>         - is there anything to be learned from calling bundling
>         a network layer?
>                 I think there is, notably, as before, that it helps
>                 people who use Internet terminology understand
>                 what bundling maps to, as well as to help the
>                 overall discussion focus on what's different.
>
>         - is there anything to be learned from comparing
>         bundling to email?
>                 again, it might bring out some interesting properties
>                 that might be of use. sure, SMTP might be the wrong
>                 thing on particular tunnels, but that doesn't mean
>                 the email 'architecture' might not be a learning
>                 tool.
>
>In both cases, there's something to be learned or understood from the 
>analogies to prior and related work.

I completely agree. 

Date: Wed, 22 Oct 2003 17:14:43 -0700
From: Joe Touch <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Scott Burleigh wrote:
> At 12:54 PM 10/22/2003 -0700, Joe Touch wrote:
> 
>> Scott Burleigh wrote:
>>
>>> At 10:39 AM 10/22/2003 -0700, Fall, Kevin R wrote:
>>>
>>>> I'm still curious if anyone has a reponse to my calling this stuff, to
>>>> first order,
>>>>         'email with fancy routing and an API'
>>>
>>> It seems to me that the appellations we hang on protocols are more 
>>> useful if they're chosen to indicate what the protocols are used for 
>>> rather than how they operate. Since Bundling is designed to be used for
>>> implementing a network (it does routing and forwarding) rather than 
>>> for conveying text messages between humans, given a choice of calling 
>>> it a network protocol or calling it an email system I would be 
>>> inclined toward the former.
>>> Scott
>>
>>
>> Email started as support for human-human communication, but often 
>> supports automation, as well as higher-level protocols (e.g., file 
>> transfer using email).
>>
>> Capabilities are what define a protocol. How it's used is an artifact.
> 
> 
> Now I'm confused.  I thought you were arguing for calling Bundling a 
> network protocol because it performs the functions that network 
> protocols perform (routing and forwarding), and I thought I was agreeing 
> with you.  Are you now arguing for calling Bundling an email system 
> instead, because it has the store-and-forward capability of email?

Actually, I thought that both I and perhaps Kevin were wondering whether 
email was also a network, for the purposes of this discussion.

> What 
> was wrong with the case you were making before?

Nothing. Email has been added as another example of a message network. 
FYI, the DNS is also a message network - with its own routing, 
forwarding, etc.

The key question from these comparisons is:

	- is there anything to be learned from calling bundling
	a network layer?
		I think there is, notably, as before, that it helps
		people who use Internet terminology understand
		what bundling maps to, as well as to help the
		overall discussion focus on what's different.

	- is there anything to be learned from comparing
	bundling to email?
		again, it might bring out some interesting properties
		that might be of use. sure, SMTP might be the wrong
		thing on particular tunnels, but that doesn't mean
		the email 'architecture' might not be a learning
		tool.

In both cases, there's something to be learned or understood from the 
analogies to prior and related work.

Joe

Date: Wed, 22 Oct 2003 15:43:56 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 12:54 PM 10/22/2003 -0700, Joe Touch wrote:

>Scott Burleigh wrote:
>
>>At 10:39 AM 10/22/2003 -0700, Fall, Kevin R wrote:
>>
>>>I'm still curious if anyone has a reponse to my calling this stuff, to
>>>first order,
>>>         'email with fancy routing and an API'
>>It seems to me that the appellations we hang on protocols are more useful 
>>if they're chosen to indicate what the protocols are used for rather than 
>>how they operate. Since Bundling is designed to be used for
>>implementing a network (it does routing and forwarding) rather than for 
>>conveying text messages between humans, given a choice of calling it a 
>>network protocol or calling it an email system I would be inclined toward 
>>the former.
>>Scott
>
>Email started as support for human-human communication, but often supports 
>automation, as well as higher-level protocols (e.g., file transfer using 
>email).
>
>Capabilities are what define a protocol. How it's used is an artifact.

Now I'm confused.  I thought you were arguing for calling Bundling a 
network protocol because it performs the functions that network protocols 
perform (routing and forwarding), and I thought I was agreeing with 
you.  Are you now arguing for calling Bundling an email system instead, 
because it has the store-and-forward capability of email?  What was wrong 
with the case you were making before?

Certainly capabilities are what define a protocol, and certainly a protocol 
can be used for a purpose other than the one for which it was originally 
designed; absolutely no dispute there.  But is that relevant?  Are you now 
saying should we label protocols according to the capabilities that define 
them rather than according to how they are nominally used?  For example, do 
you feel that we shouldn't call IP a network protocol because we don't 
always use it to operate a network (e.g., we can run TCP/IP over a 
crossover cable)?

More generally: what are the guidelines you feel should be observed when 
we're deciding how to characterize (what to call) a given protocol?  From 
the amount of time we spend on this sort of question I infer that you think 
it's fairly important.

Scott 

Date: Wed, 22 Oct 2003 12:54:03 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Scott Burleigh wrote:

> At 10:39 AM 10/22/2003 -0700, Fall, Kevin R wrote:
> 
>> I'm still curious if anyone has a reponse to my calling this stuff, to
>> first order,
>>         'email with fancy routing and an API'
> 
> It seems to me that the appellations we hang on protocols are more 
> useful if they're chosen to indicate what the protocols are used for 
> rather than how they operate. Since Bundling is designed to be used for
> implementing a network (it does routing and forwarding) rather than for 
> conveying text messages between humans, given a choice of calling it a 
> network protocol or calling it an email system I would be inclined 
> toward the former.
> 
> Scott

Email started as support for human-human communication, but often 
supports automation, as well as higher-level protocols (e.g., file 
transfer using email).

Capabilities are what define a protocol. How it's used is an artifact.

Joe

From: "Dai Stanton" <[email-masked]>
To: <[email-masked]>
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Date: Wed, 22 Oct 2003 20:34:05 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

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

I like Scott's point that the architectural significance of the bundling =
layer depends on the context in which it is being discussed. In the IPN =
it performs the role of a network layer whereas to Internets contained =
in the IPN it typically presents the aspect of a transport layer user.

It's important, however, to know what we mean by the IPN and, indeed, an =
Internet in IPN terms. As a first stab an Internet is a domain in which, =
on external examination (to take account of embedded private networks),  =
Internet and DNS addresses are unique. The boundaries of the IPN can be =
defined by the terminating service interfaces of the bundling protocol =
but, taking email as an example, these would probably not be the =
terminating points of the end-to-end communications system. SMTP is too =
chatty to use across long delay links so would be (and is) deployed =
across an Internet with a bundling gateway at the access point to the =
long delay IPN. The IPN architecture must take into account these =
satellite Internets to the IPN which are not necessarily embedded in the =
Bundled IPN.

Sorry if I'm regurgitating old and naive arguments. Never made a good =
lurker.

Dai
------=_NextPart_000_003C_01C398DB.D68FBD70
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.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I like Scott's point that the =
architectural=20
significance of the bundling layer depends on&nbsp;the context in which =
it is=20
being discussed. In the IPN it performs the role of a network layer =
whereas to=20
Internets contained in the IPN it typically presents the aspect of a =
transport=20
layer user.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It's important, however,&nbsp;to know =
what we mean=20
by the IPN and, indeed, an Internet in IPN terms. As a first stab an =
Internet is=20
a&nbsp;domain&nbsp;in which, on external examination (to=20
take&nbsp;account&nbsp;of embedded private networks),&nbsp; Internet and =
DNS=20
addresses are unique. The boundaries of the IPN can be defined by the=20
terminating service interfaces of the bundling protocol but, taking =
email as an=20
example, these would probably not be&nbsp;the terminating points of the=20
end-to-end communications system. </FONT><FONT face=3DArial =
size=3D2>SMTP is too=20
chatty to use across long delay links so would be (and is) deployed =
across an=20
Internet with a bundling gateway at the access point to the long delay =
IPN. The=20
IPN architecture must take into account these satellite Internets to the =
IPN=20
which are not necessarily embedded in the Bundled IPN.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sorry if I'm regurgitating old and =
naive arguments.=20
Never made a good lurker.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dai</FONT></DIV></BODY></HTML>

------=_NextPart_000_003C_01C398DB.D68FBD70--

Date: Wed, 22 Oct 2003 11:25:58 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 10:39 AM 10/22/2003 -0700, Fall, Kevin R wrote:

>I'm still curious if anyone has a reponse to my calling this stuff, to
>first order,
>         'email with fancy routing and an API'

It seems to me that the appellations we hang on protocols are more useful 
if they're chosen to indicate what the protocols are used for rather than 
how they operate.  Since Bundling is designed to be used for implementing a 
network (it does routing and forwarding) rather than for conveying text 
messages between humans, given a choice of calling it a network protocol or 
calling it an email system I would be inclined toward the former.

Scott

Date: Wed, 22 Oct 2003 11:12:53 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 03:53 PM 10/21/2003 -0700, Joe Touch wrote:

>Scott Burleigh wrote:
>...
>>>We add characteristics to datagrams all the time - e.g., partial 
>>>checksums are in development. That doesn't make them 'swatches'; they're 
>>>still a unit of transmission.
>>>It might make sense to add adjectives, e.g., ordered, reliable (but 
>>>that's a misnomer if there's no E2E retransmission), etc.
>>>
>>>The rest of the details, IMO, are based on interpretations about how 
>>>overlays use links. Breaking a UDP packet up and transmitting it - or 
>>>retransmitting portions, etc. - over a link, doesn't make it not a UDP packet.
>>No, but having a completely different header structure *does* make it not 
>>a UDP packet.
>>What it *doesn't* not make it (a wonderful construction) is a conceptual 
>>packet or datagram that behaves in many ways very much like other 
>>conceptual packets and datagrams, such as UDP packets, even though it is 
>>constructed quite differently and therefore clearly is operationally (if 
>>not functionally) quite distinct from -- and not interoperable with -- them.
>
>Fair enough. It may be as distinct from UDP as RTP is in that regard.
>
>...
>>>My impression is that others reading this model get hung up on names and 
>>>layers that they have to re-learn, in ways that don't add to getting at 
>>>the real issues (and there ARE real issues here).
>>Yeah, I suspect that different groups of people have very different sets 
>>of difficulties in discussing this stuff, depending on what their areas 
>>of expertise and experience are.
>
>Agreed. It would help, esp. the IDs, if the assumption was "Internet 
>speak", however ;-)

Good point.  We should keep this in mind for the next documentation cycle.

Scott 

Content-Class: urn:content-classes:message
Subject: RE: [dtn-interest] Protocol layering in the IPN backbone
Date: Wed, 22 Oct 2003 10:39:56 -0700
From: "Fall, Kevin R" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I'm still curious if anyone has a reponse to my calling this stuff, to
first order,
	'email with fancy routing and an API' 

- K

Date: Tue, 21 Oct 2003 15:52:52 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 03:38 PM 10/21/2003 -0700, Joe Touch wrote:
>Scott Burleigh wrote:
>>At 10:48 PM 10/20/2003 -0700, Joe Touch wrote:
>>>>Sure, in the Interplanetary backbone it is confusing because the 
>>>>Internet protocols are absent.  But Bundling is designed to be an 
>>>>end-to-end protocol, and on those portions of the end-to-end path where 
>>>>it is running on top of TCP/IP those Internet protocols are very much 
>>>>involved.  Since, in that environment, you've got application protocol 
>>>>running on top of Bundling, which in turn runs on top of TCP/IP, and 
>>>>since we all know that IP runs at the network layer of the stack, at 
>>>>what layer of the stack does Bundling run?
>>>>And if it's at that layer "X" during the Internet hops of the 
>>>>end-to-end path, why isn't it at the same layer X during the deep space 
>>>>hop(s)?  And if it is, then what's at the Network layer?
>>>
>>>In an overlay, the properties of the underying network - however 
>>>complex, and at whatever layer in _that_ network, are precisely a link 
>>>layer as far as the overlay is concerned. That's the nature of an overlay.
>>>
>>>IP runs at the network layer in _its_ stack, not in all stacks to all 
>>>networks. IP is a physical layer to ethernet over IP (L2VPNs).
>>>
>>>I.e., it doesn't matter that I run TCP(1) over IP(1) over TCP(2) which 
>>>is over IP(2). To the top network (1), TCP is the transport, IP is the 
>>>network, and TCP(2) and below are the link. This is why I've been saying 
>>>(for a while) that IPN essentially uses TCP as a link layer. It doesn't 
>>>matter that TCP(2) runs over a 'network' - as far as TCP(1) is 
>>>concerned, there's no network at all. It's just a link in the top (1) network.
>>
>>Ah, okay: if we all agree that "network layer" is a *relative* term, 
>>which can be used to refer to multiple layers of the same stack at the 
>>same time depending on which layer you're currently looking at, then I'm 
>>with you.  We've in fact been saying for several years (among ourselves, 
>>at least) that IPN/DTN **essentially** "uses TCP as a link layer".
>
>James Sterbenz raised the issue of calling IPN/DTN's use of TCP a "virtual 
>link" at the Aug 2001 IPN design review. There I raised the issue of how 
>it was a tunnel in an overlay. In both cases, these observations were 
>initially met with skepticism from the IPN group, FWIW.

I don't doubt it.  There is often rather spirited disagreement on these 
kinds of issues within "the IPN group"; I would be surprised if the level 
of dispute dropped in the larger setting of a peer review. 

Date: Tue, 21 Oct 2003 15:53:16 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Scott Burleigh wrote:

...
>> We add characteristics to datagrams all the time - e.g., partial 
>> checksums are in development. That doesn't make them 'swatches'; 
>> they're still a unit of transmission.
>> It might make sense to add adjectives, e.g., ordered, reliable (but 
>> that's a misnomer if there's no E2E retransmission), etc.
>>
>> The rest of the details, IMO, are based on interpretations about how 
>> overlays use links. Breaking a UDP packet up and transmitting it - or 
>> retransmitting portions, etc. - over a link, doesn't make it not a UDP 
>> packet.
> 
> No, but having a completely different header structure *does* make it 
> not a UDP packet.
> 
> What it *doesn't* not make it (a wonderful construction) is a conceptual 
> packet or datagram that behaves in many ways very much like other 
> conceptual packets and datagrams, such as UDP packets, even though it is 
> constructed quite differently and therefore clearly is operationally (if 
> not functionally) quite distinct from -- and not interoperable with -- 
> them.

Fair enough. It may be as distinct from UDP as RTP is in that regard.

...
>> My impression is that others reading this model get hung up on names 
>> and layers that they have to re-learn, in ways that don't add to 
>> getting at the real issues (and there ARE real issues here).
> 
> Yeah, I suspect that different groups of people have very different sets 
> of difficulties in discussing this stuff, depending on what their areas 
> of expertise and experience are.

Agreed. It would help, esp. the IDs, if the assumption was "Internet 
speak", however ;-)

Joe

Date: Tue, 21 Oct 2003 15:42:18 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 07:43 AM 10/21/2003 -0700, Joe Touch wrote:
>The largest distinctions I have seen between IPN and the Internet are:
>
>         - IPN prohibits E2E connections
>                 i.e., in Internet-speak, UDP is supported,
>                 but not TCP.

It actually doesn't bother to "prohibit" them; it just doesn't support them.

>         - IPN forwards based on partial addresses
>                 the Internet does this in subnets;
>                 IPN formalizes it a bit more,
>                 and does add some other steps
>
>Bundles still walk and talk like datagrams to me.

Sure.

>We add characteristics to datagrams all the time - e.g., partial checksums 
>are in development. That doesn't make them 'swatches'; they're still a 
>unit of transmission.
>It might make sense to add adjectives, e.g., ordered, reliable (but that's 
>a misnomer if there's no E2E retransmission), etc.
>
>The rest of the details, IMO, are based on interpretations about how 
>overlays use links. Breaking a UDP packet up and transmitting it - or 
>retransmitting portions, etc. - over a link, doesn't make it not a UDP packet.

No, but having a completely different header structure *does* make it not a 
UDP packet.

What it *doesn't* not make it (a wonderful construction) is a conceptual 
packet or datagram that behaves in many ways very much like other 
conceptual packets and datagrams, such as UDP packets, even though it is 
constructed quite differently and therefore clearly is operationally (if 
not functionally) quite distinct from -- and not interoperable with -- them.

>>What the questions that are pressing on our minds are :
>>-Is there any problem with the functions delegated to the various layers?
>>-**Would this architecture work** in the IPN backbone? , and
>>- Would it be fine to have the Licklider Transmission Protocol at the link
>>layer, on top of a link protocol like the CCSDS link(or some other
>>protocol) providing a limited amount of ARQ?
>
>These are interesting questions that the language and layering model 
>obfuscate. When I present my interpretation of the model to others, they 
>immediately hit upon the salient issues, and we move on to a meaningful 
>discussion quickly.
>
>My impression is that others reading this model get hung up on names and 
>layers that they have to re-learn, in ways that don't add to getting at 
>the real issues (and there ARE real issues here).

Yeah, I suspect that different groups of people have very different sets of 
difficulties in discussing this stuff, depending on what their areas of 
expertise and experience are.

Scott 

Date: Tue, 21 Oct 2003 15:38:10 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Scott Burleigh wrote:

> At 10:48 PM 10/20/2003 -0700, Joe Touch wrote:
> 
>>> Sure, in the Interplanetary backbone it is confusing because the 
>>> Internet protocols are absent.  But Bundling is designed to be an 
>>> end-to-end protocol, and on those portions of the end-to-end path 
>>> where it is running on top of TCP/IP those Internet protocols are 
>>> very much involved.  Since, in that environment, you've got 
>>> application protocol running on top of Bundling, which in turn runs 
>>> on top of TCP/IP, and since we all know that IP runs at the network 
>>> layer of the stack, at what layer of the stack does Bundling run?  
>>> And if it's at that layer "X" during the Internet hops of the 
>>> end-to-end path, why isn't it at the same layer X during the deep 
>>> space hop(s)?  And if it is, then what's at the Network layer?
>>
>>
>> In an overlay, the properties of the underying network - however 
>> complex, and at whatever layer in _that_ network, are precisely a link 
>> layer as far as the overlay is concerned. That's the nature of an 
>> overlay.
>>
>> IP runs at the network layer in _its_ stack, not in all stacks to all 
>> networks. IP is a physical layer to ethernet over IP (L2VPNs).
>>
>> I.e., it doesn't matter that I run TCP(1) over IP(1) over TCP(2) which 
>> is over IP(2). To the top network (1), TCP is the transport, IP is the 
>> network, and TCP(2) and below are the link. This is why I've been 
>> saying (for a while) that IPN essentially uses TCP as a link layer. It 
>> doesn't matter that TCP(2) runs over a 'network' - as far as TCP(1) is 
>> concerned, there's no network at all. It's just a link in the top (1) 
>> network.
> 
> 
> Ah, okay: if we all agree that "network layer" is a *relative* term, 
> which can be used to refer to multiple layers of the same stack at the 
> same time depending on which layer you're currently looking at, then I'm 
> with you.  We've in fact been saying for several years (among ourselves, 
> at least) that IPN/DTN **essentially** "uses TCP as a link layer".

James Sterbenz raised the issue of calling IPN/DTN's use of TCP a 
"virtual link" at the Aug 2001 IPN design review. There I raised the 
issue of how it was a tunnel in an overlay. In both cases, these 
observations were initially met with skepticism from the IPN group, FWIW.

> The problem, I think, is that not everybody else we talk to is has been 
> as comfortable as you are with the notion of layer designations being 
> relative rather than absolute.  In trying to communicate about IPN 
> concepts with everyone else, we find ourselves having to use those same 
> terms in that other way; this leaves us with the problem of coming up 
> with words to use for "the layer above TCP which can't be the Network 
> layer because everyone knows that the Network layer is under TCP, where 
> IP lives".  It's not so much that we're a shameless buzzword factory, 
> we're really just trying to reach common understanding with people, 
> without undertaking the major pedagogical task of getting the whole 
> world to recognize the relative nature of stack layer labels.

You're building a network; it happens to operate as an overlay over 
other networks, as do most networks. I.e., the confusion lies in trying 
to integrate the IPN with the Internet - to talk about them as being at 
the same level when they're not intended that way.

>> IMO, it's not at all confusing when you call them the application, 
>> transport, network, and link layers that they are.
> 
> Nope, not if we all agree that those labels are relative and that, when 
> you refer to "the network layer" you always qualify it as necessary: the 
> network layer of the Internet, the network layer of the IPN, the network 
> layer of the spacecraft's on-board LAN, etc.

We do that now in the Internet. We talk about ATM networks, addressing, 
and signalling, which is different from IP, even when IP runs over ATM. 
There's no reason that this should be any different.

I.e., better to put the adjectives on and make it clear, than coin new 
words and hierarchies (IMO) that end up meaning the same thing.

>> And if bundling indeed combines application and network layers, then 
>> it might be closer to NCP, and the bundles closer to crates (RFC60) - 
>> but wasn't there a lesson in separating those layers, somewhere in the 
>> 700's? ;-)
> 
> No, bundling is at the application layer of the Internet but it is at 
> the transport/network layer of the IPN. 

Yes. As IP/ATM ends up being app layer to the ATM (UNI) and network 
layer (in this case) to IP. That's a characteristic of all overlays; at 
some point the layers splice in ways that - when viewed without scoping 
- seem to invert the hierarchy.

> And yes, we did discuss (at 
> length) splitting out the transport and network functionality of 
> bundling into two protocols [taking TCP/IP as our model] but eventually 
> concluded that there was no evident advantage in this case.  I don't 
> recall the rationale that finally prevailed, but I'm sure we can 
> reconstruct it if there's interest.
> 
> Scott

It's certainly be useful to capture that, since it's likely to come up 
as a question in the future.

Joe

Date: Tue, 21 Oct 2003 14:38:31 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 10:48 PM 10/20/2003 -0700, Joe Touch wrote:
>>Sure, in the Interplanetary backbone it is confusing because the Internet 
>>protocols are absent.  But Bundling is designed to be an end-to-end 
>>protocol, and on those portions of the end-to-end path where it is 
>>running on top of TCP/IP those Internet protocols are very much 
>>involved.  Since, in that environment, you've got application protocol 
>>running on top of Bundling, which in turn runs on top of TCP/IP, and 
>>since we all know that IP runs at the network layer of the stack, at what 
>>layer of the stack does Bundling run?  And if it's at that layer "X" 
>>during the Internet hops of the end-to-end path, why isn't it at the same 
>>layer X during the deep space hop(s)?  And if it is, then what's at the 
>>Network layer?
>
>In an overlay, the properties of the underying network - however complex, 
>and at whatever layer in _that_ network, are precisely a link layer as far 
>as the overlay is concerned. That's the nature of an overlay.
>
>IP runs at the network layer in _its_ stack, not in all stacks to all 
>networks. IP is a physical layer to ethernet over IP (L2VPNs).
>
>I.e., it doesn't matter that I run TCP(1) over IP(1) over TCP(2) which is 
>over IP(2). To the top network (1), TCP is the transport, IP is the 
>network, and TCP(2) and below are the link. This is why I've been saying 
>(for a while) that IPN essentially uses TCP as a link layer. It doesn't 
>matter that TCP(2) runs over a 'network' - as far as TCP(1) is concerned, 
>there's no network at all. It's just a link in the top (1) network.

Ah, okay: if we all agree that "network layer" is a *relative* term, which 
can be used to refer to multiple layers of the same stack at the same time 
depending on which layer you're currently looking at, then I'm with 
you.  We've in fact been saying for several years (among ourselves, at 
least) that IPN/DTN **essentially** "uses TCP as a link layer".

The problem, I think, is that not everybody else we talk to is has been as 
comfortable as you are with the notion of layer designations being relative 
rather than absolute.  In trying to communicate about IPN concepts with 
everyone else, we find ourselves having to use those same terms in that 
other way; this leaves us with the problem of coming up with words to use 
for "the layer above TCP which can't be the Network layer because everyone 
knows that the Network layer is under TCP, where IP lives".  It's not so 
much that we're a shameless buzzword factory, we're really just trying to 
reach common understanding with people, without undertaking the major 
pedagogical task of getting the whole world to recognize the relative 
nature of stack layer labels.

>IMO, it's not at all confusing when you call them the application, 
>transport, network, and link layers that they are.

Nope, not if we all agree that those labels are relative and that, when you 
refer to "the network layer" you always qualify it as necessary: the 
network layer of the Internet, the network layer of the IPN, the network 
layer of the spacecraft's on-board LAN, etc.

>And if bundling indeed combines application and network layers, then it 
>might be closer to NCP, and the bundles closer to crates (RFC60) - but 
>wasn't there a lesson in separating those layers, somewhere in the 700's? ;-)

No, bundling is at the application layer of the Internet but it is at the 
transport/network layer of the IPN.  And yes, we did discuss (at length) 
splitting out the transport and network functionality of bundling into two 
protocols [taking TCP/IP as our model] but eventually concluded that there 
was no evident advantage in this case.  I don't recall the rationale that 
finally prevailed, but I'm sure we can reconstruct it if there's interest.

Scott 

Date: Tue, 21 Oct 2003 11:34:37 -0700
From: Joe Touch <[email-masked]>
To: Kevin Fall <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Re: Protocol layering in the IPN backbone
Sender: [email-masked]

Kevin Fall wrote:

Kevin,

...
>>it's a network
>>	Agreed
>>with store-and-forward forwarding
>>	Agreed
>>late-bound addresses
>>	Unclear what this really means. Bundling's late binding, IMO,
>>	is closer to what ARP does over a subnet. Yes, this is required
>>	when traversing a network overlaid on a network. But let's
>>	say "some alternate forwarding mechanism"
>>	and agree in principle.
> 
> 
> Actually it is clear what it means...  It means this:  you can construct
> addresses that contain a substring that is treated as opaque data when carried
> through the network and then interpreted in a domain ("region" for us) where it
> is interpretable.  The difference from ARP is this:  ARP will map a universally
> agreed upon (global, NAT not withstanding) address to whatever is needed to transfer
> the (datagram) one futher hop.  That is not what we are up to here.  When I relate
> DTN late binding to e-mail, you should be thinking of this sort of stuff:
> 
> 	[email-masked]

Sure. We've implemented something like that in the Internet 
architecture, FWIW -

http://www.isi.edu/touch/pubs/isi-tr-2003-578/

Whether an address is opaque or not, and how it is incrementally 
resolved, is certainly a new part here.

> Maybe not used so much anymore, but I give e-mail the benefit of the doubt in
> at least potentially supporting the type of late binding I am referring to.
> A more interesting case may be when we consider URNs as DTN addresses:
> 
> 	bundles://remote_region/urn://kevins_pager
> 
> This implies a form of associative lookup in the remote_region.  To me this differs
> substantially from what I expect 'addressing in a typical network layer' to look like.

See our tech report above. That's still lookup in a network layer, IMO.

>>hop-by-hop reliability
>>	lots of links have reliability already, including FEC
>>	and retransmission. it's a link property, not a network
>>	property.
> 
> Yes, lots of links do.  Many don't.  I would therefore argue
> that reliability is not a property of any particular layer.  It is just a property.
> It could be that just about any layer has some.

Sure. It's a link property in the DTN, AFAICT.

> But I think maybe your comment reveals something about your thinking.  If your position
> is that certain functions 'belong' to certain layers and if a subsystem provides
> a particular function that you believe is owned by some particular layer, you must
> choose to use the corresponding layer name.   Is that your approach?

It depends both on what the function is and how it's implemented. Taking 
both things into consideration, yes, IMO - and that of most of the 
network textbooks out there - that defines a layer.

You don't necessarily have to choose that layer name, but if you're 
doing some set of functions in a certain way (e.g., hop-by-hop 
reliability) then you are indeed already referring to what the rest of 
the planet ;-) thinks of as a link layer.

>>E2E acks
>>	this, perhaps with late-bound addresses, are the key
>>	differences, IMO.
> 
> um, ok I guess...  But its pretty curious to me why this would
> seem like a key difference but the other things don't.

The key differences, to make a list:
	- E2E ack'd datagrams
	- connectionless only
	- late-bound addresses

Not key differences, IMO:
	- hop-by-hop reliability
	- segmentation and reassembly on sub-paths

>>infinite message sizes
>>	nothing that is store-and-forward is infinite.
> 
> yes, 'infinite' was used loosely here
>  
>>	perhaps you mean "unlimited, but of a fixed size at the
>>	time of transmission", and yes, to me that's a datagram
>>	property. The size of that limit is an artifact of
>>	implementation considerations; even bundles will have an
>>	upper bound, e.g., that of the size of the smallest
>>	store-and-forward buffer. Otherwise, they're not being stored-
>>	and forwarded.
> 
> well, we have bundle fragmentation.  So, as in the case of IP, I guess
> you get back to 'packet' vs 'datagram'.  Whatever you want to label it,
> DTN messages are of (essentially) arbitrary length (yes, limited by
> implementation considerations).  But it is not the case they have to
> be of size limited by the smallest s&f buffer.

OK - then the bundle is very close to a UDP packet in that regard, and 
the bundle fragments are close to IP packets. Again, a nice analogy that 
uses existing terms in existing ways.

> And yes if you then
> want to call that 'not s&f', I guess I might agree 'legally', but I
> would still say its s&f to people who I am explaining the concept to.

It's S&F at the network, but not at the application layer, if that's 
what's going on.

> A more legalistic approach might be to say message fragments are routed
> where persistent storage can be employed where necessary, or some such.

Most people call that queuing. ;-)

>>>Indeed, I would feel more comfortable calling bundling 'e-mail with fancy r
> 
> outing'.
> 
>>>Both have: late bound addressing, store-and-forward forwarding, routing [so
> 
> rt of],
> 
>>>a variable-length message format, security [sort of], e2e return-receipt [s
> 
> ort of].
> 
>>Email lacks e2e return receipt per se. That's an artifact of application 
>>programs, not the email system itself.
> 
> um, no.  RFC3461.  Also X.400 I believe.

I was referring to the current way in which email ACKs are supported 
(i.e., at the application layer, e.g,. in outlook or netscape)- RFC3461 
is fairly new in that regard.

RFC3461 is best-effort (i.e., the ACK request may disappear at any hop). 
DTNs seems a bit more strict.

>>Email lacks network-layer security as well; that too is an artifact of 
>>the application program, not the email system.
> 
> RFC3207

Again, I was referring to how email currently works, not what is 
proposed or emerging. It's indeed nice to see these new extensions, and 
they make SMTP email more of a network layer.

>>>For bundling we try to convert 'sort of' into 'real', plus add an API that 
> 
> apps
> 
>>>can make effective use of  (unlike e-mail I would argue; although I'm open
>>>to opposing viewpoints).  If you like to think of e-mail as a network layer
> 
> , then
> 
>>>I guess you can, (but I would prefer not to because I feel it makes the con
> 
> versation
> 
>>>more cumbersome from that point onward).  Are you comfortable calling e-mai
> 
> l a
> 
>>>network layer?
>>
>>Although email can be configured to be a network, mail usually goes 1 
>>hop via SMTP.
> 
> Not at my site [at least for incoming mail].
> It typically goes about 3 by SMTP, and often 1  by POP/IMAP.
> I believe it is very common that multiple hops are used.

Your site goes 1 hop to mine.

I checked my mail logs. Excepting forwarding (i.e., mail to 
[email-masked], which obviously goes 2 hops), the vast majority - 
including spam - go one hop in SMTP.

>>Consider your mail to me, which went through the loopback 
>>interface (persumably to use SSL or filters) then direct from 
>>dwight.cs.berkeley.edu to tnt.isi.edu. OK, so that's 2 hops, but one of 
>>them is an artifact. It's a network, but not a very interesting one in 
>>that regard, at least in most cases.
> 
> see above.
> 
>>When email is used, e.g., to forward files (as done by Steve Crocker's 
>>company), then yes, it's a network. I.e., it's partly defined by 
>>capability, and partly by use, as with any other overlay.
>>
>>Joe
> 
> Not sure where this statement leads.  So is it 'not a network' if its
> used to forward e-mails if we don't call them "files"?
> 
> - K

email tends to go one hop in email, or at most two - one from your 
client to your outbound queue, one into my inbound queue. The last hop 
is a different protocol, one that doesn't do delivery so much as remote 
file access.

Steve's Shinkuro looks a lot more like a network. That doesn't mean 
email isn't a network, just a somewhat trivial one, network-wise.

Joe

Date: Mon, 20 Oct 2003 17:13:21 -0700
To: "David L. Mills" <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Re: editing procedures
Cc: [email-masked]
Sender: [email-masked]

At 04:58 PM 10/20/2003, David L. Mills wrote:
>Forrest,
>
>Have you personally experienced the results of translating a complex
>document with endnotes, cross references, tables of contents, equations,
>etc., from FrameMaker to Word or reverse? Give it a go. Even after you
>do that, try editing the resulting document in its native application.

Conversion functions are notoriously incomplete because the permutations of 
format representation found in work-processing files are typically huge, 
and few programmers consider it worth the trouble to cover all cases. I and 
two colleagues once created a very complex and thorough conversion program, 
but we were too early to market and were unable to sell enough copies to 
keep it alive.

The lesson: if you have important files, keep a copy of the application 
program that created them, and keep morfing them into more current formats 
as you move through life.

Forrest

To: Joe Touch <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Re: Protocol layering in the IPN backbone 
Date: Tue, 21 Oct 2003 11:00:03 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Joe Touch <[email-masked]>
> To:    Kevin Fall <[email-masked]>
> cc:    [email-masked]
> Subject: [dtn-interest] Re: Protocol layering in the IPN backbone
> Date:  Tue, 21 Oct 2003 09:46:43 PDT
>
> 
> 
> Kevin Fall wrote:
> >>Durga Prasad Pandey wrote:
> >>
> >>>--- Joe Touch <[email-masked]> wrote:
> >>>
> >>>
> >>>>Choosing a different routing or forwarding mechanism means you have a 
> >>>>network layer. Yes, there are parts that differ from some of the 
> >>>>existing IP forwarding and routing protocols, but that doesn't mean the 
> >>>>architecture isn't the familiar Internet layer structure:
> >>>>
> >>>>	applications
> >>>>
> >>>>	transport
> >>>>
> >>>>	network
> >>>>
> >>>>	link
> > 
> > While I would agree there are substantial similarities between
> > the semantics of 'bundling' and 'network layer', the problem I have
> > calling bundling simply a network layer literally is the following:
> > 
> > for datagram types of networks, our semantic notion of 'network layer' is
> > likely to include an (abstract) message format, a path selection function, 
forwarding
> > function, and an standardized address format.  Being a 'datagram' network l
ayer, we might
> > well expect a finite [somewhat small] limit to the size of messages, and th
e
> > lack of reliability/flow-control/connections/order-preservation.
> 
> I wouldn't necessarily assume any of those, except for the lack of 
> connections, except when speaking about Internet datagrams.

well, ok I guess.  There are network layers that do not have all these properties.
The problem is those other conceivable network layers are not what people typically
think of when you say 'network layer', so you end up having to explain a bunch
of gunk anyway.

> 
> Either way, though - it's a network layer.
> 

Again, call it what you will.  I believe it actually confuses the issue
to call it that, however.

> > For the "bundling" layer, we have many of these things too, and so yes you
> > could conceivably call it a network layer.
> > Why don't we do this?  Well, to say something
> > like:  "its a network layer with store-and-forward forwarding, late bound a
ddresses,
> > hop-by-hop reliability with e2e acks and infinite message sizes" is quite a
 mouthful.
> > (and makes one sort of wonder why you called it a 'network layer' at all; w
hat
> > benefit do you derive from having to add so many qualifiers?).
> 
> it's a network
> 	Agreed
> with store-and-forward forwarding
> 	Agreed
> late-bound addresses
> 	Unclear what this really means. Bundling's late binding, IMO,
> 	is closer to what ARP does over a subnet. Yes, this is required
> 	when traversing a network overlaid on a network. But let's
> 	say "some alternate forwarding mechanism"
> 	and agree in principle.

Actually it is clear what it means...  It means this:  you can construct
addresses that contain a substring that is treated as opaque data when carried
through the network and then interpreted in a domain ("region" for us) where it
is interpretable.  The difference from ARP is this:  ARP will map a universally
agreed upon (global, NAT not withstanding) address to whatever is needed to transfer
the (datagram) one futher hop.  That is not what we are up to here.  When I relate
DTN late binding to e-mail, you should be thinking of this sort of stuff:

	[email-masked]

Maybe not used so much anymore, but I give e-mail the benefit of the doubt in
at least potentially supporting the type of late binding I am referring to.
A more interesting case may be when we consider URNs as DTN addresses:

	bundles://remote_region/urn://kevins_pager

This implies a form of associative lookup in the remote_region.  To me this differs
substantially from what I expect 'addressing in a typical network layer' to look like.

> hop-by-hop reliability
> 	lots of links have reliability already, including FEC
> 	and retransmission. it's a link property, not a network
> 	property.

Yes, lots of links do.  Many don't.  I would therefore argue
that reliability is not a property of any particular layer.  It is just a property.
It could be that just about any layer has some.

But I think maybe your comment reveals something about your thinking.  If your position
is that certain functions 'belong' to certain layers and if a subsystem provides
a particular function that you believe is owned by some particular layer, you must
choose to use the corresponding layer name.   Is that your approach?

> E2E acks
> 	this, perhaps with late-bound addresses, are the key
> 	differences, IMO.

um, ok I guess...  But its pretty curious to me why this would
seem like a key difference but the other things don't.

> infinite message sizes
> 	nothing that is store-and-forward is infinite.

yes, 'infinite' was used loosely here

> 	perhaps you mean "unlimited, but of a fixed size at the
> 	time of transmission", and yes, to me that's a datagram
> 	property. The size of that limit is an artifact of
> 	implementation considerations; even bundles will have an
> 	upper bound, e.g., that of the size of the smallest
> 	store-and-forward buffer. Otherwise, they're not being stored-
> 	and forwarded.

well, we have bundle fragmentation.  So, as in the case of IP, I guess
you get back to 'packet' vs 'datagram'.  Whatever you want to label it,
DTN messages are of (essentially) arbitrary length (yes, limited by
implementation considerations).  But it is not the case they have to
be of size limited by the smallest s&f buffer.  And yes if you then
want to call that 'not s&f', I guess I might agree 'legally', but I
would still say its s&f to people who I am explaining the concept to.
A more legalistic approach might be to say message fragments are routed
where persistent storage can be employed where necessary, or some such.

> > Indeed, I would feel more comfortable calling bundling 'e-mail with fancy r
outing'.
> > Both have: late bound addressing, store-and-forward forwarding, routing [so
rt of],
> > a variable-length message format, security [sort of], e2e return-receipt [s
ort of].
> 
> Email lacks e2e return receipt per se. That's an artifact of application 
> programs, not the email system itself.

um, no.  RFC3461.  Also X.400 I believe.

> 
> Email lacks network-layer security as well; that too is an artifact of 
> the application program, not the email system.

RFC3207

> 
> > For bundling we try to convert 'sort of' into 'real', plus add an API that 
apps
> > can make effective use of  (unlike e-mail I would argue; although I'm open
> > to opposing viewpoints).  If you like to think of e-mail as a network layer
, then
> > I guess you can, (but I would prefer not to because I feel it makes the con
versation
> > more cumbersome from that point onward).  Are you comfortable calling e-mai
l a
> > network layer?
> 
> Although email can be configured to be a network, mail usually goes 1 
> hop via SMTP.

Not at my site [at least for incoming mail].
It typically goes about 3 by SMTP, and often 1  by POP/IMAP.
I believe it is very common that multiple hops are used.

> Consider your mail to me, which went through the loopback 
> interface (persumably to use SSL or filters) then direct from 
> dwight.cs.berkeley.edu to tnt.isi.edu. OK, so that's 2 hops, but one of 
> them is an artifact. It's a network, but not a very interesting one in 
> that regard, at least in most cases.

see above.

> 
> When email is used, e.g., to forward files (as done by Steve Crocker's 
> company), then yes, it's a network. I.e., it's partly defined by 
> capability, and partly by use, as with any other overlay.
> 
> Joe
> 

Not sure where this statement leads.  So is it 'not a network' if its
used to forward e-mails if we don't call them "files"?

- K

From: Bob Braden <[email-masked]>
Date: Tue, 21 Oct 2003 10:40:55 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures
Cc: [email-masked], [email-masked]
Sender: [email-masked]

  *> > 
  *> > Yes, you are right. For document-archiving across long time periods 
  *> > (e.g., a decade), you need to save data files, application programs, and 
  *> > OS/hardware platforms.
  *> 
  *> As Bob has observed, the RFC series is the counterexample. I don't need 
  *> anything other than the RFC file. Sure, the nroff is nice to have, but 
  *> it's trivial to recreate the formatting.
  *> 

Well, the unfortunate fact is that the RFC series did not fare well
when TOPS 20s were replaced by Unix and DEC tapes became unusable.  We
are still in the process of restoring paper copies of some of the early
RFCs into online files, due to that transition.  (In fact, this
disaster was avoidable, in principle; it was the result in inattention
and miscommunication -- the usual culprits.)  OTOH, the demise of SRI's
NLS system did not have a bad effect even though many early RFCs were
prepared in NLS, because the RFCs were archived as ASCII files as well
as NLS files.

Bob Braden

To: Warthman Associates <[email-masked]>
cc: "David L. Mills" <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures 
Date: Tue, 21 Oct 2003 10:28:46 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Warthman Associates <[email-masked]>
> To:    "David L. Mills" <[email-masked]>
> cc:    [email-masked]
> Subject: Re: [dtn-interest] Re: editing procedures
> Date:  Tue, 21 Oct 2003 10:01:18 PDT
>
> David,
> 
> Yes, you are right. For document-archiving across long time periods (e.g., 
> a decade), you need to save data files, application programs, and 
> OS/hardware platforms.
> 
> But there is also the issue of storage media.
> 
> The last article I read on archival-media research pointed out that digital 
> storage on magnetic or optical media is good for only a few (3?) decades, 
> whereas storage on paper, clay, metal, and stone can be good for centuries 
> or millennia, depending on material and environment.
> 
> So, in addition to keeping your data files, application programs, and 
> OS/hardware hardware, also:
> 
> - Keep printed paper copies, and
- Get a scanner that supports OCR.
> 
> In the past 5 years I have retrieved a few documents from oblivion using 
> the OCR program that came free with my HP scanner. It worked much better 
> than I expected -- at least 80% correct words (but no figures, equations, 
> or tables).
> 
> Forrest

I have recently OCR'd some things and had success with the figures and tables
as well (it even understood a table was a table and offered to make an MS Word "table"
out of it).  I found OCR success is greatly enhanced if you put provide a little user input
(like help the OCR program know what is text vs what is figures).  This is a bit
painful (a few seconds per page), but worked quite well.  Actually
the figures did somewhat better than the text.  [this was also with the
HP bundled OCR stuff that came with the scanner we have]).

- K

Date: Tue, 21 Oct 2003 10:24:29 -0700
From: Joe Touch <[email-masked]>
To: Warthman Associates <[email-masked]>
CC: "David L. Mills" <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures
Sender: [email-masked]

Warthman Associates wrote:

> David,
> 
> Yes, you are right. For document-archiving across long time periods 
> (e.g., a decade), you need to save data files, application programs, and 
> OS/hardware platforms.

As Bob has observed, the RFC series is the counterexample. I don't need 
anything other than the RFC file. Sure, the nroff is nice to have, but 
it's trivial to recreate the formatting.

> But there is also the issue of storage media.
> 
> The last article I read on archival-media research pointed out that 
> digital storage on magnetic or optical media is good for only a few (3?) 
> decades, whereas storage on paper, clay, metal, and stone can be good 
> for centuries or millennia, depending on material and environment.

Anyone who takes dealing with such data seriously already considers 
these issues.

Which is also why the RFCs at one time declared the paper copy with the 
RFC-Editor to be the de-facto original. Those copies still exist, BTW; a 
set is archived with the Postel Center here at ISI.

Joe

Date: Tue, 21 Oct 2003 10:01:18 -0700
To: "David L. Mills" <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Re: editing procedures
Cc: [email-masked]
Sender: [email-masked]

David,

Yes, you are right. For document-archiving across long time periods (e.g., 
a decade), you need to save data files, application programs, and 
OS/hardware platforms.

But there is also the issue of storage media.

The last article I read on archival-media research pointed out that digital 
storage on magnetic or optical media is good for only a few (3?) decades, 
whereas storage on paper, clay, metal, and stone can be good for centuries 
or millennia, depending on material and environment.

So, in addition to keeping your data files, application programs, and 
OS/hardware hardware, also:

- Keep printed paper copies, and
- Get a scanner that supports OCR.

In the past 5 years I have retrieved a few documents from oblivion using 
the OCR program that came free with my HP scanner. It worked much better 
than I expected -- at least 80% correct words (but no figures, equations, 
or tables).

Forrest

At 09:17 PM 10/20/2003, David L. Mills wrote:
>Forrest,
>
>Good advice to keep a copy of the application that produces treasured
>archive documents. Better keep the machine, too. Ummm. My dissertation
>in 1971 used a System/360 typesetter program of my own design for a
>Teletype 38. That was foolish of me, but I bet the program would still
>run on the IBM 9020 used by the FAA. The 38 would be a problem; I talked
>the Teletype folks into making a special typebox including Greek
>characters. Many of my earlier treasured archive documents were in
>RUNOFF for the PDP11. I've one in my basement, but when I fire it up it
>smells of burning plastic. Now about those archives on paper tape and
>9-track magtape...
>
>Good clean fun; no offense intended. My studied conclusion: if Adobe
>owns the world, invest in a mud brick factory.
>
>Dave
>
>Warthman Associates wrote:
> >
> > At 04:58 PM 10/20/2003, David L. Mills wrote:
> > >Forrest,
> > >
> > >Have you personally experienced the results of translating a complex
> > >document with endnotes, cross references, tables of contents, equations,
> > >etc., from FrameMaker to Word or reverse? Give it a go. Even after you
> > >do that, try editing the resulting document in its native application.
> >
> > Conversion functions are notoriously incomplete because the permutations of
> > format representation found in work-processing files are typically huge,
> > and few programmers consider it worth the trouble to cover all cases. I and
> > two colleagues once created a very complex and thorough conversion program,
> > but we were too early to market and were unable to sell enough copies to
> > keep it alive.
> >
> > The lesson: if you have important files, keep a copy of the application
> > program that created them, and keep morfing them into more current formats
> > as you move through life.
> >
> > Forrest
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Tue, 21 Oct 2003 09:46:43 -0700
From: Joe Touch <[email-masked]>
To: Kevin Fall <[email-masked]>
CC: [email-masked]
Subject: [dtn-interest] Re: Protocol layering in the IPN backbone
Sender: [email-masked]

Kevin Fall wrote:
>>Durga Prasad Pandey wrote:
>>
>>>--- Joe Touch <[email-masked]> wrote:
>>>
>>>
>>>>Choosing a different routing or forwarding mechanism means you have a 
>>>>network layer. Yes, there are parts that differ from some of the 
>>>>existing IP forwarding and routing protocols, but that doesn't mean the 
>>>>architecture isn't the familiar Internet layer structure:
>>>>
>>>>	applications
>>>>
>>>>	transport
>>>>
>>>>	network
>>>>
>>>>	link
> 
> While I would agree there are substantial similarities between
> the semantics of 'bundling' and 'network layer', the problem I have
> calling bundling simply a network layer literally is the following:
> 
> for datagram types of networks, our semantic notion of 'network layer' is
> likely to include an (abstract) message format, a path selection function, forwarding
> function, and an standardized address format.  Being a 'datagram' network layer, we might
> well expect a finite [somewhat small] limit to the size of messages, and the
> lack of reliability/flow-control/connections/order-preservation.

I wouldn't necessarily assume any of those, except for the lack of 
connections, except when speaking about Internet datagrams.

Either way, though - it's a network layer.

> For the "bundling" layer, we have many of these things too, and so yes you
> could conceivably call it a network layer.
> Why don't we do this?  Well, to say something
> like:  "its a network layer with store-and-forward forwarding, late bound addresses,
> hop-by-hop reliability with e2e acks and infinite message sizes" is quite a mouthful.
> (and makes one sort of wonder why you called it a 'network layer' at all; what
> benefit do you derive from having to add so many qualifiers?).

it's a network
	Agreed
with store-and-forward forwarding
	Agreed
late-bound addresses
	Unclear what this really means. Bundling's late binding, IMO,
	is closer to what ARP does over a subnet. Yes, this is required
	when traversing a network overlaid on a network. But let's
	say "some alternate forwarding mechanism"
	and agree in principle.
hop-by-hop reliability
	lots of links have reliability already, including FEC
	and retransmission. it's a link property, not a network
	property.
E2E acks
	this, perhaps with late-bound addresses, are the key
	differences, IMO.
infinite message sizes
	nothing that is store-and-forward is infinite.
	perhaps you mean "unlimited, but of a fixed size at the
	time of transmission", and yes, to me that's a datagram
	property. The size of that limit is an artifact of
	implementation considerations; even bundles will have an
	upper bound, e.g., that of the size of the smallest
	store-and-forward buffer. Otherwise, they're not being stored-
	and forwarded.

> Indeed, I would feel more comfortable calling bundling 'e-mail with fancy routing'.
> Both have: late bound addressing, store-and-forward forwarding, routing [sort of],
> a variable-length message format, security [sort of], e2e return-receipt [sort of].

Email lacks e2e return receipt per se. That's an artifact of application 
programs, not the email system itself.

Email lacks network-layer security as well; that too is an artifact of 
the application program, not the email system.

> For bundling we try to convert 'sort of' into 'real', plus add an API that apps
> can make effective use of  (unlike e-mail I would argue; although I'm open
> to opposing viewpoints).  If you like to think of e-mail as a network layer, then
> I guess you can, (but I would prefer not to because I feel it makes the conversation
> more cumbersome from that point onward).  Are you comfortable calling e-mail a
> network layer?

Although email can be configured to be a network, mail usually goes 1 
hop via SMTP. Consider your mail to me, which went through the loopback 
interface (persumably to use SSL or filters) then direct from 
dwight.cs.berkeley.edu to tnt.isi.edu. OK, so that's 2 hops, but one of 
them is an artifact. It's a network, but not a very interesting one in 
that regard, at least in most cases.

When email is used, e.g., to forward files (as done by Steve Crocker's 
company), then yes, it's a network. I.e., it's partly defined by 
capability, and partly by use, as with any other overlay.

Joe

From: Bob Braden <[email-masked]>
Date: Tue, 21 Oct 2003 09:08:37 -0700 (PDT)
To: [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures
Cc: [email-masked]
Sender: [email-masked]

  *> 
  *> Good clean fun; no offense intended. My studied conclusion: if Adobe
  *> owns the world, invest in a mud brick factory.
  *> 

Dave,

Microsoft owns the world.  What should we invest in?

Bob

  *> Dave

To: [email-masked]
cc: [email-masked]
Date: Tue, 21 Oct 2003 08:08:53 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] Re: Protocol layering in the IPN backbone
Sender: [email-masked]

> Durga Prasad Pandey wrote:
> > --- Joe Touch <[email-masked]> wrote:
> > 
> >>Choosing a different routing or forwarding mechanism means you have a 
> >>network layer. Yes, there are parts that differ from some of the 
> >>existing IP forwarding and routing protocols, but that doesn't mean the 
> >>architecture isn't the familiar Internet layer structure:
> >>
> >>	applications
> >>
> >>	transport
> >>
> >>	network
> >>
> >>	link
> >>
> > 
> > 

While I would agree there are substantial similarities between
the semantics of 'bundling' and 'network layer', the problem I have
calling bundling simply a network layer literally is the following:

for datagram types of networks, our semantic notion of 'network layer' is
likely to include an (abstract) message format, a path selection function, forwarding
function, and an standardized address format.  Being a 'datagram' network layer, we might
well expect a finite [somewhat small] limit to the size of messages, and the
lack of reliability/flow-control/connections/order-preservation.

For the "bundling" layer, we have many of these things too, and so yes you
could conceivably call it a network layer.
Why don't we do this?  Well, to say something
like:  "its a network layer with store-and-forward forwarding, late bound addresses,
hop-by-hop reliability with e2e acks and infinite message sizes" is quite a mouthful.
(and makes one sort of wonder why you called it a 'network layer' at all; what
benefit do you derive from having to add so many qualifiers?).

Indeed, I would feel more comfortable calling bundling 'e-mail with fancy routing'.
Both have: late bound addressing, store-and-forward forwarding, routing [sort of],
a variable-length message format, security [sort of], e2e return-receipt [sort of].
For bundling we try to convert 'sort of' into 'real', plus add an API that apps
can make effective use of  (unlike e-mail I would argue; although I'm open
to opposing viewpoints).  If you like to think of e-mail as a network layer, then
I guess you can, (but I would prefer not to because I feel it makes the conversation
more cumbersome from that point onward).  Are you comfortable calling e-mail a
network layer?

- K

Date: Tue, 21 Oct 2003 07:43:43 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: Durga Prasad Pandey <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Durga Prasad Pandey wrote:
> --- Joe Touch <[email-masked]> wrote:
> 
>>Choosing a different routing or forwarding mechanism means you have a 
>>network layer. Yes, there are parts that differ from some of the 
>>existing IP forwarding and routing protocols, but that doesn't mean the 
>>architecture isn't the familiar Internet layer structure:
>>
>>	applications
>>
>>	transport
>>
>>	network
>>
>>	link
>>
> 
> 
> I think it is incorrect to treat "network layer" as a concept.

Sure, lots of people have disagreed with the ISO layers and the Internet 
interpretation of them.

> My
> understanding is that it is **routing** which is the concept-it is a
> function, and it is performed at a certain layer *called* the 'network
> layer'. 

Forwarding and routing are the two functions, and they are performed, by 
definition, at the network layer.

> In the IPN, it is proposed that the **routing** function be delegated to
> the bundling layer. Now, if the bundling layer's functions was exactly
> same as the network layer in the Internet, there was no need for us to
> call it 'bundling'. Bundling, however introduces concepts such as
> custodial transfer, and late binding, which have no parallels in the
> Internet architecture.

Well, that's open for debate. Custodial transfer isn't substantially 
different from IP packet forwarding. There seems to be a lot of 
confusion about overlays in this regard. I.e., in an Internet overlay 
(IP over another network), the 'custody' of, e.g., an IP packet, is 
transferred with the IP packet between IP routers, which may transfer 
them over links which retransmit portions thereof..

Late binding defines how addresses are interpreted in the context of 
forwarding decisions, and may be a different forwarding function, but 
it's still a conventional network-layer operation.

Yes, it's not the Internet, but it walks and talks like a conventional 
network layer.

> Yes, I could forcibly call it the network layer. But wouldn't that confuse
> one more -- since I would be mixing concepts -- rather than giving the
> *different* layer a *different* name?

Different names work well when the concept is indeed different. This is 
precisely what everyone else calls a network layer.

There may be benefit to examining other forwarding functions (e.g., IPv6 
is doing that, as do geographic overlays that we're doing, etc.), other 
routing protocols, etc. They're all still conventional network layers 
though.

> And if our proposal for a cognition
> based approach to congestion control is eventually accepted, the bundling
> layer is going to be even more different; but that is only a speculation.

Link-by-link congestion control is called a link layer (pt-pt ethernet 
does it, e.g.). End to end congetestion control is called a transport 
layer. It doesn't matter whether the congestion control is based on 
fluid dynamics, quantum mechanics, or cognition - it's all called 
congestion control.

>>Talking about not needing a network layer is confusing, especially when 
>>you have a network layer, very much where the Internet architecture 
>>would dictate. The same is true for presenting them as distinct layers, 
>>separate from the Internet layers.
> 
> I think bundling is remarkably different from anything we have in the
> Internet architecture. Yes, I agree that there *is* a layer that performs
> routing in the Internet backbone -- as the Internet architecture would
> dictate -- but calling that layer the "network" layer doesn't look
> justified. 
> 
> It would also be useful to remember that "bundling" is the key concept in
> the IPN, as "datagram" is in the Internet. I believe that the Internet
> architecture is defined not only on the basis of the protocol layers and
> their functions, but also on the *key* concept of "datagram".(See "The
> design philosophy of the DARPA Internet protocols" by David Clark).
> Equating the IPN architecture with the Internet architecture doesn't look
> right at all, at least to me.

The largest distinctions I have seen between IPN and the Internet are:

	- IPN prohibits E2E connections
		i.e., in Internet-speak, UDP is supported,
		but not TCP.

	- IPN forwards based on partial addresses
		the Internet does this in subnets;
		IPN formalizes it a bit more,
		and does add some other steps

Bundles still walk and talk like datagrams to me. We add characteristics 
to datagrams all the time - e.g., partial checksums are in development. 
That doesn't make them 'swatches'; they're still a unit of transmission.
It might make sense to add adjectives, e.g., ordered, reliable (but 
that's a misnomer if there's no E2E retransmission), etc.

The rest of the details, IMO, are based on interpretations about how 
overlays use links. Breaking a UDP packet up and transmitting it - or 
retransmitting portions, etc. - over a link, doesn't make it not a UDP 
packet.

...

> What the questions that are pressing on our minds are : 
>
> -Is there any problem with the functions delegated to the various layers? 
> 
> -**Would this architecture work** in the IPN backbone? , and 
> 
> - Would it be fine to have the Licklider Transmission Protocol at the link
> layer, on top of a link protocol like the CCSDS link(or some other
> protocol) providing a limited amount of ARQ?

These are interesting questions that the language and layering model 
obfuscate. When I present my interpretation of the model to others, they 
immediately hit upon the salient issues, and we move on to a meaningful 
discussion quickly.

My impression is that others reading this model get hung up on names and 
layers that they have to re-learn, in ways that don't add to getting at 
the real issues (and there ARE real issues here).

Joe

Date: Tue, 21 Oct 2003 05:47:23 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
To: Joe Touch <[email-masked]>, Scott Burleigh <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--- Joe Touch <[email-masked]> wrote:
>Choosing a different routing or forwarding mechanism means you have a 
>network layer. Yes, there are parts that differ from some of the 
>existing IP forwarding and routing protocols, but that doesn't mean the 
>architecture isn't the familiar Internet layer structure:
>
>	applications
>
>	transport
>
>	network
>
>	link
>

I think it is incorrect to treat "network layer" as a concept. My
understanding is that it is **routing** which is the concept-it is a
function, and it is performed at a certain layer *called* the 'network
layer'. 

In the IPN, it is proposed that the **routing** function be delegated to
the bundling layer. Now, if the bundling layer's functions was exactly
same as the network layer in the Internet, there was no need for us to
call it 'bundling'. Bundling, however introduces concepts such as
custodial transfer, and late binding, which have no parallels in the
Internet architecture.

Yes, I could forcibly call it the network layer. But wouldn't that confuse
one more -- since I would be mixing concepts -- rather than giving the
*different* layer a *different* name? And if our proposal for a cognition
based approach to congestion control is eventually accepted, the bundling
layer is going to be even more different; but that is only a speculation.

> Talking about not needing a network layer is confusing, especially when 
>you have a network layer, very much where the Internet architecture 
>would dictate. The same is true for presenting them as distinct layers, 
>separate from the Internet layers.

I think bundling is remarkably different from anything we have in the
Internet architecture. Yes, I agree that there *is* a layer that performs
routing in the Internet backbone -- as the Internet architecture would
dictate -- but calling that layer the "network" layer doesn't look
justified. 

It would also be useful to remember that "bundling" is the key concept in
the IPN, as "datagram" is in the Internet. I believe that the Internet
architecture is defined not only on the basis of the protocol layers and
their functions, but also on the *key* concept of "datagram".(See "The
design philosophy of the DARPA Internet protocols" by David Clark).
Equating the IPN architecture with the Internet architecture doesn't look
right at all, at least to me.

>Fair enough. But there are correlations between the conventional 
>Internet layers and some of the Internet protocols and the IPN/DTN 
>'layering'.

Yes, indeed, there are. 

>
>Calling them something else doesn't "not" make them transport, network, 
>or link layers.

Well, I think it's a language issue, and I have already presented my
arguments above. 

What the questions that are pressing on our minds are : 
-Is there any problem with the functions delegated to the various layers? 

-**Would this architecture work** in the IPN backbone? , and 

- Would it be fine to have the Licklider Transmission Protocol at the link
layer, on top of a link protocol like the CCSDS link(or some other
protocol) providing a limited amount of ARQ?

Durga

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Mon, 20 Oct 2003 22:48:53 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Scott Burleigh wrote:

> At 02:31 PM 10/20/2003 -0700, Joe Touch wrote:
...
>> I'm not sure I agree that TCP/IP isn't what you end up with, i.e., not 
>> the TCP part, but UDP/IP/ATM in essence. Calling it "bundling" doesn't 
>> make it substantially different from what ATM does in UDP/IP/ATM, and 
>> it is not at all clear that an Interplanetary system should proscribe 
>> a single link mechanism
> 
> Well, it seems to me that if you leave out TCP then TCP/IP is not what 
> you end up with.
> 
> Maybe you end up with UDP/IP/ATM; we've had some spirited discussions of 
> that option vs Bundling in this forum, and there will probably be many 
> more.  But I don't understand what you mean by "UDP/IP/ATM in essence".  
> If you're not using the UDP protocol, and you're not using the IP 
> protocol, and you're not using the ATM protocol, but you are instead 
> using a distinct, independently defined protocol named "Bundling" that 
> has altogether different header structure and a different set of 
> specific operational features, then it seems to me that you're not using 
> UDP/IP/ATM in essence or in any other way.

Fair enough. But there are correlations between the conventional 
Internet layers and some of the Internet protocols and the IPN/DTN 
'layering'.

Calling them something else doesn't "not" make them transport, network, 
or link layers.

...
> Sure, in the Interplanetary backbone it is confusing because the 
> Internet protocols are absent.  But Bundling is designed to be an 
> end-to-end protocol, and on those portions of the end-to-end path where 
> it is running on top of TCP/IP those Internet protocols are very much 
> involved.  Since, in that environment, you've got application protocol 
> running on top of Bundling, which in turn runs on top of TCP/IP, and 
> since we all know that IP runs at the network layer of the stack, at 
> what layer of the stack does Bundling run?  And if it's at that layer 
> "X" during the Internet hops of the end-to-end path, why isn't it at the 
> same layer X during the deep space hop(s)?  And if it is, then what's at 
> the Network layer?

In an overlay, the properties of the underying network - however 
complex, and at whatever layer in _that_ network, are precisely a link 
layer as far as the overlay is concerned. That's the nature of an overlay.

IP runs at the network layer in _its_ stack, not in all stacks to all 
networks. IP is a physical layer to ethernet over IP (L2VPNs).

I.e., it doesn't matter that I run TCP(1) over IP(1) over TCP(2) which 
is over IP(2). To the top network (1), TCP is the transport, IP is the 
network, and TCP(2) and below are the link. This is why I've been saying 
(for a while) that IPN essentially uses TCP as a link layer. It doesn't 
matter that TCP(2) runs over a 'network' - as far as TCP(1) is 
concerned, there's no network at all. It's just a link in the top (1) 
network.

IMO, it's not at all confusing when you call them the application, 
transport, network, and link layers that they are. And if bundling 
indeed combines application and network layers, then it might be closer 
to NCP, and the bundles closer to crates (RFC60) - but wasn't there a 
lesson in separating those layers, somewhere in the 700's? ;-)

Joe

Date: Tue, 21 Oct 2003 04:17:22 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
Cc: [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures
Sender: [email-masked]

Forrest,

Good advice to keep a copy of the application that produces treasured
archive documents. Better keep the machine, too. Ummm. My dissertation
in 1971 used a System/360 typesetter program of my own design for a
Teletype 38. That was foolish of me, but I bet the program would still
run on the IBM 9020 used by the FAA. The 38 would be a problem; I talked
the Teletype folks into making a special typebox including Greek
characters. Many of my earlier treasured archive documents were in
RUNOFF for the PDP11. I've one in my basement, but when I fire it up it
smells of burning plastic. Now about those archives on paper tape and
9-track magtape...

Good clean fun; no offense intended. My studied conclusion: if Adobe
owns the world, invest in a mud brick factory.

Dave

Warthman Associates wrote:
> 
> At 04:58 PM 10/20/2003, David L. Mills wrote:
> >Forrest,
> >
> >Have you personally experienced the results of translating a complex
> >document with endnotes, cross references, tables of contents, equations,
> >etc., from FrameMaker to Word or reverse? Give it a go. Even after you
> >do that, try editing the resulting document in its native application.
> 
> Conversion functions are notoriously incomplete because the permutations of
> format representation found in work-processing files are typically huge,
> and few programmers consider it worth the trouble to cover all cases. I and
> two colleagues once created a very complex and thorough conversion program,
> but we were too early to market and were unable to sell enough copies to
> keep it alive.
> 
> The lesson: if you have important files, keep a copy of the application
> program that created them, and keep morfing them into more current formats
> as you move through life.
> 
> Forrest

Date: Mon, 20 Oct 2003 23:58:22 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
Cc: [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures
Sender: [email-masked]

Forrest,

Have you personally experienced the results of translating a complex
document with endnotes, cross references, tables of contents, equations,
etc., from FrameMaker to Word or reverse? Give it a go. Even after you
do that, try editing the resulting document in its native application.

Dave

Warthman Associates wrote:
> 
> At 01:26 PM 10/20/2003, Joe Touch wrote:
> 
> >         - There's no support in Word to input Wordstar files.
> 
> There used to be in the early 1980's versions of Word. For a current choice
> of conversion services, see:
> 
> http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&q=wordstar+format+conversion&btnG=Google+Search
> 
> >         - Word doesn't input or output Frame.
> 
> Word's Rich Text Format (.RTF) is the transfer medium you need. Both Word
> and FrameMaker can save files as .RTF, and both can open .RTF files. Other
> applications also save and open .RTF files.
> 
> >         - There was (and is, to my knowledge) no converter
> >         for Persuasion files into PowerPoint format.
> 
> You could try converting Persuasion files to HTML, and from there to other
> formats. See:
> 
> http://www.w3.org/Tools/Filters.html
> 
> Here are other useful converter:
> 
> http://documents.cern.ch/Convert
> 
> There are many indirect conversion methods, using multiple intermediate
> formats to get where you are going.
> 
> Also, you could dispense with presentation tools and create your
> presentations in Word of FrameMaker, so they will be conveniently available
> for your long technical documents. Just create a page size in Word of
> FrameMaker that matches your display size.
> 
> A quick way to get .PDF content into Word or Frame: select all in PDF, copy
> to clipboard, paste into Word or Frame. It's not pretty (plain ASCII), but
> it works. It's also a quick way to do a word-count of the PDF file (using
> the word-count utility in Word or Frame).
> 
> Forrest

Date: Mon, 20 Oct 2003 16:26:19 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: Warthman Associates <[email-masked]>
CC: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures
Sender: [email-masked]

Warthman Associates wrote:

> At 01:26 PM 10/20/2003, Joe Touch wrote:
> 
> 
>>         - There's no support in Word to input Wordstar files.
> 
> 
> There used to be in the early 1980's versions of Word. For a current 
> choice of conversion services, see:
> 
> http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&q=wordstar+format+conversion&btnG=Google+Search 
> 
> 
> 
> 
>>         - Word doesn't input or output Frame.
> 
> 
> Word's Rich Text Format (.RTF) is the transfer medium you need. Both 
> Word and FrameMaker can save files as .RTF, and both can open .RTF 
> files. Other applications also save and open .RTF files.

Frame outputs Word, but that's not the same thing - notably, it doesn't 
help when you have an old Frame file from someone else and don't have 
Frame yourself.

>>         - There was (and is, to my knowledge) no converter
>>         for Persuasion files into PowerPoint format.
> 
> You could try converting Persuasion files to HTML, and from there to 
> other formats.

I have a Persuasion file; I don't have Persuasion (anymore). How do I 
output HTML?

The problem isn't the lack of common formats; it's the lack of ways to 
go from one to another UNLESS you run something on both ends. It's too 
easy to end up with a dead-end.

> See:
> 
> http://www.w3.org/Tools/Filters.html

That page was written in in 1996; many of its links are dead. And I 
didn't see any that did either Persuasion or Wordstar.

> Here are other useful converter:
> 
> http://documents.cern.ch/Convert
 >
> There are many indirect conversion methods, using multiple intermediate 
> formats to get where you are going.

OK - specifically, how do I go from Persuasion, a format that's long 
since abandoned, to ANYTHING, given the fact that nothing runs 
Persuasion anymore?

> Also, you could dispense with presentation tools and create your 
> presentations in Word of FrameMaker, so they will be conveniently 
> available for your long technical documents. Just create a page size in 
> Word of FrameMaker that matches your display size.

All that does is move the problem somewhere else. I.e., then I rely on 
Word or Frame existing. Besides, I want Word/Frame because they do 
things that ASCII doesn't, right? Same reason I want 
Persuasion/PowerPoint rather than Word/Frame.

> A quick way to get .PDF content into Word or Frame: select all in PDF, 

Presumes the author allows you to select text. Some docs have a flag set 
that prohibits this. Also presumes I'm on a box that has PDF viewers 
installed. Nothing reads PDF as input except Adobe.

> copy to clipboard, paste into Word or Frame. It's not pretty (plain 
> ASCII), but it works. It's also a quick way to do a word-count of the 
> PDF file (using the word-count utility in Word or Frame).
> 
> Forrest

It also fails fairly badly on many multicolumn docs.

Joe

Date: Mon, 20 Oct 2003 15:30:29 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 02:31 PM 10/20/2003 -0700, Joe Touch wrote:

>Scott Burleigh wrote:
>
>>At 01:05 PM 10/20/2003 -0700, Joe Touch wrote:
>>
>>>As I said above, what is not clear is how this model diverges from the 
>>>Internet architecture. The diagram implies that it differs in every 
>>>layer below application and above link. E.g., how is the _architecture_ 
>>>(not the protocols, or the naming) different from, e.g., UDP over IP 
>>>end-to-end (where UDP is the bundle) and ATM on sub-paths (e.g., 
>>>bundle/bindle)?
>>Sure, clearly the architecture Durga has described for communication on 
>>the deep space backbone -- if we understand "architecture" to mean the 
>>number of protocol layers, the order of nesting of the protocols, and the 
>>general responsibilities of the protocols at each layer -- is not 
>>significantly different from the Internet architecture.  That is in fact 
>>part of what reassures us that it is plausible.
>>What your observation seems to imply, though, is that this isomorphism 
>>makes it unnecessary to introduce any new architectural concepts or 
>>language at all in order to characterize in detail a network that could 
>>operate efficiently between two arbitrarily chosen points in the solar 
>>system.  You may be right, but I'm doubtful.
>>If TCP/IP is the wrong solution for end-to-end communication in that 
>>environment, then you want to use something else that is more suitable 
>>(i.e., Bundling).
>
>I'm not sure I agree that TCP/IP isn't what you end up with, i.e., not the 
>TCP part, but UDP/IP/ATM in essence. Calling it "bundling" doesn't make it 
>substantially different from what ATM does in UDP/IP/ATM, and it is not at 
>all clear that an Interplanetary system should proscribe a single link 
>mechanism.

Well, it seems to me that if you leave out TCP then TCP/IP is not what you 
end up with.

Maybe you end up with UDP/IP/ATM; we've had some spirited discussions of 
that option vs Bundling in this forum, and there will probably be many 
more.  But I don't understand what you mean by "UDP/IP/ATM in essence".  If 
you're not using the UDP protocol, and you're not using the IP protocol, 
and you're not using the ATM protocol, but you are instead using a 
distinct, independently defined protocol named "Bundling" that has 
altogether different header structure and a different set of specific 
operational features, then it seems to me that you're not using UDP/IP/ATM 
in essence or in any other way.

You're not using UDP/IP/ATM and calling it something else, you're using 
something different (that is called something else).  That may or not be a 
wise technical decision: the Bundling protocol may or may not be 
technically superior in this context.  But that's an issue of technical 
merit, not a language issue.

Also, as you probably remember, Bundling does not either prescribe or 
proscribe any particular link-layer protocols.  ATM might be fine under 
Bundling; that's still an open question.

>>Granted, "overlay network" obviously isn't a new concept, "unreliable 
>>transmission over a network protocol" isn't a new concept, "link-layer 
>>reliability" isn't a new concept.  But for clarity in talking about 
>>exactly how this interplanetary network is configured and operated, it 
>>seems useful to develop some terms we can use to economically identify 
>>the exact protocols we're proposing to use at different layers, to 
>>describe how the protocols operate and the functionality expected from 
>>each one, to distinguish one overlay network from another that it 
>>encompasses, and so on.  Do you disagree?
>
>Talking about not needing a network layer is confusing, especially when 
>you have a network layer, very much where the Internet architecture would 
>dictate. The same is true for presenting them as distinct layers, separate 
>from the Internet layers.

Sure, in the Interplanetary backbone it is confusing because the Internet 
protocols are absent.  But Bundling is designed to be an end-to-end 
protocol, and on those portions of the end-to-end path where it is running 
on top of TCP/IP those Internet protocols are very much involved.  Since, 
in that environment, you've got application protocol running on top of 
Bundling, which in turn runs on top of TCP/IP, and since we all know that 
IP runs at the network layer of the stack, at what layer of the stack does 
Bundling run?  And if it's at that layer "X" during the Internet hops of 
the end-to-end path, why isn't it at the same layer X during the deep space 
hop(s)?  And if it is, then what's at the Network layer?

Scott 

Date: Mon, 20 Oct 2003 15:21:57 -0700
To: Joe Touch <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Re: editing procedures
Cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 01:26 PM 10/20/2003, Joe Touch wrote:

>         - There's no support in Word to input Wordstar files.

There used to be in the early 1980's versions of Word. For a current choice 
of conversion services, see:

http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&q=wordstar+format+conversion&btnG=Google+Search

>         - Word doesn't input or output Frame.

Word's Rich Text Format (.RTF) is the transfer medium you need. Both Word 
and FrameMaker can save files as .RTF, and both can open .RTF files. Other 
applications also save and open .RTF files.

>         - There was (and is, to my knowledge) no converter
>         for Persuasion files into PowerPoint format.

You could try converting Persuasion files to HTML, and from there to other 
formats. See:

http://www.w3.org/Tools/Filters.html

Here are other useful converter:

http://documents.cern.ch/Convert

There are many indirect conversion methods, using multiple intermediate 
formats to get where you are going.

Also, you could dispense with presentation tools and create your 
presentations in Word of FrameMaker, so they will be conveniently available 
for your long technical documents. Just create a page size in Word of 
FrameMaker that matches your display size.

A quick way to get .PDF content into Word or Frame: select all in PDF, copy 
to clipboard, paste into Word or Frame. It's not pretty (plain ASCII), but 
it works. It's also a quick way to do a word-count of the PDF file (using 
the word-count utility in Word or Frame).

Forrest 

Date: Mon, 20 Oct 2003 14:31:56 -0700
From: Joe Touch <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Scott Burleigh wrote:

> At 01:05 PM 10/20/2003 -0700, Joe Touch wrote:
> 
>> As I said above, what is not clear is how this model diverges from the 
>> Internet architecture. The diagram implies that it differs in every 
>> layer below application and above link. E.g., how is the 
>> _architecture_ (not the protocols, or the naming) different from, 
>> e.g., UDP over IP end-to-end (where UDP is the bundle) and ATM on 
>> sub-paths (e.g., bundle/bindle)?
> 
> Sure, clearly the architecture Durga has described for communication on 
> the deep space backbone -- if we understand "architecture" to mean the 
> number of protocol layers, the order of nesting of the protocols, and 
> the general responsibilities of the protocols at each layer -- is not 
> significantly different from the Internet architecture.  That is in fact 
> part of what reassures us that it is plausible.
> 
> What your observation seems to imply, though, is that this isomorphism 
> makes it unnecessary to introduce any new architectural concepts or 
> language at all in order to characterize in detail a network that could 
> operate efficiently between two arbitrarily chosen points in the solar 
> system.  You may be right, but I'm doubtful.
> 
> If TCP/IP is the wrong solution for end-to-end communication in that 
> environment, then you want to use something else that is more suitable 
> (i.e., Bundling). 

I'm not sure I agree that TCP/IP isn't what you end up with, i.e., not 
the TCP part, but UDP/IP/ATM in essence. Calling it "bundling" doesn't 
make it substantially different from what ATM does in UDP/IP/ATM, and it 
is not at all clear that an Interplanetary system should proscribe a 
single link mechanism.

> The routing and forwarding performed by Bundling, 
> however, are wrong for the portions of the end-to-end that that lie 
> within the Internet, where plain old out-of-the-box IP forwarding does 
> just great. 

Choosing a different routing or forwarding mechanism means you have a 
network layer. Yes, there are parts that differ from some of the 
existing IP forwarding and routing protocols, but that doesn't mean the 
architecture isn't the familiar Internet layer structure:

	applications

	transport

	network

	link

> Bundling need not and should not supplant IP; it should 
> instead use and rely on IP where possible.  We've concluded that 
> Bundling should be the network protocol for an overlay network that 
> subsumes the Internet and planetary Internets and deep space, etc., much 
> as IP is the network protocol for an overlay network (the Internet) that 
> subsumes zillions of LANs and optical backbones and such.

The Internet isn't an overlay network; without IP and IP forwarding, 
there is no transit path for data to span multiple ethernets, optical 
backbones, etc. The defining characteristic of an overlay (IMO) is that 
it provides a secondary topology, not the primary, of multihop service.

> Granted, "overlay network" obviously isn't a new concept, "unreliable 
> transmission over a network protocol" isn't a new concept, "link-layer 
> reliability" isn't a new concept.  But for clarity in talking about 
> exactly how this interplanetary network is configured and operated, it 
> seems useful to develop some terms we can use to economically identify 
> the exact protocols we're proposing to use at different layers, to 
> describe how the protocols operate and the functionality expected from 
> each one, to distinguish one overlay network from another that it 
> encompasses, and so on.  Do you disagree?

Talking about not needing a network layer is confusing, especially when 
you have a network layer, very much where the Internet architecture 
would dictate. The same is true for presenting them as distinct layers, 
separate from the Internet layers.

Granted, some of the protocols used at particular layers are new (e.g., 
the routing protocol), but others (bundling, notably) are presented at a 
variety of layers that is a disservice to understanding exactly what 
they do.

Joe

Date: Mon, 20 Oct 2003 14:02:00 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

At 01:05 PM 10/20/2003 -0700, Joe Touch wrote:

>As I said above, what is not clear is how this model diverges from the 
>Internet architecture. The diagram implies that it differs in every layer 
>below application and above link. E.g., how is the _architecture_ (not the 
>protocols, or the naming) different from, e.g., UDP over IP end-to-end 
>(where UDP is the bundle) and ATM on sub-paths (e.g., bundle/bindle)?

Sure, clearly the architecture Durga has described for communication on the 
deep space backbone -- if we understand "architecture" to mean the number 
of protocol layers, the order of nesting of the protocols, and the general 
responsibilities of the protocols at each layer -- is not significantly 
different from the Internet architecture.  That is in fact part of what 
reassures us that it is plausible.

What your observation seems to imply, though, is that this isomorphism 
makes it unnecessary to introduce any new architectural concepts or 
language at all in order to characterize in detail a network that could 
operate efficiently between two arbitrarily chosen points in the solar 
system.  You may be right, but I'm doubtful.

If TCP/IP is the wrong solution for end-to-end communication in that 
environment, then you want to use something else that is more suitable 
(i.e., Bundling).  The routing and forwarding performed by Bundling, 
however, are wrong for the portions of the end-to-end that that lie within 
the Internet, where plain old out-of-the-box IP forwarding does just 
great.  Bundling need not and should not supplant IP; it should instead use 
and rely on IP where possible.  We've concluded that Bundling should be the 
network protocol for an overlay network that subsumes the Internet and 
planetary Internets and deep space, etc., much as IP is the network 
protocol for an overlay network (the Internet) that subsumes zillions of 
LANs and optical backbones and such.

Granted, "overlay network" obviously isn't a new concept, "unreliable 
transmission over a network protocol" isn't a new concept, "link-layer 
reliability" isn't a new concept.  But for clarity in talking about exactly 
how this interplanetary network is configured and operated, it seems useful 
to develop some terms we can use to economically identify the exact 
protocols we're proposing to use at different layers, to describe how the 
protocols operate and the functionality expected from each one, to 
distinguish one overlay network from another that it encompasses, and so 
on.  Do you disagree?

Scott 

Date: Mon, 20 Oct 2003 13:26:02 -0700
From: Joe Touch <[email-masked]>
To: Warthman Associates <[email-masked]>
CC: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: editing procedures
Sender: [email-masked]

Warthman Associates wrote:

> At 07:40 PM 10/19/2003, Bob Braden wrote:
> 
>>   *>
>>   *> There are two standards emerging in the semiconductor industry for
>>   *> providing comments on review documents (other than good old-fashion
>>   *> handwriting, still the best method from my viewpoint):
>>   *>
>>   *> - Distribute copies in Word or FrameMaker, so reviewers can edit 
>> in those
>>   *> applications.
>>   *> - Distribute copies in PDF, so reviewers can add comments using 
>> Acrobat
>>   *> Reader's comment tools.
>>   *>
>>   *> In both cases, the author of the document can copy comments 
>> electronically
>>   *> and paste them into his/her copy of the original document. Of the 
>> two, I
>>   *> believe Acrobat works best and most universally.
>>   *>
>>
>> Pardon me, but that does not sound like general editing.
>>
>> That is interesting, but I question that it is relevant.  I may be
>> wrong, but I tend to doubt that the semiconductor industry is very
>> concerned that their documents will be readily accessible and editable
>> 20 years from now.  The RFC series cares a lot about this; the series
>> is already 34 years old.
>>
>> Do you believe that Word or Frame will still be backward compatible 20
>> years from now? Would you bet that Frame will even exist? Or that Adobe
>> will still be in business?
>>
>> Bob Braden
> 
> 
> You folks are trying to re-invent a wheel.
> 
> You would be better served to learn from companies who have faced the 
> technical publication problem on a gargantuan scale over the past three 
> decades, as have the semiconductor and computer-system companies (IBM 
> was once, and may still be, the world's largest publisher of technical 
> documents).
> 
> Acrobat is *not* an editing tool, but it allows convenient distribution 
> of, and commenting on, PDF review documents generated by an editing 
> tool. Do the writing in Word or FrameMaker, currently the only widely 
> used choices; if the documents are simple (as the DTN architecture 
> document currently is), Word can be used (but avoid copy-and-paste of 
> graphics; instead, learn how to use Word's file-import and 
> OLE-object-import methods correctly). As documents get into several 
> hundred pages with complex features, as I am accustomed to writing, 
> FrameMaker has been the best choice for the past decade; it functions 
> most predictably and allows cross-platform exchange of files across 
> common OSes.
> 
> It does not matter whether FrameMaker or Word will be around 20 or 100 
> years from now. The one thing you can be sure of is that whatever 
> editors take the place of Word and FrameMaker will provide a 
> format-conversion method, built-in, because that is the only way a 
> replacement tool can sell successfully into the commercial market, which 
> has many millions of legacy documents it must preserve.

Sure, in retrospect, we could have used Word 10 or even nearly 20 years 
ago and ended up with a (mostly) backward-compatible source format. 
However, it wasn't so clear in the mid-1980's that Word would win, e.g., 
vs. Wordstar, notably. There was also a time when Aldus Persuasion was 
the de-facto presentation format.

Replacements sometimes dominate a market and the original format just 
disappears. Neither Word nor Powerpoint dominated the market by 
providing backward compatible input of competitors' formats:

	- There's no support in Word to input Wordstar files.

	- Word doesn't input or output Frame.

	- There was (and is, to my knowledge) no converter
	for Persuasion files into PowerPoint format.

Joe

Date: Mon, 20 Oct 2003 13:05:04 -0700
From: Joe Touch <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Durga Prasad Pandey wrote:

> --- Joe Touch <[email-masked]> wrote:
> 
>>>Routing is done at the bundling layer, so the conventional 'network'
>>
>>layer
>>
>>>is effectively rendered redundant.
>>
>>Comparing this model to some (now) historical examples, e.g., IP over 
>>ATM, I'm left wondering what really changed.
>>
>>Doing routing at the bundle layer doesn't render a conventional network 
>>layer redundent, so much as it _is_ the conventional network layer.
> 
> If it's my choice of words that you are referring to, how does this
> sound?: We do not have a separate layer called the network layer in the
> IPN backbone, since routing is done at the bundling layer.

If routing is done at the bundle layer (I think you mean "on bundles", 
rather than "where bundles are segmented or reassembled", which is where 
I think of 'bundling' as happening), then that _is_ the network layer.

The implication of your phrasing is that you don't have a network layer. 
You do - it's just been renamed, which is why I was referring to the 
renaming issue.

>>>Similar is the fate of the transport
>>>layer, since no e2e transmission control is required. 
>>
>>That just means the network supports unreliable transport, ala UDP. E2E 
>>control and reliability are sacrificed - or placed in the hands of 
>>statistics, at least - in this environment.
> 
> Yes, e2e control and reliability are not applicable to the IPN. So we
> don't need a transport layer as we do in the Internet, right?

Internet transport also includes the information for demuxing within the 
host, e.g., ports. If bundles include that information, then there is a 
transport layer as well, just buried in with the bundle. I.e., UDP is a 
transport layer - it's just a lightweight one.

>>It would (still) be useful to distinguish between new concepts and new 
>>words for old concepts, 
> 
> I wasn't really thinking of the novelty or otherwise of this approach; the
> aim was to articulate an architecture **that works** in deep space.
> 
>>as well as to highlight exactly where this model
>>diverges from the existing Internet architecture. The above diagram 
>>doesn't particularly help in this regard.
> 
> A diagram such as the one above, can only probably show how the layers are
> arranged in a stack(?) . The existing Internet architecture is also
> represented in a similar way. Did you mean to suggest that the diagram
> should be illustrated, displaying the function of each (sub)layer?
> 
> What exactly, would you say, wouldn't be clear to a reader who is familiar
> with the basics of Delay Tolerant Networking?

As I said above, what is not clear is how this model diverges from the 
Internet architecture. The diagram implies that it differs in every 
layer below application and above link. E.g., how is the _architecture_ 
(not the protocols, or the naming) different from, e.g., UDP over IP 
end-to-end (where UDP is the bundle) and ATM on sub-paths (e.g., 
bundle/bindle)?

Joe

Date: Mon, 20 Oct 2003 12:21:33 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
To: Joe Touch <[email-masked]>, [email-masked]
Sender: [email-masked]

--- Joe Touch <[email-masked]> wrote:
> > 
> > Routing is done at the bundling layer, so the conventional 'network'
> layer
> > is effectively rendered redundant.
> 
> Comparing this model to some (now) historical examples, e.g., IP over 
> ATM, I'm left wondering what really changed.
> 
> Doing routing at the bundle layer doesn't render a conventional network 
> layer redundent, so much as it _is_ the conventional network layer.

If it's my choice of words that you are referring to, how does this
sound?: We do not have a separate layer called the network layer in the
IPN backbone, since routing is done at the bundling layer.

> 
> > Similar is the fate of the transport
> > layer, since no e2e transmission control is required. 
> 
> That just means the network supports unreliable transport, ala UDP. E2E 
> control and reliability are sacrificed - or placed in the hands of 
> statistics, at least - in this environment.

Yes, e2e control and reliability are not applicable to the IPN. So we
don't need a transport layer as we do in the Internet, right?

> It would (still) be useful to distinguish between new concepts and new 
> words for old concepts, 

I wasn't really thinking of the novelty or otherwise of this approach; the
aim was to articulate an architecture **that works** in deep space.

> as well as to highlight exactly where this model
> diverges from the existing Internet architecture. The above diagram 
> doesn't particularly help in this regard.

A diagram such as the one above, can only probably show how the layers are
arranged in a stack(?) . The existing Internet architecture is also
represented in a similar way. Did you mean to suggest that the diagram
should be illustrated, displaying the function of each (sub)layer?

What exactly, would you say, wouldn't be clear to a reader who is familiar
with the basics of Delay Tolerant Networking?

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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Mon, 20 Oct 2003 11:47:18 -0700
To: Bob Braden <[email-masked]>, [email-masked], [email-masked]
From: Warthman Associates <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re: editing procedures
Sender: [email-masked]

At 07:40 PM 10/19/2003, Bob Braden wrote:
>   *>
>   *> There are two standards emerging in the semiconductor industry for
>   *> providing comments on review documents (other than good old-fashion
>   *> handwriting, still the best method from my viewpoint):
>   *>
>   *> - Distribute copies in Word or FrameMaker, so reviewers can edit in 
> those
>   *> applications.
>   *> - Distribute copies in PDF, so reviewers can add comments using Acrobat
>   *> Reader's comment tools.
>   *>
>   *> In both cases, the author of the document can copy comments 
> electronically
>   *> and paste them into his/her copy of the original document. Of the 
> two, I
>   *> believe Acrobat works best and most universally.
>   *>
>
>Pardon me, but that does not sound like general editing.
>
>That is interesting, but I question that it is relevant.  I may be
>wrong, but I tend to doubt that the semiconductor industry is very
>concerned that their documents will be readily accessible and editable
>20 years from now.  The RFC series cares a lot about this; the series
>is already 34 years old.
>
>Do you believe that Word or Frame will still be backward compatible 20
>years from now? Would you bet that Frame will even exist? Or that Adobe
>will still be in business?
>
>Bob Braden

You folks are trying to re-invent a wheel.

You would be better served to learn from companies who have faced the 
technical publication problem on a gargantuan scale over the past three 
decades, as have the semiconductor and computer-system companies (IBM was 
once, and may still be, the world's largest publisher of technical documents).

Acrobat is *not* an editing tool, but it allows convenient distribution of, 
and commenting on, PDF review documents generated by an editing tool. Do 
the writing in Word or FrameMaker, currently the only widely used choices; 
if the documents are simple (as the DTN architecture document currently 
is), Word can be used (but avoid copy-and-paste of graphics; instead, learn 
how to use Word's file-import and OLE-object-import methods correctly). As 
documents get into several hundred pages with complex features, as I am 
accustomed to writing, FrameMaker has been the best choice for the past 
decade; it functions most predictably and allows cross-platform exchange of 
files across common OSes.

It does not matter whether FrameMaker or Word will be around 20 or 100 
years from now. The one thing you can be sure of is that whatever editors 
take the place of Word and FrameMaker will provide a format-conversion 
method, built-in, because that is the only way a replacement tool can sell 
successfully into the commercial market, which has many millions of legacy 
documents it must preserve.

Forrest

-----------------------------------------------------------------
Forrest Warthman       Warthman Associates      Technical Writers
2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
(650)494-8555          (650)857-1815 fax         www.warthman.com 

Date: Mon, 20 Oct 2003 10:49:58 -0700
From: Joe Touch <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Durga Prasad Pandey wrote:
> Hi Folks,
> I had some discussion with Scott and Vint recently on layering in the IPN
> **backbone**(in deep space), and I have assimilated the following model
> which I wanted to share with you all:
>  _____________________________________________
> |                                             |
> | Application Layer                           |
> |_____________________________________________|
> |                                             |
> | Bundling Layer                              |
> | Convergence sub-layer                       | 
> |_____________________________________________|
> |                                             |
> | Data link layer                             |
> | Licklider Transmission Protocol (sub-layer) |
> | CCSDS Link Layer Protocol (sub-layer)       |
> |_____________________________________________|
> |                                             |
> | Physical Layer                              |
> |_____________________________________________|
> 
> Routing is done at the bundling layer, so the conventional 'network' layer
> is effectively rendered redundant.

Comparing this model to some (now) historical examples, e.g., IP over 
ATM, I'm left wondering what really changed.

Doing routing at the bundle layer doesn't render a conventional network 
layer redundent, so much as it _is_ the conventional network layer.

> Similar is the fate of the transport
> layer, since no e2e transmission control is required. 

That just means the network supports unreliable transport, ala UDP. E2E 
control and reliability are sacrificed - or placed in the hands of 
statistics, at least - in this environment.

> The Licklider
> transmission protocol at the link layer will provide a limited amount of
> ARQ. The CCSDS link layer protocol will ensure reliable delivery by strong
> FEC, etc.

Hop-by-hop flow control and reliability are certainly useful in this 
environment, but they are no different from, e.g., switched full-duplex 
ethernet flow control or wireless FEC.

> The convergence sub-layer is the interface between the bundling
> layer, and the data link layer.
> 
> Thoughts?

It would (still) be useful to distinguish between new concepts and new 
words for old concepts, as well as to highlight exactly where this model 
diverges from the existing Internet architecture. The above diagram 
doesn't particularly help in this regard.

Joe

From: Bob Braden <[email-masked]>
Date: Mon, 20 Oct 2003 09:48:14 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

 *> Bob,
  *> 
  *> I come away from the ID/RFC instructions to authors with the conclusion
  *> that the ASCII and whatever else must be -exactly- the same thing. I
  *> further conclude that including additional unrelated material in the
  *> whatever else is forbidden. Certainly I don't want so spend a whole lot
  *> of time preparing a document that may break the rules and create a big
  *> job to "repair" it. Been there, done that.
  *> 
  *> Dave 
  *> 

Dave,

This is basically incorrect (please see Section 2.4 of the latest
"Instructions to RFC Authors"), but as I promised, I will reply in more
detail off this list.

Bob

Date: Mon, 20 Oct 2003 15:21:47 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Bob,

I come away from the ID/RFC instructions to authors with the conclusion
that the ASCII and whatever else must be -exactly- the same thing. I
further conclude that including additional unrelated material in the
whatever else is forbidden. Certainly I don't want so spend a whole lot
of time preparing a document that may break the rules and create a big
job to "repair" it. Been there, done that.

Dave 

Bob Braden wrote:
> 
>   *>
>   *> I'm going to propose something really radical. While the bulk of a
>   *> j-random RFC yields to ugly ASCII, many tables, figures and most
>   *> equations do not. Once upon a time journal editors expected formatted
>   *> tables and figures to appear at the end of the text itself in separate
>   *> pages for typesetter and illutrator convenience. Of course, typesetters
>   *> have all retired and illustrators work only on web pages, so we
>   *> faculty/research nerds have had to learn to do that ourselves. So, is
>   *> there merit in doing the same for RFCs? The ASCIIficated text would be
>   *> accompanied by PS/PostScript/? figure/table pages and what equations
>   *> that may be necessary included in comparable appendices. Frankly, I hate
>   *> this but such compromise might be acceptable.
>   *>
> 
> Dave,
> 
> As I mentioned in my just-previous message, Jon Postel set up a
> procedure to do a variant of what you are asking, perhaps 10 years ago,
> and it has been the policy ever since.  This is all explained in
> "Instructions to RFC Authors".  It is not quite as easy as you make it
> sound, but I will not bother this list with the details.
> 
> Sorry to go on about this, folks, but I get deeply upset by oceans
> of misinformation.  I will stop now (unless sorely provoked).
> 
> Bob Braden
> 
>   *> I'm probably going to be real sorry I suggested that, because Bob might
>   *> take me up on it.
>   *>
>   *> Dave
>   *>
>   *> Scott W Brim wrote:
>   *> >
>   *> > On Sun, Oct 19, 2003 12:03:05PM -0700, Bob Braden allegedly wrote:
>   *> > > Not AFAIK -- I had to install Adobe Acrobat to create PDFs in Windows,
>   *> > > but perhaps this bears looking into.
>   *> >
>   *> > Ghostscript includes ps2pdf.  Cygwin adds a number of tools.
>   *> >
>   *> > > But I don't see how to build a viable editorial process around PDF.
>   *> > > How would we edit it, for example?
>   *> >
>   *> > Right.
>   *> > _______________________________________________
>   *> > dtn-interest mailing list
>   *> > [email-masked]
>   *> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>   *> _______________________________________________
>   *> dtn-interest mailing list
>   *> [email-masked]
>   *> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>   *>

Date: Mon, 20 Oct 2003 15:16:00 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Bob,

Ever downloaded/accessed a US patent? You get lossless TIFF (from the
definitive paper) and convert to lossy PDF using supplied tools. Well
now, we can send you paper documents printed on acid-free paper. You
scan to TIFF and post for archive. Fancy that.

Don't get me started on RFC-1305. I submitted it in PostScript <prior>
to the declarative ruling that all RFCs had to be ASCII. The document
has remained for almost twelve years a Draft Standard because I refuse
to rewrite it in ASCII. As it turned out, an almost-ASCII gloss is
available, since Xerox Ventura used that as document source. The gloss
is so hacked up by formatting codes as to be almost unreadable. The fate
of the NTPv4 specification, as well as its security model and
authentication protocol specification, is on indefinite hold pending
resolution of these issues.

Xerox Ventura was bought first by Corel and then by WordPerfect and
subsequently killed. There is indeed a lesson there and the fate of
FrameMaker and even TIFF, PDF and ASCII itself is not forever assured.
Heck, my personal archives on 9-track magtape, 8-inch floppy and paper
tape (!) may be forever lost to electro-archeology. From the standpoint
of archival integrity and longevity, the Patent Office might even have
it right.

Dave

Bob Braden wrote:
> 
>   *>
>   *> >From my own experience, the most important lack with ASCII format is
>   *> tables, diagrams and equations. I have a document here on NTP securit
> 
>   *> that I really would like to see as RFC for comments and exposure. While
>   *> the tables and at least some figures could be butchered as ASCII, the
>   *> equations are at the heart of the document and there is simply no hope
>   *> these can be rendered in ASCII with any degree of fidelity.
>   *>
> 
> Dave,
> 
> This is a well known and lamentable fact, but I have NEVER heard any
> proposals to fully solve this problem that seem viable.  I would be
> happy if there were.  In the meantime, ASCII art handles 95% of the
> needs in RFCs, although NTP is at one extreme end of the spectrum.
> [That is why you are the only RFC author who has ever been allowed to
> publish an RFC purely in Postscript/PDF (Maybe there was one other.)]
> 
> As you know, we DO have a viable mechanism to get around this problem
> in most cases.  As long as the fancy diagrams are purely explanatory,
> they can be made available in a parallel Postscript/PDF version of the
> document.  The only requirement is that the ASCII version (without the
> fancy diagrams) be the definitive protocol specification.  But this
> has turned out to have two serious drawbacks.  First, the authors
> have usually found it was too much work to put our editorial changes
> back into their source to create an equivalent .ps file.  Second,
> we recently found that several .ps files in our archive had become
> corrupted over the past 6 years.  We asked the authors to recreate
> them, and they just threw up their hands.  The text preparation
> tools they had used (e.g., Frame, I think) had long dropped into the
> bit bucket, and it was not possible for them to recreate their
> own documents.
> 
> That's a hell of a way to run a railroad, or an archival document series.
> 
> Bob

Date: Sun, 19 Oct 2003 19:59:01 -0700 (PDT)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

  *> 
  *> I'm going to propose something really radical. While the bulk of a
  *> j-random RFC yields to ugly ASCII, many tables, figures and most
  *> equations do not. Once upon a time journal editors expected formatted
  *> tables and figures to appear at the end of the text itself in separate
  *> pages for typesetter and illutrator convenience. Of course, typesetters
  *> have all retired and illustrators work only on web pages, so we
  *> faculty/research nerds have had to learn to do that ourselves. So, is
  *> there merit in doing the same for RFCs? The ASCIIficated text would be
  *> accompanied by PS/PostScript/? figure/table pages and what equations
  *> that may be necessary included in comparable appendices. Frankly, I hate
  *> this but such compromise might be acceptable.
  *> 

Dave,

As I mentioned in my just-previous message, Jon Postel set up a
procedure to do a variant of what you are asking, perhaps 10 years ago,
and it has been the policy ever since.  This is all explained in
"Instructions to RFC Authors".  It is not quite as easy as you make it
sound, but I will not bother this list with the details.

Sorry to go on about this, folks, but I get deeply upset by oceans
of misinformation.  I will stop now (unless sorely provoked).

Bob Braden

  *> I'm probably going to be real sorry I suggested that, because Bob might
  *> take me up on it.
  *> 
  *> Dave
  *> 
  *> Scott W Brim wrote:
  *> > 
  *> > On Sun, Oct 19, 2003 12:03:05PM -0700, Bob Braden allegedly wrote:
  *> > > Not AFAIK -- I had to install Adobe Acrobat to create PDFs in Windows,
  *> > > but perhaps this bears looking into.
  *> > 
  *> > Ghostscript includes ps2pdf.  Cygwin adds a number of tools.
  *> > 
  *> > > But I don't see how to build a viable editorial process around PDF.
  *> > > How would we edit it, for example?
  *> > 
  *> > Right.
  *> > _______________________________________________
  *> > dtn-interest mailing list
  *> > [email-masked]
  *> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
  *> _______________________________________________
  *> dtn-interest mailing list
  *> [email-masked]
  *> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
  *> 

Date: Sun, 19 Oct 2003 19:53:05 -0700 (PDT)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

  *> 
  *> >From my own experience, the most important lack with ASCII format is
  *> tables, diagrams and equations. I have a document here on NTP securit

  *> that I really would like to see as RFC for comments and exposure. While
  *> the tables and at least some figures could be butchered as ASCII, the
  *> equations are at the heart of the document and there is simply no hope
  *> these can be rendered in ASCII with any degree of fidelity.
  *> 

Dave,

This is a well known and lamentable fact, but I have NEVER heard any
proposals to fully solve this problem that seem viable.  I would be
happy if there were.  In the meantime, ASCII art handles 95% of the
needs in RFCs, although NTP is at one extreme end of the spectrum.
[That is why you are the only RFC author who has ever been allowed to
publish an RFC purely in Postscript/PDF (Maybe there was one other.)]

As you know, we DO have a viable mechanism to get around this problem
in most cases.  As long as the fancy diagrams are purely explanatory,
they can be made available in a parallel Postscript/PDF version of the
document.  The only requirement is that the ASCII version (without the
fancy diagrams) be the definitive protocol specification.  But this
has turned out to have two serious drawbacks.  First, the authors
have usually found it was too much work to put our editorial changes
back into their source to create an equivalent .ps file.  Second,
we recently found that several .ps files in our archive had become
corrupted over the past 6 years.  We asked the authors to recreate
them, and they just threw up their hands.  The text preparation
tools they had used (e.g., Frame, I think) had long dropped into the
bit bucket, and it was not possible for them to recreate their
own documents.

That's a hell of a way to run a railroad, or an archival document series.

Bob

Date: Sun, 19 Oct 2003 19:40:10 -0700 (PDT)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re: editing procedures
Sender: [email-masked]

  *> 
  *> There are two standards emerging in the semiconductor industry for 
  *> providing comments on review documents (other than good old-fashion 
  *> handwriting, still the best method from my viewpoint):
  *> 
  *> - Distribute copies in Word or FrameMaker, so reviewers can edit in those 
  *> applications.
  *> - Distribute copies in PDF, so reviewers can add comments using Acrobat 
  *> Reader's comment tools.
  *> 
  *> In both cases, the author of the document can copy comments electronically 
  *> and paste them into his/her copy of the original document. Of the two, I 
  *> believe Acrobat works best and most universally.
  *> 

Pardon me, but that does not sound like general editing.

That is interesting, but I question that it is relevant.  I may be
wrong, but I tend to doubt that the semiconductor industry is very
concerned that their documents will be readily accessible and editable
20 years from now.  The RFC series cares a lot about this; the series
is already 34 years old.

Do you believe that Word or Frame will still be backward compatible 20
years from now? Would you bet that Frame will even exist? Or that Adobe
will still be in business?

Bob Braden

Date: Mon, 20 Oct 2003 01:40:57 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Scott,

Seems like all my old friends are on frequency. My recent experience in
the document wars is that lots of folks mention some tool or other that
could save format agendae from certain destruction. Some of these, like
a perl script to convert HTML to manpage, turn out to be urban legends.
The problem is that the find/build/install/learning curves can be steep
and ponderous and the results something less than beautiful.

I'm going to propose something really radical. While the bulk of a
j-random RFC yields to ugly ASCII, many tables, figures and most
equations do not. Once upon a time journal editors expected formatted
tables and figures to appear at the end of the text itself in separate
pages for typesetter and illutrator convenience. Of course, typesetters
have all retired and illustrators work only on web pages, so we
faculty/research nerds have had to learn to do that ourselves. So, is
there merit in doing the same for RFCs? The ASCIIficated text would be
accompanied by PS/PostScript/? figure/table pages and what equations
that may be necessary included in comparable appendices. Frankly, I hate
this but such compromise might be acceptable.

I'm probably going to be real sorry I suggested that, because Bob might
take me up on it.

Dave

Scott W Brim wrote:
> 
> On Sun, Oct 19, 2003 12:03:05PM -0700, Bob Braden allegedly wrote:
> > Not AFAIK -- I had to install Adobe Acrobat to create PDFs in Windows,
> > but perhaps this bears looking into.
> 
> Ghostscript includes ps2pdf.  Cygwin adds a number of tools.
> 
> > But I don't see how to build a viable editorial process around PDF.
> > How would we edit it, for example?
> 
> Right.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Mon, 20 Oct 2003 01:19:11 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Bob,

That's a good point. All my stuff starts with PostScript from some word
processor or other, then go through Acrobat to make PDF. I have not read
the Acrobat glossy brochure in great detail, but there is expectation
PDF files can be edited. Someone else might confirm/deny that
assumption. Acrobat Reader is of course free, but Acrobat itself is not.
If editing involves machining via ASCII, LaTex or anything like that, I
would think the advantages for PDF, presuming there are some, would
evaporate.

As you know, I have been responsible for a fair number of RFCs, some of
which written by committee. In all of them I was the only editor that
actually marked up the draft in response to input from other committee
members. I could be that the perceived requirement that the ID be
gang-edited in source may not be necessary. In fact, I don't know how to
edit the daughter-of-rfc-2030, as you produced the ASCII document from
my hoked-up Adobe FrameMaker text rendering.

Date: Sun, 19 Oct 2003 17:06:08 -0700
To: "Adrian J. Hooke" <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: [dtn-interest] architecture
Sender: [email-masked]

At 12:42 PM 10/19/2003, Adrian J. Hooke wrote:
>At 10:17 AM 10/18/03, Bob Braden wrote:
>>Actually, I don't think this is quite right.  Firms that design buildings 
>>have architects and engineers.  The engineers do the detailed 
>>specification, while the architects are somewhere between sculptors and 
>>designers. They lay out the general plan and function, leaving the gritty 
>>details like beam loadings, plumbing, etc. to the engineers.
>
>We've had this discussion for almost 30 years. We actually once had a NASA 
>program manager who's son was a building architect, and the view of that 
>guy was quite different. He claimed that he was the ultimate authority and 
>had the ultimate responsibility to deliver a building that met his 
>customer's requirements. So yes, he "sculpted" the conceptual vision of 
>how the building would look and function, and yes he also "designed" it 
>enough to know that it could be built, and yes he turned over the gritty 
>details to the subsystem specialists. But in this last phase he retained 
>overall *control* of the project, and if a gritty design detail did not 
>work out to his satisfaction he could direct that the detailed work be 
>ripped out and done-over in a different way.
>
>IMHO, it's this aspect of overall conceptual *authority* for the system 
>and overall *responsibility* to the customer that it meets its intended 
>use that is the hallmark of architect. More often than not, unfortunately, 
>information system architects just produce wiring diagrams.

I think Adrian has is right. The computer scientists and electrical 
engineers from Intel, IBM, and other semiconductor manufacturers 
*voluntarily* chose the name "architect" for their primary designers, from 
the Greek: archi (first, primary) tekton (builder, craftsman, 
technologist). They are also the ones who voluntarily applied the 
"architecture" named to their detailed specifications of instruction sets 
and protocols.

The name "architect" is widely applied to primary leaders of anything: the 
"architects of the American constitution" (Jefferson also happened to *be* 
an architect), the "architects of the European Union", etc. And when I got 
my architecture degree at Berkeley, we took a rich mixture of engineering, 
math, programming, operations research, economics, and law courses. There 
were no art or sculpture courses.

Forrest  

Date: Sun, 19 Oct 2003 16:48:18 -0700
To: Kevin Fall <[email-masked]>, Bob Braden <[email-masked]>
From: Warthman Associates <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] editing procedures
Sender: [email-masked]

At 12:32 PM 10/19/2003, Kevin Fall wrote:
> >
> > From:  Bob Braden <[email-masked]>
> > To:    [email-masked], [email-masked]
> > cc:    [email-masked], [email-masked]
> > Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> > Date:  Sun, 19 Oct 2003 12:03:05 PDT
> >
> >   *>
> >   *> how does pdf fail?  I believe pdf writer for Windows is free, and 
> there
> >
> > Not AFAIK -- I had to install Adobe Acrobat to create PDFs in Windows,
> > but perhaps this bears looking into.
>
>yes, "real" PDFWriter is part of Acrobat, but there is this
>(admittedly not so pretty) process:
>
>         http://www.pmhawkins.com/freepdf.htm
>
> >
> > But I don't see how to build a viable editorial process around PDF.
> > How would we edit it, for example?  Perhaps extract ASCII from it,
> > generate LateX or nroff from that, and then create a new PDF file?
> > Sounds dicey to me...
>
>yes that sounds dicey.  Ultimately there is some document editor(s) who
>choose a document system they will use.  So, it might simply be that
>the choice of the editable format is with the current doc editor(s), and
>you just agree that whomever they are will need to be able to produce PDF
>somehow.  If years go by and it is time to update somebody's older doc, I
>would expect -somebody- would be able to convert an old (nroff, Frame, 
>Word, etc)
>doc into a currently-editable format.  ASCII/OCR would be the worst case,
>but I would think it would be a rarity that you would have to go that far.
>Presumably the stored editable doc would be stored with the rfc editor or
>equivalent...
>
> > If we could force everyone in the Internet to
> > use LateX, things might be easier, but ...
> >
> > Bob
>
>Its ok for me, but I know there are others who prefer wysiwyg editing
>[I personally oscillate between frame, word, latex and simple ascii files].

There are two standards emerging in the semiconductor industry for 
providing comments on review documents (other than good old-fashion 
handwriting, still the best method from my viewpoint):

- Distribute copies in Word or FrameMaker, so reviewers can edit in those 
applications.
- Distribute copies in PDF, so reviewers can add comments using Acrobat 
Reader's comment tools.

In both cases, the author of the document can copy comments electronically 
and paste them into his/her copy of the original document. Of the two, I 
believe Acrobat works best and most universally.

Adobe provides free copies of Acrobat Reader for Windows, MacOS, Linux, 
Solaris, AIX, HP-UX, Sumbian OS, OS/2, Palm, and PocketPC at:

http://www.adobe.com/products/acrobat/readstep2.html

For help on how to use the commenting tools, see:

http://www.adobe.com/products/acrobat/pdfs/acrruserguide.pdf

Also, beware of using Word for any complex documents. File corruption 
(never explainable) is common in documents with pasted graphics, 
auto-numbered captions, table straddles, etc. FrameMaker is a much more 
robust tool for technical documents. Most manufacturers are using 
FrameMaker, in spite of their engineers' understandable preference for the 
simpler and more familiar Word environment.

Forrest

Date: Sun, 19 Oct 2003 12:57:20 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Protocol layering in the IPN backbone
Sender: [email-masked]

Hi Folks,
I had some discussion with Scott and Vint recently on layering in the IPN
**backbone**(in deep space), and I have assimilated the following model
which I wanted to share with you all:
 _____________________________________________
|                                             |
| Application Layer                           |
|_____________________________________________|
|                                             |
| Bundling Layer                              |
| Convergence sub-layer                       | 
|_____________________________________________|
|                                             |
| Data link layer                             |
| Licklider Transmission Protocol (sub-layer) |
| CCSDS Link Layer Protocol (sub-layer)       |
|_____________________________________________|
|                                             |
| Physical Layer                              |
|_____________________________________________|

Routing is done at the bundling layer, so the conventional 'network' layer
is effectively rendered redundant. Similar is the fate of the transport
layer, since no e2e transmission control is required. The Licklider
transmission protocol at the link layer will provide a limited amount of
ARQ. The CCSDS link layer protocol will ensure reliable delivery by strong
FEC, etc. The convergence sub-layer is the interface between the bundling
layer, and the data link layer.

Thoughts?

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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Sun, 19 Oct 2003 15:48:43 -0400
From: Scott W Brim <[email-masked]>
To: Bob Braden <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

On Sun, Oct 19, 2003 12:03:05PM -0700, Bob Braden allegedly wrote:
> Not AFAIK -- I had to install Adobe Acrobat to create PDFs in Windows,
> but perhaps this bears looking into.

Ghostscript includes ps2pdf.  Cygwin adds a number of tools.

> But I don't see how to build a viable editorial process around PDF.
> How would we edit it, for example?  

Right.

Date: Sun, 19 Oct 2003 12:42:44 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

At 10:17 AM 10/18/03, Bob Braden wrote:
>Actually, I don't think this is quite right.  Firms that design buildings 
>have architects and engineers.  The engineers do the detailed 
>specification, while the architects are somewhere between sculptors and 
>designers. They lay out the general plan and function, leaving the gritty 
>details like beam loadings, plumbing, etc. to the engineers.

We've had this discussion for almost 30 years. We actually once had a NASA 
program manager who's son was a building architect, and the view of that 
guy was quite different. He claimed that he was the ultimate authority and 
had the ultimate responsibility to deliver a building that met his 
customer's requirements. So yes, he "sculpted" the conceptual vision of how 
the building would look and function, and yes he also "designed" it enough 
to know that it could be built, and yes he turned over the gritty details 
to the subsystem specialists. But in this last phase he retained overall 
*control* of the project, and if a gritty design detail did not work out to 
his satisfaction he could direct that the detailed work be ripped out and 
done-over in a different way.

IMHO, it's this aspect of overall conceptual *authority* for the system and 
overall *responsibility* to the customer that it meets its intended use 
that is the hallmark of architect. More often than not, unfortunately, 
information system architects just produce wiring diagrams.

///adrian

PS: looks like [email-masked] works

Date: Sun, 19 Oct 2003 15:30:10 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] List test
To: "Adrian J. Hooke" <[email-masked]>, [email-masked]
Sender: [email-masked]

ack

oops - was that renewal on my watch??

vint

At 10:32 AM 10/19/2003 -0700, Adrian J. Hooke wrote:
>It looks as though the ipnrg.org domain name was allowed to expire a month or so ago, so messages to [email-masked] seem to be bouncing. Please let me know if you got this message.
>
>///a
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

To: Bob Braden <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project] 
Date: Sun, 19 Oct 2003 12:32:05 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Bob Braden <[email-masked]>
> To:    [email-masked], [email-masked]
> cc:    [email-masked], [email-masked]
> Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> Date:  Sun, 19 Oct 2003 12:03:05 PDT
>
>   *> 
>   *> how does pdf fail?  I believe pdf writer for Windows is free, and there
> 
> Not AFAIK -- I had to install Adobe Acrobat to create PDFs in Windows,
> but perhaps this bears looking into.

yes, "real" PDFWriter is part of Acrobat, but there is this
(admittedly not so pretty) process:

	http://www.pmhawkins.com/freepdf.htm

> 
> But I don't see how to build a viable editorial process around PDF.
> How would we edit it, for example?  Perhaps extract ASCII from it,
> generate LateX or nroff from that, and then create a new PDF file?
> Sounds dicey to me...

yes that sounds dicey.  Ultimately there is some document editor(s) who
choose a document system they will use.  So, it might simply be that
the choice of the editable format is with the current doc editor(s), and
you just agree that whomever they are will need to be able to produce PDF
somehow.  If years go by and it is time to update somebody's older doc, I
would expect -somebody- would be able to convert an old (nroff, Frame, Word, etc)
doc into a currently-editable format.  ASCII/OCR would be the worst case,
but I would think it would be a rarity that you would have to go that far.
Presumably the stored editable doc would be stored with the rfc editor or
equivalent...

> If we could force everyone in the Internet to
> use LateX, things might be easier, but ...
> 
> Bob

Its ok for me, but I know there are others who prefer wysiwyg editing
[I personally oscillate between frame, word, latex and simple ascii files].

- K

Date: Sun, 19 Oct 2003 12:03:05 -0700 (PDT)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

  *> 
  *> how does pdf fail?  I believe pdf writer for Windows is free, and there

Not AFAIK -- I had to install Adobe Acrobat to create PDFs in Windows,
but perhaps this bears looking into.

But I don't see how to build a viable editorial process around PDF.
How would we edit it, for example?  Perhaps extract ASCII from it,
generate LateX or nroff from that, and then create a new PDF file?
Sounds dicey to me...  If we could force everyone in the Internet to
use LateX, things might be easier, but ...

Bob

  *> are plenty of unix tools that can generate/display it.  Its searchable
  *> with Acrobat reader, convertable to ascii if you must, etc...
  *> 
  *> - K
  *> 

Date: Sun, 19 Oct 2003 11:23:01 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] List test
To: [email-masked]
Sender: [email-masked]

I got it.
D.
--- "Adrian J. Hooke" <[email-masked]> wrote:
> It looks as though the ipnrg.org domain name was allowed to expire a
> month 
> or so ago, so messages to [email-masked] seem to be 
> bouncing. Please let me know if you got this message.
> 
> ///a 
> 
> _______________________________________________
> 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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Sun, 19 Oct 2003 10:33:20 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] List test
Sender: [email-masked]

It looks as though the ipnrg.org domain name was allowed to expire a month 
or so ago, so messages to [email-masked] seem to be 
bouncing. Please let me know if you got this message.

///a 

Date: Sun, 19 Oct 2003 10:32:59 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] List test
Sender: [email-masked]

It looks as though the ipnrg.org domain name was allowed to expire a month 
or so ago, so messages to [email-masked] seem to be 
bouncing. Please let me know if you got this message.

///a

Date: Sun, 19 Oct 2003 02:51:03 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: [email-masked]
Subject: [dtn-interest] Re: RFCs, pdf, ASCII, etc
Sender: [email-masked]

Kevin,

I'm not going to wade into this one on this list; I didn't intend to
stir things up. But, as parting shot, I am just recovering from a really
nasty fight about my policy of producing NTP documentation only in HTML.
I was blindsided by the very angry protest and evil backlash that
produced for the diehard Unix manpage crowd. It got even worse when the
DocBookers, PODmen and who knows what other rabble showed up. I finally
had to call the XML police to put down the rebellion. Everybody claimed
their format was best and displayed a set of utilities that could
convert (badly) from evil foreign format to their precious favorite.

Maybe Bob is right; give them ugly ASCII and feed them worms.

Dave

Kevin Fall wrote:
> 
> >
> > From:  "David L. Mills" <[email-masked]>
> > To:    [email-masked]
> > Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> > Date:  Sat, 18 Oct 2003 22:44:49 -0000
> >
> > Bob and Kevin,
> >
> > Sorry about the rude swipe and I don't mean to inflame the issue.
> > However, I submit the most ubiquitous web/print technology today is PDF.
> > Adobe is pretty good at cross-platform support, at least for Unix,
> > Windows and Mac. While I can light up PDF in Solaris, I haven't lit up
> > PDF on xBSD or Linux.
> >
> > Dave
> 
> Well, seems like a healthy discussion (although this is arguably not exactly the
> right list to have it. As the list 'owner' I will apologize for that upfront, but...)
> 
> I recently was using LaTeX on Windows under cygwin and also on Linux.  It ran fine, I used
> dvipdf to make a pdf and then could the Windows Acrobat or ghostview
> to go from there.  PDFWriter and/or Distiller can be installed on Windows to produce a pdf
> from anything that you can otherwise print.  No problems as far as I can tell,
> although for reasons unknown I have had smaller output and in some cases better
> documents produced with the simpler PDFWriter program as opposed to Distiller
> [from FrameMaker no less!].  Go figure.
> 
> With regard to converting to ASCII/HTML, I found this:
> 
>         http://www.adobe.com/products/acrobat/access_onlinetools.html
> 
> Interestingly, this is a service to convert pdf to ASCII/HTML primarily for the
> purpose of feeding the output into speech synthesizers for blind users.  As such
> it doesn't do images, but I believe there are other systems that will make
> JPEGs out of those.  At least one OCR package I have used does this pretty effectively.
> 
> - K

To: "David L. Mills" <[email-masked]>
cc: [email-masked]
Date: Sat, 18 Oct 2003 16:49:03 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] RFCs, pdf, ASCII, etc
Sender: [email-masked]

>
> From:  "David L. Mills" <[email-masked]>
> To:    [email-masked]
> Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> Date:  Sat, 18 Oct 2003 22:44:49 -0000
>
> Bob and Kevin,
> 
> Sorry about the rude swipe and I don't mean to inflame the issue.
> However, I submit the most ubiquitous web/print technology today is PDF.
> Adobe is pretty good at cross-platform support, at least for Unix,
> Windows and Mac. While I can light up PDF in Solaris, I haven't lit up
> PDF on xBSD or Linux.
> 
> Dave

Well, seems like a healthy discussion (although this is arguably not exactly the
right list to have it. As the list 'owner' I will apologize for that upfront, but...)

I recently was using LaTeX on Windows under cygwin and also on Linux.  It ran fine, I used
dvipdf to make a pdf and then could the Windows Acrobat or ghostview
to go from there.  PDFWriter and/or Distiller can be installed on Windows to produce a pdf
from anything that you can otherwise print.  No problems as far as I can tell,
although for reasons unknown I have had smaller output and in some cases better
documents produced with the simpler PDFWriter program as opposed to Distiller
[from FrameMaker no less!].  Go figure.

With regard to converting to ASCII/HTML, I found this:

	http://www.adobe.com/products/acrobat/access_onlinetools.html

Interestingly, this is a service to convert pdf to ASCII/HTML primarily for the
purpose of feeding the output into speech synthesizers for blind users.  As such
it doesn't do images, but I believe there are other systems that will make
JPEGs out of those.  At least one OCR package I have used does this pretty effectively.

- K

Date: Sat, 18 Oct 2003 22:44:49 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Bob and Kevin,

Sorry about the rude swipe and I don't mean to inflame the issue.
However, I submit the most ubiquitous web/print technology today is PDF.
Adobe is pretty good at cross-platform support, at least for Unix,
Windows and Mac. While I can light up PDF in Solaris, I haven't lit up
PDF on xBSD or Linux.

Dave

Kevin Fall wrote:
> 
> >
> > From:  Bob Braden <[email-masked]>
> > To:    [email-masked]
> > cc:    [email-masked]
> > Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> > Date:  Sat, 18 Oct 2003 12:06:37 PDT
> >
> >
> >  I take considerable umbrage with the ASCII requirement, which is
> >   *> utmost silly in today's technology.
> >
> > Dave,
> >
> > That's brave talk, but what particular technology today do you suggest
> > has the universality, longevity, and searchability of plain old ASCII?
> > We would love to know of one.  The only viable solution we see is to
> > standardize on Microsoft products for all CPUs and software in the
> > world.  That might work for most purposes...
> >
> > Bob Braden
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> how does pdf fail?  I believe pdf writer for Windows is free, and there
> are plenty of unix tools that can generate/display it.  Its searchable
> with Acrobat reader, convertable to ascii if you must, etc...
> 
> - K

Date: Sat, 18 Oct 2003 17:53:17 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Kevin Fall <[email-masked]>, Bob Braden <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

doesn't the conversion lead to display deficits, etc.

v

At 02:37 PM 10/18/2003 -0700, Kevin Fall wrote:
>convertable to ascii if you must, etc...

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

To: Bob Braden <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project] 
Date: Sat, 18 Oct 2003 14:37:37 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Bob Braden <[email-masked]>
> To:    [email-masked]
> cc:    [email-masked]
> Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> Date:  Sat, 18 Oct 2003 12:06:37 PDT
>
> 
>  I take considerable umbrage with the ASCII requirement, which is
>   *> utmost silly in today's technology.
> 
> Dave,
> 
> That's brave talk, but what particular technology today do you suggest
> has the universality, longevity, and searchability of plain old ASCII?
> We would love to know of one.  The only viable solution we see is to
> standardize on Microsoft products for all CPUs and software in the
> world.  That might work for most purposes...
> 
> Bob Braden
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

how does pdf fail?  I believe pdf writer for Windows is free, and there
are plenty of unix tools that can generate/display it.  Its searchable
with Acrobat reader, convertable to ascii if you must, etc...

- K

Date: Sat, 18 Oct 2003 14:22:06 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: "vinton g. cerf" <[email-masked]>, [email-masked]
Sender: [email-masked]

True. This is completely against the spirit with which Dr Postel had begun
'request for comments'. If a speculative document wouldn't ask for
comments, what would?
D.
--- "vinton g. cerf" <[email-masked]> wrote:
> it is a grave disappointment to think that the principal Internet 
> information publishing apparatus has become so dysfunctional and
> paranoid
> that it can no longer support speculative or prospective documents
> intended
> to truly generate comments as the term RFC once meant.
> 
> vint
> 
> At 05:37 PM 10/18/2003 +0000, David L. Mills wrote:
> >I make no judgment here, but I do think it is entirely appropriate to
> >publish via more conventional means. The ACM Computer Communications
> >Review is designed specifially for wild ideas not yet suitable for
> prime
> >time.
> 
> Vint Cerf
> SVP Technology Strategy
> MCI
> 22001 Loudoun County Parkway, F2-4115
> Ashburn, VA 20147
> 703 886 1690 (v806 1690)
> 703 886 0047 fax
> [email-masked]
> www.mci.com/cerfsup 
> 
> _______________________________________________
> 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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Sat, 18 Oct 2003 17:11:45 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Kevin Fall <[email-masked]>, [email-masked]
Sender: [email-masked]

let's stick with the project(s) for now - workshopping only after some serious successes

v

At 10:59 AM 10/18/2003 -0700, Kevin Fall wrote:
>Well, and now that I've stepped in it:
>I felt our DTN meeting at ISI in May was informative and useful
>and have occasionally contemplated the idea of trying to 'workshopize' it.
>Thoughts?

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Sat, 18 Oct 2003 17:08:14 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: "David L. Mills" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

it is a grave disappointment to think that the principal Internet 
information publishing apparatus has become so dysfunctional and paranoid
that it can no longer support speculative or prospective documents intended
to truly generate comments as the term RFC once meant.

vint

At 05:37 PM 10/18/2003 +0000, David L. Mills wrote:
>I make no judgment here, but I do think it is entirely appropriate to
>publish via more conventional means. The ACM Computer Communications
>Review is designed specifially for wild ideas not yet suitable for prime
>time.

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Sat, 18 Oct 2003 17:05:32 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Joe Touch <[email-masked]>
Cc: Durga Prasad Pandey <[email-masked]>, [email-masked]
Sender: [email-masked]

so I am learning - sigh

v
At 10:27 AM 10/18/2003 -0700, Joe Touch wrote:
>Even informational need IESG review these days, and that can be a substantial hurdle.

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Sat, 18 Oct 2003 12:06:37 -0700 (PDT)
From: Bob Braden <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Cc: [email-masked]
Sender: [email-masked]

 I take considerable umbrage with the ASCII requirement, which is
  *> utmost silly in today's technology.

Dave,

That's brave talk, but what particular technology today do you suggest
has the universality, longevity, and searchability of plain old ASCII?
We would love to know of one.  The only viable solution we see is to
standardize on Microsoft products for all CPUs and software in the
world.  That might work for most purposes...

Bob Braden

To: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project] 
Date: Sat, 18 Oct 2003 10:59:06 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  "David L. Mills" <[email-masked]>
> cc:    [email-masked]
> Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> Date:  Sat, 18 Oct 2003 17:37:48 -0000
>
> Vint,
> 
> I confirm things are not as they used to be. I just submitted what I
> thought was a trivial update to a prior RFC and found it was necessary
> to re-issue as a ID and go through the IETF process all over again. This
> is the third update of the RFC; the prior two updates had no such
> baggage. While on the exercise I bumped again on the Postel format
> issue, as my habit is PDF, but Bob was kind enough to reformat to Postel
> anyway. I take considerable umbrage with the ASCII requirement, which is
> utmost silly in today's technology.
> 

here here.  In the days of line printers these ASCII things
were just about the only document that printed properly on darn
near any printer.  Now they are about the only types of documents that
don't.  And trying to get your favorite editor to produce that particular
format is always, eh.. 'interesting'.

> I make no judgment here, but I do think it is entirely appropriate to
> publish via more conventional means. The ACM Computer Communications
> Review is designed specifially for wild ideas not yet suitable for prime
> time.
> 
> Dave

And there seems to be an ever-growing collection of workshops.  (many of
which become unfortunately immortal once spawned).

Well, and now that I've stepped in it:
I felt our DTN meeting at ISI in May was informative and useful
and have occasionally contemplated the idea of trying to 'workshopize' it.
Thoughts?

- K

Date: Sat, 18 Oct 2003 17:49:06 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
To: [email-masked]
Subject: Re: [dtn-interest] Power Blackout prevention - DTN SCADA/ Planet Lab
Sender: [email-masked]

Henry,

Power distribution folks already use GPS to measure phase shift in order
to balance loads. There was a discussion some time ago about using NTP
to do this, but NTP and a computer is not precise enough.

Twenty years ago power management for the Eastern/Quebec grid was
coordinated at a central site in Ohio using WWVB timestamping, but from
the evidence of the recent blackout, this is no longer the case. It
seems that only the PJM interconnect folk know how to run a power
distribution system. While this was the case during the blackout and our
lights stayed lit, along comes Isabel and they went out for several
days. We weren't able to eat all the freezer food before it went bad.

Dave

henry brown wrote:
> 
> http://www.sciam.com/article.cfm?chanID=sa004&articleID=000784B6-E5FB-1F86-9B8C83414B7FFE87
> Better communication among power stations would also aid in stabilizing
> the grid. Protective relays rely on local information and can be fooled
> into disconnecting a line unnecessarily. Dedicated fiber optics would
> permit fast comparisons of conditions at adjacent stations, forestalling
> needless shutdowns. The Global Positioning System (GPS) could put a time
> stamp on each station reading, allowing operators to make better decisions
> by looking at successive snapshots of grid conditions. The Bonneville
> Power Administration, based in Portland, Ore., and Ameren Corporation, a
> St. Louis-based utility, use GPS time stamping.
> 
> Could DTN create time stamping via GPS enabled router?
> Use GPS heartbeat off of SCADA to update remote routers at power plants.
> 
> SOE for SCADA
> 
> Multiple protocols are constantly being updated in Control Centers.
> RTU outages and their Sequence of Events (SOE) are not time synchronized.
> These points of data are thus passed along through Protocols and
> the data is not time synched correctly.
> 
> Many utilities are trying to develop SOE solutions.
> Does DTN have a method to time correct RTU data as it passes through
> the switch, router, firewall?
> 
> Time synchronization is critical in seeing patterns in the alarm
> information. While control centers are synchronized to GPS, RTU's in
> the field are not. Cost???
> 
> How can DTN improve time synchronization of data coming in from remote
> RTU sites? How do you deal with latency?
> 
> Could software be used to manage time synch without expensive RTU
> upgrades and software? This may allow you to retrofit preexisting SCADA
> cheaply. Many utilities might use this network of routers to synch
> all devices to GPS in control centers. All control centers are presently
> GPS time synched daily by FERC regulation. The older RTUs are however
> not synchronized from control center. How could DTN support this?
> 
> Could Planet Lab/Linux be used to accomplish this?
> 
> References:
> http://www.esac.com/ser.htm
> http://www.planet-lab.org/php/slices.php
> http://www.planet-lab.org/php/proj_top.php
> 
> --
> Henry Brown
> PNM Power Operations
> 505 241-2297
> [email-masked]
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Sat, 18 Oct 2003 17:37:48 +0000
From: "David L. Mills" <[email-masked]>
Organization: University of Delaware
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Vint,

I confirm things are not as they used to be. I just submitted what I
thought was a trivial update to a prior RFC and found it was necessary
to re-issue as a ID and go through the IETF process all over again. This
is the third update of the RFC; the prior two updates had no such
baggage. While on the exercise I bumped again on the Postel format
issue, as my habit is PDF, but Bob was kind enough to reformat to Postel
anyway. I take considerable umbrage with the ASCII requirement, which is
utmost silly in today's technology.

I make no judgment here, but I do think it is entirely appropriate to
publish via more conventional means. The ACM Computer Communications
Review is designed specifially for wild ideas not yet suitable for prime
time.

Dave

"vinton g. cerf" wrote:
> 
> joe, et al,
> 
> my impression is that the publication hurdles for RFCs seem remarkably
> higher than they once were and that this series is no longer particularly
> useful for publishing of intermediate results. If informational RFCs are
> still accepted, that's the obvious route - I will ask Braden his opinion.
> 
> v
> 
> At 11:54 AM 10/17/2003 -0700, Joe Touch wrote:
> >It might be useful to clarify my position (now that I've had the coffee):
> >
> >        1) not all IPN documents need to be published as RFCs
> >        I'm not speaking of current IPN IDs, but the
> >        implication from previous mails that things which
> >        are not otherwise published should be IDs/RFCs too.
> >
> >        2) pre-publication papers can - and should - be issued
> >        as tech reports, esp. to enable them to be more widely
> >        cited.
> >
> >        3) if there is a particularly useful intermediate stage
> >        of an ID which, for many reasons, would not emerge from
> >        the RFC process intact (i.e., an offshoot, etc.,
> >        which is not widely agreed), it could be published
> >        as a tech report as well.
> >
> >        I'd prefer to see these intermediate forms as RFCs,
> >        but the current IESG review process is not always conducive
> >        to publishing intermediate results.
> >
> >Some architectural documents may be useful as RFCs, and RFCs need not exclusively be protocols. In particular, it might be useful to issue a requirements doc, a specifications doc, and a design document as RFCs.
> >
> >Joe
> >
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> Vint Cerf
> SVP Technology Strategy
> MCI
> 22001 Loudoun County Parkway, F2-4115
> Ashburn, VA 20147
> 703 886 1690 (v806 1690)
> 703 886 0047 fax
> [email-masked]
> www.mci.com/cerfsup
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Sat, 18 Oct 2003 10:37:29 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: Avri Doria <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Avri Doria wrote:

> While I agree that a IRTF technical reports is an interesting idea, and 
> I would be willing to work with folks to propose such a thing, I don't 
> think there are insurmountable barriers to putting out IRTF reports as 
> informational or experimental RFCs.
> 
> I may be wrong, but I don't think that the IESG needs to do much of a 
> review of IRTF documents sent to the RFC editor except in so far as they 
> need to confirm that they do not impinge on any IETF standards work.  

That's the place where things get held up - in IESG review. I.e., while 
each AD decides whether they or one of their subgroups should review its 
content.

My own experience, after taking drafts to specific WGs X and Y and 
having them suggest 'informational', then submitting them for RFC, is 
that the ADs turned back around and said, "did you show this to WG X and 
Y", and it goes around in circles.

This is a well-known problem with the IESG review process; i.e., I 
wouldn't be surprised if this came back with "did you show this to 
PPVPN" or "TSVWG", etc. While I agree that these documents _should_ go 
through as informational or even experimental quickly, I'm not hopeful 
that will actually happen in a timely fashion.

Joe

Date: Sat, 18 Oct 2003 10:27:51 -0700
From: Joe Touch <[email-masked]>
Organization: USC/ISI
To: "vinton g. cerf" <[email-masked]>
CC: Durga Prasad Pandey <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

vinton g. cerf wrote:

> joe, et al,
> 
> my impression is that the publication hurdles for RFCs seem remarkably
> higher than they once were and that this series is no longer particularly
> useful for publishing of intermediate results. If informational RFCs are
> still accepted, that's the obvious route - I will ask Braden his opinion.

Even informational need IESG review these days, and that can be a 
substantial hurdle.

Date: Sat, 18 Oct 2003 10:17:05 -0700 (PDT)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Cc: [email-masked]
Sender: [email-masked]

  *> 
  *> The name "architecture" comes from building design. The architectural plans 
  *> of a building specify exactly how the building is to be built, and it is 
  *> the document government agencies rely on for certification and inspection.

Actually, I don't think this is quite right.  Firms that design buildings
have architects and engineers.  The engineers do the detailed specification,
while the architects are somewhere between sculptors and designers. They
lay out the general plan and function, leaving the gritty details like
beam loadings, plumbing, etc. to the engineers.   In network research
and Computer Science in general, "architecture" has been mostly used
in this general sense.  The semiconductor world is different, and
not relevant here.

Bob Braden

  *> This original use of the name "architecture", however, applies to hardware, 
  *> not software (i.e., the functions people and nature perform in the buildings).
  *> 
  *> Forrest
  *> 
  *> 
  *> _______________________________________________
  *> dtn-interest mailing list
  *> [email-masked]
  *> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
  *> 

Date: Sat, 18 Oct 2003 10:04:07 -0700
To: Joe Touch <[email-masked]>, Durga Prasad Pandey <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Cc: [email-masked]
Sender: [email-masked]

At 10:07 AM 10/17/2003, Joe Touch wrote:

>... Overall architecture documents aren't protocol specs,

In the commercial world of semiconductor software, an "architecture" 
document is commonly meant to name the most rigorous specification of 
software functionality, be it a protocol, an instruction set, etc. 
Examples: the Intel Pentium Instruction-Set Architecture (ISA) Manual and 
the IBM PowerPC Architecture book specify how microprocessor hardware must 
implement the architecture, and thereby tells programmers what they can 
expect from hardware.

The name "architecture" comes from building design. The architectural plans 
of a building specify exactly how the building is to be built, and it is 
the document government agencies rely on for certification and inspection. 
This original use of the name "architecture", however, applies to hardware, 
not software (i.e., the functions people and nature perform in the buildings).

Forrest

Date: Sat, 18 Oct 2003 09:22:48 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

At 05:18 AM 10/18/03, vinton g. cerf wrote:
>that is surely the right designation.
>vint
>At 10:41 PM 10/17/2003 -0700, Kevin Fall wrote:
> >I expect it should be informational.  Any other opinions?
>At 09:45 AM 10/15/03, Bob Braden wrote:
>What bad thing would happen if you submitted them without change
>(except the date and version numbers, of course)?
----------------------------------------------------

So.... if we agree that we should go for Informational RFCs:

a) Do *all* of the IDs listed below get resubmitted?
b) Unchanged or updated?
c) By whom, and when?

///adrian
(who is in Las Vegas setting up the rest of the conference 
http://telemetry.org/itconference.htm that leads up to: 
http://telemetry.org/keynote.htm )

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Title           : Delay-Tolerant Network Architecture
Author(s)       : V. Cerf et al.
Filename        : draft-irtf-dtnrg-arch-00.txt
Pages           : 24
Date            : 2003-3-24
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-00.txt
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
         Title           : Bundle Protocol Specification
         Author(s)       : K. Scott, S. Burleigh
         Filename        : draft-irtf-dtnrg-bundle-spec-00.txt
         Pages           : 30
         Date            : 2003-3-24
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-00.txt
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
         Title           : Delay-Tolerant Networking: An Example Interplanetary
                           Internet Bundle Transfer
         Author(s)       : R. Durst
         Filename        : draft-irtf-dtnrg-ipn-bundle-xfer-00.txt
         Pages           : 15
         Date            : 2003-3-24
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ipn-bundle-xfer-00.txt
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Date: Sat, 18 Oct 2003 08:18:25 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Kevin Fall <[email-masked]>, Joe Touch <[email-masked]>
Cc: Durga Prasad Pandey <[email-masked]>, [email-masked]
Sender: [email-masked]

that is surely the right designation.

vint

At 10:41 PM 10/17/2003 -0700, Kevin Fall wrote:
>I expect it should be informational.  Any other opinions?

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Sat, 18 Oct 2003 06:42:56 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Joe Touch <[email-masked]>
Cc: Durga Prasad Pandey <[email-masked]>, [email-masked]
Sender: [email-masked]

joe, et al,

my impression is that the publication hurdles for RFCs seem remarkably
higher than they once were and that this series is no longer particularly
useful for publishing of intermediate results. If informational RFCs are
still accepted, that's the obvious route - I will ask Braden his opinion.

v

At 11:54 AM 10/17/2003 -0700, Joe Touch wrote:
>It might be useful to clarify my position (now that I've had the coffee):
>
>        1) not all IPN documents need to be published as RFCs
>        I'm not speaking of current IPN IDs, but the
>        implication from previous mails that things which
>        are not otherwise published should be IDs/RFCs too.
>
>        2) pre-publication papers can - and should - be issued
>        as tech reports, esp. to enable them to be more widely
>        cited.
>
>        3) if there is a particularly useful intermediate stage
>        of an ID which, for many reasons, would not emerge from
>        the RFC process intact (i.e., an offshoot, etc.,
>        which is not widely agreed), it could be published
>        as a tech report as well.
>
>        I'd prefer to see these intermediate forms as RFCs,
>        but the current IESG review process is not always conducive
>        to publishing intermediate results.
>
>Some architectural documents may be useful as RFCs, and RFCs need not exclusively be protocols. In particular, it might be useful to issue a requirements doc, a specifications doc, and a design document as RFCs.
>
>Joe
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

To: Joe Touch <[email-masked]>
cc: Durga Prasad Pandey <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project] 
Date: Fri, 17 Oct 2003 22:41:23 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Joe Touch <[email-masked]>
> To:    Durga Prasad Pandey <[email-masked]>
> cc:    [email-masked]
> Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> Date:  Fri, 17 Oct 2003 10:07:01 PDT
>
> 
> 
> Durga Prasad Pandey wrote:
> 
> > --- Joe Touch <[email-masked]> wrote:
> > 
> >>An alternative to cluttering the RFCs with interim versions would be to 
> >>issue papers as tech reports - that way they're accessible, but 
> >>considered archival but not necessarily definitive.
> > 
> > This effectively means that we are introducing  an intermediate stage
> > called 'technical report' through which an internet draft must pass before
> > it becomes an RFC?...
> 
> The problem, as others have observed, with Internet Drafts is that they 
> should be cited for their content, since they are ephemeral. That's the 
> whole point of IDs - the fact that they disappear was (and is) supposed 
> to encourage the circulation and distribution of half-baked ideas.
> 
> I.e., IDs are like Royal Society letters of old.
> 
> However, some RFCs and IDs are - IMO - being published in the wrong 
> place. Overall architecture documents aren't protocol specs, half-baked 
> or not; those documents could, and perhaps should, be published 
> elsewhere and cited by IDs and RFCs.
> 
> Joe
> 

Well, in the particular case of the DTN architecture, there is now
the SIGCOMM paper from Aug.  Seems reasonable to me to reference
papers such as that (or papers in other networking conferences/mags) for such things.
Then again, perhaps FDNA will continue and provide us another
venue for architecture publications...

I'm placing it on my 'to-do' list to update the current [probably just expired]
DTN architecture RFC by the IETF deadline so we can attempt to RFC-ify it.
I expect it should be informational.  Any other opinions?

- K

Date: Fri, 17 Oct 2003 18:18:21 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Joe Touch <[email-masked]>, [email-masked]
Sender: [email-masked]

--- Joe Touch <[email-masked]> wrote:
> It might be useful to clarify my position (now that I've had the
> coffee):

Yes, it seems to have had some effect! :)

> 
> 	1) not all IPN documents need to be published as RFCs
> 	I'm not speaking of current IPN IDs, but the
> 	implication from previous mails that things which
> 	are not otherwise published should be IDs/RFCs too.

Let's see. 
-Discussions on most(probably all) mailing lists are archived, so they are
preserved anyway.
-Publications are preserved by dint of their being publications, unless
some obscure(?)(sorry for using this word, but I am trying to be honest)
conference or publication suddenly closes shop(shouldn't happen usually,
but not impossible either!).
-Bob was probably referring to valuable ideas a person might have which
might not make its way into publications. Well, if the ideas are
valuable(the RFC editor's judgement would decide that!!) , what's the harm
in issuing them as RFCs?  RFCs are 'request for comments', and they should
remain that in spirit...

To sum up, it might be better to have some extra 'not so great' RFCs ,
than lose a single valuable idea from being archived just because we are
being too selective. Remember Mahatma Gandhi: Setting a hundred criminals
free is preferable to convicting a single inocent.. :)

> 
> 	2) pre-publication papers can - and should - be issued
> 	as tech reports, esp. to enable them to be more widely
> 	cited.

Good idea.

> 
> 	3) if there is a particularly useful intermediate stage
> 	of an ID which, for many reasons, would not emerge from
> 	the RFC process intact (i.e., an offshoot, etc.,
> 	which is not widely agreed), it could be published
> 	as a tech report as well.

I think your idea of a tech report is good, and should be formalised. 

> 
> 	I'd prefer to see these intermediate forms as RFCs,
> 	but the current IESG review process is not always conducive
> 	to publishing intermediate results.

Sometimes review processes need to be reviewed too :)

=====
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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Fri, 17 Oct 2003 18:15:43 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Joe Touch <[email-masked]>, [email-masked]
Sender: [email-masked]

--- Joe Touch <[email-masked]> wrote:
> It might be useful to clarify my position (now that I've had the
> coffee):

Yes, it seems to have had some effect! :)

> 
> 	1) not all IPN documents need to be published as RFCs
> 	I'm not speaking of current IPN IDs, but the
> 	implication from previous mails that things which
> 	are not otherwise published should be IDs/RFCs too.

Let's see. 
-Discussions on most(probably all) mailing lists are archived, so they are
preserved anyway.
-Publications are preserved by dint of their being publications, unless
some obscure(?)(sorry for using this word, but I am trying to be honest)
conference or publication suddenly closes shop(shouldn't happen usually,
but not impossible either!).
-Bob was probably referring to valuable ideas a person might have which
might not make its way into publications. Well, if the ideas are
valuable(the RFC editor's judgement would decide that!!) , what's the harm
in issuing them as RFCs?  RFCs are 'request for comments', and they should
remain that in spirit...

To sum up, it might be better to have some extra 'not so great' RFCs ,
than lose a single valuable idea from being archived just because we are
being too selective. Remember Mahatma Gandhi: Setting a hundred criminals
free is preferable to convicting a single inocent.. :)

> 
> 	2) pre-publication papers can - and should - be issued
> 	as tech reports, esp. to enable them to be more widely
> 	cited.

Good idea.

> 
> 	3) if there is a particularly useful intermediate stage
> 	of an ID which, for many reasons, would not emerge from
> 	the RFC process intact (i.e., an offshoot, etc.,
> 	which is not widely agreed), it could be published
> 	as a tech report as well.

I think your idea of a tech report is good, and should be formalised. 

> 
> 	I'd prefer to see these intermediate forms as RFCs,
> 	but the current IESG review process is not always conducive
> 	to publishing intermediate results.

Sometimes review processes need to be reviewed too :)

=====
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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Sat, 18 Oct 2003 10:09:46 +0900
Subject: Re: [dtn-interest] Routing in intermittently connected networks
Cc: [email-masked]
To: Scott Burleigh <[email-masked]>
From: avri <[email-masked]>
Sender: [email-masked]

On fredag, okt 17, 2003, at 06:14 Asia/Seoul, Scott Burleigh wrote:

> At 08:17 PM 10/13/2003 +0200, Anders Lindgren wrote:
>
>>
>> http://www.sm.luth.se/~dugdale/publications/icr_lindgren.pdf
>>
>> Any comments or suggestions are welcome.
>>
>> Best regards,
>>
>> /Anders
>
> I like this paper very much, and the work seems highly applicable to 
> our routing problem in delay-tolerant networks.  I especially admire 
> the elegance of the forwarding strategy (though, as you point out, it 
> still makes sense to investigate alternatives that might offer even 
> better performance).  At first I was concerned about scalability, but 
> on a closer reading I convinced myself that the demand for routing 
> resources at any single node was an order-N function of network size; 
> not a problem for mobile ad hoc networks, I think, at least not the 
> ones we're looking at now.
>
> Scott
>

Thanks for the review and the comments.

In terms of scaling, the assumption we made is that the protocol would 
need to scale to a maximum of a few100 of systems, sort of on the order 
of  intra-area protocols.  Of course in the design of the full protocol 
that incorporates this strategy we will have to pay attention to the 
amount of information that is passed and the amount of time it takes to 
pass it.

Another area we have yet to tackle, (and while I say we, it is really 
Anders doing the hard work) is the acknowledgment and dropping 
strategy.  Especially in a DTN where certain nodes have custodial 
responsibilities but even in a network where the targets are reached 
while many relays are still holding the bundles.  One of my scalability 
issues has to do with the amount of bundle carrying capability in the 
relays.

And of course we then need to prototype it and try it in the field.  
But we are still waiting for funding for that part of the task. I my 
fingers are becoming permanently crossed.

Anyway, as we move along we will be happy to work with other 
researchers, and on this list, on these and other issues.

thanks
a.

Date: Sat, 18 Oct 2003 09:17:49 +0900
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
From: Avri Doria <[email-masked]>
To: [email-masked]
Sender: [email-masked]

While I agree that a IRTF technical reports is an interesting idea, and 
I would be willing to work with folks to propose such a thing, I don't 
think there are insurmountable barriers to putting out IRTF reports as 
informational or experimental RFCs.

I may be wrong, but I don't think that the IESG needs to do much of a 
review of IRTF documents sent to the RFC editor except in so far as 
they need to confirm that they do not impinge on any IETF standards 
work.  I.e. while we would not be able to put out a protocol 
specification in the standards track very easily and would certainly 
not be able to put out a document that changed any aspect of a current 
standards track protocol, I don't think we would have much of a problem 
with using the very underused experimental track.

a.

On lördag, okt 18, 2003, at 03:54 Asia/Seoul, Joe Touch wrote:

> It might be useful to clarify my position (now that I've had the 
> coffee):
>
> 	1) not all IPN documents need to be published as RFCs
> 	I'm not speaking of current IPN IDs, but the
> 	implication from previous mails that things which
> 	are not otherwise published should be IDs/RFCs too.
>
> 	2) pre-publication papers can - and should - be issued
> 	as tech reports, esp. to enable them to be more widely
> 	cited.
>
> 	3) if there is a particularly useful intermediate stage
> 	of an ID which, for many reasons, would not emerge from
> 	the RFC process intact (i.e., an offshoot, etc.,
> 	which is not widely agreed), it could be published
> 	as a tech report as well.
>
> 	I'd prefer to see these intermediate forms as RFCs,
> 	but the current IESG review process is not always conducive
> 	to publishing intermediate results.
>
> Some architectural documents may be useful as RFCs, and RFCs need not 
> exclusively be protocols. In particular, it might be useful to issue a 
> requirements doc, a specifications doc, and a design document as RFCs.
>
> Joe
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Fri, 17 Oct 2003 11:54:18 -0700
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
CC: Durga Prasad Pandey <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

It might be useful to clarify my position (now that I've had the coffee):

	1) not all IPN documents need to be published as RFCs
	I'm not speaking of current IPN IDs, but the
	implication from previous mails that things which
	are not otherwise published should be IDs/RFCs too.

	2) pre-publication papers can - and should - be issued
	as tech reports, esp. to enable them to be more widely
	cited.

	3) if there is a particularly useful intermediate stage
	of an ID which, for many reasons, would not emerge from
	the RFC process intact (i.e., an offshoot, etc.,
	which is not widely agreed), it could be published
	as a tech report as well.

	I'd prefer to see these intermediate forms as RFCs,
	but the current IESG review process is not always conducive
	to publishing intermediate results.

Some architectural documents may be useful as RFCs, and RFCs need not 
exclusively be protocols. In particular, it might be useful to issue a 
requirements doc, a specifications doc, and a design document as RFCs.

Joe

Date: Fri, 17 Oct 2003 10:09:46 -0700
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
CC: Durga Prasad Pandey <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

I need more coffee, or less ;-)

Joe Touch wrote:
> Durga Prasad Pandey wrote:
> 
>> --- Joe Touch <[email-masked]> wrote:
>>
>>> An alternative to cluttering the RFCs with interim versions would be 
>>> to issue papers as tech reports - that way they're accessible, but 
>>> considered archival but not necessarily definitive.
>>
>>
>> This effectively means that we are introducing  an intermediate stage
>> called 'technical report' through which an internet draft must pass 
>> before
>> it becomes an RFC?...
> 
> The problem, as others have observed, with Internet Drafts is that they 
> should be cited for their content, since they are ephemeral. That's the 
         ^ never
> whole point of IDs - the fact that they disappear was (and is) supposed 
> to encourage the circulation and distribution of half-baked ideas.
> 
> I.e., IDs are like Royal Society letters of old.
> 
> However, some RFCs and IDs are - IMO - being published in the wrong 
> place. Overall architecture documents aren't protocol specs, half-baked 
> or not; those documents could, and perhaps should, be published 
> elsewhere and cited by IDs and RFCs.
> 
> Joe
> 
> 

Date: Fri, 17 Oct 2003 10:07:01 -0700
From: Joe Touch <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

Durga Prasad Pandey wrote:

> --- Joe Touch <[email-masked]> wrote:
> 
>>An alternative to cluttering the RFCs with interim versions would be to 
>>issue papers as tech reports - that way they're accessible, but 
>>considered archival but not necessarily definitive.
> 
> This effectively means that we are introducing  an intermediate stage
> called 'technical report' through which an internet draft must pass before
> it becomes an RFC?...

The problem, as others have observed, with Internet Drafts is that they 
should be cited for their content, since they are ephemeral. That's the 
whole point of IDs - the fact that they disappear was (and is) supposed 
to encourage the circulation and distribution of half-baked ideas.

I.e., IDs are like Royal Society letters of old.

However, some RFCs and IDs are - IMO - being published in the wrong 
place. Overall architecture documents aren't protocol specs, half-baked 
or not; those documents could, and perhaps should, be published 
elsewhere and cited by IDs and RFCs.

Joe

Date: Fri, 17 Oct 2003 01:13:24 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Joe Touch <[email-masked]>, [email-masked]
Sender: [email-masked]

--- Joe Touch <[email-masked]> wrote:
> An alternative to cluttering the RFCs with interim versions would be to 
> issue papers as tech reports - that way they're accessible, but 
> considered archival but not necessarily definitive.

This effectively means that we are introducing  an intermediate stage
called 'technical report' through which an internet draft must pass before
it becomes an RFC? Sounds like a proposal for the ISOC to consider..

On another note, I do wish the IPN drafts become RFCs soon! They are
extremely well written and easy to understand, and it would be a pity if
they cannot be referenced in papers. For a first timer to DTN/IPN, they
are the best material available. Maybe someone someday will write a great
book on the A-Z of DTNs, but till then we will probably rely on these
documents.

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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Thu, 16 Oct 2003 14:14:47 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Routing in intermittently connected networks
Cc: [email-masked]
Sender: [email-masked]

At 08:17 PM 10/13/2003 +0200, Anders Lindgren wrote:

>All,
>
>Following Durga's example, I would like to point you to our work on
>probabilistic routing in intermittently connected networks. A report/paper
>describing our work so far can be found at
>http://www.sm.luth.se/~dugdale/publications/icr_lindgren.pdf
>
>Any comments or suggestions are welcome.
>
>Best regards,
>
>/Anders

I like this paper very much, and the work seems highly applicable to our 
routing problem in delay-tolerant networks.  I especially admire the 
elegance of the forwarding strategy (though, as you point out, it still 
makes sense to investigate alternatives that might offer even better 
performance).  At first I was concerned about scalability, but on a closer 
reading I convinced myself that the demand for routing resources at any 
single node was an order-N function of network size; not a problem for 
mobile ad hoc networks, I think, at least not the ones we're looking at now.

Scott 

Date: Thu, 16 Oct 2003 11:04:09 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] Re: Durga's project
To: "J. Leigh Torgerson" <[email-masked]>, [email-masked]
Sender: [email-masked]

--- "J. Leigh Torgerson" <[email-masked]> wrote:

> 
> A. Your stack diagram shows the Licklider Transmission Protocol; of 
> course no one has really defined that yet - there are conceptual 
> ideas people are kicking around, some debates of whether it's a 
> transport layer protocol or hop-by-hop reliable link protocol or ?? 
> It would be good to assess what impact differing link reliability 
> levels (and mechanisms) might have on your AI approach to congestion 
> control.

Yes, that sounds significant. Once we find that the basic model is
actually *detecting* congestion satisfactorily, I think we can go ahead
and check out how it behaves when different parameters(such as link layer
reliability) are varied. It would be more advanced work, I suppose.

> 
> B. The end-to-end IPN would contain both deep space links, which are 
> notoriously asymmetrical, and local links which may be much less 
> asymmetrical. Flow control using AI inferences about the network 
> using only locally-derived information might show some unexpected 
> behaviors depending on where the congestion actually is upstream or 
> downstream of the local node. Can your modeling can accomodate 
> different rates in the various modeled links?

Regarding local information: Scott recently made a very fundamental
observation, that global state need not necessarily be 'global'. I am
attaching his email below that will clear the picture.

Thanks for the excellent review!
Durga
--------
Hi, Chris and Durga. 
Something I just realized, that's not particularly   startling but maybe
worth keeping in mind: when we use the words "global   state" or "global
knowledge" I think we may unconsciously think of that   global-ness as
being naturally symmetric, i.e., global access to global   knowledge. It
need not be; that is, it may be useful for only a subset of   nodes --
even just one -- to have extensive non-local knowledge. This   makes the
scaling problem a bit more manageable. Even in the IPN we can   reasonably
expect to acquire and manage "global" knowledge of some aspects   of the
network at, say, an Earth-based network control center; a lot of   that
knowledge may be stale, but even the stale stuff can be the basis for  
useful inferences and (as you say) bayesian projections of current global
state. The notions of "structural flow control" we've been fiddling with 
would likely rely on this kind of thing. As you point out, we might be 
able to do even better, but I think we've got to have at least this much, 
 somehow.     

Scott  

=====
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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Wed, 15 Oct 2003 19:27:56 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Joe Touch <[email-masked]>, Bob Braden <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I do think the IPN drafts are 'Mature' enough, and additional ideas could
come in as seperate RFCs/extensions. Or else we would have to wait for a
long time, before we make it an RFC- changes will always keep coming...

Durga

--- Joe Touch <[email-masked]> wrote:
> An alternative to cluttering the RFCs with interim versions would be to 
> issue papers as tech reports - that way they're accessible, but 
> considered archival but not necessarily definitive.
> 
> Joe
> 
> Bob Braden wrote:
> 
> >   *> 
> >   *> I agree. The three latest I-Ds (below) were all dated 2003-3-24,
> so 
> >   *> presumably they have just expired. I think that we agreed to go
> the RFC 
> >   *> route the next time around, which "ought" to be quite soon. (Of
> course, we 
> >   *> all "ought" to be rich by now.)
> >   *> 
> >   *> ///adrian
> >   *> 
> > 
> > Adrian,
> > 
> > We have heard that story far too often, but people don't ever quite
> get
> > around to it.  So much valuable source material slips back into
> > oblivion.
> > 
> > What bad thing would happen if you submitted them without change
> > (except the date and version numbers, of course)?
> > 
> > Bob
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

=====
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Wed, 15 Oct 2003 10:54:04 -0700
From: Joe Touch <[email-masked]>
To: Bob Braden <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

An alternative to cluttering the RFCs with interim versions would be to 
issue papers as tech reports - that way they're accessible, but 
considered archival but not necessarily definitive.

Joe

Bob Braden wrote:

>   *> 
>   *> I agree. The three latest I-Ds (below) were all dated 2003-3-24, so 
>   *> presumably they have just expired. I think that we agreed to go the RFC 
>   *> route the next time around, which "ought" to be quite soon. (Of course, we 
>   *> all "ought" to be rich by now.)
>   *> 
>   *> ///adrian
>   *> 
> 
> Adrian,
> 
> We have heard that story far too often, but people don't ever quite get
> around to it.  So much valuable source material slips back into
> oblivion.
> 
> What bad thing would happen if you submitted them without change
> (except the date and version numbers, of course)?
> 
> Bob
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 15 Oct 2003 10:45:21 -0700
To: [email-masked]
From: "J. Leigh Torgerson" <[email-masked]>
Subject: Re: [dtn-interest] Re: Durga's project
Sender: [email-masked]

Looks like a highly worthwhile project Durga..

Here are my thoughts about things you might want to model now or 
later (you may already be planning these things!):

A. Your stack diagram shows the Licklider Transmission Protocol; of 
course no one has really defined that yet - there are conceptual 
ideas people are kicking around, some debates of whether it's a 
transport layer protocol or hop-by-hop reliable link protocol or ?? 
It would be good to assess what impact differing link reliability 
levels (and mechanisms) might have on your AI approach to congestion 
control.

B. The end-to-end IPN would contain both deep space links, which are 
notoriously asymmetrical, and local links which may be much less 
asymmetrical. Flow control using AI inferences about the network 
using only locally-derived information might show some unexpected 
behaviors depending on where the congestion actually is upstream or 
downstream of the local node. Can your modeling can accomodate 
different rates in the various modeled links?

Best of luck with your work!
regards,
Leigh

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

To: "vinton g. cerf" <[email-masked]>
cc: Bob Braden <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project] 
Date: Wed, 15 Oct 2003 10:21:03 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  "vinton g. cerf" <[email-masked]>
> To:    Bob Braden <[email-masked]>, [email-masked],
	 [email-masked]
> Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
> Date:  Wed, 15 Oct 2003 13:01:03 EDT
>
> perhaps with a disclaimer that work continues and updates are expected ?
> 
> vint
> 
> At 09:45 AM 10/15/2003 -0700, Bob Braden wrote:
> >What bad thing would happen if you submitted them without change
> >(except the date and version numbers, of course)?
> 
> Vint Cerf
> SVP Technology Strategy
> MCI
> 22001 Loudoun County Parkway, F2-4115
> Ashburn, VA 20147
> 703 886 1690 (v806 1690)
> 703 886 0047 fax
> [email-masked]
> www.mci.com/cerfsup 

It strikes me we are very close to having those things ready.
There is an ID final submit deadline of Oct 27 for the upcoming
IETF.  Not that we particularly have to meet this date, but maybe
it would be good to shoot for. [?]

- K

Date: Wed, 15 Oct 2003 13:01:03 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
To: Bob Braden <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

perhaps with a disclaimer that work continues and updates are expected ?

vint

At 09:45 AM 10/15/2003 -0700, Bob Braden wrote:
>What bad thing would happen if you submitted them without change
>(except the date and version numbers, of course)?

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

From: Bob Braden <[email-masked]>
Date: Wed, 15 Oct 2003 09:45:01 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

  *> 
  *> I agree. The three latest I-Ds (below) were all dated 2003-3-24, so 
  *> presumably they have just expired. I think that we agreed to go the RFC 
  *> route the next time around, which "ought" to be quite soon. (Of course, we 
  *> all "ought" to be rich by now.)
  *> 
  *> ///adrian
  *> 

Adrian,

We have heard that story far too often, but people don't ever quite get
around to it.  So much valuable source material slips back into
oblivion.

What bad thing would happen if you submitted them without change
(except the date and version numbers, of course)?

Bob

Date: Wed, 15 Oct 2003 09:39:00 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] DTN RFCs [was Re: Durga's project]
Sender: [email-masked]

At 09:22 AM 10/15/2003, Bob Braden wrote:
>If you scan back over the slice of Internet history captured in the first 
>3300 RFCs, you will realize that "maturity" is not a requirement.  Much of 
>the value to future generations will be in capturing in archival documents 
>the present state of your thinking.

I agree. The three latest I-Ds (below) were all dated 2003-3-24, so 
presumably they have just expired. I think that we agreed to go the RFC 
route the next time around, which "ought" to be quite soon. (Of course, we 
all "ought" to be rich by now.)

///adrian

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From: Bob Braden <[email-masked]>
Date: Wed, 15 Oct 2003 09:22:42 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: Durga's project
Cc: [email-masked]
Sender: [email-masked]

  *> 
  *> > 2. if durga references IPN perhaps it would be wise to reference some
  *> > more permanent papers than Internet Drafts.
  *> 
  *> Do we have permanent papers on IPN? Perhaps the drafts should have matured
  *> into RFCs?
  *> 

If you scan back over the slice of Internet history captured in
the first 3300 RFCs, you will realize that "maturity" is not a
requirement.  Much of the value to future generations will be
in capturing in archival documents the present state of your
thinking.

Bob Braden

From: Bob Braden <[email-masked]>
Date: Wed, 15 Oct 2003 09:20:30 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: Durga's project
Sender: [email-masked]

   *> 2. if durga references IPN perhaps it would be wise to reference some more 
  *> permanent papers than Internet Drafts.

It sounds like IPN drafts should become RFCs, real soon now.

Bob Braden

Subject: Re: [dtn-interest] Re: Durga's project
From: Michael Welzl <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
Cc: "vinton g. cerf" <[email-masked]>, [email-masked]
Organization: University of Innsbruck
Date: 15 Oct 2003 17:34:55 +0200
Sender: [email-masked]

On Wed, 2003-10-15 at 17:23, Durga Prasad Pandey wrote:
> --- Michael Welzl <[email-masked]> wrote:
> 
> > 
> > Seriously, I think this one's worth citing, it appears to
> > be a great introduction into DTN.
> 
> Point taken. The question of citing a paper on IPN still remains- the one
> you mentioned is on DTNs.

ARGH

DTN ... IPN ... sometimes, when I'm busy and things
are hectic, I'm getting lost in the world of three
letter acronyms    :(

sorry. I don't know of an IPN paper.

cheers,
Michael

Date: Wed, 15 Oct 2003 08:34:30 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Re: Durga's project
Sender: [email-masked]

At 08:23 AM 10/15/2003 -0700, Durga Prasad Pandey wrote:

>--- Michael Welzl <[email-masked]> wrote:
>
> >
> > Seriously, I think this one's worth citing, it appears to
> > be a great introduction into DTN.
>
>Point taken. The question of citing a paper on IPN still remains- the one
>you mentioned is on DTNs.

There are several references on the IPNSIG web site 
(http://www.ipnsig.org/techinfo.htm) that might be suitable.  I'd suggest 
the paper presented at the 2002 World Space Congress, or maybe the one 
presented at SpaceOps 2002.

Scott 

Date: Wed, 15 Oct 2003 08:23:02 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] Re: Durga's project
To: Michael Welzl <[email-masked]>
Cc: "vinton g. cerf" <[email-masked]>, [email-masked]
Sender: [email-masked]

--- Michael Welzl <[email-masked]> wrote:

> 
> Seriously, I think this one's worth citing, it appears to
> be a great introduction into DTN.

Point taken. The question of citing a paper on IPN still remains- the one
you mentioned is on DTNs.

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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Subject: Re: [dtn-interest] Re: Durga's project
From: Michael Welzl <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
Cc: "vinton g. cerf" <[email-masked]>, [email-masked]
Organization: University of Innsbruck
Date: 15 Oct 2003 17:14:10 +0200
Sender: [email-masked]

Hi,

I liked the paper in IEEE Communications Magazine, June 2003
(vol 41, no. 6) a lot ... but perhaps that's because I like
the whole issue as I got my own paper published in it
(on scalability vs. QoS)   ;-)

Seriously, I think this one's worth citing, it appears to
be a great introduction into DTN.

Cheers,
Michael

On Wed, 2003-10-15 at 17:08, Durga Prasad Pandey wrote:
> > 2. if durga references IPN perhaps it would be wise to reference some
> > more permanent papers than Internet Drafts.
> 
> Do we have permanent papers on IPN? Perhaps the drafts should have matured
> into RFCs?
> 
> 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!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
-- 
Michael Welzl <[email-masked]>
University of Innsbruck

Date: Wed, 15 Oct 2003 08:08:16 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] Re: Durga's project
To: "vinton g. cerf" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 2. if durga references IPN perhaps it would be wise to reference some
> more permanent papers than Internet Drafts.

Do we have permanent papers on IPN? Perhaps the drafts should have matured
into RFCs?

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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Wed, 15 Oct 2003 08:06:34 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] Re: Durga's project
To: "vinton g. cerf" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 2. if durga references IPN perhaps it would be wise to reference some
> more 
> permanent papers than Internet Drafts.

Which one would you suggest?

> 3. The idea that the system can "learn" probably requires that the
> system 
> show some periodicity or repeated behaviors to be learned or it is all 
> randon. The sensitivity of the learning system to the degree of
> randomness 
> in the system should be assessed.

Exactly. And we presume that we won't have a lot of information available
on which to base congestion decisions, which is precisely the reason why
we are using Inductive Machine Learning: It works even when very little
information is available about the system. I do think the pattern of
congestion would be repetitive to an extent that it can be modeled. As you
have pointed out, the extent of repetition will definitely be a factor
that we keep in mind(and try to identify within the constraints of the
simulated data) while working on the experiment.

Thanks!
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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Date: Wed, 15 Oct 2003 07:46:16 -0700
To: [email-masked]
From: "vinton g. cerf" <[email-masked]> (by way of "Adrian J. Hooke" <[email-masked]>)
Subject: [dtn-interest] Re: Durga's project
Sender: [email-masked]

1. this is a well-written proposal
2. if durga references IPN perhaps it would be wise to reference some more 
permanent papers than Internet Drafts.
3. The idea that the system can "learn" probably requires that the system 
show some periodicity or repeated behaviors to be learned or it is all 
randon. The sensitivity of the learning system to the degree of randomness 
in the system should be assessed.
4. A good summer's work, I think.

Vint

Date: Wed, 15 Oct 2003 07:45:03 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] Peer review/ Comments: DTN summer research report
Sender: [email-masked]

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

Folks: could I ask all of you to kindly take a little bit of time and 
respond to Durga's request for a peer review? He spent a lot of time over 
his summer doing this work, and getting feedback is important to his 
immediate future.

Please just post comments back to dtn-interest, per his request:

At 04:54 AM 10/13/2003, Durga Prasad Pandey wrote:
>Could I invite you to go through the report, which is available at:
><http://www.geocities.com/dpsmiles/Report4.1.pdf>http://www.geocities.com/dpsmiles/Report4.1.pdf
>and post in your comments to this list.

Best regards
Adrian

Adrian J. Hooke
Leader,InterPlanetary Network (IPN) Study
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

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

<html>
Folks: could I ask all of you to kindly take a little bit of time and
respond to Durga's request for a peer review? He spent a lot of time over
his summer doing this work, and getting feedback is important to his
immediate future. <br><br>
Please just post comments back to dtn-interest, per his 
request:<br><br>
At 04:54 AM 10/13/2003, Durga Prasad Pandey wrote:<br>
<blockquote type=cite class=cite cite>Could I invite you to go through
the report, which is available at:<br>
<a href="http://www.geocities.com/dpsmiles/Report4.1.pdf">http://www.geocities.com/dpsmiles/Report4.1.pdf</a><br>
and post in your comments to this list. </blockquote><br>
Best regards<br>
Adrian<br>
<x-sigsep><p></x-sigsep>
Adrian J. Hooke<br>
Leader,InterPlanetary Network (IPN) Study<br>
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>
</html>

--=====================_434991156==_.ALT--

Date: Tue, 14 Oct 2003 12:42:39 -0600 (MDT)
From: henry brown <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Power Blackout prevention - DTN SCADA/ Planet Lab
Sender: [email-masked]

http://www.sciam.com/article.cfm?chanID=sa004&articleID=000784B6-E5FB-1F86-9B8C83414B7FFE87
Better communication among power stations would also aid in stabilizing 
the grid. Protective relays rely on local information and can be fooled 
into disconnecting a line unnecessarily. Dedicated fiber optics would 
permit fast comparisons of conditions at adjacent stations, forestalling 
needless shutdowns. The Global Positioning System (GPS) could put a time 
stamp on each station reading, allowing operators to make better decisions 
by looking at successive snapshots of grid conditions. The Bonneville 
Power Administration, based in Portland, Ore., and Ameren Corporation, a 
St. Louis-based utility, use GPS time stamping.

Could DTN create time stamping via GPS enabled router?
Use GPS heartbeat off of SCADA to update remote routers at power plants.

SOE for SCADA

Multiple protocols are constantly being updated in Control Centers.
RTU outages and their Sequence of Events (SOE) are not time synchronized.
These points of data are thus passed along through Protocols and
the data is not time synched correctly.

Many utilities are trying to develop SOE solutions.
Does DTN have a method to time correct RTU data as it passes through
the switch, router, firewall?

Time synchronization is critical in seeing patterns in the alarm
information. While control centers are synchronized to GPS, RTU's in 
the field are not. Cost???

How can DTN improve time synchronization of data coming in from remote 
RTU sites? How do you deal with latency?

Could software be used to manage time synch without expensive RTU 
upgrades and software? This may allow you to retrofit preexisting SCADA
cheaply. Many utilities might use this network of routers to synch 
all devices to GPS in control centers. All control centers are presently
GPS time synched daily by FERC regulation. The older RTUs are however 
not synchronized from control center. How could DTN support this?

Could Planet Lab/Linux be used to accomplish this?  
 
References:
http://www.esac.com/ser.htm
http://www.planet-lab.org/php/slices.php
http://www.planet-lab.org/php/proj_top.php

-- 
Henry Brown
PNM Power Operations
505 241-2297
[email-masked]

Date: Mon, 13 Oct 2003 20:17:45 +0200 (MEST)
From: Anders Lindgren <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [dtn-interest] Routing in intermittently connected networks
Sender: [email-masked]

All,

Following Durga's example, I would like to point you to our work on
probabilistic routing in intermittently connected networks. A report/paper
describing our work so far can be found at
http://www.sm.luth.se/~dugdale/publications/icr_lindgren.pdf

Any comments or suggestions are welcome.

Best regards,

/Anders

On Mon, 13 Oct 2003, Durga Prasad Pandey wrote:

> Hi DTN Fans:

>  Last summer, I performed research on congestion issues in DTNs, as a
> result of which we have come up with a proposal for an experiment to
> test the effectiveness of a cognition based congestion detection daemon.
>
> Could I invite you to go through the report, which is available at:
> http://www.geocities.com/dpsmiles/Report4.1.pdf
> and post in your comments to this list.

>  Thanks for your time. I look forward to a lively discussion and many
> comments and suggestions.
>
> Best regards,
> Durga

Date: Mon, 13 Oct 2003 04:54:20 -0700 (PDT)
From: Durga Prasad Pandey <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Calling for Peer review and Comments: DTN summer research report
Sender: [email-masked]

--0-488930949-1066046060=:88665
Content-Type: text/plain; charset=us-ascii

Hi DTN Fans:
 
Last summer, I performed research on congestion issues in DTNs, as a result of which we have come up with a proposal for an experiment to test the effectiveness of a cognition based congestion detection daemon. 
 
Could I invite you to go through the report, which is available at:
http://www.geocities.com/dpsmiles/Report4.1.pdf
and post in your comments to this list. 
 
Thanks for your time. I look forward to a lively discussion and many comments and suggestions.
 
Best regards,
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!?
The New Yahoo! Shopping - with improved product search
--0-488930949-1066046060=:88665
Content-Type: text/html; charset=us-ascii

<DIV>Hi DTN Fans:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Last summer, I performed research on congestion issues in DTNs, as a result of which we have come up with a proposal for an experiment to test the effectiveness of a cognition based congestion detection daemon. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Could I invite&nbsp;you to go through the report, which is available at:</DIV>
<DIV><A href="http://www.geocities.com/dpsmiles/Report4.1.pdf">http://www.geocities.com/dpsmiles/Report4.1.pdf</A></DIV>
<DIV>and post in your comments to this list.&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks for your time. I look&nbsp;forward to a lively discussion and many comments and suggestions.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best regards,</DIV>
<DIV>Durga</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV><BR><BR>Durga Prasad Pandey<br>Assistant Online Editor, ACM Crossroads<br>http://www.acm.org/crossroads/<br>Indian School of Mines<br>47 Emerald Hostel<br>Dhanbad 826004 India<br>[email-masked]<br>DP's inn: http://geocities.com/dpsmiles/<p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://shopping.yahoo.com/?__yltc=s%3A150000443%2Cd%3A22708228%2Cslk%3Atext%2Csec%3Amail">The New Yahoo! Shopping</a> - with improved product search
--0-488930949-1066046060=:88665--

Date: Thu, 9 Oct 2003 21:49:44 -0400
From: Manikantan Ramadas <[email-masked]>
To: "Scott,Keith L." <[email-masked]>
Cc: "vinton g. cerf" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Kevin Fall <[email-masked]>, Juan Alonso <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN configuration question
Sender: [email-masked]

--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

It works now. Thanks!

And I actually had to add something of the form :
    *.mars.sol     mars.sol	  marsGW    ONDEMAND
in /etc/bundles/route on the mars gateway (where in place of marsGW,=20
I gave the FQDN of the host on which the Mars gateway was being simulated).

However, I do get a bunch of warnings from the bundleDaemon-s running on th=
e=20
Mars gateway : "bundle_daemon> bundleRoute: ENONAMEINREGION"
and the one running on host marsBox :=20
"db_deliver_bundles_to_registration_id:  deliver_bundle_file fails, ret =3D=
 -1"

Well, I shall figure them out from the source code myself. It shouldn't be =
a=20
problem.

Thanks a lot!
Mani.

On Thu, Oct 09, 2003 at 02:18:32PM -0400, Scott,Keith L. wrote:
> I think that you need an entry for the mars.sol region in the route file=
=20
> on the Mars gateway.  Even though the Mars gateway has an 'interface' in=
=20
> the mars.sol region, you need a routing entry for that region.  So=20
> something like:
>=20
> *.mars.sol   foo.mars.sol   ONDEMAND
>=20
> in the route file on the mars gateway may be what you need.  The=20
> requirement to have a 'bogus' entry for regions you do not route=20
> _through_ is a deficiency in the released version of the code.
>=20
>       --keith
>=20
>=20
> vinton g. cerf wrote:
>=20
> >you have just turned up the routing problem.
> >
> >durst, Scott, Keith, Kevin, anything to suggest?
> >
> >vint
> >
> >
> >At 04:21 PM 10/8/2003 -0400, Manikantan Ramadas wrote:
> >=20
> >
> >>*** PGP SIGNATURE VERIFICATION ***
> >>*** Status:   Good Signature from Invalid Key
> >>*** Alert:    Please verify signer's key before trusting signature.
> >>*** Signer:   Manikantan Ramadas (OUCS) <[email-masked]>=20
> >>(0x1A2C7D35)
> >>*** Signed:   10/8/2003 4:21:06 PM
> >>*** Verified: 10/9/2003 3:24:03 AM
> >>*** BEGIN PGP VERIFIED MESSAGE ***
> >>
> >>
> >>Hi,
> >>
> >>
> >>I have been playing with the DTN implementation and trying to reproduce
> >>a simple DTN setting analogous to the one described in the
> >>draft-irtf-dtnrg-ipn-bundle-xfer-00.txt.=20
> >>
> >>
> >>I have two regions earth.sol and mars.sol connected by the backbone=20
> >>ipn.sol region. I have a gateway each covering the earth-IPN and mars-I=
PN=20
> >>region boundaries (say earthIPN.earth.sol [also earthIPN.ipn.sol in its=
=20
> >>other
> >>interface] and marsIPN.mars.sol [also marsIPN.ipn.sol],
> >>and a host on each of the earth.sol and mars.sol regions, say=20
> >>earthBox.earth.sol and marsBox.earth.sol respectively.=20
> >>
> >>
> >>Well, I could get bundle transfers work between earthBox.earth.sol to t=
he
> >>gateway marsIPN.mars.sol, but not to the host marsBox.mars.sol. The
> >>bundles I send to marsBox.mars.sol from earthBox.earth.sol reach the ma=
rs
> >>gateway marsIPN.mars.sol however (I can see them in /var/spool/bundles)=
,=20
> >>and they do not know how to get to the host marsBox.=20
> >>
> >>
> >>I have specified tcp convergence layer (with all my "region ..." lines
> >>in bundleNode.conf files ending with "tcp yes") and all my nodes are
> >>available "ONDEMAND" as specified in the /etc/bundles/route files of all
> >>nodes.
> >>
> >>
> >>The mail I used from the archive for help in configuring
> >>at  http://mailman.dtnrg.org/pipermail/dtn-interest/2003-June/000177.ht=
ml=20
> >>,
> >>seems to suggest that I need to add an entry for marsBox.mars.sol in the
> >>host table of the gateway marsIPN.mars.sol. I have trouble figuring out
> >>where this "host table" should exist and what its format should be.=20
> >>Does that go into another config file in /etc/bundles?
> >>
> >>
> >>I would really appreciate if any one could shed some light on this.
> >>
> >>Thanks!
> >>Mani.
> >>
> >>
> >>--=20
> >>"Happiness is when what you think, what you say, and what you do
> >>are in harmony."                                - Mahatma Gandhi
> >>____________________________________________________________________
> >>
> >>* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
> >>____________________________________________________________________
> >>
> >>
> >>
> >>*** END PGP VERIFIED MESSAGE ***
> >>  =20
> >>
> >>List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest=
>,=20
> >>      <mailto:[email-masked]?subject=3Dsubscrib=
e>=20
> >>List-Unsubscribe:=20
> >><http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>,=20
> >>      <mailto:[email-masked]?subject=3Dunsubscr=
ibe>=20
> >>List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-interest/>=20
> >>List-Help: <mailto:[email-masked]?subject=3Dhel=
p>=20
> >>List-Id: Delay Tolerant Networking Interest List=20
> >><dtn-interest.mailman.dtnrg.org>=20
> >>
> >><file://C:\Data\Eudora\attach\attach-1\[dtn-interest] DTN=20
> >>configuratio.ems <0880.0002>>[dtn-interest] DTN configuratio.ems=20
> >>
> >
> >Vint Cerf
> >SVP Technology Strategy
> >MCI
> >22001 Loudoun County Parkway, F2-4115
> >Ashburn, VA 20147
> >703 886 1690 (v806 1690)
> >703 886 0047 fax
> >[email-masked]
> >www.mci.com/cerfsup=20
> >
> >=20
> >

--=20
"Happiness is when what you think, what you say, and what you do
are in harmony."                                - Mahatma Gandhi
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature
Content-Disposition: inline

--2fHTh5uZTiUOsy+g--

Date: Wed, 8 Oct 2003 16:21:07 -0400
From: Manikantan Ramadas <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN configuration question
Sender: [email-masked]

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

Hi,

  I have been playing with the DTN implementation and trying to reproduce
a simple DTN setting analogous to the one described in the
draft-irtf-dtnrg-ipn-bundle-xfer-00.txt.=20

  I have two regions earth.sol and mars.sol connected by the backbone ipn.s=
ol=20
region. I have a gateway each covering the earth-IPN and mars-IPN region=20
boundaries (say earthIPN.earth.sol [also earthIPN.ipn.sol in its other
interface] and marsIPN.mars.sol [also marsIPN.ipn.sol],
and a host on each of the earth.sol and mars.sol regions, say=20
earthBox.earth.sol and marsBox.earth.sol respectively.=20

  Well, I could get bundle transfers work between earthBox.earth.sol to the
gateway marsIPN.mars.sol, but not to the host marsBox.mars.sol. The
bundles I send to marsBox.mars.sol from earthBox.earth.sol reach the mars
gateway marsIPN.mars.sol however (I can see them in /var/spool/bundles), an=
d=20
they do not know how to get to the host marsBox.=20

  I have specified tcp convergence layer (with all my "region ..." lines
in bundleNode.conf files ending with "tcp yes") and all my nodes are
available "ONDEMAND" as specified in the /etc/bundles/route files of all
nodes.

  The mail I used from the archive for help in configuring
at  http://mailman.dtnrg.org/pipermail/dtn-interest/2003-June/000177.html ,
seems to suggest that I need to add an entry for marsBox.mars.sol in the
host table of the gateway marsIPN.mars.sol. I have trouble figuring out
where this "host table" should exist and what its format should be.=20
Does that go into another config file in /etc/bundles?

  I would really appreciate if any one could shed some light on this.
 =20
Thanks!
Mani.

--=20
"Happiness is when what you think, what you say, and what you do
are in harmony."                                - Mahatma Gandhi
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

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

--ew6BAiZeqk4r7MaW--

Date: Wed, 8 Oct 2003 16:14:16 -0400
From: Manikantan Ramadas <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN configuration question
Sender: [email-masked]

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

Hi,

  I have been playing with the DTN implementation and trying to reproduce
a simple DTN setting analogous to the one described in the
draft-irtf-dtnrg-ipn-bundle-xfer-00.txt.=20

  I have two regions earth.sol and mars.sol connected by the backbone ipn.s=
ol=20
region. I have a gateway each covering the earth-IPN and mars-IPN region=20
boundaries (say earthIPN.earth.sol [also earthIPN.ipn.sol in its other
interface] and marsIPN.mars.sol [also marsIPN.ipn.sol],
and a host on each of the earth.sol and mars.sol regions, say=20
earthBox.earth.sol and marsBox.earth.sol respectively.=20

  Well, I could get bundle transfers work between earthBox.earth.sol to the
gateway marsIPN.mars.sol, but not to the host marsBox.mars.sol. The
bundles I send to marsBox.mars.sol from earthBox.earth.sol reach the mars
gateway marsIPN.mars.sol however (I can see them in /var/spool/bundles), an=
d=20
they do not know how to get to the host marsBox.=20

  I have specified tcp convergence layer (with all my "region ..." lines
in bundleNode.conf files ending with "tcp yes") and all my nodes are
available "ONDEMAND" as specified in the /etc/bundles/route files of all
nodes.

  The mail I used from the archive for help in configuring
at  http://mailman.dtnrg.org/pipermail/dtn-interest/2003-June/000177.html ,
seems to suggest that I need to add an entry for marsBox.mars.sol in the
host table of the gateway marsIPN.mars.sol. I have trouble figuring out
where this "host table" should exist and what its format should be.=20
Does that go into another config file in /etc/bundles?

  I would really appreciate if any one could shed some light on this.
 =20
Thanks!
Mani.

--=20
"Happiness is when what you think, what you say, and what you do
are in harmony."                                - Mahatma Gandhi
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--1SQmhf2mF2YjsYvc
Content-Type: application/pgp-signature
Content-Disposition: inline

--1SQmhf2mF2YjsYvc--