Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:
From: Daniel Ellard <[email-masked]>
To: [email-masked]
Date: Thu, 30 Apr 2009 13:47:09 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Simon Perreault wrote:
> Folks,
> 
> A Doodle poll has been created. Please enter your preferences so that we
> may gather hard data.
> 
> http://www.doodle.com/6mdtwuqif6mszea2

There are still a few holdouts who haven't stated a
preference...

If you have a preference, please enter it by Monday 5/4.

If you don't have a preference, please don't complain :-)

Thanks,
	-Dan

Date: Wed, 29 Apr 2009 16:36:59 +0100
From: Stephen Farrell <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Burleigh, Scott C wrote:
> Okay, so now I'm confused.  Are we saying that DTN developers will get a lot of cognitive leverage from using API functions that operate on things that are called sockets (or socket-like objects of some sort) but aren't really sockets at all, can't be handled as file descriptors the way real sockets can, and in fact are very different from sockets?  

Yes!

> More than from using API functions and structures whose names map to concepts in the specification of the protocol they're trying to use?

No. But maybe they'll get started quicker and then later be more able
to use a more modern API.

> The functionality of BP-based data interchange differs in some significant ways from the functionality provided by file descriptors.  Why confuse the neophyte DTN developer by pretending otherwise?  And at the same time, isn't trying to jam all BP functionality into the "sockets" model kind of Procrustean?  There's stuff that just doesn't fit; do we leave it out of the API?

I'm not for trying to do that (jamming stuff in or being Procrustean:-)
but I don't think the other mails arguing for doing something
sockets-like are arguing that that's all that should be done.

In other words: let's provide (1) some minimal ways to benefit from DTN
via a sockets-like API and then also (2) a way to make better use of DTN
via an API that matches the BP better.

> I certainly acknowledge the value of having a standard, common API for BP, but I am increasingly doubtful that we can design that API quickly.  There doesn't seem to be much point in pushing one out right away that ends up being wrong, and I don't think the need is really urgent or critical.  Let think about it first.

Fair point. But (1) could be done quite quickly IMO, while I agree
that (2) might take a while.

S.

From: Peter Lovell <[email-masked]>
To: Hans Kruse <[email-masked]>, [email-masked]
Date: Wed, 29 Apr 2009 11:19:20 -0400
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re(2): [dtn-security] Bundle Security Protocol Implementation

Hi Nasir and Hans,

If I remember correctly, ION does not yet include BSP in its
implementation. That may have changed but I think that was the situation
a few months ago.

So I would suggest that you begin with DTN2 BSP which is intended to be
a reference implementation. That's not completely up-to-date but fairly
close (and that will be corrected soon).

I am happy to provide suggestions and advice on this one (since I wrote it).

Regards.....Peter

On Wed, Apr 29, 2009, Hans Kruse <[email-masked]> wrote:

>Nasir,
>the Java implementation you refer to has not been supported in a long
>time as we have been focusing on the NASA ION code base.  I would
>suggest that either ION or DTN2 would be the best place to start from.
>
>On Apr 29, 2009, at 7:59 AM, <[email-masked]> wrote:
>
>> Hi All,
>>
>> We at Surrey university are implementing the Bundle Security
>> Protocol Specification internet draft .. The implementation will
>> have following features:
>>
>> BSP Features:
>> - Support for Authentication via BAB, PIB
>> - Support for confidentiality via PCB
>> - Support for compulsory cipher suites
>>
>> We are going to use "BP reference implementation by Ohio university
>> in Java". We thought that some may be working on security
>> implementation. So, any one with any progress, or want to give some
>> suggestion. All inputs will be realy appreciated.
>>
>> "Most important how we should merge this with Bundle Protocol
>> Implementation" ..
>>
>> regards,
>> Nasir
>> University of Surrey
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>Hans Kruse, Professor
>J. Warren McClure School of Information and Telecommunication Systems
>Adjunct Associate Professor of Electrical Engineering and Computer
>Science
>292 Lindley Hall, Ohio University, Athens, OH, 45701
>740-593-4891 voice, 740-593-4889 fax
>
>
>_______________________________________________
>dtn-security mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-security

From: "Burleigh, Scott C" <[email-masked]>
To: Joseph Ishac <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 29 Apr 2009 08:19:09 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Okay, so now I'm confused.  Are we saying that DTN developers will get a lot of cognitive leverage from using API functions that operate on things that are called sockets (or socket-like objects of some sort) but aren't really sockets at all, can't be handled as file descriptors the way real sockets can, and in fact are very different from sockets?  More than from using API functions and structures whose names map to concepts in the specification of the protocol they're trying to use?

Well, maybe they will.  I think we've got kind of a corollary to the duck principle at work here, though.  If it doesn't look like a duck, doesn't walk like a duck, and doesn't quack like a duck, it's not a duck.  If it's not a duck, how much real benefit do we get from calling it a duck?

The functionality of BP-based data interchange differs in some significant ways from the functionality provided by file descriptors.  Why confuse the neophyte DTN developer by pretending otherwise?  And at the same time, isn't trying to jam all BP functionality into the "sockets" model kind of Procrustean?  There's stuff that just doesn't fit; do we leave it out of the API?

I certainly acknowledge the value of having a standard, common API for BP, but I am increasingly doubtful that we can design that API quickly.  There doesn't seem to be much point in pushing one out right away that ends up being wrong, and I don't think the need is really urgent or critical.  Let think about it first.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Joseph Ishac
> Sent: Tuesday, April 28, 2009 6:44 PM
> To: [email-masked]; dtn-
> [email-masked]
> Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> 
> So I'm a bit confused.  Why not just have a bpselect() in addition to
> your bpsocket(), etc?  I thought the logic in this subthread was to have
> an API that reflected that of the socket system calls; not actually use
> the existing calls directly.
> 
> -Joseph
> 
> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
> > Wes, I don't think anybody's claiming that it would be difficult to
> emulate the behavior of select() for a socket-like bundling API.  The issue
> is whether or not the standard select() system call that ships with your
> operating system will operate correctly when you provide the value returned
> by bpsocket() [or whatever] to it as one of the file descriptors in its
> readFdSet.
> >
> > For example, the underlying BP endpoint open() [or whatever] may not even
> return an integer.  If it is, it may not be an actual file descriptor.
> Etc.
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Eddy, Wesley M. (GRC-MS00)[Verizon]
> [mailto:[email-masked]]
> > > Sent: Tuesday, April 28, 2009 4:51 PM
> > > To: [email-masked]; Burleigh, Scott C
> > > Cc: [email-masked]
> > > Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat
> application)
> > >
> > > I don't understand why multiple replies have indicated that the
> select()
> > > behavior would be somehow difficult to emulate for a socket-like
> > > bundling API.  If the bundle agent is holding payloads waiting to be
> > > delivered, the read test passes.  If it has free storage, the write
> test
> > > passes, and the error test would possibly not be relevant.  It doesn't
> > > seem to be all that complicated ... you block for the specified amount
> > > of time until one of the test conditions comes true or the time runs
> out,
> > > and then return.
> > >
> > > What am I missing?
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: Joseph Ishac <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 29 Apr 2009 08:19:09 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Okay, so now I'm confused.  Are we saying that DTN developers will get a lot of cognitive leverage from using API functions that operate on things that are called sockets (or socket-like objects of some sort) but aren't really sockets at all, can't be handled as file descriptors the way real sockets can, and in fact are very different from sockets?  More than from using API functions and structures whose names map to concepts in the specification of the protocol they're trying to use?

Well, maybe they will.  I think we've got kind of a corollary to the duck principle at work here, though.  If it doesn't look like a duck, doesn't walk like a duck, and doesn't quack like a duck, it's not a duck.  If it's not a duck, how much real benefit do we get from calling it a duck?

The functionality of BP-based data interchange differs in some significant ways from the functionality provided by file descriptors.  Why confuse the neophyte DTN developer by pretending otherwise?  And at the same time, isn't trying to jam all BP functionality into the "sockets" model kind of Procrustean?  There's stuff that just doesn't fit; do we leave it out of the API?

I certainly acknowledge the value of having a standard, common API for BP, but I am increasingly doubtful that we can design that API quickly.  There doesn't seem to be much point in pushing one out right away that ends up being wrong, and I don't think the need is really urgent or critical.  Let think about it first.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Joseph Ishac
> Sent: Tuesday, April 28, 2009 6:44 PM
> To: [email-masked]; dtn-
> [email-masked]
> Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> 
> So I'm a bit confused.  Why not just have a bpselect() in addition to
> your bpsocket(), etc?  I thought the logic in this subthread was to have
> an API that reflected that of the socket system calls; not actually use
> the existing calls directly.
> 
> -Joseph
> 
> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
> > Wes, I don't think anybody's claiming that it would be difficult to
> emulate the behavior of select() for a socket-like bundling API.  The issue
> is whether or not the standard select() system call that ships with your
> operating system will operate correctly when you provide the value returned
> by bpsocket() [or whatever] to it as one of the file descriptors in its
> readFdSet.
> >
> > For example, the underlying BP endpoint open() [or whatever] may not even
> return an integer.  If it is, it may not be an actual file descriptor.
> Etc.
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Eddy, Wesley M. (GRC-MS00)[Verizon]
> [mailto:[email-masked]]
> > > Sent: Tuesday, April 28, 2009 4:51 PM
> > > To: [email-masked]; Burleigh, Scott C
> > > Cc: [email-masked]
> > > Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat
> application)
> > >
> > > I don't understand why multiple replies have indicated that the
> select()
> > > behavior would be somehow difficult to emulate for a socket-like
> > > bundling API.  If the bundle agent is holding payloads waiting to be
> > > delivered, the read test passes.  If it has free storage, the write
> test
> > > passes, and the error test would possibly not be relevant.  It doesn't
> > > seem to be all that complicated ... you block for the specified amount
> > > of time until one of the test conditions comes true or the time runs
> out,
> > > and then return.
> > >
> > > What am I missing?
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Greg Troxel <[email-masked]>
To: "Eddy\, Wesley M. \(GRC-MS00\)\[Verizon\]" <[email-masked]>
Date: Wed, 29 Apr 2009 11:05:56 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API

--=-=-=

"Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]> writes:

> I don't understand why multiple replies have indicated that the select()
> behavior would be somehow difficult to emulate for a socket-like
> bundling API.  If the bundle agent is holding payloads waiting to be
> delivered, the read test passes.  If it has free storage, the write test
> passes, and the error test would possibly not be relevant.  It doesn't
> seem to be all that complicated ... you block for the specified amount
> of time until one of the test conditions comes true or the time runs out,
> and then return.
>
> What am I missing?

That was my first reaction also, but I think the underlying issue that
isn't being talked about is that some (me, and I'm guessing Wes is also
in this category) expect that extending the sockets API to handle AF_BP
would be a first-class in-kernel implementation, and then if one wanted
to run a BPA in user space that would somehow have a private
registration to the kernel.  So the select system call would call the
select/poll implementation for this address family in the kernel, which
would do the right thing; structurally this would be no different from
how select works on TCP in 4.4BSD-derived kernels.  This is perhaps
hard, but certainly doable.

This is similar to how pfkeyv2 and IKE works - user programs do pfkey
operations, and the fact that IKE, which ultimately services those, is
not in kernel is hidden from the pfkey-using program.

I think others who talk about bpsend and bpselect are expecting that
there is a sockets-like API that isn't really sockets, and that it's in
a user-space library talking to some other user-space program running
the BPA.  In this case the library might multiplex things over a
unix-domain socket that it uses to talk to the BPA, and thus not be able
to hand back a fd number to use with native select.  I can see why that
might seem easier, but it doesn't feel like the path to changing the
world so that BP is the dominant paradigm.

The hard part is handling operations in the DTN api that don't have
natural counterparts in sockets.  registration is kind of like listen,
but then there's the question of unlisten vs implicit teardown from
closing the socket.  Then there is persistent registration that lasts
while the socket is closed.  The sockets way would seem to be to add a
BP_REGISTER ioctl that you can do on a socket, and to separate "give me
bundles on this registration" from "register this endpoint".

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

Date: Wed, 29 Apr 2009 10:15:22 -0400
From: "Daniel W. Brown" <[email-masked]>
To: Simon Perreault <[email-masked]>
Cc: Kevin Fall <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Simon Perreault wrote:
> Ivancic, William D. (GRC-RHN0) wrote, on 29/04/09 08:17 AM:
>   
>> Dan, We used DTN for 100s of Mbyte and will use DTN for Gbyte bundles for image data from spacecraft.  We should not put any limits or restrictions on anything here - particularly when we don't know how DTN will be used.  So, this requires some real thought.  A jump to something familiar is not necessarily the wise approach.  It may be, but it also may not be if it means that it puts unnecessary restrictions on what can be done.
>>     
>
> It can be done using sockets (and has already been done for other protocols) by
> using mmap().
>
> I see no restriction there.
>   
Can we use memory mapping if the BPA implementation is in-kernel? 
(honest question, I don't know)

What if the app does not have a free contiguous address space large 
enough to map all of the data at once for very large bundles? Is the app 
just out of luck? Might there be environments without a shared memory 
interface between the BPA and the app, but a communication bus does exist?

I'm not trying to bog down in implementation details for the sake of it 
- just providing some possible use cases to think about in the quest for 
requirements. And if providing efficient support for large bundles is or 
becomes a requirement, I think that might have ramifications for the API.

On the other hand, perhaps a general purpose API must contain some 
assumptions and restrictions in order to be effective, and special 
applications will require special-purpose interfaces.

Date: Wed, 29 Apr 2009 15:14:50 +0100
From: Stephen Farrell <[email-masked]>
To: Teemu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Teemu wrote:
 > Personally I'm a big fan of asynchronous networking APIs. It would
appear to
> me that an asynchronous, pub/sub type API would be a much better fit for DTN
> applications than a BSD Sockets type API (the Hotnets 2007 paper by Demmer
> et al. provides nice arguments for it). I'm not sure I see the value of
> trying to force a sockets API to a scenario where it's not a very good fit
> simply because of its familiarity and success in a different type of a
> networking scenario.

I agree. However, that does not mean that its a "bad thing" for a
sockets-like API to exist in addition to a pub/sub API, right? That
way, you're not forced into using either.

As I said, I'd like both to be available if possible.

Stephen.

Date: Wed, 29 Apr 2009 17:01:05 +0300
From: Teemu <[email-masked]>
To: Hans Kruse <[email-masked]>, Simon Perreault <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Hi,

Having worked with a bunch of different applications over DTN, what we¹ve
found is that the normal send/receive types of interactions are often
inadequate. Usually we end up wanting to do things like inspect every bundle
(or all bundles of a specific service) at the application layer, modifying
them and possibly indicating to the underlying DTN layer that the bundle
should be discarded. All this without being an explicit recipient of the
bundles.

Personally I'm a big fan of asynchronous networking APIs. It would appear to
me that an asynchronous, pub/sub type API would be a much better fit for DTN
applications than a BSD Sockets type API (the Hotnets 2007 paper by Demmer
et al. provides nice arguments for it). I'm not sure I see the value of
trying to force a sockets API to a scenario where it's not a very good fit
simply because of its familiarity and success in a different type of a
networking scenario.

Cheers,
-Teemu

On 28.4.2009 21.29, "Hans Kruse" <[email-masked]> wrote:

> Agreed -- and we have someone working on it .... so maybe "please send
> requirements"?
> 
> On Apr 28, 2009, at 2:21 PM, Simon Perreault wrote:
> 
>> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
>>> This should be written to run on BOTH ION and DTN-2
>> 
>> Please pardon the thread hijacking...
>> 
>> We need a DTN API.
>> 
>> This is especially important in the case of DTN network management because
>> we're
>> shortly going to have a set of small utilities that need to behave similarly
>> everywhere. These utilities should be source-compatible with different DTN
>> implementations.
>> 
>> The DTN API would be analogous to the BSD API that made socket programming so
>> successful. Perhaps it could even be an extension of the BSD API.
>> 
>> The document would specify C function interfaces. Implementation would be
>> left
>> unspecified. For example, a DTN API library for DTN-2 could take the
>> parameters
>> and transform that into a RPC to the dtnd program.
>> 
>> Is anything stopping this besides the usual "Please send text"?
>> 
>> Thanks,
>> Simon

From: Hans Kruse <[email-masked]>
To: <[email-masked]>
Date: Wed, 29 Apr 2009 09:21:00 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Bundle Security Protocol Implementation

--Apple-Mail-4-711055148
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Nasir,
the Java implementation you refer to has not been supported in a long  
time as we have been focusing on the NASA ION code base.  I would  
suggest that either ION or DTN2 would be the best place to start from.

On Apr 29, 2009, at 7:59 AM, <[email-masked]> wrote:

> Hi All,
>
> We at Surrey university are implementing the Bundle Security  
> Protocol Specification internet draft .. The implementation will  
> have following features:
>
> BSP Features:
> - Support for Authentication via BAB, PIB
> - Support for confidentiality via PCB
> - Support for compulsory cipher suites
>
> We are going to use "BP reference implementation by Ohio university  
> in Java". We thought that some may be working on security  
> implementation. So, any one with any progress, or want to give some  
> suggestion. All inputs will be realy appreciated.
>
> "Most important how we should merge this with Bundle Protocol  
> Implementation" ..
>
> regards,
> Nasir
> University of Surrey
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

--Apple-Mail-4-711055148
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Nasir,<div>the Java =
implementation you refer to has not been supported in a long time as we =
have been focusing on the NASA ION code base. &nbsp;I would suggest that =
either ION or DTN2 would be the best place to start =
from.</div><div><br><div><div>On Apr 29, 2009, at 7:59 AM, &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"> <div> <!-- Converted from text/plain format --><p><font =
size=3D"2">Hi All,<br> <br> We at Surrey university are implementing the =
Bundle Security Protocol Specification internet draft .. The =
implementation will have following features:<br> <br> BSP Features:<br> =
- Support for Authentication via BAB, PIB<br> - Support for =
confidentiality via PCB<br> - Support for compulsory cipher suites<br> =
<br> We are going to use "BP reference implementation by Ohio university =
in Java". We thought that some may be working on security =
implementation. So, any one with any progress, or want to give some =
suggestion. All inputs will be realy appreciated.<br> <br> "Most =
important how we should merge this with Bundle Protocol Implementation" =
..<br> <br> regards,<br> Nasir<br> University of Surrey<br> </font> </p> =
</div> _______________________________________________<br>dtn-interest =
mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-4-711055148--

Date: Wed, 29 Apr 2009 09:14:29 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

A proposal: rather than quibble about points such as what
"like a socket" means, let's see some strawman proposals for
the APIs people are thinking about.  Is one week enough time
for everyone to flesh out their proposal to first approximation?

-Dan

Date: Wed, 29 Apr 2009 08:30:32 -0400
From: Simon Perreault <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: Kevin Fall <[email-masked]>, "Daniel W. Brown" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Ivancic, William D. (GRC-RHN0) wrote, on 29/04/09 08:17 AM:
> Dan, We used DTN for 100s of Mbyte and will use DTN for Gbyte bundles for image data from spacecraft.  We should not put any limits or restrictions on anything here - particularly when we don't know how DTN will be used.  So, this requires some real thought.  A jump to something familiar is not necessarily the wise approach.  It may be, but it also may not be if it means that it puts unnecessary restrictions on what can be done.

It can be done using sockets (and has already been done for other protocols) by
using mmap().

I see no restriction there.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Daniel W. Brown" <[email-masked]>, Kevin Fall <[email-masked]>
Date: Wed, 29 Apr 2009 07:17:34 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

> [email-masked]] On Behalf Of Daniel W.
> Brown
> 
> I wonder if the potentially large size of Application Protocol Data
> Units for BP (compared to UDP datagram payloads) might call for
> allowing
> incremental access (or snaplen-limited access) to the bundle contents
> by
> the application.  Take for example a sniffing app (e.g. wireshark) that
> might be generally interested only in pieces of the bundle data
> (perhaps
> extension blocks and the first 1k of the payload), perhaps for all
> bundles.  Might it be worth considering a requirement that the API not
> force all interested (registered) apps to swallow all APDU's whole
> regardless of size?  Or are bundles just generally relied on to not be
> large in practice?
> 
> Dan

Dan, We used DTN for 100s of Mbyte and will use DTN for Gbyte bundles for image data from spacecraft.  We should not put any limits or restrictions on anything here - particularly when we don't know how DTN will be used.  So, this requires some real thought.  A jump to something familiar is not necessarily the wise approach.  It may be, but it also may not be if it means that it puts unnecessary restrictions on what can be done.

/will

Content-class: urn:content-classes:message
Date: Wed, 29 Apr 2009 12:59:04 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Bundle Security Protocol Implementation

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9C8C1.E48928D5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

We at Surrey university are implementing the Bundle Security Protocol =
Specification internet draft .. The implementation will have following =
features:

BSP Features:=20
- Support for Authentication via BAB, PIB=20
- Support for confidentiality via PCB
- Support for compulsory cipher suites=20

We are going to use "BP reference implementation by Ohio university in =
Java". We thought that some may be working on security implementation. =
So, any one with any progress, or want to give some suggestion. All =
inputs will be realy appreciated.=20

"Most important how we should merge this with Bundle Protocol =
Implementation" ..=20

regards,
Nasir
University of Surrey

------_=_NextPart_001_01C9C8C1.E48928D5
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>Bundle Security Protocol Implementation</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi All,<BR>
<BR>
We at Surrey university are implementing the Bundle Security Protocol =
Specification internet draft .. The implementation will have following =
features:<BR>
<BR>
BSP Features:<BR>
- Support for Authentication via BAB, PIB<BR>
- Support for confidentiality via PCB<BR>
- Support for compulsory cipher suites<BR>
<BR>
We are going to use &quot;BP reference implementation by Ohio university =
in Java&quot;. We thought that some may be working on security =
implementation. So, any one with any progress, or want to give some =
suggestion. All inputs will be realy appreciated.<BR>
<BR>
&quot;Most important how we should merge this with Bundle Protocol =
Implementation&quot; ..<BR>
<BR>
regards,<BR>
Nasir<BR>
University of Surrey<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9C8C1.E48928D5--

Date: Wed, 29 Apr 2009 07:30:17 -0400
From: "Daniel W. Brown" <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

I wonder if the potentially large size of Application Protocol Data 
Units for BP (compared to UDP datagram payloads) might call for allowing 
incremental access (or snaplen-limited access) to the bundle contents by 
the application.  Take for example a sniffing app (e.g. wireshark) that 
might be generally interested only in pieces of the bundle data (perhaps 
extension blocks and the first 1k of the payload), perhaps for all 
bundles.  Might it be worth considering a requirement that the API not 
force all interested (registered) apps to swallow all APDU's whole 
regardless of size?  Or are bundles just generally relied on to not be 
large in practice?

Dan

Kevin Fall wrote:
> We did some work on this a while ago, ultimately advocating for a 
> pub/sub style API.  If, as I am beginning to believe, we evolve to be 
> handling "content" more directly, I believe this will be the direction 
> to go.
>
> - K
>
>
> On Apr 28, 2009, at Apr 2811:29 AMPDT, Hans Kruse wrote:
>
>> Agreed -- and we have someone working on it .... so maybe "please 
>> send requirements"?
>>
>> On Apr 28, 2009, at 2:21 PM, Simon Perreault wrote:
>>
>>> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
>>>> This should be written to run on BOTH ION and DTN-2
>>>
>>> Please pardon the thread hijacking...
>>>
>>> We need a DTN API.
>>>
>>> This is especially important in the case of DTN network management 
>>> because we're
>>> shortly going to have a set of small utilities that need to behave 
>>> similarly
>>> everywhere. These utilities should be source-compatible with 
>>> different DTN
>>> implementations.
>>>
>>> The DTN API would be analogous to the BSD API that made socket 
>>> programming so
>>> successful. Perhaps it could even be an extension of the BSD API.
>>>
>>> The document would specify C function interfaces. Implementation 
>>> would be left
>>> unspecified. For example, a DTN API library for DTN-2 could take the 
>>> parameters
>>> and transform that into a RPC to the dtnd program.
>>>
>>> Is anything stopping this besides the usual "Please send text"?
>>>
>>> Thanks,
>>> Simon
>>> -- 
>>> STUN/TURN server    --> http://numb.viagenie.ca
>>> Interplanetary news --> http://reeves.viagenie.ca
>>> vCard 4.0           --> http://www.vcarddav.org
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked] 
>>> <mailto:[email-masked]>
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> Hans Kruse, Professor
>> J. Warren McClure School of Information and Telecommunication Systems
>> Adjunct Associate Professor of Electrical Engineering and Computer 
>> Science
>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>> 740-593-4891 voice, 740-593-4889 fax
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked] 
>> <mailto:[email-masked]>
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

Date: Wed, 29 Apr 2009 10:48:07 +0100
From: Stephen Farrell <[email-masked]>
To: "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

My general take on this is that I'd also like the
option of a socket-like API as a way to more easily
port existing apps. to run (to the extent they can)
in a DTN, and as a way to introduce developers that
know the API to DTN.

But I'd also like to see work on a "more modern" API
as well, that'd allow new apps to make better use of
the BP.

I don't see a conflict in having both options, though
it is more work.

S.

PS: For LTP, I did exactly the sockets-like thing,
though of course LTP is much simpler, but it worked
just fine. Feel free to scoff at my limited and
somewhat archaic code if it helps here:-) [1]

[1] https://down.dsg.cs.tcd.ie/ltplib/doc/html/ltp_8h.html

Date: Wed, 29 Apr 2009 03:11:41 -0400
From: "G. Clark" <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>, Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Thanks for the reply :)

Comments inline:

Kevin Fall wrote:
>
> On Apr 28, 2009, at Apr 2810:05 PMPDT, G. Clark wrote:
>
>> Comments inline:
>>
>> Kevin Fall wrote:
>>> Perhaps I also missed something, but what exactly is the motivation  
>>> for trying to go with a sockets-like API (designed for connection- 
>>> oriented TCP type protocols) for something like DTN that is rather 
>>> a  different beast?  Just familiarity?
>>>
>>>
>> Wait.  Sockets weren't necessarily designed for connection-oriented 
>> protocols; UDP works just fine.
>
> please see the "Overview" page of this document:
> http://www.eecs.berkeley.edu/Pubs/TechRpts/1983/CSD-83-146.pdf
> the primary focus was on dealing with the virtual circuit type of 
> abstraction.
>
I never knew that; in retrospect, I suppose trying to tell somebody from 
Berkeley what BSD sockets were / weren't designed for was a bad idea :)
> and I didn't say it doesn't work for UDP.   (although it works poorly 
> in the sense that PMTU discovery isn't there, and applications 
> manipulate addresses, and tear-away writes aren't there and fill-on 
> reads aren't really there exactly, lack of security aspects)... but alas.
>
>> Matter of fact, I'd say that DTN using the sockets API with UDP 
>> constructs would be a simple solution that would make DTN almost 
>> immediately accessible to people trying to pick it up and use it.  
>> Want to code a DTN application?  Call socket() with AF_DTN and 
>> SOCK_DGRAM, and it magically works.  This would be a Good Thing (tm).
>
> It doesn't just magically work.  Lots of apps have built in timers, 
> address manipulation, other "reliable" protocols when choosing UDP, 
> etc.  There may be some value of having a sockets-like API, but I 
> think it would be (quite) unfortunate if we didn't set our sights 
> rather higher.  
I never said it magically worked *perfectly*.  It does live up to the 
80/20 rule, though: 80% of your users are only ever going to use 20% of 
your functionality.
> Further, as described in the paper I mentioned earlier, its sort of 
> nice to not have to bind the application directly to the protocol but 
> instead allow it to be done separately.  This takes some attention to 
> detail, but would appear to be a pretty powerful concept.
I'm not opposed to the concept at all; it looks like this exists already 
with the idea of endpoints, and it'd be even closer if endpoints were to 
map to something more than application-level sockets (which was brought 
up on this list previously, as I recall).

One thing that scares me, though, is this part of the document: "The 
most challenging part of implementing this API in a DTN context is the 
name resolution. However, given that many DTNs are small in scale, we 
could proactively flood local name bindings throughout the network to 
avoid needing a potentially long round trip to obtain the location of 
where to find a publication, and unknown name lookups would be routed to 
a well-known gateway node."

Also, what would the overhead of an implementation of this new idea be 
like as opposed to sockets?
>
>>
>>
>> So yes, familiarity should be a huge consideration here; we're 
>> counting on other people hoping to write applications with this 
>> library, right?  That means that it's a plus if there's minimal 
>> effort involved in figuring out the library.
>
> I suspect that most people writing network applications today are not 
> writing to the sockets API.  There are lots of middleware/RPC/etc 
> systems that are easier to reason about.
>
I know there are many applications that use some kind of middleware for 
their socket implementation (e.g. boost libraries), but just as many use 
either sockets or some kind of custom-built wrapper for sockets.  Either 
way, it'd be a lot easier to port all of those APIs / middlewares / etc 
to use DTN if DTN used a socket-like API.  On the other hand, if we 
picked one of the middleware solutions, we'd probably alienate every 
other solution that wasn't like that one.  Sockets seems to me to be the 
one thing many (most?) existing APIs have in common, and that's exactly 
why I'm trying to argue that sockets would be a workable option for a 
DTN API.
> When I worked with the BSD people, Mike Karels once explained sockets 
> to a group this way:  "sockets are like pipes where you do your own 
> plumbing".
>
I like doing my own plumbing because I (usually) know what I'm getting 
into.  It also helps that there are tons of do-it-yourself guides on the 
web already.
> - K
>
>>
>>> On Apr 28, 2009, at Apr 289:18 PMPDT, Scott C. Burleigh wrote:
>>>
>>>
>>>> Okay, so now I'm confused.  Are we saying that DTN developers are  
>>>> going
>>>> to get a lot of cognitive leverage from using API functions that  
>>>> operate
>>>> on things that are called sockets (or socket-like objects of some  
>>>> sort)
>>>> but aren't really sockets at all, can't be handled as file descriptors
>>>> the way real sockets can, and in fact are very different from sockets?
>>>> More than from using API functions and structures whose names map to
>>>> concepts in the specification of the protocol they're trying to use?
>>>> Well, maybe so.  I didn't realize this was what we were aiming for.
>>>>
>>>>
>> It would be a plus, for reasons mentioned above.
>>
>> Also, one of the big questions in this thread is: what exactly *are* 
>> we aiming for here?  I doubt we'll get much further (read: we'll be 
>> stuck here forever arguing the details of an interface that exists 
>> differently in everybody's individual imagination) until we figure 
>> out what we want this API to do, let alone how we want the details to 
>> work.
Reading back over that sentence, it came out a bit stronger than I meant 
it to. . . but I do think that figuring out a layer / level for this API 
to operate would be good.  Do we have to worry about the hardware 
requirements of objects in space when we write this?  Is this for 
testing only?  etc.
>>>> Joseph Ishac wrote:
>>>>
>>>>> So I'm a bit confused.  Why not just have a bpselect() in addition to
>>>>> your bpsocket(), etc?  I thought the logic in this subthread was 
>>>>> to  have
>>>>> an API that reflected that of the socket system calls; not 
>>>>> actually  use
>>>>> the existing calls directly.
>>>>>
>>>>> -Joseph
>>>>>
>>>>> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>>>>>
>>>>>
>>>>>> Wes, I don't think anybody's claiming that it would be difficult  
>>>>>> to emulate the behavior of select() for a socket-like bundling  
>>>>>> API.  The issue is whether or not the standard select() system  
>>>>>> call that ships with your operating system will operate 
>>>>>> correctly  when you provide the value returned by bpsocket() [or 
>>>>>> whatever] to  it as one of the file descriptors in its readFdSet.
>>>>>>
>>>>>> For example, the underlying BP endpoint open() [or whatever] may  
>>>>>> not even return an integer.  If it is, it may not be an actual  
>>>>>> file descriptor.  Etc.
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] 
>>>>>>> [mailto:[email-masked] ]
>>>>>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>>>>>> To: [email-masked]; Burleigh, Scott C
>>>>>>> Cc: [email-masked]
>>>>>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat  
>>>>>>> application)
>>>>>>>
>>>>>>> I don't understand why multiple replies have indicated that the  
>>>>>>> select()
>>>>>>> behavior would be somehow difficult to emulate for a socket-like
>>>>>>> bundling API.  If the bundle agent is holding payloads waiting 
>>>>>>> to  be
>>>>>>> delivered, the read test passes.  If it has free storage, the  
>>>>>>> write test
>>>>>>> passes, and the error test would possibly not be relevant.  It  
>>>>>>> doesn't
>>>>>>> seem to be all that complicated ... you block for the specified  
>>>>>>> amount
>>>>>>> of time until one of the test conditions comes true or the time  
>>>>>>> runs out,
>>>>>>> and then return.
>>>>>>>
>>>>>>> What am I missing?
>>>>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>> Regards,
>> Gilbert Clark
>> Grad Student
>> Ohio University
>>
>
Regards,
Gilbert Clark
Grad Student
Ohio University

From: Kevin Fall <[email-masked]>
To: "G. Clark" <[email-masked]>
Date: Tue, 28 Apr 2009 22:35:07 -0700
Cc: "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>, Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

On Apr 28, 2009, at Apr 2810:05 PMPDT, G. Clark wrote:

> Comments inline:
>
> Kevin Fall wrote:
>> Perhaps I also missed something, but what exactly is the  
>> motivation  for trying to go with a sockets-like API (designed for  
>> connection- oriented TCP type protocols) for something like DTN  
>> that is rather a  different beast?  Just familiarity?
>>
>>
> Wait.  Sockets weren't necessarily designed for connection-oriented  
> protocols; UDP works just fine.

please see the "Overview" page of this document:
http://www.eecs.berkeley.edu/Pubs/TechRpts/1983/CSD-83-146.pdf
the primary focus was on dealing with the virtual circuit type of  
abstraction.

and I didn't say it doesn't work for UDP.   (although it works poorly  
in the sense that PMTU discovery isn't there, and applications  
manipulate addresses, and tear-away writes aren't there and fill-on  
reads aren't really there exactly, lack of security aspects)... but  
alas.

> Matter of fact, I'd say that DTN using the sockets API with UDP  
> constructs would be a simple solution that would make DTN almost  
> immediately accessible to people trying to pick it up and use it.   
> Want to code a DTN application?  Call socket() with AF_DTN and  
> SOCK_DGRAM, and it magically works.  This would be a Good Thing (tm).

It doesn't just magically work.  Lots of apps have built in timers,  
address manipulation, other "reliable" protocols when choosing UDP,  
etc.  There may be some value of having a sockets-like API, but I  
think it would be (quite) unfortunate if we didn't set our sights  
rather higher.  Further, as described in the paper I mentioned  
earlier, its sort of nice to not have to bind the application directly  
to the protocol but instead allow it to be done separately.  This  
takes some attention to detail, but would appear to be a pretty  
powerful concept.

>
>
> So yes, familiarity should be a huge consideration here; we're  
> counting on other people hoping to write applications with this  
> library, right?  That means that it's a plus if there's minimal  
> effort involved in figuring out the library.

I suspect that most people writing network applications today are not  
writing to the sockets API.  There are lots of middleware/RPC/etc  
systems that are easier to reason about.

When I worked with the BSD people, Mike Karels once explained sockets  
to a group this way:  "sockets are like pipes where you do your own  
plumbing".

- K

>
>> On Apr 28, 2009, at Apr 289:18 PMPDT, Scott C. Burleigh wrote:
>>
>>
>>> Okay, so now I'm confused.  Are we saying that DTN developers are   
>>> going
>>> to get a lot of cognitive leverage from using API functions that   
>>> operate
>>> on things that are called sockets (or socket-like objects of some   
>>> sort)
>>> but aren't really sockets at all, can't be handled as file  
>>> descriptors
>>> the way real sockets can, and in fact are very different from  
>>> sockets?
>>> More than from using API functions and structures whose names map to
>>> concepts in the specification of the protocol they're trying to use?
>>> Well, maybe so.  I didn't realize this was what we were aiming for.
>>>
>>>
> It would be a plus, for reasons mentioned above.
>
> Also, one of the big questions in this thread is: what exactly *are*  
> we aiming for here?  I doubt we'll get much further (read: we'll be  
> stuck here forever arguing the details of an interface that exists  
> differently in everybody's individual imagination) until we figure  
> out what we want this API to do, let alone how we want the details  
> to work.
>>> Joseph Ishac wrote:
>>>
>>>> So I'm a bit confused.  Why not just have a bpselect() in  
>>>> addition to
>>>> your bpsocket(), etc?  I thought the logic in this subthread was  
>>>> to  have
>>>> an API that reflected that of the socket system calls; not  
>>>> actually  use
>>>> the existing calls directly.
>>>>
>>>> -Joseph
>>>>
>>>> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>>>>
>>>>
>>>>> Wes, I don't think anybody's claiming that it would be  
>>>>> difficult  to emulate the behavior of select() for a socket-like  
>>>>> bundling  API.  The issue is whether or not the standard  
>>>>> select() system  call that ships with your operating system will  
>>>>> operate correctly  when you provide the value returned by  
>>>>> bpsocket() [or whatever] to  it as one of the file descriptors  
>>>>> in its readFdSet.
>>>>>
>>>>> For example, the underlying BP endpoint open() [or whatever]  
>>>>> may  not even return an integer.  If it is, it may not be an  
>>>>> actual  file descriptor.  Etc.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked] 
>>>>>>  ]
>>>>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>>>>> To: [email-masked]; Burleigh, Scott C
>>>>>> Cc: [email-masked]
>>>>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat   
>>>>>> application)
>>>>>>
>>>>>> I don't understand why multiple replies have indicated that  
>>>>>> the  select()
>>>>>> behavior would be somehow difficult to emulate for a socket-like
>>>>>> bundling API.  If the bundle agent is holding payloads waiting  
>>>>>> to  be
>>>>>> delivered, the read test passes.  If it has free storage, the   
>>>>>> write test
>>>>>> passes, and the error test would possibly not be relevant.  It   
>>>>>> doesn't
>>>>>> seem to be all that complicated ... you block for the  
>>>>>> specified  amount
>>>>>> of time until one of the test conditions comes true or the  
>>>>>> time  runs out,
>>>>>> and then return.
>>>>>>
>>>>>> What am I missing?
>>>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> Regards,
> Gilbert Clark
> Grad Student
> Ohio University
>

Date: Wed, 29 Apr 2009 01:05:35 -0400
From: "G. Clark" <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Comments inline:

Kevin Fall wrote:
> Perhaps I also missed something, but what exactly is the motivation  
> for trying to go with a sockets-like API (designed for connection- 
> oriented TCP type protocols) for something like DTN that is rather a  
> different beast?  Just familiarity?
>
>   
Wait.  Sockets weren't necessarily designed for connection-oriented 
protocols; UDP works just fine.  Matter of fact, I'd say that DTN using 
the sockets API with UDP constructs would be a simple solution that 
would make DTN almost immediately accessible to people trying to pick it 
up and use it.  Want to code a DTN application?  Call socket() with 
AF_DTN and SOCK_DGRAM, and it magically works.  This would be a Good 
Thing (tm).

So yes, familiarity should be a huge consideration here; we're counting 
on other people hoping to write applications with this library, right?  
That means that it's a plus if there's minimal effort involved in 
figuring out the library.
> On Apr 28, 2009, at Apr 289:18 PMPDT, Scott C. Burleigh wrote:
>
>   
>> Okay, so now I'm confused.  Are we saying that DTN developers are  
>> going
>> to get a lot of cognitive leverage from using API functions that  
>> operate
>> on things that are called sockets (or socket-like objects of some  
>> sort)
>> but aren't really sockets at all, can't be handled as file descriptors
>> the way real sockets can, and in fact are very different from sockets?
>> More than from using API functions and structures whose names map to
>> concepts in the specification of the protocol they're trying to use?
>> Well, maybe so.  I didn't realize this was what we were aiming for.
>>
>>     
It would be a plus, for reasons mentioned above.

Also, one of the big questions in this thread is: what exactly *are* we 
aiming for here?  I doubt we'll get much further (read: we'll be stuck 
here forever arguing the details of an interface that exists differently 
in everybody's individual imagination) until we figure out what we want 
this API to do, let alone how we want the details to work.
>> Joseph Ishac wrote:
>>     
>>> So I'm a bit confused.  Why not just have a bpselect() in addition to
>>> your bpsocket(), etc?  I thought the logic in this subthread was to  
>>> have
>>> an API that reflected that of the socket system calls; not actually  
>>> use
>>> the existing calls directly.
>>>
>>> -Joseph
>>>
>>> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>>>
>>>       
>>>> Wes, I don't think anybody's claiming that it would be difficult  
>>>> to emulate the behavior of select() for a socket-like bundling  
>>>> API.  The issue is whether or not the standard select() system  
>>>> call that ships with your operating system will operate correctly  
>>>> when you provide the value returned by bpsocket() [or whatever] to  
>>>> it as one of the file descriptors in its readFdSet.
>>>>
>>>> For example, the underlying BP endpoint open() [or whatever] may  
>>>> not even return an integer.  If it is, it may not be an actual  
>>>> file descriptor.  Etc.
>>>>
>>>> Scott
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked] 
>>>>> ]
>>>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>>>> To: [email-masked]; Burleigh, Scott C
>>>>> Cc: [email-masked]
>>>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat  
>>>>> application)
>>>>>
>>>>> I don't understand why multiple replies have indicated that the  
>>>>> select()
>>>>> behavior would be somehow difficult to emulate for a socket-like
>>>>> bundling API.  If the bundle agent is holding payloads waiting to  
>>>>> be
>>>>> delivered, the read test passes.  If it has free storage, the  
>>>>> write test
>>>>> passes, and the error test would possibly not be relevant.  It  
>>>>> doesn't
>>>>> seem to be all that complicated ... you block for the specified  
>>>>> amount
>>>>> of time until one of the test conditions comes true or the time  
>>>>> runs out,
>>>>> and then return.
>>>>>
>>>>> What am I missing?
>>>>>           
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>     
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   
Regards,
Gilbert Clark
Grad Student
Ohio University

Date: Wed, 29 Apr 2009 01:05:35 -0400
From: "G. Clark" <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Comments inline:

Kevin Fall wrote:
> Perhaps I also missed something, but what exactly is the motivation  
> for trying to go with a sockets-like API (designed for connection- 
> oriented TCP type protocols) for something like DTN that is rather a  
> different beast?  Just familiarity?
>
>   
Wait.  Sockets weren't necessarily designed for connection-oriented 
protocols; UDP works just fine.  Matter of fact, I'd say that DTN using 
the sockets API with UDP constructs would be a simple solution that 
would make DTN almost immediately accessible to people trying to pick it 
up and use it.  Want to code a DTN application?  Call socket() with 
AF_DTN and SOCK_DGRAM, and it magically works.  This would be a Good 
Thing (tm).

So yes, familiarity should be a huge consideration here; we're counting 
on other people hoping to write applications with this library, right?  
That means that it's a plus if there's minimal effort involved in 
figuring out the library.
> On Apr 28, 2009, at Apr 289:18 PMPDT, Scott C. Burleigh wrote:
>
>   
>> Okay, so now I'm confused.  Are we saying that DTN developers are  
>> going
>> to get a lot of cognitive leverage from using API functions that  
>> operate
>> on things that are called sockets (or socket-like objects of some  
>> sort)
>> but aren't really sockets at all, can't be handled as file descriptors
>> the way real sockets can, and in fact are very different from sockets?
>> More than from using API functions and structures whose names map to
>> concepts in the specification of the protocol they're trying to use?
>> Well, maybe so.  I didn't realize this was what we were aiming for.
>>
>>     
It would be a plus, for reasons mentioned above.

Also, one of the big questions in this thread is: what exactly *are* we 
aiming for here?  I doubt we'll get much further (read: we'll be stuck 
here forever arguing the details of an interface that exists differently 
in everybody's individual imagination) until we figure out what we want 
this API to do, let alone how we want the details to work.
>> Joseph Ishac wrote:
>>     
>>> So I'm a bit confused.  Why not just have a bpselect() in addition to
>>> your bpsocket(), etc?  I thought the logic in this subthread was to  
>>> have
>>> an API that reflected that of the socket system calls; not actually  
>>> use
>>> the existing calls directly.
>>>
>>> -Joseph
>>>
>>> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>>>
>>>       
>>>> Wes, I don't think anybody's claiming that it would be difficult  
>>>> to emulate the behavior of select() for a socket-like bundling  
>>>> API.  The issue is whether or not the standard select() system  
>>>> call that ships with your operating system will operate correctly  
>>>> when you provide the value returned by bpsocket() [or whatever] to  
>>>> it as one of the file descriptors in its readFdSet.
>>>>
>>>> For example, the underlying BP endpoint open() [or whatever] may  
>>>> not even return an integer.  If it is, it may not be an actual  
>>>> file descriptor.  Etc.
>>>>
>>>> Scott
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked] 
>>>>> ]
>>>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>>>> To: [email-masked]; Burleigh, Scott C
>>>>> Cc: [email-masked]
>>>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat  
>>>>> application)
>>>>>
>>>>> I don't understand why multiple replies have indicated that the  
>>>>> select()
>>>>> behavior would be somehow difficult to emulate for a socket-like
>>>>> bundling API.  If the bundle agent is holding payloads waiting to  
>>>>> be
>>>>> delivered, the read test passes.  If it has free storage, the  
>>>>> write test
>>>>> passes, and the error test would possibly not be relevant.  It  
>>>>> doesn't
>>>>> seem to be all that complicated ... you block for the specified  
>>>>> amount
>>>>> of time until one of the test conditions comes true or the time  
>>>>> runs out,
>>>>> and then return.
>>>>>
>>>>> What am I missing?
>>>>>           
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>     
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   
Regards,
Gilbert Clark
Grad Student
Ohio University

From: Kevin Fall <[email-masked]>
To: [email-masked], "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>
Date: Tue, 28 Apr 2009 21:26:42 -0700
Cc: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Perhaps I also missed something, but what exactly is the motivation  
for trying to go with a sockets-like API (designed for connection- 
oriented TCP type protocols) for something like DTN that is rather a  
different beast?  Just familiarity?

Regarding whether socket() returns a file descriptor, it is system  
dependent.  In Win* it has been a different object.
(see, for example http://www.sockets.com/ 
winsock.htm#Deviation_DataType).

- K

On Apr 28, 2009, at Apr 289:18 PMPDT, Scott C. Burleigh wrote:

> Okay, so now I'm confused.  Are we saying that DTN developers are  
> going
> to get a lot of cognitive leverage from using API functions that  
> operate
> on things that are called sockets (or socket-like objects of some  
> sort)
> but aren't really sockets at all, can't be handled as file descriptors
> the way real sockets can, and in fact are very different from sockets?
> More than from using API functions and structures whose names map to
> concepts in the specification of the protocol they're trying to use?
> Well, maybe so.  I didn't realize this was what we were aiming for.
>
> Joseph Ishac wrote:
>> So I'm a bit confused.  Why not just have a bpselect() in addition to
>> your bpsocket(), etc?  I thought the logic in this subthread was to  
>> have
>> an API that reflected that of the socket system calls; not actually  
>> use
>> the existing calls directly.
>>
>> -Joseph
>>
>> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>>
>>> Wes, I don't think anybody's claiming that it would be difficult  
>>> to emulate the behavior of select() for a socket-like bundling  
>>> API.  The issue is whether or not the standard select() system  
>>> call that ships with your operating system will operate correctly  
>>> when you provide the value returned by bpsocket() [or whatever] to  
>>> it as one of the file descriptors in its readFdSet.
>>>
>>> For example, the underlying BP endpoint open() [or whatever] may  
>>> not even return an integer.  If it is, it may not be an actual  
>>> file descriptor.  Etc.
>>>
>>> Scott
>>>
>>>
>>>> -----Original Message-----
>>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked] 
>>>> ]
>>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>>> To: [email-masked]; Burleigh, Scott C
>>>> Cc: [email-masked]
>>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat  
>>>> application)
>>>>
>>>> I don't understand why multiple replies have indicated that the  
>>>> select()
>>>> behavior would be somehow difficult to emulate for a socket-like
>>>> bundling API.  If the bundle agent is holding payloads waiting to  
>>>> be
>>>> delivered, the read test passes.  If it has free storage, the  
>>>> write test
>>>> passes, and the error test would possibly not be relevant.  It  
>>>> doesn't
>>>> seem to be all that complicated ... you block for the specified  
>>>> amount
>>>> of time until one of the test conditions comes true or the time  
>>>> runs out,
>>>> and then return.
>>>>
>>>> What am I missing?
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: [email-masked], "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>
Date: Tue, 28 Apr 2009 21:26:42 -0700
Cc: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Perhaps I also missed something, but what exactly is the motivation  
for trying to go with a sockets-like API (designed for connection- 
oriented TCP type protocols) for something like DTN that is rather a  
different beast?  Just familiarity?

Regarding whether socket() returns a file descriptor, it is system  
dependent.  In Win* it has been a different object.
(see, for example http://www.sockets.com/ 
winsock.htm#Deviation_DataType).

- K

On Apr 28, 2009, at Apr 289:18 PMPDT, Scott C. Burleigh wrote:

> Okay, so now I'm confused.  Are we saying that DTN developers are  
> going
> to get a lot of cognitive leverage from using API functions that  
> operate
> on things that are called sockets (or socket-like objects of some  
> sort)
> but aren't really sockets at all, can't be handled as file descriptors
> the way real sockets can, and in fact are very different from sockets?
> More than from using API functions and structures whose names map to
> concepts in the specification of the protocol they're trying to use?
> Well, maybe so.  I didn't realize this was what we were aiming for.
>
> Joseph Ishac wrote:
>> So I'm a bit confused.  Why not just have a bpselect() in addition to
>> your bpsocket(), etc?  I thought the logic in this subthread was to  
>> have
>> an API that reflected that of the socket system calls; not actually  
>> use
>> the existing calls directly.
>>
>> -Joseph
>>
>> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>>
>>> Wes, I don't think anybody's claiming that it would be difficult  
>>> to emulate the behavior of select() for a socket-like bundling  
>>> API.  The issue is whether or not the standard select() system  
>>> call that ships with your operating system will operate correctly  
>>> when you provide the value returned by bpsocket() [or whatever] to  
>>> it as one of the file descriptors in its readFdSet.
>>>
>>> For example, the underlying BP endpoint open() [or whatever] may  
>>> not even return an integer.  If it is, it may not be an actual  
>>> file descriptor.  Etc.
>>>
>>> Scott
>>>
>>>
>>>> -----Original Message-----
>>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked] 
>>>> ]
>>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>>> To: [email-masked]; Burleigh, Scott C
>>>> Cc: [email-masked]
>>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat  
>>>> application)
>>>>
>>>> I don't understand why multiple replies have indicated that the  
>>>> select()
>>>> behavior would be somehow difficult to emulate for a socket-like
>>>> bundling API.  If the bundle agent is holding payloads waiting to  
>>>> be
>>>> delivered, the read test passes.  If it has free storage, the  
>>>> write test
>>>> passes, and the error test would possibly not be relevant.  It  
>>>> doesn't
>>>> seem to be all that complicated ... you block for the specified  
>>>> amount
>>>> of time until one of the test conditions comes true or the time  
>>>> runs out,
>>>> and then return.
>>>>
>>>> What am I missing?
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 28 Apr 2009 21:18:50 -0700
From: "Scott C. Burleigh" <[email-masked]>
To: [email-masked], "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Okay, so now I'm confused.  Are we saying that DTN developers are going 
to get a lot of cognitive leverage from using API functions that operate 
on things that are called sockets (or socket-like objects of some sort) 
but aren't really sockets at all, can't be handled as file descriptors 
the way real sockets can, and in fact are very different from sockets?  
More than from using API functions and structures whose names map to 
concepts in the specification of the protocol they're trying to use?  
Well, maybe so.  I didn't realize this was what we were aiming for.

Joseph Ishac wrote:
> So I'm a bit confused.  Why not just have a bpselect() in addition to
> your bpsocket(), etc?  I thought the logic in this subthread was to have
> an API that reflected that of the socket system calls; not actually use
> the existing calls directly.
>
> -Joseph
>
> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>   
>> Wes, I don't think anybody's claiming that it would be difficult to emulate the behavior of select() for a socket-like bundling API.  The issue is whether or not the standard select() system call that ships with your operating system will operate correctly when you provide the value returned by bpsocket() [or whatever] to it as one of the file descriptors in its readFdSet.
>>
>> For example, the underlying BP endpoint open() [or whatever] may not even return an integer.  If it is, it may not be an actual file descriptor.  Etc.
>>
>> Scott
>>
>>     
>>> -----Original Message-----
>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked]]
>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>> To: [email-masked]; Burleigh, Scott C
>>> Cc: [email-masked]
>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
>>>
>>> I don't understand why multiple replies have indicated that the select()
>>> behavior would be somehow difficult to emulate for a socket-like
>>> bundling API.  If the bundle agent is holding payloads waiting to be
>>> delivered, the read test passes.  If it has free storage, the write test
>>> passes, and the error test would possibly not be relevant.  It doesn't
>>> seem to be all that complicated ... you block for the specified amount
>>> of time until one of the test conditions comes true or the time runs out,
>>> and then return.
>>>
>>> What am I missing?

Date: Tue, 28 Apr 2009 21:18:50 -0700
From: "Scott C. Burleigh" <[email-masked]>
To: [email-masked], "dtn-interest@ma ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Okay, so now I'm confused.  Are we saying that DTN developers are going 
to get a lot of cognitive leverage from using API functions that operate 
on things that are called sockets (or socket-like objects of some sort) 
but aren't really sockets at all, can't be handled as file descriptors 
the way real sockets can, and in fact are very different from sockets?  
More than from using API functions and structures whose names map to 
concepts in the specification of the protocol they're trying to use?  
Well, maybe so.  I didn't realize this was what we were aiming for.

Joseph Ishac wrote:
> So I'm a bit confused.  Why not just have a bpselect() in addition to
> your bpsocket(), etc?  I thought the logic in this subthread was to have
> an API that reflected that of the socket system calls; not actually use
> the existing calls directly.
>
> -Joseph
>
> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>   
>> Wes, I don't think anybody's claiming that it would be difficult to emulate the behavior of select() for a socket-like bundling API.  The issue is whether or not the standard select() system call that ships with your operating system will operate correctly when you provide the value returned by bpsocket() [or whatever] to it as one of the file descriptors in its readFdSet.
>>
>> For example, the underlying BP endpoint open() [or whatever] may not even return an integer.  If it is, it may not be an actual file descriptor.  Etc.
>>
>> Scott
>>
>>     
>>> -----Original Message-----
>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked]]
>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>> To: [email-masked]; Burleigh, Scott C
>>> Cc: [email-masked]
>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
>>>
>>> I don't understand why multiple replies have indicated that the select()
>>> behavior would be somehow difficult to emulate for a socket-like
>>> bundling API.  If the bundle agent is holding payloads waiting to be
>>> delivered, the read test passes.  If it has free storage, the write test
>>> passes, and the error test would possibly not be relevant.  It doesn't
>>> seem to be all that complicated ... you block for the specified amount
>>> of time until one of the test conditions comes true or the time runs out,
>>> and then return.
>>>
>>> What am I missing?

From: Kevin Fall <[email-masked]>
To: Charles Woloszynski <[email-masked]>
Date: Tue, 28 Apr 2009 20:13:31 -0700
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--Apple-Mail-6-674606227
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

do you have a pointer to a doc you like there?

Our paper was this one:

www.cs.berkeley.edu/~demmer/papers/api-hotnets07.pdf

- K

On Apr 28, 2009, at Apr 285:51 PMPDT, Charles Woloszynski wrote:

> Does it make sense to look at the DDS APIs?  I think that came from  
> OMG.org
>
>
> Charlie
>
> Sent from my iPhone
>
> On Apr 28, 2009, at 8:12 PM, Kevin Fall <[email-masked]> wrote:
>
>> We did some work on this a while ago, ultimately advocating for a  
>> pub/sub style API.  If, as I am beginning to believe, we evolve to  
>> be handling "content" more directly, I believe this will be the  
>> direction to go.
>>
>> - K
>>
>>
>> On Apr 28, 2009, at Apr 2811:29 AMPDT, Hans Kruse wrote:
>>
>>> Agreed -- and we have someone working on it .... so maybe "please  
>>> send requirements"?
>>>
>>> On Apr 28, 2009, at 2:21 PM, Simon Perreault wrote:
>>>
>>>> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
>>>>> This should be written to run on BOTH ION and DTN-2
>>>>
>>>> Please pardon the thread hijacking...
>>>>
>>>> We need a DTN API.
>>>>
>>>> This is especially important in the case of DTN network  
>>>> management because we're
>>>> shortly going to have a set of small utilities that need to  
>>>> behave similarly
>>>> everywhere. These utilities should be source-compatible with  
>>>> different DTN
>>>> implementations.
>>>>
>>>> The DTN API would be analogous to the BSD API that made socket  
>>>> programming so
>>>> successful. Perhaps it could even be an extension of the BSD API.
>>>>
>>>> The document would specify C function interfaces. Implementation  
>>>> would be left
>>>> unspecified. For example, a DTN API library for DTN-2 could take  
>>>> the parameters
>>>> and transform that into a RPC to the dtnd program.
>>>>
>>>> Is anything stopping this besides the usual "Please send text"?
>>>>
>>>> Thanks,
>>>> Simon
>>>> -- 
>>>> STUN/TURN server    --> http://numb.viagenie.ca
>>>> Interplanetary news --> http://reeves.viagenie.ca
>>>> vCard 4.0           --> http://www.vcarddav.org
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>> Hans Kruse, Professor
>>> J. Warren McClure School of Information and Telecommunication  
>>> Systems
>>> Adjunct Associate Professor of Electrical Engineering and Computer  
>>> Science
>>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>>> 740-593-4891 voice, 740-593-4889 fax
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-6-674606227
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">do you have a pointer to a doc =
you like there?<div><br></div><div>Our paper was this =
one:</div><div><br></div><div><a =
href=3D"http://www.cs.berkeley.edu/~demmer/papers/api-hotnets07.pdf">www.c=
s.berkeley.edu/~demmer/papers/api-hotnets07.pdf</a>&nbsp;</div><div><br></=
div><div>- K</div><div><br></div><div><br><div><div>On Apr 28, 2009, at =
Apr 285:51 PMPDT, Charles Woloszynski wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
bgcolor=3D"#FFFFFF"><div>Does it make sense to look at the DDS APIs? =
&nbsp;I think that came from =
OMG.org</div><div><br></div><div><br>Charlie<div><br>Sent from my =
iPhone</div></div><div><br>On Apr 28, 2009, at 8:12 PM, Kevin Fall =
&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>> =
wrote:<br><br></div><div></div><blockquote type=3D"cite"><div>We did =
some work on this a while ago, ultimately advocating for a pub/sub style =
API. &nbsp;If, as I am beginning to believe, we evolve to be handling =
"content" more directly, I believe this will be the direction to =
go.<div><br></div><div>- K</div><div><br></div><div><br><div><div>On Apr =
28, 2009, at Apr 2811:29 AMPDT, Hans Kruse wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Agreed -- and we have someone =
working on it .... so maybe "please send =
requirements"?<div><br><div><div>On Apr 28, 2009, at 2:21 PM, Simon =
Perreault wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 =
01:54 PM:<br><blockquote type=3D"cite">This should be written to run on =
BOTH ION and DTN-2<br></blockquote><br>Please pardon the thread =
hijacking...<br><br>We need a DTN API.<br><br>This is especially =
important in the case of DTN network management because we're<br>shortly =
going to have a set of small utilities that need to behave =
similarly<br>everywhere. These utilities should be source-compatible =
with different DTN<br>implementations.<br><br>The DTN API would be =
analogous to the BSD API that made socket programming so<br>successful. =
Perhaps it could even be an extension of the BSD API.<br><br>The =
document would specify C function interfaces. Implementation would be =
left<br>unspecified. For example, a DTN API library for DTN-2 could take =
the parameters<br>and transform that into a RPC to the dtnd =
program.<br><br>Is anything stopping this besides the usual "Please send =
text"?<br><br>Thanks,<br>Simon<br>-- <br>STUN/TURN server =
&nbsp;&nbsp;&nbsp;--> <a href=3D"http://numb.viagenie.ca"></a><a =
href=3D"http://numb.viagenie.ca">http://numb.viagenie.ca</a><br>Interplane=
tary news --> <a href=3D"http://reeves.viagenie.ca"></a><a =
href=3D"http://reeves.viagenie.ca">http://reeves.viagenie.ca</a><br>vCard =
4.0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--> <a =
href=3D"http://www.vcarddav.org"></a><a =
href=3D"http://www.vcarddav.org">http://www.vcarddav.org</a><br>__________=
_____________________________________<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]"></a><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
></a><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</div></blockquote></div><br><div> <span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Hans =
Kruse, Professor</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren =
McClure School of Information and Telecommunication =
Systems</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Adjunct Associate Professor =
of Electrical Engineering and Computer Science</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">740-593-4891 voice, =
740-593-4889 fax</font></div></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></div>_______________________________________________<br>d=
tn-interest mailing list<br><a =
href=3D"mailto:[email-masked]"></a><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote></div><br></div></div></blockquote><blockquote =
type=3D"cite"><div><span>_______________________________________________</=
span><br><span>dtn-interest mailing list</span><br><span><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a></span><br><span><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a></sp=
an><br></div></blockquote></div></blockquote></div><br></div></body></html=
>=

--Apple-Mail-6-674606227--

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Trace-MD: h=11; b=31; l=R71D32M65F45T34S72R243M17C39C27I60;
Date: 28 Apr 2009 19:55:28 -0700
From: "Mark Delany" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

On Tue, Apr 28, 2009 at 09:43:40PM -0400, Joseph Ishac allegedly wrote:
> So I'm a bit confused.  Why not just have a bpselect() in addition to
> your bpsocket(), etc?  I thought the logic in this subthread was to have
> an API that reflected that of the socket system calls; not actually use
> the existing calls directly.

The problem with this approach is that you're assuming that you control who does
the select().

APIs like libcurl offer you an fd that your code does the select() on. Is that
fd a DTN fd or a regular socket or some other beast? In which case, which
select() do you call and how do you merge bpselect() with the system select()?

APIs like libevent ask you to provide an fd which they do the select() on. Which
select() should they call? How do you tell them?

Yet other APIs like state threads ask you to provide an fd that they morph into
their own object which in turn may be presented to any of
poll/select/kqueue/epoll and read/write/sendmsg/recvmsg, depending on the
OS. What should they do?

One question to ask is whether applications will be specially built *just* for
DTN or whether the expectation is that DTN might one day be seen as "just
another endpoint" that is supported by multi-endpoint applications.

Ie, do you ever expect/hope to have a URI like dtn://somewhere.someplanet that
you can enter into a browser? And will apache or an amqp router ever bind to a
DTN endpoint? If so, they'll likely want a socket, warts and all.

Mark.

Date: Tue, 28 Apr 2009 22:05:45 -0400
From: "G. Clark" <[email-masked]>
To: Joseph Ishac <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

A major problem I see is that even if there's a bpselect in there, it 
won't work on both the sockets we create with our custom file 
descriptors / structures / whatever we use and with the FD_SETs we use 
with a standard select() call. 

In other words, I can bpselect() over DTN sockets, and select() over 
normal FDs, but what if I want to select over both stdin and a DTN 
socket descriptor / structure at the same time?  I'm kind of out of 
luck.  Thus, we need to come up with a select() that can handle both. . 
. and that's where it becomes tricky.

Gilbert Clark
Grad Student
Ohio University

Joseph Ishac wrote:
> So I'm a bit confused.  Why not just have a bpselect() in addition to
> your bpsocket(), etc?  I thought the logic in this subthread was to have
> an API that reflected that of the socket system calls; not actually use
> the existing calls directly.
>
> -Joseph
>
> On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
>   
>> Wes, I don't think anybody's claiming that it would be difficult to emulate the behavior of select() for a socket-like bundling API.  The issue is whether or not the standard select() system call that ships with your operating system will operate correctly when you provide the value returned by bpsocket() [or whatever] to it as one of the file descriptors in its readFdSet.
>>
>> For example, the underlying BP endpoint open() [or whatever] may not even return an integer.  If it is, it may not be an actual file descriptor.  Etc.
>>
>> Scott
>>
>>     
>>> -----Original Message-----
>>> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked]]
>>> Sent: Tuesday, April 28, 2009 4:51 PM
>>> To: [email-masked]; Burleigh, Scott C
>>> Cc: [email-masked]
>>> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
>>>
>>> I don't understand why multiple replies have indicated that the select()
>>> behavior would be somehow difficult to emulate for a socket-like
>>> bundling API.  If the bundle agent is holding payloads waiting to be
>>> delivered, the read test passes.  If it has free storage, the write test
>>> passes, and the error test would possibly not be relevant.  It doesn't
>>> seem to be all that complicated ... you block for the specified amount
>>> of time until one of the test conditions comes true or the time runs out,
>>> and then return.
>>>
>>> What am I missing?
>>>       
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 28 Apr 2009 20:55:00 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

OH.  I had assumed we were talking about dtn_socket, dtn_recvfrom, etc.
(or dtn::socket, dtn::recvfrom, etc., or other forms depending on language)
and not trying to insert code into the actual system code ... that would be
pretty much ridiculous, considering modern systems are implementing
these as system calls rather than library functions.

________________________________________
From: Burleigh, Scott C [[email-masked]]
Sent: Tuesday, April 28, 2009 8:04 PM
To: Eddy, Wesley M. (GRC-MS00)[Verizon]; [email-masked]
Cc: [email-masked]
Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Wes, I don't think anybody's claiming that it would be difficult to emulate the behavior of select() for a socket-like bundling API.  The issue is whether or not the standard select() system call that ships with your operating system will operate correctly when you provide the value returned by bpsocket() [or whatever] to it as one of the file descriptors in its readFdSet.

For example, the underlying BP endpoint open() [or whatever] may not even return an integer.  If it is, it may not be an actual file descriptor.  Etc.

Scott

> -----Original Message-----
> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2009 4:51 PM
> To: [email-masked]; Burleigh, Scott C
> Cc: [email-masked]
> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
>
> I don't understand why multiple replies have indicated that the select()
> behavior would be somehow difficult to emulate for a socket-like
> bundling API.  If the bundle agent is holding payloads waiting to be
> delivered, the read test passes.  If it has free storage, the write test
> passes, and the error test would possibly not be relevant.  It doesn't
> seem to be all that complicated ... you block for the specified amount
> of time until one of the test conditions comes true or the time runs out,
> and then return.
>
> What am I missing?
>
>
> ________________________________________
> From: [email-masked] [dtn-interest-
> [email-masked]] On Behalf Of [email-masked]
> [[email-masked]]
> Sent: Tuesday, April 28, 2009 4:50 PM
> To: Burleigh, Scott C
> Cc: [email-masked]
> Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
>
> I vote for a sockets API because:
>
> A) It'd be familiar to anybody who knows network code
>
> B) It might not be as bad to hack into a kernel / something (much, much)
> later on.
>
> C) getsockopt / setsockopt / ioctl can be used to set configuration options
> specific to either DTN2 or ION, depending on what's running (e.g.
> persistent
> registration, etc).
>
> Further, for registration and the like, why couldn't we use either
> setsockopt()
> or ioctl() calls to establish those, and simply assume that the endpoint
> will
> vanish when an FD is close()'d unless specified otherwise?
>
> It's true that select() would be evil to code and that some things would
> most
> likely be unwieldy, but personally I feel like being able to pick up the
> library
> and use it (almost) just like socket()s would make up for that.
>
> Anyway, just my two cents.
>
> Gilbert Clark
> Grad Student
> Ohio University
>
> Quoting "Burleigh, Scott C" <[email-masked]>:
>
> > Sure, but that's the easy stuff; supporting something like select()
> > would be tougher.  I'm thinking we're better off not acting like
> > we're using file descriptors when that's not what we've really got.
> > An abstraction along the same general model as (FILE *) seems safer
> > to me.
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Simon Perreault [mailto:[email-masked]]
> > > Sent: Tuesday, April 28, 2009 1:02 PM
> > > To: Burleigh, Scott C
> > > Cc: Daniel Ellard; [email-masked]
> > > Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat
> > application)
> > >
> > > Burleigh, Scott C wrote, on 28/04/09 03:44 PM:
> > > > the "socket" can't currently act much like a real file
> > descriptor
> > >
> > > I would imagine that read() and write() would receive and send
> > bundles to
> > > the
> > > connect()ed EID, similarly to how it's done with UDP.
> > >
> > > Simon
> > > --
> > > STUN/TURN server    --> http://numb.viagenie.ca
> > > Interplanetary news --> http://reeves.viagenie.ca
> > > vCard 4.0           --> http://www.vcarddav.org
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 28 Apr 2009 21:43:40 -0400
From: Joseph Ishac <[email-masked]>
To: [email-masked], "[email-masked]" <[email-masked]>
Mail-Followup-To: [email-masked],"dtn-interest@ma ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
Reply-To: Joseph Ishac <[email-masked]>

So I'm a bit confused.  Why not just have a bpselect() in addition to
your bpsocket(), etc?  I thought the logic in this subthread was to have
an API that reflected that of the socket system calls; not actually use
the existing calls directly.

-Joseph

On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
> Wes, I don't think anybody's claiming that it would be difficult to emulate the behavior of select() for a socket-like bundling API.  The issue is whether or not the standard select() system call that ships with your operating system will operate correctly when you provide the value returned by bpsocket() [or whatever] to it as one of the file descriptors in its readFdSet.
> 
> For example, the underlying BP endpoint open() [or whatever] may not even return an integer.  If it is, it may not be an actual file descriptor.  Etc.
> 
> Scott
> 
> > -----Original Message-----
> > From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 4:51 PM
> > To: [email-masked]; Burleigh, Scott C
> > Cc: [email-masked]
> > Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> > 
> > I don't understand why multiple replies have indicated that the select()
> > behavior would be somehow difficult to emulate for a socket-like
> > bundling API.  If the bundle agent is holding payloads waiting to be
> > delivered, the read test passes.  If it has free storage, the write test
> > passes, and the error test would possibly not be relevant.  It doesn't
> > seem to be all that complicated ... you block for the specified amount
> > of time until one of the test conditions comes true or the time runs out,
> > and then return.
> > 
> > What am I missing?

Date: Tue, 28 Apr 2009 21:43:40 -0400
From: Joseph Ishac <[email-masked]>
To: [email-masked], "[email-masked]" <[email-masked]>
Mail-Followup-To: [email-masked],"dtn-interest@ma ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
Reply-To: Joseph Ishac <[email-masked]>

So I'm a bit confused.  Why not just have a bpselect() in addition to
your bpsocket(), etc?  I thought the logic in this subthread was to have
an API that reflected that of the socket system calls; not actually use
the existing calls directly.

-Joseph

On Tue, Apr 28, 2009 at 07:04:57PM -0500, Burleigh, Scott C wrote:
> Wes, I don't think anybody's claiming that it would be difficult to emulate the behavior of select() for a socket-like bundling API.  The issue is whether or not the standard select() system call that ships with your operating system will operate correctly when you provide the value returned by bpsocket() [or whatever] to it as one of the file descriptors in its readFdSet.
> 
> For example, the underlying BP endpoint open() [or whatever] may not even return an integer.  If it is, it may not be an actual file descriptor.  Etc.
> 
> Scott
> 
> > -----Original Message-----
> > From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 4:51 PM
> > To: [email-masked]; Burleigh, Scott C
> > Cc: [email-masked]
> > Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> > 
> > I don't understand why multiple replies have indicated that the select()
> > behavior would be somehow difficult to emulate for a socket-like
> > bundling API.  If the bundle agent is holding payloads waiting to be
> > delivered, the read test passes.  If it has free storage, the write test
> > passes, and the error test would possibly not be relevant.  It doesn't
> > seem to be all that complicated ... you block for the specified amount
> > of time until one of the test conditions comes true or the time runs out,
> > and then return.
> > 
> > What am I missing?

From: Charles Woloszynski <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Tue, 28 Apr 2009 20:51:22 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--Apple-Mail-1-666079748
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Does it make sense to look at the DDS APIs?  I think that came from  
OMG.org

Charlie

Sent from my iPhone

On Apr 28, 2009, at 8:12 PM, Kevin Fall <[email-masked]> wrote:

> We did some work on this a while ago, ultimately advocating for a  
> pub/sub style API.  If, as I am beginning to believe, we evolve to  
> be handling "content" more directly, I believe this will be the  
> direction to go.
>
> - K
>
>
> On Apr 28, 2009, at Apr 2811:29 AMPDT, Hans Kruse wrote:
>
>> Agreed -- and we have someone working on it .... so maybe "please  
>> send requirements"?
>>
>> On Apr 28, 2009, at 2:21 PM, Simon Perreault wrote:
>>
>>> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
>>>> This should be written to run on BOTH ION and DTN-2
>>>
>>> Please pardon the thread hijacking...
>>>
>>> We need a DTN API.
>>>
>>> This is especially important in the case of DTN network management  
>>> because we're
>>> shortly going to have a set of small utilities that need to behave  
>>> similarly
>>> everywhere. These utilities should be source-compatible with  
>>> different DTN
>>> implementations.
>>>
>>> The DTN API would be analogous to the BSD API that made socket  
>>> programming so
>>> successful. Perhaps it could even be an extension of the BSD API.
>>>
>>> The document would specify C function interfaces. Implementation  
>>> would be left
>>> unspecified. For example, a DTN API library for DTN-2 could take  
>>> the parameters
>>> and transform that into a RPC to the dtnd program.
>>>
>>> Is anything stopping this besides the usual "Please send text"?
>>>
>>> Thanks,
>>> Simon
>>> -- 
>>> STUN/TURN server    --> http://numb.viagenie.ca
>>> Interplanetary news --> http://reeves.viagenie.ca
>>> vCard 4.0           --> http://www.vcarddav.org
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> Hans Kruse, Professor
>> J. Warren McClure School of Information and Telecommunication Systems
>> Adjunct Associate Professor of Electrical Engineering and Computer  
>> Science
>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>> 740-593-4891 voice, 740-593-4889 fax
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-1-666079748
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body bgcolor=3D"#FFFFFF"><div>Does it make sense to look at the =
DDS APIs? &nbsp;I think that came from =
OMG.org</div><div><br></div><div><br>Charlie<div><br>Sent from my =
iPhone</div></div><div><br>On Apr 28, 2009, at 8:12 PM, Kevin Fall =
&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>> =
wrote:<br><br></div><div></div><blockquote type=3D"cite"><div>We did =
some work on this a while ago, ultimately advocating for a pub/sub style =
API. &nbsp;If, as I am beginning to believe, we evolve to be handling =
"content" more directly, I believe this will be the direction to =
go.<div><br></div><div>- K</div><div><br></div><div><br><div><div>On Apr =
28, 2009, at Apr 2811:29 AMPDT, Hans Kruse wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Agreed -- and we have someone =
working on it .... so maybe "please send =
requirements"?<div><br><div><div>On Apr 28, 2009, at 2:21 PM, Simon =
Perreault wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 =
01:54 PM:<br><blockquote type=3D"cite">This should be written to run on =
BOTH ION and DTN-2<br></blockquote><br>Please pardon the thread =
hijacking...<br><br>We need a DTN API.<br><br>This is especially =
important in the case of DTN network management because we're<br>shortly =
going to have a set of small utilities that need to behave =
similarly<br>everywhere. These utilities should be source-compatible =
with different DTN<br>implementations.<br><br>The DTN API would be =
analogous to the BSD API that made socket programming so<br>successful. =
Perhaps it could even be an extension of the BSD API.<br><br>The =
document would specify C function interfaces. Implementation would be =
left<br>unspecified. For example, a DTN API library for DTN-2 could take =
the parameters<br>and transform that into a RPC to the dtnd =
program.<br><br>Is anything stopping this besides the usual "Please send =
text"?<br><br>Thanks,<br>Simon<br>-- <br>STUN/TURN server =
&nbsp;&nbsp;&nbsp;--> <a href=3D"http://numb.viagenie.ca"><a =
href=3D"http://numb.viagenie.ca">http://numb.viagenie.ca</a></a><br>Interp=
lanetary news --> <a href=3D"http://reeves.viagenie.ca"><a =
href=3D"http://reeves.viagenie.ca">http://reeves.viagenie.ca</a></a><br>vC=
ard 4.0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--> =
<a href=3D"http://www.vcarddav.org"><a =
href=3D"http://www.vcarddav.org">http://www.vcarddav.org</a></a><br>______=
_________________________________________<br>dtn-interest mailing =
list<br><a href=3D"mailto:[email-masked]"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a></a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a></a>=
<br></div></blockquote></div><br><div> <span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Hans =
Kruse, Professor</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren =
McClure School of Information and Telecommunication =
Systems</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Adjunct Associate Professor =
of Electrical Engineering and Computer Science</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">740-593-4891 voice, =
740-593-4889 fax</font></div></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></div>_______________________________________________<br>d=
tn-interest mailing list<br><a =
href=3D"mailto:[email-masked]"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a></a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote></div><br></div></div></blockquote><blockquote =
type=3D"cite"><div><span>_______________________________________________</=
span><br><span>dtn-interest mailing list</span><br><span><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a></span><br><span><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a></sp=
an><br></div></blockquote></body></html>=

--Apple-Mail-1-666079748--

From: Kevin Fall <[email-masked]>
To: Hans Kruse <[email-masked]>
Date: Tue, 28 Apr 2009 17:12:41 -0700
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--Apple-Mail-4-663756540
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

We did some work on this a while ago, ultimately advocating for a pub/ 
sub style API.  If, as I am beginning to believe, we evolve to be  
handling "content" more directly, I believe this will be the direction  
to go.

- K

On Apr 28, 2009, at Apr 2811:29 AMPDT, Hans Kruse wrote:

> Agreed -- and we have someone working on it .... so maybe "please  
> send requirements"?
>
> On Apr 28, 2009, at 2:21 PM, Simon Perreault wrote:
>
>> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
>>> This should be written to run on BOTH ION and DTN-2
>>
>> Please pardon the thread hijacking...
>>
>> We need a DTN API.
>>
>> This is especially important in the case of DTN network management  
>> because we're
>> shortly going to have a set of small utilities that need to behave  
>> similarly
>> everywhere. These utilities should be source-compatible with  
>> different DTN
>> implementations.
>>
>> The DTN API would be analogous to the BSD API that made socket  
>> programming so
>> successful. Perhaps it could even be an extension of the BSD API.
>>
>> The document would specify C function interfaces. Implementation  
>> would be left
>> unspecified. For example, a DTN API library for DTN-2 could take  
>> the parameters
>> and transform that into a RPC to the dtnd program.
>>
>> Is anything stopping this besides the usual "Please send text"?
>>
>> Thanks,
>> Simon
>> -- 
>> STUN/TURN server    --> http://numb.viagenie.ca
>> Interplanetary news --> http://reeves.viagenie.ca
>> vCard 4.0           --> http://www.vcarddav.org
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> Hans Kruse, Professor
> J. Warren McClure School of Information and Telecommunication Systems
> Adjunct Associate Professor of Electrical Engineering and Computer  
> Science
> 292 Lindley Hall, Ohio University, Athens, OH, 45701
> 740-593-4891 voice, 740-593-4889 fax
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-4-663756540
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">We did some work on this a =
while ago, ultimately advocating for a pub/sub style API. &nbsp;If, as I =
am beginning to believe, we evolve to be handling "content" more =
directly, I believe this will be the direction to =
go.<div><br></div><div>- K</div><div><br></div><div><br><div><div>On Apr =
28, 2009, at Apr 2811:29 AMPDT, Hans Kruse wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Agreed -- and we have someone =
working on it .... so maybe "please send =
requirements"?<div><br><div><div>On Apr 28, 2009, at 2:21 PM, Simon =
Perreault wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 =
01:54 PM:<br><blockquote type=3D"cite">This should be written to run on =
BOTH ION and DTN-2<br></blockquote><br>Please pardon the thread =
hijacking...<br><br>We need a DTN API.<br><br>This is especially =
important in the case of DTN network management because we're<br>shortly =
going to have a set of small utilities that need to behave =
similarly<br>everywhere. These utilities should be source-compatible =
with different DTN<br>implementations.<br><br>The DTN API would be =
analogous to the BSD API that made socket programming so<br>successful. =
Perhaps it could even be an extension of the BSD API.<br><br>The =
document would specify C function interfaces. Implementation would be =
left<br>unspecified. For example, a DTN API library for DTN-2 could take =
the parameters<br>and transform that into a RPC to the dtnd =
program.<br><br>Is anything stopping this besides the usual "Please send =
text"?<br><br>Thanks,<br>Simon<br>-- <br>STUN/TURN server =
&nbsp;&nbsp;&nbsp;--> <a =
href=3D"http://numb.viagenie.ca">http://numb.viagenie.ca</a><br>Interplane=
tary news --> <a =
href=3D"http://reeves.viagenie.ca">http://reeves.viagenie.ca</a><br>vCard =
4.0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--> <a =
href=3D"http://www.vcarddav.org">http://www.vcarddav.org</a><br>__________=
_____________________________________<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</div></blockquote></div><br><div> <span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Hans =
Kruse, Professor</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren =
McClure School of Information and Telecommunication =
Systems</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Adjunct Associate Professor =
of Electrical Engineering and Computer Science</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">740-593-4891 voice, =
740-593-4889 fax</font></div></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></div>_______________________________________________<br>d=
tn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></blockquote></div><br></div></body></html>=

--Apple-Mail-4-663756540--

From: "Burleigh, Scott C" <[email-masked]>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 28 Apr 2009 17:04:57 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Wes, I don't think anybody's claiming that it would be difficult to emulate the behavior of select() for a socket-like bundling API.  The issue is whether or not the standard select() system call that ships with your operating system will operate correctly when you provide the value returned by bpsocket() [or whatever] to it as one of the file descriptors in its readFdSet.

For example, the underlying BP endpoint open() [or whatever] may not even return an integer.  If it is, it may not be an actual file descriptor.  Etc.

Scott

> -----Original Message-----
> From: Eddy, Wesley M. (GRC-MS00)[Verizon] [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2009 4:51 PM
> To: [email-masked]; Burleigh, Scott C
> Cc: [email-masked]
> Subject: RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> 
> I don't understand why multiple replies have indicated that the select()
> behavior would be somehow difficult to emulate for a socket-like
> bundling API.  If the bundle agent is holding payloads waiting to be
> delivered, the read test passes.  If it has free storage, the write test
> passes, and the error test would possibly not be relevant.  It doesn't
> seem to be all that complicated ... you block for the specified amount
> of time until one of the test conditions comes true or the time runs out,
> and then return.
> 
> What am I missing?
> 
> 
> ________________________________________
> From: [email-masked] [dtn-interest-
> [email-masked]] On Behalf Of [email-masked]
> [[email-masked]]
> Sent: Tuesday, April 28, 2009 4:50 PM
> To: Burleigh, Scott C
> Cc: [email-masked]
> Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> 
> I vote for a sockets API because:
> 
> A) It'd be familiar to anybody who knows network code
> 
> B) It might not be as bad to hack into a kernel / something (much, much)
> later on.
> 
> C) getsockopt / setsockopt / ioctl can be used to set configuration options
> specific to either DTN2 or ION, depending on what's running (e.g.
> persistent
> registration, etc).
> 
> Further, for registration and the like, why couldn't we use either
> setsockopt()
> or ioctl() calls to establish those, and simply assume that the endpoint
> will
> vanish when an FD is close()'d unless specified otherwise?
> 
> It's true that select() would be evil to code and that some things would
> most
> likely be unwieldy, but personally I feel like being able to pick up the
> library
> and use it (almost) just like socket()s would make up for that.
> 
> Anyway, just my two cents.
> 
> Gilbert Clark
> Grad Student
> Ohio University
> 
> Quoting "Burleigh, Scott C" <[email-masked]>:
> 
> > Sure, but that's the easy stuff; supporting something like select()
> > would be tougher.  I'm thinking we're better off not acting like
> > we're using file descriptors when that's not what we've really got.
> > An abstraction along the same general model as (FILE *) seems safer
> > to me.
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Simon Perreault [mailto:[email-masked]]
> > > Sent: Tuesday, April 28, 2009 1:02 PM
> > > To: Burleigh, Scott C
> > > Cc: Daniel Ellard; [email-masked]
> > > Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat
> > application)
> > >
> > > Burleigh, Scott C wrote, on 28/04/09 03:44 PM:
> > > > the "socket" can't currently act much like a real file
> > descriptor
> > >
> > > I would imagine that read() and write() would receive and send
> > bundles to
> > > the
> > > connect()ed EID, similarly to how it's done with UDP.
> > >
> > > Simon
> > > --
> > > STUN/TURN server    --> http://numb.viagenie.ca
> > > Interplanetary news --> http://reeves.viagenie.ca
> > > vCard 4.0           --> http://www.vcarddav.org
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Burleigh, Scott C" <[email-masked]>
Date: Tue, 28 Apr 2009 18:50:38 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

I don't understand why multiple replies have indicated that the select()
behavior would be somehow difficult to emulate for a socket-like
bundling API.  If the bundle agent is holding payloads waiting to be
delivered, the read test passes.  If it has free storage, the write test
passes, and the error test would possibly not be relevant.  It doesn't
seem to be all that complicated ... you block for the specified amount
of time until one of the test conditions comes true or the time runs out,
and then return.

What am I missing?

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, April 28, 2009 4:50 PM
To: Burleigh, Scott C
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

I vote for a sockets API because:

A) It'd be familiar to anybody who knows network code

B) It might not be as bad to hack into a kernel / something (much, much) later on.

C) getsockopt / setsockopt / ioctl can be used to set configuration options
specific to either DTN2 or ION, depending on what's running (e.g. persistent
registration, etc).

Further, for registration and the like, why couldn't we use either setsockopt()
or ioctl() calls to establish those, and simply assume that the endpoint will
vanish when an FD is close()'d unless specified otherwise?

It's true that select() would be evil to code and that some things would most
likely be unwieldy, but personally I feel like being able to pick up the library
and use it (almost) just like socket()s would make up for that.

Anyway, just my two cents.

Gilbert Clark
Grad Student
Ohio University

Quoting "Burleigh, Scott C" <[email-masked]>:

> Sure, but that's the easy stuff; supporting something like select()
> would be tougher.  I'm thinking we're better off not acting like
> we're using file descriptors when that's not what we've really got.
> An abstraction along the same general model as (FILE *) seems safer
> to me.
>
> Scott
>
> > -----Original Message-----
> > From: Simon Perreault [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 1:02 PM
> > To: Burleigh, Scott C
> > Cc: Daniel Ellard; [email-masked]
> > Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat
> application)
> >
> > Burleigh, Scott C wrote, on 28/04/09 03:44 PM:
> > > the "socket" can't currently act much like a real file
> descriptor
> >
> > I would imagine that read() and write() would receive and send
> bundles to
> > the
> > connect()ed EID, similarly to how it's done with UDP.
> >
> > Simon
> > --
> > STUN/TURN server    --> http://numb.viagenie.ca
> > Interplanetary news --> http://reeves.viagenie.ca
> > vCard 4.0           --> http://www.vcarddav.org
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 28 Apr 2009 22:44:40 +0100
To: [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Noting CFP: E-DTN Workshop on the Emergence of Delay-/Disruption-Tolerant Networks

(I like this one, as it's not solely limited to focus on the DTNRG's bundle protocol.)

http://www.e-dtn.org/2009/

Workshop on the Emergence of Delay-/Disruption-Tolerant Networks (E-DTN)

Important Dates:

Abstract-registration Deadline: June 15, 2009
Paper-submission Deadline: June 20, 2009
Acceptance Notification: July 31, 2009

October, 2009, St.-Petersburg, Russia
(in conjunction with ICUMT 2009)

Networking research for challenged environments has attracted
a lot of attention lately. Numerous attractive protocols have
been proposed, which are expected to network places and devices that
currently do not have the opportunity of “going online”. Such
environments reside at the edges of the current Internet infrastructure.
For example, public and private transport vehicles, underwater, satellite and
deep-space networks are potential DTN deployments of interest.
Communication in the above-mentioned challenged environments is usually
infrastructureless and consists mainly of mobile battery-powered
devices. Moreover, mobility patterns are usually unknown, making
connectivity periods between DTN-nodes intermittent and opportunistic.
To achieve communication in such environments one has to deal with
several performance tradeoffs, such as end-to-end delivery delay and
energy consumption, or reliability and storage congestion.
Since, in most cases, end-to-end connectivity does not exist (hence the
difference from ad hoc networking) current Internet protocols
fail permanently.

Although there have already been a lot of research proposals for
routing, (storage) congestion control, error control and
application design for such networks, the IRTF has
focused mainly on the Bundle Protocol (BP); BP is an application
layer protocol that does not include the appropriate functionalities to
deal with issues such as routing or storage congestion, for example. That
said, DTN research and its future directions seem to lack a stable
basis. For example, it is not clear yet if a “one-fits-all” protocol
stack will be deployed, or if such an approach is feasible at all.
In contrast, several different protocols that each would suit the needs
of its specific architecture/setup would need to be able to interoperate.

This workshop seeks novel ideas in the form of preliminary or work-in-progress
results as well as mature research papers for Delay-/Disruption
Tolerant Networks. We also encourage position papers that address and criticize the past, current
and future trends of DTN research and are intended to trigger discussions on the
whole spectrum of DTNs. Topics include but are not limited to:

    * DTN Routing
    * Congestion and Storage Congestion Control
    * Resource Sharing in DTN environments
    * Network Coding techniques for DTNs
    * Application Development
    * DTN Management Platforms
    * Error and Flow Control
    * Experiences and Measurements from DTN testbeds
    * Privacy and Security of Information in DTNs
    * DTN Simulators and related tools
    * Performance Evaluation and Metrics for DTN Research
    * Performance and Design Tradeoffs for DTN Algorithms and Protocols
    * Social Networking through DTNs
    * Satellite Constellations and DTNs
    * Naming/Addressing and interoperability issues with the Internet architecture
    * DTN Architectures:
          o Satellite Communications
          o Deep-space Communications
          o Underwater Communications
          o Connectivity in Developing Countries
          o Communication in Public and Private Transport Vehicles

A selection of the best papers will be invited for a special issue on the Emergence of Delay-/Disruption-Tolerant Networks in the Journal of Internet Engineering.

Important Dates:

Abstract-registration Deadline: June 15, 2009
Paper-submission Deadline: June 20, 2009
Acceptance Notification: July 31, 2009

Content-class: urn:content-classes:message
Date: Tue, 28 Apr 2009 22:38:28 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9C849.D0CC4730
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Scott Burleigh wrote:

> I like the idea of using something that's close to the main line of =
what the networking community is already used to.

and yet, all these years you've been working on CCSDS...

Try IP!

------_=_NextPart_001_01C9C849.D0CC4730
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] DTN API (Was: Re: DTN heartbeat =
application)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Scott Burleigh wrote:<BR>
<BR>
&gt; I like the idea of using something that's close to the main line of =
what the networking community is already used to.<BR>
<BR>
and yet, all these years you've been working on CCSDS...<BR>
<BR>
Try IP!</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9C849.D0CC4730--

To: "Burleigh, Scott C" <[email-masked]>
Date: Tue, 28 Apr 2009 16:50:49 -0400
From: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

I vote for a sockets API because:

A) It'd be familiar to anybody who knows network code

B) It might not be as bad to hack into a kernel / something (much, much) later on.

C) getsockopt / setsockopt / ioctl can be used to set configuration options
specific to either DTN2 or ION, depending on what's running (e.g. persistent
registration, etc).

Further, for registration and the like, why couldn't we use either setsockopt()
or ioctl() calls to establish those, and simply assume that the endpoint will
vanish when an FD is close()'d unless specified otherwise?

It's true that select() would be evil to code and that some things would most
likely be unwieldy, but personally I feel like being able to pick up the library
and use it (almost) just like socket()s would make up for that.

Anyway, just my two cents.

Gilbert Clark
Grad Student
Ohio University

Quoting "Burleigh, Scott C" <[email-masked]>:

> Sure, but that's the easy stuff; supporting something like select()
> would be tougher.  I'm thinking we're better off not acting like
> we're using file descriptors when that's not what we've really got. 
> An abstraction along the same general model as (FILE *) seems safer
> to me.
> 
> Scott
> 
> > -----Original Message-----
> > From: Simon Perreault [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 1:02 PM
> > To: Burleigh, Scott C
> > Cc: Daniel Ellard; [email-masked]
> > Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat
> application)
> > 
> > Burleigh, Scott C wrote, on 28/04/09 03:44 PM:
> > > the "socket" can't currently act much like a real file
> descriptor
> > 
> > I would imagine that read() and write() would receive and send
> bundles to
> > the
> > connect()ed EID, similarly to how it's done with UDP.
> > 
> > Simon
> > --
> > STUN/TURN server    --> http://numb.viagenie.ca
> > Interplanetary news --> http://reeves.viagenie.ca
> > vCard 4.0           --> http://www.vcarddav.org
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Sender: [email-masked]
From: Michael Demmer <[email-masked]>
Date: Tue, 28 Apr 2009 13:23:12 -0700
To: "Burleigh, Scott C" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--0016e644cb2895e4aa0468a33cce
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> Sure, but that's the easy stuff; supporting something like select() would
> be tougher.  I'm thinking we're better off not acting like we're using file
> descriptors when that's not what we've really got.  An abstraction along the
> same general model as (FILE *) seems safer to me.

I'd generally agree with this.

There's little gained by pretending that a handle to a DTN agent is a file
when it doesn't behave like one or have similar properties.

A stream-oriented approach is ok for handling an inflow (or outflow) of
related bundles, but as Scott said, you still need some sort of select()
type behavior to listen for incoming bundles.

Also in the DTN2 RI at least, a registration can persist for longer than the
life of the connected application, so you'd want some other mechanism to
handle that (hence the separate dtn_register and dtn_bind calls in the DTN2
api).

-m

--0016e644cb2895e4aa0468a33cce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"b=
order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin=
g-left: 1ex;">Sure, but that&#39;s the easy stuff; supporting something lik=
e select() would be tougher. =A0I&#39;m thinking we&#39;re better off not a=
cting like we&#39;re using file descriptors when that&#39;s not what we&#39=
;ve really got. =A0An abstraction along the same general model as (FILE *) =
seems safer to me.</blockquote>

<div><br>I&#39;d generally agree with this.<br><br>There&#39;s little gaine=
d by pretending that a handle to a DTN agent is a file when it doesn&#39;t =
behave like one or have similar properties.<br><br>A stream-oriented approa=
ch is ok for handling an inflow (or outflow) of related bundles, but as Sco=
tt said, you still need some sort of select() type behavior to listen for i=
ncoming bundles.<br>

<br>Also in the DTN2 RI at least, a registration can persist for longer tha=
n the life of the connected application, so you&#39;d want some other mecha=
nism to handle that (hence the separate dtn_register and dtn_bind calls in =
the DTN2 api).<br>

<br>-m<br></div></div><br>

--0016e644cb2895e4aa0468a33cce--

From: "Burleigh, Scott C" <[email-masked]>
To: Simon Perreault <[email-masked]>
Date: Tue, 28 Apr 2009 13:12:16 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Sure, but that's the easy stuff; supporting something like select() would be tougher.  I'm thinking we're better off not acting like we're using file descriptors when that's not what we've really got.  An abstraction along the same general model as (FILE *) seems safer to me.

Scott

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2009 1:02 PM
> To: Burleigh, Scott C
> Cc: Daniel Ellard; [email-masked]
> Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> 
> Burleigh, Scott C wrote, on 28/04/09 03:44 PM:
> > the "socket" can't currently act much like a real file descriptor
> 
> I would imagine that read() and write() would receive and send bundles to
> the
> connect()ed EID, similarly to how it's done with UDP.
> 
> Simon
> --
> STUN/TURN server    --> http://numb.viagenie.ca
> Interplanetary news --> http://reeves.viagenie.ca
> vCard 4.0           --> http://www.vcarddav.org

Date: Tue, 28 Apr 2009 16:01:32 -0400
From: Simon Perreault <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Burleigh, Scott C wrote, on 28/04/09 03:44 PM:
> the "socket" can't currently act much like a real file descriptor

I would imagine that read() and write() would receive and send bundles to the
connect()ed EID, similarly to how it's done with UDP.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: David Young <[email-masked]>, Michael Demmer <[email-masked]>
Date: Tue, 28 Apr 2009 14:50:00 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Registration is similar to bind() in many ways.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of David Young
>Sent: Tuesday, April 28, 2009 3:34 PM
>To: Michael Demmer
>Cc: [email-masked]
>Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
>
>>> > The DTN API would be analogous to the BSD API that made socket
>>> > programming so
>>> > successful. Perhaps it could even be an extension of the BSD API.
>>
>> I thought about this for a while -- I'm not sure that sockets is
>exactly the
>> right model for disconnection tolerant applications, since there's
>some
>> significant advantage to be gained by having a more robust interface
>than a
>> simple byte stream or message stream.
>
>I thought maybe a subset of the sockets interface can be done- not
>streams (bundles don't have a sequence) but datagrams and raw sockets.
> I do agree that there needs to be a bit more to the interface- I
>couldn't really come up with an equivalent to the "registration" in
>sockets.  A socket is fine to implement the application-BA interface,
>but we'd need to add something to it to permit an eid registration to
>be created, removed, or possibly have it's TTL changed.
>
>--
>David Young
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: Daniel Ellard <[email-masked]>, Simon Perreault <[email-masked]>
Date: Tue, 28 Apr 2009 12:44:30 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

I like the idea of using something that's close to the main line of what the networking community is already used to.

Sockets is one obvious candidate, though making DTN subject to system file descriptor limits is kind of unattractive -- and in ION the fact that the "socket" can't currently act much like a real file descriptor is a drawback.

Something like stream stdio might be easier, and it also carries connotations of buffering that might help make the model a somewhat better fit.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Daniel Ellard
> Sent: Tuesday, April 28, 2009 11:29 AM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
> 
> Simon Perreault wrote:
> > Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
> >> This should be written to run on BOTH ION and DTN-2
> >
> > Please pardon the thread hijacking...
> >
> > We need a DTN API.
> 
> Yes, we do.
> 
> Is there any reason not to begin with the C interface used
> in the DTN-RI apps (declared in 'applib')?
> 
> Before you answer, note that I used the words 'begin with'
> rather than 'use'.  I'm not advocating that it's perfect
> as-is.  Some parts are a bit clunky, and I'm sure we can
> improve it, but it does get the job done.
> 
> 
> > This is especially important in the case of DTN network management
> because we're
> > shortly going to have a set of small utilities that need to behave
> similarly
> > everywhere. These utilities should be source-compatible with different
> DTN
> > implementations.
> >
> > The DTN API would be analogous to the BSD API that made socket
> programming so
> > successful. Perhaps it could even be an extension of the BSD API.
> >
> > The document would specify C function interfaces. Implementation would be
> left
> > unspecified. For example, a DTN API library for DTN-2 could take the
> parameters
> > and transform that into a RPC to the dtnd program.
> >
> > Is anything stopping this besides the usual "Please send text"?
> 
> We will send the text, if the starting point is DTN-RI
> applib.  (If it's something else, well, we don't know what
> text to send, yet...)
> 
> -Dan
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Sender: [email-masked]
From: Michael Demmer <[email-masked]>
Date: Tue, 28 Apr 2009 12:42:33 -0700
To: David Young <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--001636af03423763550468a2ab3b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Tue, Apr 28, 2009 at 12:33 PM, David Young <[email-masked]>wrote:

> >> > The DTN API would be analogous to the BSD API that made socket
> >> > programming so
> >> > successful. Perhaps it could even be an extension of the BSD API.
> >
> > I thought about this for a while -- I'm not sure that sockets is exactly
> the
> > right model for disconnection tolerant applications, since there's some
> > significant advantage to be gained by having a more robust interface than
> a
> > simple byte stream or message stream.
>
> I thought maybe a subset of the sockets interface can be done- not
> streams (bundles don't have a sequence) but datagrams and raw sockets.
>  I do agree that there needs to be a bit more to the interface- I
> couldn't really come up with an equivalent to the "registration" in
> sockets.  A socket is fine to implement the application-BA interface,
> but we'd need to add something to it to permit an eid registration to
> be created, removed, or possibly have it's TTL changed.

Yep. And at that point, you're not really getting much out of the "sockets"
abstraction.

If someone is thinking of moving DTN implementations down into an OS kernel,
then you might lean towards a socket interface.

-m

--001636af03423763550468a2ab3b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Tue, Apr 28, 2009 at 12:33 PM, David Youn=
g <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">david.a.=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8=
ex; padding-left: 1ex;">

<div class=3D"im">&gt;&gt; &gt; The DTN API would be analogous to the BSD A=
PI that made socket<br>
&gt;&gt; &gt; programming so<br>
&gt;&gt; &gt; successful. Perhaps it could even be an extension of the BSD =
API.<br>
&gt;<br>
&gt; I thought about this for a while -- I&#39;m not sure that sockets is e=
xactly the<br>
&gt; right model for disconnection tolerant applications, since there&#39;s=
 some<br>
&gt; significant advantage to be gained by having a more robust interface t=
han a<br>
&gt; simple byte stream or message stream.<br>
<br>
</div>I thought maybe a subset of the sockets interface can be done- not<br=
>
streams (bundles don&#39;t have a sequence) but datagrams and raw sockets.<=
br>
=A0I do agree that there needs to be a bit more to the interface- I<br>
couldn&#39;t really come up with an equivalent to the &quot;registration&qu=
ot; in<br>
sockets. =A0A socket is fine to implement the application-BA interface,<br>
but we&#39;d need to add something to it to permit an eid registration to<b=
r>
be created, removed, or possibly have it&#39;s TTL changed.<font color=3D"#=
888888"></font></blockquote><div><br>Yep. And at that point, you&#39;re not=
 really getting much out of the &quot;sockets&quot; abstraction.<br><br>

If someone is thinking of moving DTN implementations down into an OS kernel=
, then you might lean towards a socket interface.<br><br>-m<br></div></div>=
<br>

--001636af03423763550468a2ab3b--

From: "Parikh, Salil" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 28 Apr 2009 15:36:46 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--_000_06CBA47B9C3FA7409BF459DAA035248902CECC555AIMCMBX3MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

See also:

http://conferences.sigcomm.org/hotnets/2007/papers/hotnets6-final50.pdf

Towards a Modern Communications API
Michael Demmer (UCB), Kevin Fall (Intel Research), Teemu Koponen (HIIT / IC=
SI), and Scott Shenker (ICSI / UCB)

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Michael Demmer
Sent: Tuesday, April 28, 2009 2:56 PM
To: Daniel Ellard
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Yes, we do.

Is there any reason not to begin with the C interface used
in the DTN-RI apps (declared in 'applib')?

Before you answer, note that I used the words 'begin with'
rather than 'use'.  I'm not advocating that it's perfect
as-is.  Some parts are a bit clunky, and I'm sure we can
improve it, but it does get the job done.

Given that I wrote this interface, I'd say I agree with this assessment. It=
's ok for what it does but is by no means perfect.

Were I to do this all over again, I would likely not use XDR for the marsha=
lling / unmarshalling but rather would just roll my own implementation for =
the RPC service.

That would (I think) allow for a more user-friendly C API and could avoid s=
ome of the clunkiness and brittleness associated with the XDR routines.

> This is especially important in the case of DTN network management becaus=
e we're
> shortly going to have a set of small utilities that need to behave simila=
rly
> everywhere. These utilities should be source-compatible with different DT=
N
> implementations.
>
> The DTN API would be analogous to the BSD API that made socket programmin=
g so
> successful. Perhaps it could even be an extension of the BSD API.

I thought about this for a while -- I'm not sure that sockets is exactly th=
e right model for disconnection tolerant applications, since there's some s=
ignificant advantage to be gained by having a more robust interface than a =
simple byte stream or message stream.

-m

--_000_06CBA47B9C3FA7409BF459DAA035248902CECC555AIMCMBX3MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>See also:<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><a
href=3D"http://conferences.sigcomm.org/hotnets/2007/papers/hotnets6-final50=
.pdf">http://conferences.sigcomm.org/hotnets/2007/papers/hotnets6-final50.p=
df</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Towards a Modern Communications API <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Michael Demmer (UCB), Kevin Fall (Intel Research), Teemu Kop=
onen
(HIIT / ICSI), and Scott Shenker (ICSI / UCB)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal style=3D'margin-left:.5in'><b><span style=3D'font-size=
:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size=
:10.0pt;
font-family:"Tahoma","sans-serif"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Michael
Demmer<br>
<b>Sent:</b> Tuesday, April 28, 2009 2:56 PM<br>
<b>To:</b> Daniel Ellard<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat applicat=
ion)<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<div>

<blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

<p class=3DMsoNormal style=3D'margin-left:.5in'>Yes, we do.<br>
<br>
Is there any reason not to begin with the C interface used<br>
in the DTN-RI apps (declared in 'applib')?<br>
<br>
Before you answer, note that I used the words 'begin with'<br>
rather than 'use'. &nbsp;I'm not advocating that it's perfect<br>
as-is. &nbsp;Some parts are a bit clunky, and I'm sure we can<br>
improve it, but it does get the job done.<o:p></o:p></p>

</blockquote>

<div>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:0in;margi=
n-bottom:
12.0pt;margin-left:.5in'><br>
Given that I wrote this interface, I'd say I agree with this assessment. It=
's
ok for what it does but is by no means perfect.<br>
<br>
Were I to do this all over again, I would likely not use XDR for the
marshalling / unmarshalling but rather would just roll my own implementatio=
n
for the RPC service.<br>
<br>
That would (I think) allow for a more user-friendly C API and could avoid s=
ome
of the clunkiness and brittleness associated with the XDR routines.<br>
<br>
<o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

<p class=3DMsoNormal style=3D'margin-left:.5in'>&gt; This is especially imp=
ortant
in the case of DTN network management because we're<o:p></o:p></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'>&gt; shortly going to have =
a set of
small utilities that need to behave similarly<br>
&gt; everywhere. These utilities should be source-compatible with different=
 DTN<br>
&gt; implementations.<br>
&gt;<br>
&gt; The DTN API would be analogous to the BSD API that made socket program=
ming
so<br>
&gt; successful. Perhaps it could even be an extension of the BSD API.<o:p>=
</o:p></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:0in;margi=
n-bottom:
12.0pt;margin-left:.5in'><br>
I thought about this for a while -- I'm not sure that sockets is exactly th=
e
right model for disconnection tolerant applications, since there's some
significant advantage to be gained by having a more robust interface than a
simple byte stream or message stream.<br>
&nbsp;<br>
-m<o:p></o:p></p>

</div>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_06CBA47B9C3FA7409BF459DAA035248902CECC555AIMCMBX3MITREO_--

Date: Tue, 28 Apr 2009 15:33:57 -0400
From: David Young <[email-masked]>
To: Michael Demmer <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

>> > The DTN API would be analogous to the BSD API that made socket
>> > programming so
>> > successful. Perhaps it could even be an extension of the BSD API.
>
> I thought about this for a while -- I'm not sure that sockets is exactly the
> right model for disconnection tolerant applications, since there's some
> significant advantage to be gained by having a more robust interface than a
> simple byte stream or message stream.

I thought maybe a subset of the sockets interface can be done- not
streams (bundles don't have a sequence) but datagrams and raw sockets.
 I do agree that there needs to be a bit more to the interface- I
couldn't really come up with an equivalent to the "registration" in
sockets.  A socket is fine to implement the application-BA interface,
but we'd need to add something to it to permit an eid registration to
be created, removed, or possibly have it's TTL changed.

-- 
David Young

Date: Tue, 28 Apr 2009 15:11:18 -0400
From: Joseph Ishac <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Mail-Followup-To: "Ivancic, William D. (GRC-RHN0)"  <[email-masked]>,Simon Perreault  <[email-masked]>,"[email-masked]"  <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)
Reply-To: Joseph Ishac <[email-masked]>

Yes, the thought was to develop a common API - something that an
application developer could write to and have work regardless of the
specific underlying implementation.

In tandem with this common API was the idea of developing a
middleware shim that would bind to ION and DTN2 while providing the
common API interface to applications.  The middleware solution was
proposed if it proved to be difficult to update DTN2 or ION to support a
new (or modified depending on how you look at it) API natively (the
ideal solution).

This is an area I'm slated to look into... So, I'll second the request
for requirements and note to keep in mind the different use cases, EID
schemes, etc

-Joseph

On Tue, Apr 28, 2009 at 01:30:15PM -0500, William Ivancic wrote:
> Joseph Ishac and I have been discussing the same.  Joseph had some thoughts regarding this.  I think one was a quick piece of middleware to get something operational that would provide a shim to a real API for DTN-2 an ION.
> 
> Joseph, perhaps you can expand on this.
> 
> 
> Will
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic 
> 
> > -----Original Message-----
> > From: Simon Perreault [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 2:22 PM
> > To: Ivancic, William D. (GRC-RHN0)
> > Cc: [email-masked]
> > Subject: DTN API (Was: Re: DTN heartbeat application)
> > 
> > Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
> > > This should be written to run on BOTH ION and DTN-2
> > 
> > Please pardon the thread hijacking...
> > 
> > We need a DTN API.
> > 
> > This is especially important in the case of DTN network management
> > because we're
> > shortly going to have a set of small utilities that need to behave
> > similarly
> > everywhere. These utilities should be source-compatible with different
> > DTN
> > implementations.
> > 
> > The DTN API would be analogous to the BSD API that made socket
> > programming so
> > successful. Perhaps it could even be an extension of the BSD API.
> > 
> > The document would specify C function interfaces. Implementation would
> > be left
> > unspecified. For example, a DTN API library for DTN-2 could take the
> > parameters
> > and transform that into a RPC to the dtnd program.
> > 
> > Is anything stopping this besides the usual "Please send text"?
> > 
> > Thanks,
> > Simon
> > --
> > STUN/TURN server    --> http://numb.viagenie.ca
> > Interplanetary news --> http://reeves.viagenie.ca
> > vCard 4.0           --> http://www.vcarddav.org
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Sender: [email-masked]
From: Michael Demmer <[email-masked]>
Date: Tue, 28 Apr 2009 11:56:11 -0700
To: Daniel Ellard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--0016e644cb2864257f0468a20549
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> Yes, we do.
>
> Is there any reason not to begin with the C interface used
> in the DTN-RI apps (declared in 'applib')?
>
> Before you answer, note that I used the words 'begin with'
> rather than 'use'.  I'm not advocating that it's perfect
> as-is.  Some parts are a bit clunky, and I'm sure we can
> improve it, but it does get the job done.

Given that I wrote this interface, I'd say I agree with this assessment.
It's ok for what it does but is by no means perfect.

Were I to do this all over again, I would likely not use XDR for the
marshalling / unmarshalling but rather would just roll my own implementation
for the RPC service.

That would (I think) allow for a more user-friendly C API and could avoid
some of the clunkiness and brittleness associated with the XDR routines.

> This is especially important in the case of DTN network management because
> we're
> > shortly going to have a set of small utilities that need to behave
> similarly
> > everywhere. These utilities should be source-compatible with different
> DTN
> > implementations.
> >
> > The DTN API would be analogous to the BSD API that made socket
> programming so
> > successful. Perhaps it could even be an extension of the BSD API.
>

I thought about this for a while -- I'm not sure that sockets is exactly the
right model for disconnection tolerant applications, since there's some
significant advantage to be gained by having a more robust interface than a
simple byte stream or message stream.

-m

--0016e644cb2864257f0468a20549
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde=
r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le=
ft: 1ex;">Yes, we do.<br>
<br>
Is there any reason not to begin with the C interface used<br>
in the DTN-RI apps (declared in &#39;applib&#39;)?<br>
<br>
Before you answer, note that I used the words &#39;begin with&#39;<br>
rather than &#39;use&#39;. =A0I&#39;m not advocating that it&#39;s perfect<=
br>
as-is. =A0Some parts are a bit clunky, and I&#39;m sure we can<br>
improve it, but it does get the job done.</blockquote><div><br>Given that I=
 wrote this interface, I&#39;d say I agree with this assessment. It&#39;s o=
k for what it does but is by no means perfect.<br><br>Were I to do this all=
 over again, I would likely not use XDR for the marshalling / unmarshalling=
 but rather would just roll my own implementation for the RPC service.<br>

<br>That would (I think) allow for a more user-friendly C API and could avo=
id some of the clunkiness and brittleness associated with the XDR routines.=
<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1=
px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"=
>

&gt; This is especially important in the case of DTN network management bec=
ause we&#39;re<br><div class=3D"im">
&gt; shortly going to have a set of small utilities that need to behave sim=
ilarly<br>
&gt; everywhere. These utilities should be source-compatible with different=
 DTN<br>
&gt; implementations.<br>
&gt;<br>
&gt; The DTN API would be analogous to the BSD API that made socket program=
ming so<br>
&gt; successful. Perhaps it could even be an extension of the BSD API.</div=
></blockquote><div><br>I thought about this for a while -- I&#39;m not sure=
 that sockets is exactly the right model for disconnection tolerant applica=
tions, since there&#39;s some significant advantage to be gained by having =
a more robust interface than a simple byte stream or message stream.<br>

=A0<br>-m<br><br></div></div><br>

--0016e644cb2864257f0468a20549--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Simon Perreault <[email-masked]>
Date: Tue, 28 Apr 2009 13:30:15 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Joseph Ishac and I have been discussing the same.  Joseph had some thoughts regarding this.  I think one was a quick piece of middleware to get something operational that would provide a shim to a real API for DTN-2 an ION.

Joseph, perhaps you can expand on this.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2009 2:22 PM
> To: Ivancic, William D. (GRC-RHN0)
> Cc: [email-masked]
> Subject: DTN API (Was: Re: DTN heartbeat application)
> 
> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
> > This should be written to run on BOTH ION and DTN-2
> 
> Please pardon the thread hijacking...
> 
> We need a DTN API.
> 
> This is especially important in the case of DTN network management
> because we're
> shortly going to have a set of small utilities that need to behave
> similarly
> everywhere. These utilities should be source-compatible with different
> DTN
> implementations.
> 
> The DTN API would be analogous to the BSD API that made socket
> programming so
> successful. Perhaps it could even be an extension of the BSD API.
> 
> The document would specify C function interfaces. Implementation would
> be left
> unspecified. For example, a DTN API library for DTN-2 could take the
> parameters
> and transform that into a RPC to the dtnd program.
> 
> Is anything stopping this besides the usual "Please send text"?
> 
> Thanks,
> Simon
> --
> STUN/TURN server    --> http://numb.viagenie.ca
> Interplanetary news --> http://reeves.viagenie.ca
> vCard 4.0           --> http://www.vcarddav.org

From: Hans Kruse <[email-masked]>
To: Simon Perreault <[email-masked]>
Date: Tue, 28 Apr 2009 14:29:32 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

--Apple-Mail-19-643167090
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Agreed -- and we have someone working on it .... so maybe "please send  
requirements"?

On Apr 28, 2009, at 2:21 PM, Simon Perreault wrote:

> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
>> This should be written to run on BOTH ION and DTN-2
>
> Please pardon the thread hijacking...
>
> We need a DTN API.
>
> This is especially important in the case of DTN network management  
> because we're
> shortly going to have a set of small utilities that need to behave  
> similarly
> everywhere. These utilities should be source-compatible with  
> different DTN
> implementations.
>
> The DTN API would be analogous to the BSD API that made socket  
> programming so
> successful. Perhaps it could even be an extension of the BSD API.
>
> The document would specify C function interfaces. Implementation  
> would be left
> unspecified. For example, a DTN API library for DTN-2 could take the  
> parameters
> and transform that into a RPC to the dtnd program.
>
> Is anything stopping this besides the usual "Please send text"?
>
> Thanks,
> Simon
> -- 
> STUN/TURN server    --> http://numb.viagenie.ca
> Interplanetary news --> http://reeves.viagenie.ca
> vCard 4.0           --> http://www.vcarddav.org
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

--Apple-Mail-19-643167090
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Agreed -- and we have someone =
working on it .... so maybe "please send =
requirements"?<div><br><div><div>On Apr 28, 2009, at 2:21 PM, Simon =
Perreault wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 =
01:54 PM:<br><blockquote type=3D"cite">This should be written to run on =
BOTH ION and DTN-2<br></blockquote><br>Please pardon the thread =
hijacking...<br><br>We need a DTN API.<br><br>This is especially =
important in the case of DTN network management because we're<br>shortly =
going to have a set of small utilities that need to behave =
similarly<br>everywhere. These utilities should be source-compatible =
with different DTN<br>implementations.<br><br>The DTN API would be =
analogous to the BSD API that made socket programming so<br>successful. =
Perhaps it could even be an extension of the BSD API.<br><br>The =
document would specify C function interfaces. Implementation would be =
left<br>unspecified. For example, a DTN API library for DTN-2 could take =
the parameters<br>and transform that into a RPC to the dtnd =
program.<br><br>Is anything stopping this besides the usual "Please send =
text"?<br><br>Thanks,<br>Simon<br>-- <br>STUN/TURN server =
&nbsp;&nbsp;&nbsp;--> <a =
href=3D"http://numb.viagenie.ca">http://numb.viagenie.ca</a><br>Interplane=
tary news --> <a =
href=3D"http://reeves.viagenie.ca">http://reeves.viagenie.ca</a><br>vCard =
4.0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--> <a =
href=3D"http://www.vcarddav.org">http://www.vcarddav.org</a><br>__________=
_____________________________________<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-19-643167090--

Date: Tue, 28 Apr 2009 14:28:57 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Simon Perreault <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Simon Perreault wrote:
> Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
>> This should be written to run on BOTH ION and DTN-2
> 
> Please pardon the thread hijacking...
> 
> We need a DTN API.

Yes, we do.

Is there any reason not to begin with the C interface used
in the DTN-RI apps (declared in 'applib')?

Before you answer, note that I used the words 'begin with'
rather than 'use'.  I'm not advocating that it's perfect
as-is.  Some parts are a bit clunky, and I'm sure we can
improve it, but it does get the job done.

> This is especially important in the case of DTN network management because we're
> shortly going to have a set of small utilities that need to behave similarly
> everywhere. These utilities should be source-compatible with different DTN
> implementations.
> 
> The DTN API would be analogous to the BSD API that made socket programming so
> successful. Perhaps it could even be an extension of the BSD API.
> 
> The document would specify C function interfaces. Implementation would be left
> unspecified. For example, a DTN API library for DTN-2 could take the parameters
> and transform that into a RPC to the dtnd program.
> 
> Is anything stopping this besides the usual "Please send text"?

We will send the text, if the starting point is DTN-RI
applib.  (If it's something else, well, we don't know what
text to send, yet...)

-Dan

Date: Tue, 28 Apr 2009 14:21:55 -0400
From: Simon Perreault <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] DTN API (Was: Re: DTN heartbeat application)

Ivancic, William D. (GRC-RHN0) wrote, on 28/04/09 01:54 PM:
> This should be written to run on BOTH ION and DTN-2

Please pardon the thread hijacking...

We need a DTN API.

This is especially important in the case of DTN network management because we're
shortly going to have a set of small utilities that need to behave similarly
everywhere. These utilities should be source-compatible with different DTN
implementations.

The DTN API would be analogous to the BSD API that made socket programming so
successful. Perhaps it could even be an extension of the BSD API.

The document would specify C function interfaces. Implementation would be left
unspecified. For example, a DTN API library for DTN-2 could take the parameters
and transform that into a RPC to the dtnd program.

Is anything stopping this besides the usual "Please send text"?

Thanks,
Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

Content-Class: urn:content-classes:message
Date: Tue, 28 Apr 2009 12:13:32 -0600
From: "Moore, Brad" <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] [SPAM] - Applications - particularly video - Email found in subject

I have experimented a bit with video, and managed to get video working
across DTN, using the dtn_tunnel application. The video application used
was vlc. (http://www.videolan.org/). The dtn_tunnel application made it
appear that the vlc sender was sending to a local port, which came out
at the other side of the DTN appearing as a local port that the vlc
player was listening to on the receiving side. 

Brad Moore

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Ivancic, William D. (GRC-RHN0)
Sent: Tuesday, April 28, 2009 11:33 AM
To: [email-masked]
Subject: [SPAM] - [dtn-interest] Applications - particularly video -
Email found in subject

Does anyone have or are you working a video application.  If so, can you
share the application with the group.  I had someone at NASA working a
simple video/audio application, but I figure one probably exists and I
want to implement a heartbeat application that sends "I'm alive"
messages to predefined endpoints (admin or otherwise).  The heartbeat
will be more useful in the near term than the video application.

It probably would be nice to keep a list of applications a links to them
on DTNRG in the existing location:
http://www.dtnrg.org/wiki/DtnBone/DtnApps

Thanks in advance.

/will

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

Date: Tue, 28 Apr 2009 20:59:26 +0300
From: Joerg Ott <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Applications - particularly video

Well, we got our DT-Talkie (more on this to come):
http://www.netlab.tkk.fi/tutkimus/dtn/dttalkie/

See http://www.netlab.tkk.fi/~jo/dtn/index.html#apps for some more.

Joerg

Ivancic, William D. (GRC-RHN0) wrote:
> Does anyone have or are you working a video application.  If so, can you share the application with the group.  I had someone at NASA working a simple video/audio application, but I figure one probably exists and I want to implement a heartbeat application that sends "I'm alive" messages to predefined endpoints (admin or otherwise).  The heartbeat will be more useful in the near term than the video application.
> 
> It probably would be nice to keep a list of applications a links to them on DTNRG in the existing location:
> http://www.dtnrg.org/wiki/DtnBone/DtnApps
> 
> Thanks in advance.
> 
> 
> /will
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 28 Apr 2009 12:54:29 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN heartbeat application

I am going to have one of our engineers create the following application.  Any suggestions on what else one may want from a heartbeat application would be greatly appreciated and considered.

DTN Heartbeat Application
===========================
The purpose of this application is to periodically send a bundle to an endpoint or endpoints indicating that the DTN application is running.   This application should be capable of sending heartbeats and receiving heartbeats.

Send parameters:  
*	Destination (up to 5 EIDs (endpoint identifiers)
*	Creation time (in application, not bundle)
*	Heartbeat Rate (how often to send)
*	Bundle Lifetime
*	Location (optional)

Information that should be in the bundle:
*	Source EID
*	Creation time (in application, not bundle)
*	Heartbeat Rate (how often one should expect to receive an "I'm Alive" notice from the particular EID)
*	Location (optional)

The information from the heartbeat bundle as well as the receive time should be written to standard out as well as a log file that could later be parsed.

This should be written to run on BOTH ION and DTN-2

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 28 Apr 2009 12:33:26 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Applications - particularly video

Does anyone have or are you working a video application.  If so, can you share the application with the group.  I had someone at NASA working a simple video/audio application, but I figure one probably exists and I want to implement a heartbeat application that sends "I'm alive" messages to predefined endpoints (admin or otherwise).  The heartbeat will be more useful in the near term than the video application.

It probably would be nice to keep a list of applications a links to them on DTNRG in the existing location:
http://www.dtnrg.org/wiki/DtnBone/DtnApps

Thanks in advance.

/will

From: Alex McMahon <[email-masked]>
To: DTN <[email-masked]>, dtn-users <[email-masked]>
Organization: Trinity College Dublin
Date: Wed, 22 Apr 2009 13:57:10 +0100
Subject: [dtn-interest] DTN mercurial repository on sourceforge
Reply-To: [email-masked]

Hi,

There are several folks with pending DTN2 contributions and there has
been confusion on access to the repository and where the repository
"lives". 

Basically, from here on I shall be responsible for that sort of thing
and shall strive for continuity to the way Michael Demmer managed the
code. The DTN2 repository is located at /home/groups/d/dt/dtn on 
web.sourceforge.net. It is probably a good idea to reiterate how to
contribute to the main source tree. 

The conventions provided in
http://www.dtnrg.org/docs/code/DTN2/CONTRIBUTING briefly describe how to
get involved with DTN development. To contribute back to the main source
tree, first do a commit to the clone of the repository that you are
developing on and then export a changeset using: 

hg export REV

Where REV is the revision number of your commit. Capture the output from
the command into a file and email it as an attachment to
[email-masked]. Using the exported changeset (as opposed to
a simple patch) is preferable because the changeset will include your
name, email, and checkin comment which will be put into the mercurial
change log. You can do this in bulk for multiple commits using: 

hg export -o mypatch-%n REV1 [REV2] [REV3]

This will create N files, one for each revision, named "mypatch-1",
"mypatch-2", etc. Run 'hg help export' for more information. Any bugs
should be reported to dtn-users _at_ mailman _dot_ dtnrg _dot_ org.

All the best,

Alex McMahon

Date: Fri, 17 Apr 2009 23:08:12 +0100
From: Paulo Mendes <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: ACM U-NET'09 (co-located with ACM CoNEXT)

ACM U-NET'09 — User-provided Networking: Challenges and Opportunities
Co-located with ACM CoNEXT 2009
Rome, Italy, December 1, 2009
http://conferences.sigcomm.org/co-next/2009/workshops/unet/

Submission Deadline: July 17, 2009
Submit at: http://edas.info/N7753

*Motivation*

This workshop is dedicated to the debate of concepts, challenges, and
opportunities concerning user-provided networking, i.e., scenarios where
users cooperate by sharing wireless resources as well as Internet services.
To provide a specific example that relates to Internet access 
(connectivity),
the end-user (or a community of end-users) is a micro-operator in the sense
that he/she shares his/her subscribed broadband Internet access based on
some form of incentive scheme. In addition, the end-user may or may not
provide other network functionality such as local mobility management, or
persistent storage and forwarding services. This new role is disruptive 
in what
concerns Internet service models, since there is no distinction between 
what is
today known as end-user device and network device: in the future, end-user
devices will actively participate as part of the network. In contrast, 
the Internet
has been up to now mostly the means for end-users to obtain some form of 
network
service, originally related to connectivity, person-to-person 
communication, or
information retrieval. Such user-centric provider role is also 
disruptive given that
the regular network boundaries of trust have to be extended in a way 
that should
mimic social behavior: there is the need to form networks of trust in 
order to
accommodate a robust network growth, given that the key to such growth 
is the
willingness to cooperate.

Another disruptive aspect of user-provided networking is that due to the 
nature of
the wireless media and the way that humans move, support for intermittent
connectivity as well as fast and transparent roaming between 
micro-operators needs
to be considered. Finally, and given that user-provided networking 
spreads dynamically
having as network elements regular end-user devices, there is the need 
to consider
cases where information is opportunistically relayed instead of routed 
based on topological
information.

Due to the disruptive aspects mentioned, user-provided networking seem 
to have the
potential to provide a paradigm shift in Internet communication models, 
given that such
novel functionality allow wireless networks to operate in a completely 
autonomic way and
also given that the end-user becomes a provider of Internet services 
(e.g. connectivity) based
upon cooperation incentives or rewards and based upon his/her own 
mobility and social
patterns. Services are established on the fly, and do not necessarily 
imply the use of multihop
technology or routing. For instance, connectivity may be, in most cases, 
simply relayed.

The workshop program will include presentations of peer-reviewed papers 
and a discussion
panel with guests from industry and academia. We envision U-NET as a 
forum aiming to ignite
a debate concerning technical challenges and impact (negatively or 
positively) that
user-provided networking may have on Internet communication models.

*Topics*

U-NET'09 solicits high quality technical contributions within the 
context of user-provided
networking. Topics of interest include but are not limited to:
* Challenges and opportunities for access providers.
* Impact on Internet architectures.
* Internet connectivity.
* Trust models, incentives to share broadband access.
* Human behaviour and mobility patterns.
* Self-organization.
* Wireless cooperation.

Papers submitted are expected to be highly innovative and may 
incorporate early stage ideas;
position papers (clearly identified as such) pointing to new directions 
and capable of
generating discussion are also welcome. Submission must be original and 
not already published
in any other conference proceeding or journal. Proceedings of the 
workshop will be published
in the ACM Digital Library.

*Submissions*

Submitted papers must be at most 6 (six) pages long (including figures, 
tables and references)
in the standard ACM double column format. All text must use font sizes 
of 10 points or larger.
Longer submissions will not be reviewed. The review process is 
single-blind. Submissions will b
e done via EDAS at http://edas.info/N7753.

*Important Dates*

Submissions due: July 17, 2009
Notification of acceptance: September 4, 2009
Camera ready version due: October 1, 2009
Workshop date: December 1, 2009

*Program Committee*

PC Chairs

Paulo Mendes, INESC Porto, Portugal
Olivier Marcé, Alcatel-Lucent Bell Labs, France

Technical Program Committee

Rute Sofia, INESC Porto, Portugal
André Zúquete, University of Aveiro, Portugal
Vassilis Kostakos, University of Madeira, Portugal
Jon Crowcroft, University of Cambridge, United Kingdom
Cecilia Mascolo, University of Cambridge, United Kingdom
Eiko Yoneki, University of Cambridge, United Kingdom
Dirk Trossen, British Telecom Innovate, United Kingdom
Prosper Chemouli, France Telecom, France
Martin May, Thomson Paris Research Laboratory, France
Karen Sollins, MIT, USA
Lixia Zhang, UCLA, USA
James Kempf, Ericsson Research, USA
Dipankar Raychaudhuri, Rutgders University, USA
Bernhard Plattner, ETH, Switzerland
George Polyzos, Athens University of Economics and Business, Greece
Maria Papadopouli, FORTH/University of Creete, Greece
Anand Prasand, NEC, Japan
Gunnar Karlsson, KTH, Sweden
Yevgeni Koucheryavy, Tampere University of Technology, Finland
Marcus Brunner, NEC, Germany
Petri Mähönen, RWTH Aachen University, Germany

-- 
-----------------------------------------------------
Paulo Mendes, Ph.D
Area Leader, Internet Architectures and Networking
Telecommunication and Multimedia Unit
INESC Porto
Tel. +351 22 209 4264
Fax. +351 22 209 4050
http://ian.inescporto.pt

Date: Thu, 16 Apr 2009 12:54:36 -0400
From: Simon Perreault <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

Folks,

A Doodle poll has been created. Please enter your preferences so that we
may gather hard data.

http://www.doodle.com/6mdtwuqif6mszea2

Thanks,
Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

From: Hans Kruse <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>,  [email-masked]
Date: Thu, 16 Apr 2009 09:46:51 -0400
Subject: [dtn-interest] SMC-IT 09 Presentations

--Apple-Mail-7--410593262
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

We are still looking for presenters for the workshop described in the  
attached call.   If you got too busy (and who isn't) to send in a  
summary, please e-mail me at least a proposed title, and we will work  
with you on reviewing your proposed talk.  The workshop is scheduled  
for Monday, July 20, so that should take care of some NASA scheduling  
conflicts.

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

--Apple-Mail-7--410593262
Content-Type: multipart/mixed;
	boundary=Apple-Mail-8--410593261

--Apple-Mail-8--410593261
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>We are still looking for presenters for the workshop described in the attached call. &nbsp; If you got too busy (and who isn't) to send in a summary, please e-mail me at least a proposed title, and we will work with you on reviewing your proposed talk. &nbsp;The workshop is scheduled for Monday, July 20, so that should take care of some NASA scheduling conflicts.</div><div><br></div><div></div></body></html>
--Apple-Mail-8--410593261
Content-Disposition: attachment;
	filename=smc-it-cfp.rtf
Content-Type: text/rtf;
	x-unix-mode=0644;
	name="smc-it-cfp.rtf"
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf430
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
{\*\listtable{\list\listtemplateid1\listhybrid{\listlevel\levelnfc23\levelnfcn23\leveljc2\leveljcn2\levelfollow0\levelstartat1\levelspace360\levelindent0{\*\levelmarker \{hyphen\}}{\leveltext\leveltemplateid0\'02\'05.;}{\levelnumbers\'01;}}{\listname ;}\listid1}}
{\*\listoverridetable{\listoverride\listid1\listoverridecount0\ls1}}
\margl1440\margr1440\vieww15760\viewh14700\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\qc\pardirnatural

\f0\b\fs26 \cf0 Call for Presentations for\
a Mini-Workshop on\
  \ul Standards Based Operational Network Structures for Future Space Missions\ulnone \
at the Third IEEE International Conference on \
Space Mission Challenges in Information Technology (SMC-IT)\
Pasadena, California; July 19 - 23, 2009
\fs24 \
\
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural

\b0\fs22 \cf0 This one-day mini workshop focuses on the use of standards-based, automatic communications protocols in the design of future space missions, specifically the Delay Tolerant Networking (DTN) protocols.  Invited and contributed presentations will explore the available technologies, and both potential benefits as well as challenges inherent in an evolution from classical mission-by-mission communications design to a design based on standard protocols.\
\
We invite the submission of original research or concept design contributions in the following areas:\
\
\pard\tx220\tx720\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\li720\fi-720\ql\qnatural\pardirnatural
\ls1\ilvl0\cf0 {\listtext	\uc0\u8259 	}  Space communication network design based on DTN standards.\
{\listtext	\uc0\u8259 	}  Research results from operational experience with, or simulation of, DTN-based space communication networks.\
{\listtext	\uc0\u8259 	}  Routing and node/service discovery in DTN-based space networks.\
{\listtext	\uc0\u8259 	}  Naming and Addressing in DTN-based space networks.\
{\listtext	\uc0\u8259 	}  Network Management for DTN-based space networks.\
{\listtext	\uc0\u8259 	}  Command and Control of space assets based on DTN protocols.\
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
\cf0 \
The program committee invites the submission of contributions outside the areas listed above, and will make every effort to incorporate\
quality presentations into the workshop program.  All submissions will be peer-reviewed.  The abstracts for the selected contributions, as\
well as the presentation slides, will be published on the conference web site.\
\

\b Deadline for 1-page abstracts: April 13, 2009 (Midnight EDT).\
\

\b0 For more information and author instructions, please see http://www.ocp.ohiou.edu/smc-it/ or e-mail [email-masked].\
For more information on SMC-IT 2009, please see http://www.smc-it.org/\
\
\
\
}
--Apple-Mail-8--410593261
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> </div><br></body></html>=

--Apple-Mail-8--410593261--

--Apple-Mail-7--410593262--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Joerg Ott <[email-masked]>, Daniel Ellard <[email-masked]>
Date: Thu, 16 Apr 2009 08:38:36 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

With the DTNbone coming online, you should be able to test continuously.  Of course some things are best worked out face-to-face, but most testing should be possible remotely.  

For some testing face-to-face would just be people sitting around playing card while they wait for the links to come up three hours later.  Well, that is some of the testing that MUST be done for a true DTN.  One must test disconnection and long periods of it.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Joerg Ott
> Sent: Thursday, April 16, 2009 5:49 AM
> To: Daniel Ellard
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Proposed date for the first DTN 
> Disconnectathon:
> 
> 
> > What would work, to be a bit constructive here, is to have 
> remote only 
> > testing at some point.  And if some people want to get 
> together at BBN 
> > at this point, this could be done as well.  But this should happen 
> > preferably _after_ the IETF as it would allow some set of people to 
> > get a first round of debugging done face-to-face.  And we 
> found that 
> > the timeframe for the interop is tight already anyway...
> 
> Actually, having this a bit later would also help getting out 
> of the main vacation periods :-)  Or would the 
> Disconnectathlon lose too much if we move it later?  Just 
> curious whether people got internal demands for earlier testing...
> 
> Cheers,
> Joerg
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Hans Kruse <[email-masked]>
To: Joerg Ott <[email-masked]>
Date: Thu, 16 Apr 2009 09:27:13 -0400
Cc: "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

--Apple-Mail-1--411771245
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

What might help is to set up definite time slots (if we can't converge  
in space, lets at least converge in time) for one.  Well in advance so  
everyone can pick a lab or conference room to be in (away from the  
office), and block it out on the corporate calendar ;(.  How about  
setting up a skype conference (or other similar technology) for the  
time frame, so real-time conversations are possible.

On Apr 16, 2009, at 9:13 AM, Joerg Ott wrote:

>> On Thu, Apr 16, 2009 at 12:48:38PM +0300, Joerg Ott wrote:
>>>> What would work, to be a bit constructive here, is to have
>>>> remote only testing at some point.  And if some people want
>>>> to get together at BBN at this point, this could be done
>>>> as well.  But this should happen preferably _after_ the IETF as
>>>> it would allow some set of people to get a first round of
>>>> debugging done face-to-face.  And we found that the timeframe
>>>> for the interop is tight already anyway...
>>> Actually, having this a bit later would also help getting out
>>> of the main vacation periods :-)  Or would the Disconnectathlon
>>> lose too much if we move it later?  Just curious whether people
>>> got internal demands for earlier testing...
>>>
>>
>> 	actually, this sounds almost ideal for testing dtn.
>> 	not having everyone present at the same time/place
>> 	sort of defines "delay-tolerent" - no?  :)
>
> Kinda true.  Yet, sometimes we might just get better attention
> (or be more attentive ourselves :-) when the peer to test with is
> sitting across the table.  Plus you cannot get disturbed from your
> lab/office environment.
>
> Maybe just let's get as much of both as possible (just being greedy).
>
> Cheers,
> Joerg
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

--Apple-Mail-1--411771245
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">What might help is to set up =
definite time slots (if we can't converge in space, lets at least =
converge in time) for one. &nbsp;Well in advance so everyone can pick a =
lab or conference room to be in (away from the office), and block it out =
on the corporate calendar ;(. &nbsp;How about setting up a skype =
conference (or other similar technology) for the time frame, so =
real-time conversations are possible.<div><br><div><div>On Apr 16, 2009, =
at 9:13 AM, Joerg Ott wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><blockquote type=3D"cite">On Thu, Apr 16, 2009 at =
12:48:38PM +0300, Joerg Ott wrote:<br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">What =
would work, to be a bit constructive here, is to =
have<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">remote =
only testing at some point. &nbsp;And if some people =
want<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">to get =
together at BBN at this point, this could be =
done<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">as =
well. &nbsp;But this should happen preferably _after_ the IETF =
as<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">it =
would allow some set of people to get a first round =
of<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">debugging done face-to-face. &nbsp;And we found that the =
timeframe<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">for =
the interop is tight already =
anyway...<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Actually, having this a bit =
later would also help getting =
out<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">of the main vacation periods :-) &nbsp;Or would the =
Disconnectathlon<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">lose too much if we move it =
later? &nbsp;Just curious whether =
people<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">got internal demands for earlier =
testing...<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>actually, =
this sounds almost ideal for testing dtn.<br></blockquote><blockquote =
type=3D"cite"><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>not having everyone present at the same =
time/place<br></blockquote><blockquote type=3D"cite"><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>sort of =
defines "delay-tolerent" - no? &nbsp;:)<br></blockquote><br>Kinda true. =
&nbsp;Yet, sometimes we might just get better attention<br>(or be more =
attentive ourselves :-) when the peer to test with is<br>sitting across =
the table. &nbsp;Plus you cannot get disturbed from your<br>lab/office =
environment.<br><br>Maybe just let's get as much of both as possible =
(just being =
greedy).<br><br>Cheers,<br>Joerg<br>______________________________________=
_________<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-1--411771245--

Date: Thu, 16 Apr 2009 09:27:36 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Joerg Ott <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

Joerg Ott wrote:
> Dan,
> 
> I disagree with your assessment.  *Any* additional trip is a burden
> these days, particularly since there are quite a few folks in
> Europe with implementations and several of them intend to
> attend the IETF (partly even just for this purpose).  Putting
> a second a trip right next to this is clearly not an option.

My assessment follows logically from the answers I received
to the emails I sent to this list on 3/24 and 4/6. The
simple fact is that among the groups who have responded so
far, only a small number currently plan to send anyone at
all to Stockholm.  The original thought was to have
something at both sites during IETF, but if it's true that
there will only be three DTNers in Stockholm (including
yourself) it doesn't seem worth the effort.

After IETF is not practical; people have too many other
conflicts in August and September.

And, as I mentioned in my previous email, it already appears
impossible to find a date that will work for everyone.
We'll do the best we can but someone isn't going to get what
they want.  The sooner people share their schedules, the
more likely it is we can find something that works for at
least the majority.

If people have different opinions, or simply haven't made
their plans yet, there is still time to adjust.  In the
meanwhile, I can only make plans based on information people
share with me.

-Dan

Date: Thu, 16 Apr 2009 16:13:02 +0300
From: Joerg Ott <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

> On Thu, Apr 16, 2009 at 12:48:38PM +0300, Joerg Ott wrote:
>>> What would work, to be a bit constructive here, is to have
>>> remote only testing at some point.  And if some people want
>>> to get together at BBN at this point, this could be done
>>> as well.  But this should happen preferably _after_ the IETF as
>>> it would allow some set of people to get a first round of
>>> debugging done face-to-face.  And we found that the timeframe
>>> for the interop is tight already anyway...
>> Actually, having this a bit later would also help getting out
>> of the main vacation periods :-)  Or would the Disconnectathlon
>> lose too much if we move it later?  Just curious whether people
>> got internal demands for earlier testing...
>>
> 
> 	actually, this sounds almost ideal for testing dtn.
> 	not having everyone present at the same time/place
> 	sort of defines "delay-tolerent" - no?  :)

Kinda true.  Yet, sometimes we might just get better attention
(or be more attentive ourselves :-) when the peer to test with is
sitting across the table.  Plus you cannot get disturbed from your
lab/office environment.

Maybe just let's get as much of both as possible (just being greedy).

Cheers,
Joerg

Date: Thu, 16 Apr 2009 12:48:38 +0300
From: Joerg Ott <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

> What would work, to be a bit constructive here, is to have
> remote only testing at some point.  And if some people want
> to get together at BBN at this point, this could be done
> as well.  But this should happen preferably _after_ the IETF as
> it would allow some set of people to get a first round of
> debugging done face-to-face.  And we found that the timeframe
> for the interop is tight already anyway...

Actually, having this a bit later would also help getting out
of the main vacation periods :-)  Or would the Disconnectathlon
lose too much if we move it later?  Just curious whether people
got internal demands for earlier testing...

Cheers,
Joerg

Date: Thu, 16 Apr 2009 11:20:55 +0300
From: Joerg Ott <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

Dan,

I disagree with your assessment.  *Any* additional trip is a burden
these days, particularly since there are quite a few folks in
Europe with implementations and several of them intend to
attend the IETF (partly even just for this purpose).  Putting
a second a trip right next to this is clearly not an option.

As we discussed at the interim meeting, we could have two
events running in parallel with local coordination among
the participants and some remote connections.  But we should
take advantage of people being co-located anyway whenever
possible.

So, this week is a no-go and so is the basic idea of adding
another trip to some random place.

What would work, to be a bit constructive here, is to have
remote only testing at some point.  And if some people want
to get together at BBN at this point, this could be done
as well.  But this should happen preferably _after_ the IETF as
it would allow some set of people to get a first round of
debugging done face-to-face.  And we found that the timeframe
for the interop is tight already anyway...

Joerg

Daniel Ellard wrote:
> It's clear that there's no date in July that works well for
> everyone (with holidays, vacations, other conferences,
> pre-existing commitments, etc), and many people are not
> planning to attend IETF in Stockholm or prefer to not mix
> the two events.
> 
> July 15-17 at BBN in Cambridge seems to be the most workable
> choice.  If it makes a huge difference to someone, we could
> move to earlier that week, but that seems like the sweet spot.
> 
> Please let me know if there's something impossible about
> that week.  I will start a page on the DTNRG wiki with more
> details, as soon as I get a few more things nailed down.
> 
> Thanks,
> 	-Dan
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 14 Apr 2009 22:52:43 +0200
From: Xiaoming Fu <[email-masked]>
Organization: University of Goettingen, Germany
To: [email-masked]
Subject: [dtn-interest] CFP: SIMPLEX 2009 - Simplifying Complex Networks

Our apologies if you receive multiple copies of this CFP:

Call For Papers Simplex 2009

1st Annual Workshop on Simplifying Complex Network for Practitioners

http://www.simplexconf.net
1st July 2009, Venice, Italy

Network Science, sometimes also called "complex networks science", has
recently attracted much attention from the scientific community, mainly
due to the almost ubiquitous presence of complex networks in real-world
systems. Examples of complex networks are found in living organisms, in
engineering systems, as well as in social networks. Most of the
real-world systems have  the required degree of complexity to be called
"complex systems". Complex may have to do with the intricate dynamics of
the interacting components, with the non-trivial properties of the
underlying network topology, or with the sheer size of the system itself.

Despite the numerous workshops and conferences related to network
science, it is still a set of loosely interacting communities. Those
communities would benefit from better interactions. Researchers in
network science can be categorized according to the theoretical school
from which they come, e.g. statistical physics, game theory, information
theory, distributed algorithms. Each school tackles a very particular
aspect of complex systems, like statistical interactions between
components, or the computation of the equilibrium of a particular
system. The assumptions made by each school to apply their theoretical
tools makes it very difficult for practitioners to apply their results
to practical situations.

Simplex is expected to trigger the communication networks community to
propose the topics that should be tackled from the network science
perspective, and let the network community explain how to best use their
tools for practical problems of communication networks. Two types of
contributions are foreseen from prospective authors. The first type
would consist of use-cases of theoretical tools and methods to solve
practical problems. Such contributions should be as usable as possible
by practitioners in the related field. The second type of contributions
would come from practitioners that have identified a problem that may be
solved by tools from network sciences. The point of such contributions
is to make the network sciences community aware of the importance of a
high-impact problem, and to suggest means by which the problem may be
solved by the network sciences community. Both contributions should
stimulate interaction between theoreticians and practitioners, and
also have high potential impact in either field.

Topics of interest include (but are not restricted to):

- Design of wired/wireless networks
- Representing and analyzing dynamic networks
- Network robustness to failures and attacks
- Mining of large scale networks
- Forwarding/routing for opportunistic network
- Mobility/connectivity modeling
- Anti-spam and Sybil attacks

All submitted papers will be carefully evaluated based on originality,
significance, technical soundness, and clarity of expression.

All submissions must be in English. Submissions should be in PDF format
and must not exceed 6 pages. After the workshop, proceedings will be
published by Springer-Verlag.

Steering Committee
Jon Crowcroft        University of Cambridge, UK
Steve Uhlig        Deutsche Telekom Laboratories/TU Berlin, Germany
Pan Hui            Deutsche Telekom Laboratories/TU Berlin, Germany
Walter Willinger    ATT research, USA

PC Co-chairs
Steve Uhlig         T-labs/TU Berlin, Germany
Pan Hui            T-labs/TU Berlin, Germany

Web Co-chairs
Fehmi Ben Abdesslem    University of St Andrews, UK
Nishanth Sastry        University of Cambridge, UK

TPC members
Alain Barrat        University of Marseille, France
Marian Boguna        University of Barcelona, Spain
Stefan Bornholdt    University of Bremen, Germany
Paul Bourgine        Ecole Polytechnique, France
Augustin Chaintreau    Thomson research lab, France
Mark Crovella        Boston University, USA
Nathan Eagle        MIT/Santa Fe Institute, USA
Damien Fey        McGill University, Canada
Marta Gonzalez        Northeastern University, USA
Pan Hui            T-labs/TU Berlin, Germany
Almerima Jamakovic    TNO ICT, Netherlands
Hawoong Jeong        KAIST, Korea
Dimitri Krioukov    CAIDA, USA
Matthieu Latapy        UPMC/LIP6, France
Vito Latora        University of Catania, Italy
Shishir Nagaraja    UIUC, USA
Clemence Magnien    UPMC/LIP6, France
Jose Mendes        University of Aveiro, Portugal
Richard Mortier        Vipadia Ltd., UK
Raul Mondragon        University of London, UK
Andrew Moore        University of Cambridge, UK
Nadine Peyrieras    INAF-CNRS, France
Michael Rabbat        McGill University, Canada
Nishanth Sastry        University of Cambridge, UK
Georgios Smaragdakis    Deutsche Telekom Laboratories, Germany
Steve Uhlig        T-labs/TU Berlin, Germany
Walter Willinger    AT&T research, USA
Shi Zhou        University College London, UK

Deadlines
Paper submission:             April 30, 2009
Notification of acceptance:         May 30, 2009
Registration deadline:            June 10, 2009
Workshop:                 July 1, 2009

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 10 Apr 2009 08:53:47 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Proposed date for the first DTN Disconnectathon:

Dan,

If you provide the DTN Agent EID and Convergence layer information and I put the appropriate lifetime on my bundle, I should be able to start interoperability testing with that future machine today. 

Maybe I only need the DTN Agent EID.  The "nearest" Bundle Agent should be able to discover the correct convergence layer - perhaps from the "near by" name resolver - were "near" means last hop and has nothing to do with distance.

.... Well, this is were we eventually want to get to, I think.   ;-)

/will

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Daniel Ellard
> Sent: Friday, April 10, 2009 9:20 AM
> To: [email-masked]
> Subject: [dtn-interest] Proposed date for the first DTN 
> Disconnectathon:
> 
> 
> It's clear that there's no date in July that works well for 
> everyone (with holidays, vacations, other conferences, 
> pre-existing commitments, etc), and many people are not 
> planning to attend IETF in Stockholm or prefer to not mix the 
> two events.
> 
> July 15-17 at BBN in Cambridge seems to be the most workable 
> choice.  If it makes a huge difference to someone, we could 
> move to earlier that week, but that seems like the sweet spot.
> 
> Please let me know if there's something impossible about that 
> week.  I will start a page on the DTNRG wiki with more 
> details, as soon as I get a few more things nailed down.
> 
> Thanks,
> 	-Dan
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Fri, 10 Apr 2009 09:20:03 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Proposed date for the first DTN Disconnectathon:

It's clear that there's no date in July that works well for
everyone (with holidays, vacations, other conferences,
pre-existing commitments, etc), and many people are not
planning to attend IETF in Stockholm or prefer to not mix
the two events.

July 15-17 at BBN in Cambridge seems to be the most workable
choice.  If it makes a huge difference to someone, we could
move to earlier that week, but that seems like the sweet spot.

Please let me know if there's something impossible about
that week.  I will start a page on the DTNRG wiki with more
details, as soon as I get a few more things nailed down.

Thanks,
	-Dan

Date: Thu, 9 Apr 2009 11:10:56 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] draft-irtf-dtnrg-uri-scheme

So following on from our meeting in Mountain View, the relevant
folks managed to get the -00 version of the DTN naming scheme
draft out without the list noticing for almost two weeks:-)

Please read it [1] and comment. There's plenty of scope for
lively discussion there!

Regards,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-dtn-uri-scheme

Date: Wed, 8 Apr 2009 09:34:48 -0700
From: Katia Obraczka <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Call for Participation NetSciCom'09 (in conjunction with INFOCOM'09)

The workshop program is now available from the workshop website at 
http://netscicom2009.asu.edu/program.html . 

==============================================================
              CALL FOR PARTICIPATION
   
                  NetSciCom 2009
  First IEEE International Workshop on Network Science
            For Communication Networks
  
         April 24, 2009 - Rio de Janeiro, Brazil
             http://netscicom2009.asu.edu/
   
          In conjunction with IEEE Infocom 2009
===============================================================
   
SCOPE: 
   
Network Science is a newly emerging discipline with applications in a
variety of domains, such as, Communication Networks, Power Grid
Networks, Transportation Networks, Social Networks, Biological Networks
and Economics. Designing complex communication networks of the future
needs a deep understanding of the interplay between the physical-, the
communication- and the social networks involved. An understanding of
such interdependency can only be achieved by closer interaction between
Network Scientists, Communication Network Designers, and Social and
Behavioral Scientists. The goal of this workshop is to a provide a forum
where this diverse group of researchers can meet and exchange ideas that
will lead to deeper insights into the design of robust, efficient and
complex communication networks of the future.
   
TOPICS OF INTEREST: 
   
The topics of this workshop lie at the intersection of Network Science
and Communication Network Design - including Topology Design and
Analysis, Traffic Modeling, Traffic Routing, Social Media Analysis:
blogs and friendship networks, Bio-inspired networks, Internet scale
measurement and analysis of online communities, Social network analysis
with mobile phone data, Interdependency between power grid,
communication and transportation networks,
   
==================================================================
   
WORKSHOP PROGRAM: 

The workshop program is now available from the workshop website at 
http://netscicom2009.asu.edu/program.html . 
      
Workshop date: April 24, 2009

==================================================================
   
PROGRAM CO-CHAIRS:
   
Arun Sen, Arizona State U.
Andrea Richa, Arizona State U.
Katia Obraczka, UC Santa Cruz

PROGRAM COMMITTEE:

J. Altmann, Seoul National University, Korea
M. Boguna, University of Barcelona, Spain
R. Bonneau, AFOSR
J. M. Coyle, ARO
J. J. Garcia-Luna-Aceves, UCSC
G. Konjevod, ASU
D. Krioukov, CAIDA, UC San Diego
M. Latapy, CNRS, France
C. Magnien, CNRS, France
R. Mateus, UFMG, Brazil
M. Mitzenmacher, Harvard Univ.
C. Qiao, Univ. Buffalo (SUNY)
K. Ramchandran, U.C. Berkeley
H. Sadjadpour, UCSC
C. Scheideler, T.U. Munich
E. Silva, UFRJ, Brazil
R. Ulman, ARO
P. Varaiya, U.C. Berkeley
J. Walrand, U.C. Berkeley
G. Xue, ASU
E. Zegura, Georgia Tech
T. Znati, NSF
  
===================================================================

Date: Wed, 08 Apr 2009 17:24:25 +0100
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "Slywczak, Richard A. \(GRC-MC00\)" <[email-masked]>, "Kollar, Thaddeus J. \(GRC-V000\)\[DB Consulting Group, Inc.\]" <[email-masked]>, vivek dave <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] A Small Query

We use Netem to do most of that. Works a treat really, ICMP
rtt of 40 minutes no problem:-)

S.

Ivancic, William D. (GRC-RHN0) wrote:
> NASA has a nice linux-base channel emulator that can vary the link
> characteristics for both directions.  You can put in errors, delays, and
> run cron jobs and such to take the link down.  Basically, this puts a
> Linux box in bridge mode.  The CD is self-booting so you can run it on
> any generic machine with two or more Ethernet ports.
>  
> Unfortunately, I cannot get to the web page and it may still only be
> available to US or US Government as it is extremely painful to release
> even the most benign software.
>  
> I couldn't and I'm internal NASA, but You might be able to get to it at:
>  
> http://channel-emulator.grc.nasa.gov/wiki/index.php?ChannelEmulator
>  
> Or, this may be an internal page.
>  
> http://pdf.aiaa.org/preview/CDReadyMMST06_1307/PV2006_6128.pdf
>  
>  
> Cached
> http://74.125.95.132/search?q=cache:40jlcoN9Zp8J:channel-emulator.grc.nasa.gov/+channel+emulator+grc&cd=2&hl=en&ct=clnk&gl=us
> <http://74.125.95.132/search?q=cache:40jlcoN9Zp8J:channel-emulator.grc.nasa.gov/+channel+emulator+grc&cd=2&hl=en&ct=clnk&gl=us>
>  
>  
>  
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
> 
>  
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On
>     Behalf Of *vivek dave
>     *Sent:* Wednesday, April 08, 2009 1:16 AM
>     *To:* [email-masked]
>     *Subject:* [dtn-interest] A Small Query
> 
>     Hi,
>     I just want to ask whether DTN2 has any special features for
>     simulating link delays, packet drops, link breaks, or asymmetric
>     channel rates, as we have OWLTSim in ION...Please reply as soon as
>     possible. Thank you
>     Regards,
>     Vivek Dave
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: vivek dave <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 8 Apr 2009 11:07:35 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Slywczak, Richard A. \(GRC-MC00\)" <[email-masked]>, "Kollar, Thaddeus J. \(GRC-V000\)\[DB Consulting Group, Inc.\]" <[email-masked]>
Subject: Re: [dtn-interest] A Small Query

--_000_3A5AA67A8B120B48825BFFCF5443856137DECA01A9NDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

NASA has a nice linux-base channel emulator that can vary the link characte=
ristics for both directions.  You can put in errors, delays, and run cron j=
obs and such to take the link down.  Basically, this puts a Linux box in br=
idge mode.  The CD is self-booting so you can run it on any generic machine=
 with two or more Ethernet ports.

Unfortunately, I cannot get to the web page and it may still only be availa=
ble to US or US Government as it is extremely painful to release even the m=
ost benign software.

I couldn't and I'm internal NASA, but You might be able to get to it at:

http://channel-emulator.grc.nasa.gov/wiki/index.php?ChannelEmulator

Or, this may be an internal page.

http://pdf.aiaa.org/preview/CDReadyMMST06_1307/PV2006_6128.pdf

Cached
http://74.125.95.132/search?q=3Dcache:40jlcoN9Zp8J:channel-emulator.grc.nas=
a.gov/+channel+emulator+grc&cd=3D2&hl=3Den&ct=3Dclnk&gl=3Dus

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

________________________________
From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of vivek dave
Sent: Wednesday, April 08, 2009 1:16 AM
To: [email-masked]
Subject: [dtn-interest] A Small Query

Hi,
I just want to ask whether DTN2 has any special features for simulating lin=
k delays, packet drops, link breaks, or asymmetric channel rates, as we hav=
e OWLTSim in ION...Please reply as soon as possible. Thank you
Regards,
Vivek Dave

--_000_3A5AA67A8B120B48825BFFCF5443856137DECA01A9NDJSSCC03ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009>NASA has a nice linux-base channel emulator that=
 can=20
vary the link characteristics for both directions.&nbsp; You can put in err=
ors,=20
delays, and run cron jobs and such to take the link down.&nbsp; Basically, =
this=20
puts a Linux box in bridge mode.&nbsp; The CD is self-booting so you can ru=
n it=20
on any generic machine with two or more Ethernet ports.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009>Unfortunately, I cannot get to the web page and =
it may=20
still only be available to US or US Government as it is extremely painful t=
o=20
release even the most benign software.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009>&nbsp;</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009>I couldn't and I'm internal NASA, but You might =
be able=20
to get to it at:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009><A=20
href=3D"http://channel-emulator.grc.nasa.gov/wiki/index.php?ChannelEmulator=
">http://channel-emulator.grc.nasa.gov/wiki/index.php?ChannelEmulator</A></=
SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009>Or, this may be an internal page.</SPAN></FONT><=
/DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009><A=20
href=3D"http://pdf.aiaa.org/preview/CDReadyMMST06_1307/PV2006_6128.pdf">htt=
p://pdf.aiaa.org/preview/CDReadyMMST06_1307/PV2006_6128.pdf</A></SPAN></FON=
T></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009>Cached</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009><A=20
href=3D"http://74.125.95.132/search?q=3Dcache:40jlcoN9Zp8J:channel-emulator=
.grc.nasa.gov/+channel+emulator+grc&amp;cd=3D2&amp;hl=3Den&amp;ct=3Dclnk&am=
p;gl=3Dus">http://74.125.95.132/search?q=3Dcache:40jlcoN9Zp8J:channel-emula=
tor.grc.nasa.gov/+channel+emulator+grc&amp;cd=3D2&amp;hl=3Den&amp;ct=3Dclnk=
&amp;gl=3Dus</A></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP=
AN=20
class=3D750422415-08042009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV><!-- Co=
nverted from text/plain format -->
<P><FONT size=3D2>******************************<BR>William D. Ivancic<BR>P=
hone=20
216-433-3494<BR>Fax 216-433-8705<BR>Networking Lab 216-433-2620<BR>DTN Lab=
=20
216-433-2981<BR>Mobile 440-503-4892<BR><A=20
href=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~iv=
ancic</A><BR></FONT></P>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B>=20
  [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf O=
f=20
  </B>vivek dave<BR><B>Sent:</B> Wednesday, April 08, 2009 1:16 AM<BR><B>To=
:</B>=20
  [email-masked]<BR><B>Subject:</B> [dtn-interes=
t] A=20
  Small Query<BR></FONT><BR></DIV>
  <DIV></DIV>Hi, <BR>I just want to ask whether DTN2 has any special featur=
es=20
  for simulating link delays, packet drops, link breaks, or asymmetric chan=
nel=20
  rates, as we have OWLTSim in ION...Please reply as soon as possible. Than=
k=20
  you<BR>Regards,<BR>Vivek Dave<BR></BLOCKQUOTE></BODY></HTML>

--_000_3A5AA67A8B120B48825BFFCF5443856137DECA01A9NDJSSCC03ndcn_--

Date: Wed, 8 Apr 2009 00:16:09 -0500
From: vivek dave <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] A Small Query

--0016e64355e4bbcd200467043aec
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,
I just want to ask whether DTN2 has any special features for simulating link
delays, packet drops, link breaks, or asymmetric channel rates, as we have
OWLTSim in ION...Please reply as soon as possible. Thank you
Regards,
Vivek Dave

--0016e64355e4bbcd200467043aec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi, <br>I just want to ask whether DTN2 has any special features for simulating link delays, packet drops, link breaks, or asymmetric channel rates, as we have OWLTSim in ION...Please reply as soon as possible. Thank you<br>
Regards,<br>Vivek Dave<br>

--0016e64355e4bbcd200467043aec--

Date: Mon, 6 Apr 2009 15:27:11 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] March Meeting notes...

...are here [1] and I've updated the meeting info page [2]
a bit with slides etc.

I'll post to the IETF proceedings in about a week, feel
free to send corrections in the meantime.

In particular, I don't think the actual attendee list [3] is
quite correct, so let me know if I should fix that (if you
care:-)

Ta,
S.

[1] http://down.dsg.cs.tcd.ie/dtnrg-at-google/MeetingNotes.html
[2] http://down.dsg.cs.tcd.ie/dtnrg-at-google/
[3] http://down.dsg.cs.tcd.ie/dtnrg-at-google/attended.txt

From: "Scott, Keith L." <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 6 Apr 2009 10:14:03 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Initial planning for the first DTN Disconnectathon	[again]

I've got two hats at MITRE, one for the DARPA team and one for some MITRE internal R&D using DTN.

For the internal R&D work, we're working on a number of experimental features (various forms of multicast support, 'enhanced' neighbor discovery, augmented routing information) but we haven't even gotten to spec'ing these out so interoperability testing isn't an issue this round.

If it were to be useful for us to attend, Stockholm is almost surely not the right answer, and I would vote for 'split between BBN and Stockholm' (if there is going to be sufficient attendance at Stockholm) or at BBN a few weeks prior.

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Ellard
Sent: Monday, April 06, 2009 10:00 AM
To: [email-masked]
Subject: [dtn-interest] Initial planning for the first DTN Disconnectathon [again]

I'm sending this again, because I suspect that for many of
you, the first message got lost in the noise during IETF
week.  In any case, the response has been minimal, with each
choice having exactly one vote so far.

I know July is a long way off, but things fill up quickly.

- - - -

For those of you who did not attend the DTNRG meeting last
week, one idea that was proposed (and received positively)
was to have regular meetings where all the people writing
BPAs, apps, and other DTN-related software could get
together in the same room and do interoperability,
compatibility, and other hands-on testing.

The basic idea is taken from the "Connectathons"
(http://www.connectathon.org/) organized by the NFS
community, and so the name "Disconnectathon" was proposed.
(Don't like the name?  Propose a better one... on a
different thread, please.  Let's plan it first.)

The first question is when to have the first one.  A
proposal was to do it during the next IETF meeting, in
Stockholm, at the end of July.  This isn't perfectly ideal
for several reasons, however, most importantly the cost of
having everyone attend IETF and travel to Stockholm.  A
second proposal was to have two concurrent (and
network-connected Disconnectathons--one in Stockholm, for
IETF attendees, and the second in Boston, hosted by BBN.  A
third idea is to schedule the Disconnectathon a week or two
prior to the IETF meeting, to make it a preamble to the
DTNRG and IETF meetings.  Again, BBN is happy to host the
meeting, if Boston is a good location for everyone.

In any case, given the complicated logistics of planning
something around the IETF (or during the height of summer
vacation season) I think it makes sense to choose one of
these approaches soon, and start nailing down dates.
Therefore, if the idea of a Disconnectathon appeals to you,
please send me your current best guess of:

1.  Which schedule/site works best for you:

	a)  At and during the IETF meeting

	b)  Split between BBN and the IETF meeting

	c)  A week or two beforehand, at BBN or elsewhere

	d)  Some other option (please elaborate)

2.  How many people you anticipate sending to your preferred
choice.  If your preference is b), please provide numbers
for each location.

3.  Any suggestions you have.

Thanks,
	-Dan

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 06 Apr 2009 09:59:32 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Initial planning for the first DTN Disconnectathon [again]

I'm sending this again, because I suspect that for many of
you, the first message got lost in the noise during IETF
week.  In any case, the response has been minimal, with each
choice having exactly one vote so far.

I know July is a long way off, but things fill up quickly.

- - - -

For those of you who did not attend the DTNRG meeting last
week, one idea that was proposed (and received positively)
was to have regular meetings where all the people writing
BPAs, apps, and other DTN-related software could get
together in the same room and do interoperability,
compatibility, and other hands-on testing.

The basic idea is taken from the "Connectathons"
(http://www.connectathon.org/) organized by the NFS
community, and so the name "Disconnectathon" was proposed.
(Don't like the name?  Propose a better one... on a
different thread, please.  Let's plan it first.)

The first question is when to have the first one.  A
proposal was to do it during the next IETF meeting, in
Stockholm, at the end of July.  This isn't perfectly ideal
for several reasons, however, most importantly the cost of
having everyone attend IETF and travel to Stockholm.  A
second proposal was to have two concurrent (and
network-connected Disconnectathons--one in Stockholm, for
IETF attendees, and the second in Boston, hosted by BBN.  A
third idea is to schedule the Disconnectathon a week or two
prior to the IETF meeting, to make it a preamble to the
DTNRG and IETF meetings.  Again, BBN is happy to host the
meeting, if Boston is a good location for everyone.

In any case, given the complicated logistics of planning
something around the IETF (or during the height of summer
vacation season) I think it makes sense to choose one of
these approaches soon, and start nailing down dates.
Therefore, if the idea of a Disconnectathon appeals to you,
please send me your current best guess of:

1.  Which schedule/site works best for you:

	a)  At and during the IETF meeting

	b)  Split between BBN and the IETF meeting

	c)  A week or two beforehand, at BBN or elsewhere

	d)  Some other option (please elaborate)

2.  How many people you anticipate sending to your preferred
choice.  If your preference is b), please provide numbers
for each location.

3.  Any suggestions you have.

Thanks,
	-Dan

From: "Symington, Susan F." <[email-masked]>
To: dtn interest <[email-masked]>
Date: Fri, 3 Apr 2009 17:16:11 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-retrans-block-05

All,

I just submitted a new version of the Retransmission Block I-D. This revision responds to comments received so far. In particular, it addresses the concern that Stephen raised at the mountain view meeting that an adversary who has compromised a key could use this key and the Retransmission Block to perpetrate an insertion attack. I have addressed this concern by requiring nodes to identify duplicates not just as bundles that have the same source, creation timestamp and fragment info (if a fragment) as each other, but also to take into consideration the payload of the bundles. Instead of storing the actual payload, a checksum or digest of it can be calculated and stored.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: IETF I-D Submission Tool [mailto:[email-masked]]
>Sent: Friday, April 03, 2009 5:05 PM
>To: Symington, Susan F.
>Subject: New Version Notification for draft-irtf-dtnrg-bundle-retrans-
>block-05
>
>
>A new version of I-D, draft-irtf-dtnrg-bundle-retrans-block-05.txt has
>been successfuly submitted by Susan Symington and posted to the IETF
>repository.
>
>Filename:	 draft-irtf-dtnrg-bundle-retrans-block
>Revision:	 05
>Title:		 Delay-Tolerant Networking Retransmission Block
>Creation_date:	 2009-04-03
>WG ID:		 Independent Submission
>Number_of_pages: 18
>
>Abstract:
>This document defines an optional extension block, called a
>Retransmission Block (RB), that may be used with the Bundle Protocol
>[refs.DTNBP] within the context of a Delay-Tolerant Network
>architecture [refs.DTNarch].  The Retransmission Block (RB) is
>designed to be used within a DTN that, as a matter of policy, deletes
>all replayed bundles from the network.  It is designed to be used in
>a network that permits duplicate bundles to be forwarded if those
>bundles have been retransmitted by a custodian, that may (if
>possible) permit duplicate bundles to be forwarded if those bundles
>are in intentional or unintentional routing loops (contingent on the
>availability of mechanisms to distinguish looping bundles from other
>bundles), but that will consider all other duplicate bundles to be
>maliciously replayed bundles and delete them as such.  The
>Retransmission Block is designed to be inserted into a bundle by a
>custodian when the custodian is retransmitting that bundle.  The
>purpose of the RB is to mark the bundle as a custody-based
>retransmission so that it can be distinguished from other types of
>duplicate bundles and thereby be spared from deletion.  This document
>defines the format and processing of this new Retransmission Block.
>
>
>
>The IETF Secretariat.
>

From: "Symington, Susan F." <[email-masked]>
To: dtn interest <[email-masked]>
Date: Fri, 3 Apr 2009 16:36:08 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-03

This new draft incorporates the recent suggestions regarding defining a block of numbers for private metadata types.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: IETF I-D Submission Tool [mailto:[email-masked]]
>Sent: Friday, April 03, 2009 4:32 PM
>To: Symington, Susan F.
>Subject: New Version Notification for draft-irtf-dtnrg-bundle-metadata-
>block-03
>
>
>A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-03.txt has
>been successfuly submitted by Susan Symington and posted to the IETF
>repository.
>
>Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>Revision:	 03
>Title:		 Delay-Tolerant Networking Metadata Extension Block
>Creation_date:	 2009-04-03
>WG ID:		 Independent Submission
>Number_of_pages: 12
>
>Abstract:
>This document defines an extension block that may be used with the
>Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>Network architecture [refs.DTNarch].  This Metadata Extension Block
>is designed to be used to carry application-level information that
>DTN nodes can use to make DTN-level processing decisions regarding
>bundles, such as deciding whether to store a bundle or determining to
>which nodes to forward a bundle.  The actual metadata that is carried
>in a metadata block must be formatted according to the metadata type
>that is identified in the block's metadata type field.  One specific
>metadata type, for encoding metadata as URIs, is defined in this
>document.  Other metadata types may be defined in separate documents.
>
>
>
>The IETF Secretariat.
>

From: Steve Crocker <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 3 Apr 2009 15:35:44 -0400
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] DTN Network Management Subgroup - Meeting Notes for 30 March 2009 Teleconference

--Apple-Mail-78-634623371
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

"On April 17, at APL's Laurel Maryland facilities, there will be a =20
face-to-face between ... and others "

Please count us in among the others.

At present, I have a meeting at 2:00 in Columbia, not far away.  If I =20=

can't adjust the timing of that meeting, I should at least be able to =20=

come for part of the meeting.

Thanks,

Steve

On Apr 3, 2009, at 12:16 PM, Ivancic, William D. (GRC-RHN0) wrote:

> DTN Network Management - Collaborators
> Meeting Notes for
> Monday, March 30, 2009
> 1:00 - 2:00 EST (18:00 - 19:00 UTC)
>
> A teleconference was held on Monday, March 30, 2009.
> These notes are to document this teleconference.
>
> The next teleconference will be Monday, April 13.
>
> On April 17, at APL's Laurel Maryland facilities, there will be a =20
> face-to-face between NASA Glenn Research Center, Applied Physic Lab, =20=

> Ohio University, University of Maryland - Baltimore Campus and =20
> perhaps participation from BBN, Goddard, Viag=E9nie (remote) and =20
> others - see below:
>
> Participants
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> .	BBN - Cambridge
> .	Hans Kruse,  - Ohio University
> .	Will Ivancic, Joseph Ishac, - NASA Glenn
> .	Scott Burleigh - NASA JPL
> .	Applied Physics Lab
> .	Keith Scott - MITRE
> .	Simon.Perreault - Viag=E9nie
>
> Agenda
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
> Quick brief of DTNRG meeting of 19,20 March at Google
> - Interoperable Utilities (DTN-2 and ION: ping, traceroute, send, =20
> receive, iperf)
>
> ***  Joseph Ishac of NASA Glenn has taken the action to work on =20
> making the Utilities on DTN-2 and ION interoperable with identical =20
> command line entries. ***
>
> *** We also can use some type of heartbeat application sent out =20
> periodically from bundle agents to an administrative node indicating =20=

> everything is OK and I am still alive. ***
>
> - Desire to get "something up and report something" (OU working)
>
> *** Ohio University is working on getting some SNMP type Network =20
> Monitoring for DTN up and running with perhaps a web-based interface =20=

> that people can log into to see the status of the DTNbone.  ***
>
> Quick brief of Network Management related working groups at IETF
> - netmod
> - netconf
> (It appears the framework and ideas of netconf and netmod may be =20
> useful, but management is over Bundling as well as ... SSH or =20
> something when in a connected environment)
>
> Discussion of Robert Coles draft on network management (need to test =20=

> before commit of configuration updates) =
http://tools.ietf.org/html/draft-cole-netconf-robust-config-00
>
> - Also notion of a "reporting interface" to multiple MIBs for =20
> autonomous reporting.
>
> *** netmod and netconf appear to have a lot of similarities to what =20=

> DTN may wish to do regarding remote DTN configuration.  Netmod and =20
> netconf basically came into existence because SNMP was not =20
> addressing network configuration very well (much do to the lack of =20
> security prior to SNMPv3).  ***
>
> *** Robert Coles of APL has proposed work related to remote network =20=

> configuration and graceful test and validation of configurations =20
> prior to a hard commit.  This would allow remote devices to back out =20=

> of configurations that cannot be validated.  This is useful in manet =20=

> networks and is probably necessary for DTNs. ***
>
> SNMP vs Netconf (ASN.1 vs XML) or Both
>
> *** This is an item for continued discussion and evaluation.  Jim =20
> McKim of GRC indicated that much of the hooks to get information out =20=

> of DTN-2 are XSLT (the Extensible Stylesheet Language =20
> Transformations) based so working with XML appears fairly straight =20
> forward.  ****
>
> Requirements Document status - Ivancic
>
> *** No much has been done lately do to other commitments ***
>
> *** One requirement that was discussed was the need for bandwidth =20
> efficiency.  This was somewhat a side discussion regarding SNMP and =20=

> XML representations and the ability to compress such formats.  For =20
> space-based systems, compression (processing is an issue onboard) =20
> and bandwidth is an issue over links.  The space-base processors may =20=

> not be capable of doing all the necessary compressions and =20
> processing.  In such a case, a spacecraft operator may decide to =20
> forgo use of DTN network management and instead provide their own =20
> system that uses custom telemetry. Such may be unavoidable and =20
> should be noted in the requirements document as a trade-off. ***
>
> Face-to-Face meeting scheduled for April 17 at John Hopkins APL (to =20=

> get University of Maryland Baltimore Campus involved).
>
> *******  Goal of the April 17th Meeting:  ********
>
> 1) Divide work between APL and GRC to avoid overlap and maximize =20
> resources
> 2) Bring University of Maryland Baltimore Campus online
> 3) Leverage DTNbone to test and exercise Network Management
>
>
> 1st Draft of the agenda below as a starting point for discussion and =20=

> revision.
>
> April 17th Agenda (in no particular order yet)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> DTN test utilities - Joseph Ishac
> - DTN heartbeat (still alive and everything is OK message)
>
> DTN applications (traffic generator)
> - we need traffic to flow to test things
>
> DTN network management
> - Monitoring
> - Configuration
> *** Test Configuration and graceful back out (Robert Coles - APL)
> *** Highly suspect network management will be used for Security (key =20=

> distribution) as well as contact information for contact graph =20
> routing and other such items.
>
> SNMP reuse vs other stuff
> - XML representations or not or both?
>
> DTN-2 Code (pulling out BBN MIBs) - Jim McKim (NASA GRC)
>
> MANET network management experience and lessons learned (APL, BBN?)
>
>
>
> ******************************
> Submitted by Will Ivancic
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-78-634623371
Content-Type: text/html;
	charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">"On April 17, at APL's Laurel =
Maryland facilities, there will be a face-to-face between ... and =
others&nbsp;"<div><br></div><div>Please count us in among the =
others.<br><div><br></div><div>At present, I have a meeting at 2:00 in =
Columbia, not far away. &nbsp;If I can't adjust the timing of that =
meeting, I should at least be able to come for part of the =
meeting.</div><div><br></div><div>Thanks,</div><div><br></div><div>Steve</=
div><div><br></div><div><br></div><div><br></div><div><br><div><div>On =
Apr 3, 2009, at 12:16 PM, Ivancic, William D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>DTN =
Network Management - Collaborators<br>Meeting Notes for<br>Monday, March =
30, 2009<br>1:00 - 2:00 EST (18:00 - 19:00 UTC)<br><br>A teleconference =
was held on Monday, March 30, 2009.<br>These notes are to document this =
teleconference.<br><br>The next teleconference will be Monday, April 13. =
<br><br>On April 17, at APL's Laurel Maryland facilities, there will be =
a face-to-face between NASA Glenn Research Center, Applied Physic Lab, =
Ohio University, University of Maryland - Baltimore Campus and perhaps =
participation from BBN, Goddard, Viag=E9nie (remote) and others - see =
below:<br><br>Participants<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>.=
<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>BBN - Cambridge<br>.<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Hans Kruse, &nbsp;- Ohio =
University<br>.<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Will Ivancic, Joseph Ishac, - NASA Glenn<br>.<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Scott =
Burleigh - NASA JPL<br>.<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Applied Physics Lab<br>.<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Keith =
Scott - MITRE<br>.<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Simon.Perreault - =
Viag=E9nie<br><br>Agenda<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Quick brief =
of DTNRG meeting of 19,20 March at Google<br>- Interoperable Utilities =
(DTN-2 and ION: ping, traceroute, send, receive, iperf)<br><br>*** =
&nbsp;Joseph Ishac of NASA Glenn has taken the action to work on making =
the Utilities on DTN-2 and ION interoperable with identical command line =
entries. ***<br><br>*** We also can use some type of heartbeat =
application sent out periodically from bundle agents to an =
administrative node indicating everything is OK and I am still alive. =
***<br><br>- Desire to get "something up and report something" (OU =
working)<br><br>*** Ohio University is working on getting some SNMP type =
Network Monitoring for DTN up and running with perhaps a web-based =
interface that people can log into to see the status of the DTNbone. =
&nbsp;***<br><br>Quick brief of Network Management related working =
groups at IETF<br>- netmod<br>- netconf<br>(It appears the framework and =
ideas of netconf and netmod may be useful, but management is over =
Bundling as well as ... SSH or something when in a connected =
environment)<br><br>Discussion of Robert Coles draft on network =
management (need to test before commit of configuration updates) <a =
href=3D"http://tools.ietf.org/html/draft-cole-netconf-robust-config-00">ht=
tp://tools.ietf.org/html/draft-cole-netconf-robust-config-00</a><br><br> =
- Also notion of a "reporting interface" to multiple MIBs for autonomous =
reporting.<br><br>*** netmod and netconf appear to have a lot of =
similarities to what DTN may wish to do regarding remote DTN =
configuration. &nbsp;Netmod and netconf basically came into existence =
because SNMP was not addressing network configuration very well (much do =
to the lack of security prior to SNMPv3). &nbsp;***<br><br>*** Robert =
Coles of APL has proposed work related to remote network configuration =
and graceful test and validation of configurations prior to a hard =
commit. &nbsp;This would allow remote devices to back out of =
configurations that cannot be validated. &nbsp;This is useful in manet =
networks and is probably necessary for DTNs. ***<br><br>SNMP vs Netconf =
(ASN.1 vs XML) or Both<br><br>*** This is an item for continued =
discussion and evaluation. &nbsp;Jim McKim of GRC indicated that much of =
the hooks to get information out of DTN-2 are XSLT (the Extensible =
Stylesheet Language Transformations) based so working with XML appears =
fairly straight forward. &nbsp;****<br><br>Requirements Document status =
- Ivancic<br><br>*** No much has been done lately do to other =
commitments ***<br><br>*** One requirement that was discussed was the =
need for bandwidth efficiency. &nbsp;This was somewhat a side discussion =
regarding SNMP and XML representations and the ability to compress such =
formats. &nbsp;For space-based systems, compression (processing is an =
issue onboard) and bandwidth is an issue over links. &nbsp;The =
space-base processors may not be capable of doing all the necessary =
compressions and processing. &nbsp;In such a case, a spacecraft operator =
may decide to forgo use of DTN network management and instead provide =
their own system that uses custom telemetry. Such may be unavoidable and =
should be noted in the requirements document as a trade-off. =
***<br><br>Face-to-Face meeting scheduled for April 17 at John Hopkins =
APL (to get University of Maryland Baltimore Campus =
involved).<br><br>******* &nbsp;Goal of the April 17th Meeting: =
&nbsp;********<br><br>1) Divide work between APL and GRC to avoid =
overlap and maximize resources<br>2) Bring University of Maryland =
Baltimore Campus online<br>3) Leverage DTNbone to test and exercise =
Network Management <br><br><br>1st Draft of the agenda below as a =
starting point for discussion and revision.<br><br>April 17th Agenda (in =
no particular order =
yet)<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<b=
r><br>DTN test utilities - Joseph Ishac<br>- DTN heartbeat (still alive =
and everything is OK message)<br><br>DTN applications (traffic =
generator)<br> - we need traffic to flow to test things<br><br>DTN =
network management<br> - Monitoring<br> - Configuration<br> *** Test =
Configuration and graceful back out (Robert Coles - APL)<br> *** Highly =
suspect network management will be used for Security (key distribution) =
as well as contact information for contact graph routing and other such =
items.<br><br>SNMP reuse vs other stuff<br> - XML representations or not =
or both?<br><br>DTN-2 Code (pulling out BBN MIBs) - Jim McKim (NASA =
GRC)<br><br>MANET network management experience and lessons learned =
(APL, BBN?)<br><br><br><br>******************************<br>Submitted =
by Will =
Ivancic<br><br>_______________________________________________<br>dtn-inte=
rest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</div></blockquote></div><br></div></div></body></html>=

--Apple-Mail-78-634623371--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: DTN <[email-masked]>
Date: Fri, 3 Apr 2009 11:16:50 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN Network Management Subgroup - Meeting Notes for 30 March 2009 Teleconference

DTN Network Management - Collaborators
Meeting Notes for
Monday, March 30, 2009
1:00 - 2:00 EST (18:00 - 19:00 UTC)

A teleconference was held on Monday, March 30, 2009.
These notes are to document this teleconference.

The next teleconference will be Monday, April 13. 

On April 17, at APL's Laurel Maryland facilities, there will be a face-to-face between NASA Glenn Research Center, Applied Physic Lab, Ohio University, University of Maryland - Baltimore Campus and perhaps participation from BBN, Goddard, Viagénie (remote) and others - see below:

Participants
=============
.	BBN - Cambridge
.	Hans Kruse,  - Ohio University
.	Will Ivancic, Joseph Ishac, - NASA Glenn
.	Scott Burleigh - NASA JPL
.	Applied Physics Lab
.	Keith Scott - MITRE
.	Simon.Perreault - Viagénie

Agenda
=========
Quick brief of DTNRG meeting of 19,20 March at Google
- Interoperable Utilities (DTN-2 and ION: ping, traceroute, send, receive, iperf)

***  Joseph Ishac of NASA Glenn has taken the action to work on making the Utilities on DTN-2 and ION interoperable with identical command line entries. ***

*** We also can use some type of heartbeat application sent out periodically from bundle agents to an administrative node indicating everything is OK and I am still alive. ***

- Desire to get "something up and report something" (OU working)

*** Ohio University is working on getting some SNMP type Network Monitoring for DTN up and running with perhaps a web-based interface that people can log into to see the status of the DTNbone.  ***

Quick brief of Network Management related working groups at IETF
- netmod
- netconf
(It appears the framework and ideas of netconf and netmod may be useful, but management is over Bundling as well as ... SSH or something when in a connected environment)

Discussion of Robert Coles draft on network management (need to test before commit of configuration updates) http://tools.ietf.org/html/draft-cole-netconf-robust-config-00

 - Also notion of a "reporting interface" to multiple MIBs for autonomous reporting.

*** netmod and netconf appear to have a lot of similarities to what DTN may wish to do regarding remote DTN configuration.  Netmod and netconf basically came into existence because SNMP was not addressing network configuration very well (much do to the lack of security prior to SNMPv3).  ***

*** Robert Coles of APL has proposed work related to remote network configuration and graceful test and validation of configurations prior to a hard commit.  This would allow remote devices to back out of configurations that cannot be validated.  This is useful in manet networks and is probably necessary for DTNs. ***

SNMP vs Netconf (ASN.1 vs XML) or Both

*** This is an item for continued discussion and evaluation.  Jim McKim of GRC indicated that much of the hooks to get information out of DTN-2 are XSLT (the Extensible Stylesheet Language Transformations) based so working with XML appears fairly straight forward.  ****

Requirements Document status - Ivancic

*** No much has been done lately do to other commitments ***

*** One requirement that was discussed was the need for bandwidth efficiency.  This was somewhat a side discussion regarding SNMP and XML representations and the ability to compress such formats.  For space-based systems, compression (processing is an issue onboard) and bandwidth is an issue over links.  The space-base processors may not be capable of doing all the necessary compressions and processing.  In such a case, a spacecraft operator may decide to forgo use of DTN network management and instead provide their own system that uses custom telemetry. Such may be unavoidable and should be noted in the requirements document as a trade-off. ***

Face-to-Face meeting scheduled for April 17 at John Hopkins APL (to get University of Maryland Baltimore Campus involved).

*******  Goal of the April 17th Meeting:  ********

1) Divide work between APL and GRC to avoid overlap and maximize resources
2) Bring University of Maryland Baltimore Campus online
3) Leverage DTNbone to test and exercise Network Management 

1st Draft of the agenda below as a starting point for discussion and revision.

April 17th Agenda (in no particular order yet)
==============================================

DTN test utilities - Joseph Ishac
- DTN heartbeat (still alive and everything is OK message)

DTN applications (traffic generator)
 - we need traffic to flow to test things

DTN network management
 - Monitoring
 - Configuration
 *** Test Configuration and graceful back out (Robert Coles - APL)
 *** Highly suspect network management will be used for Security (key distribution) as well as contact information for contact graph routing and other such items.

SNMP reuse vs other stuff
 - XML representations or not or both?

DTN-2 Code (pulling out BBN MIBs) - Jim McKim (NASA GRC)

MANET network management experience and lessons learned (APL, BBN?)

******************************
Submitted by Will Ivancic

From: "Symington, Susan F." <[email-masked]>
To: Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Fri, 3 Apr 2009 10:28:27 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] FW: New Version Notification	for	draft-irtf-dtnrg-bundle-metadata-block-02

Nacho,

I think we have converged. My responses are below. Thanks for your suggested wording about user-defined types.

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ignacio
>Solis
>Sent: Thursday, April 02, 2009 6:02 PM
>To: dtn interest
>Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-
>dtnrg-bundle-metadata-block-02
>
>Symington, Susan F. wrote:
>>>>> I assume the "make this information available for use" includes
>>>>> some way
>>>>> for
>>>>> the node to make this information available to apps. Maybe that
>>>>> should
>>>>> be more
>>>>> explicit? Or is this covered by another RFC?
>>>>>
>>>> [Susan] It isn't the intent that this be covered by another RFC. The
>>>> intent is that the DTN BPA processing the metadata block be able to
>>>> extract the metadata from the metadata block and use this metadata
>>>> as it was intended (which is somewhat dependent on the metadata type
>>>> being used and the metadata itself, and may also depend on local
>>>> policy). It is really difficult to envision how we can be more
>>>> specific than this unless we want to talk about the particulars of a
>>>> specific metadata type. (The I-D already mentions bundle storage or
>>>> forwarding decisions as examples of how the metadata could be used.)
>>>>
>>>> The purpose of the metadata is to enable DTN nodes to make network-
>>>> level decisions regarding how to process bundles. I wasn't thinking
>>>> that this metadata would be or would need to be made available to an
>>>> application, unless perhaps the application is the destination of
>>>> the bundle.
>>> Well, at some point there will be an application that wants to add
>>> metadata.  Is this not covered by this I-D or is it covered by
>>>  - Generating a Metadata Block and inserting it into a bundle
>>>
>>> Or do we envision that only the internals of the routing will be the
>>> one adding metadata? If the metadata is "application-level
>>> information" then it seems appropriate that applications have access
>>> to it.
>>>
>> [Susan]
>> When a bundle is forwarded from node to node within a DTN, the
>forwarding nodes at each hop don't typically deliver that bundle to
>applications that they may have running on them unless those
>applications are the destination of the bundle.  It is hard for me to
>imagine how you envision applications at these intermediate-hop nodes
>becoming involved with a bundle that is passing through them. How would
>they even become aware of the bundle?
>
>I was actually thinking of end-to-end apps.

[Susan] 
Well, that's a relief!  Yes, the source app is envisioned to be able to provide metadata for the bundle similar to the way it can provide the payload for the bundle. Likewise the metadata can be delivered to the destination application along with the payload. No problem. It's the BPA that actually generates the bundle and the blocks though, so the BPA is what has to be capable of generating the metadata block (and the payload block, for that matter). That's all that this part of the I-D is talking about. 

>
>> I do envision that in some cases the BPAs of intermediate nodes that
>support both the metadata block and the metadata type being used may
>want to add metadata, and yes, I see this as being covered by the
>ability to insert a metadata block into the bundle (and delete an old
>block if need be).
>
>That's probably fine with the current I-D.
>
>
>>>>> Shouldn't we define a "user-defined" meta-data type just like we
>are
>>>>> defining
>>>>> the URI (0x01) type? Or do we want to leave this to IANA?  Also,
>>>>> initially I
>>>>> thought that we might need to specify the encoding of the URI, but
>I
>>>>> guess RFC
>>>>> 3986 says that percentage encoded octets might be used for non-
>ascii
>>>>> characters (depending on schema).
>>>>>
>>>> [Susan]I envision lots of different user-defined metadata types, and
>>>> those types can be identified by 0x02, 0x03, .... As someone defines
>>>> a new metadata type, they would use the "next" number to identify
>>>> it. Registration with IANA can ensure global uniqueness.  (This is
>>>> basically what we are doing now as we define new block types.)
>>> Well, to me something that requires IANA participation is not
>>> considered user-defined.   If anything IANA could define which type
>>> counts as user defined, just like we have 10/8 or 192.168/16.  I can
>>> use this without fear to collide with official definitions within my
>>> own network.
>>>
>> [Susan]
>> I see, are you suggesting that in the I-d we should define a segment
>of numbers that people are free to use to experiment with?  I'm happy to
>do that if that's what you want. Do you have a specific suggestion for
>wording I should put in? That might be the easiest way to make sure the
>text is suitable to you. Even with a segment of IDs that users can use
>for their user-defined metadata types, though, isn't it is still
>possible that two different users will select the same number and
>collide with each other?
>
>It is true that they might collide. We suffer the same problem with 10/8
>and
>the like. But for testing I think this is useful and doesn't carry a
>high cost.
>
>I have no idea what the best wording is. I assume it would require
>modifying
>section 4.
>
>
>4. Predefined Metadata Types
>   As mentioned in the previous section, any number of different
>   metadata types may be defined to indicate the format of both the
>   metadata field and the EID references in the optional EID Reference
>   Count and List field (if present) and, if necessary, how metadata of
>   this type should be processed. Two metadata types are predefined in
>   this document, URI Metadata Type (0x01) and Private Metadata Type
>(0x02).

[Susan] 
Thank you very much for this wording. I will add it to the I-D, but specifying a range of user-defined types (as Peter Lovell suggested) instead of just one single type.
>
>4.1  URI Metadata Type (0x01)
>   It is believed that use of URIs will ...
>
>
>4.2  Private Metadata Type (0x02)
>   The metadata type 0x02 has been reserved as Private Metadata Type.
>   It can be used for private, testing, experimental or local metadata
>   without registration with IANA.  Local policy will define how the
>   metadata type 0x02 is handled. Processing, generating, forwarding,
>   storing and deleting metadata type 0x02 is OPTIONAL.
>
>
>
>BTW, I'm not one of the URI supporters, though I don't mind it being one
>of
>the types.
>
[Susan] Ditto for me.
>
>
>-------
>Nacho
>
>>>>> Symington, Susan F. wrote:
>>>>>> All,
>>>>>>
>>>>>> I just posted a revision to the DTN Metadata Block I-D.  I tried
>to
>>>>> respond to the many good comments and suggestions that I got from
>>>>> Joerg,
>>>>> Stephen, and Kevin. Both the discussion that we had recently at
>>>>> Mountain
>>>>> View and recent email exchanges in response to postings from
>>>>> Armando and
>>>>> Nacho also helped.
>>>>>> As you will see, I am trying to strike a compromise between
>Kevin's
>>>>> desire to use URIs as THE metadata type and competing desires for a
>>>>> more
>>>>> efficient alternative. I defined a URI metadata type in this I-D
>>>>> and if
>>>>> someone wants, they can just use that. But if someone wants to
>define
>>>>> their own metadata type, that's okay too.
>>>>>> I also added some text about what the appropriate (and
>>>>>> inappropriate)
>>>>> uses of the block might be, since folks seemed to want this. Thank
>>>>> you,
>>>>> Nacho, for your good examples.
>>>>>> Please let me know what you think. Thanks!
>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-
>>>>>> metadata-
>>>>> block-02.txt
>>>>>> -susan
>>>>>>
>>>>>> *****************************************************************
>>>>>> Susan Symington
>>>>>> The MITRE Corporation
>>>>>> [email-masked]
>>>>>> 703-983-7209 (voice)
>>>>>> 703-983-7142 (fax)
>>>>>> ******************************************************************
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>>>>>>> Sent: Tuesday, March 31, 2009 4:38 PM
>>>>>>> To: Symington, Susan F.
>>>>>>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-
>>>>> metadata-
>>>>>>> block-02
>>>>>>>
>>>>>>>
>>>>>>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-
>02.txt
>>>>> has
>>>>>>> been successfuly submitted by Susan Symington and posted to the
>>>>>>> IETF
>>>>>>> repository.
>>>>>>>
>>>>>>> Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>>>>>>> Revision:	 02
>>>>>>> Title:		 Delay-Tolerant Networking Metadata Extension
>Block
>>>>>>> Creation_date:	 2009-03-31
>>>>>>> WG ID:		 Independent Submission
>>>>>>> Number_of_pages: 12
>>>>>>>
>>>>>>> Abstract:
>>>>>>> This document defines an extension block that may be used with
>the
>>>>>>> Bundle Protocol [refs.DTNBP] within the context of a Delay-
>Tolerant
>>>>>>> Network architecture [refs.DTNarch].  This Metadata Extension
>Block
>>>>>>> is designed to be used to carry application-level information
>that
>>>>>>> DTN nodes can use to make DTN-level processing decisions
>regarding
>>>>>>> bundles, such as deciding whether to store a bundle or
>>>>>>> determining to
>>>>>>> which nodes to forward a bundle.  The actual metadata that is
>>>>>>> carried
>>>>>>> in a metadata block must be formatted according to the metadata
>>>>>>> type
>>>>>>> that is identified in the block's metadata type field.  One
>>>>>>> specific
>>>>>>> metadata type, for encoding metadata as URIs, is defined in this
>>>>>>> document.  Other metadata types may be defined in separate
>>>>>>> documents.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The IETF Secretariat.
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dtn-interest mailing list
>>>>>> [email-masked]
>>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Peter Lovell <[email-masked]>
To: Susan <[email-masked]>, Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 02 Apr 2009 20:42:08 -0400
Subject: [dtn-interest] Re(2): FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02

On Thu, Apr 2, 2009, Symington, Susan F. <[email-masked]> wrote:

>>Well, to me something that requires IANA participation is not
>>considered user-defined.   If anything IANA could define which type
>>counts as user defined, just like we have 10/8 or 192.168/16.  I can
>>use this without fear to collide with official definitions within my
>>own network.
>>
>[Susan]
>I see, are you suggesting that in the I-d we should define a segment of
>numbers that people are free to use to experiment with?  I'm happy to do
>that if that's what you want. Do you have a specific suggestion for
>wording I should put in? That might be the easiest way to make sure the
>text is suitable to you. Even with a segment of IDs that users can use
>for their user-defined metadata types, though, isn't it is still
>possible that two different users will select the same number and
>collide with each other?

BP has language of this kind, reserving block types 192 and up for
private/experimental use. Personally I suggest the range 192-249 for
that use, leaving 250 and up for future needs.

Regards.....Peter

Date: Thu, 2 Apr 2009 18:30:45 -0400
From: Rajesh Krishnan <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02

I agree with Susan's position that separate I-Ds/RFCs should cover
concrete metadata syntax and semantics.   As this community
experiments with multiple content networking approaches, we may need
different approaches to both syntax and semantics.    Particular
constraints of deep space and underwater networking may require
different approaches to metadata from say future content-oriented high
speed inter-networks.

Some folks may require high expressiveness, where others may want
sound and complete inference. Some folks may want to adopt the
semantic web technologies (W3C recommendations) to represent
meta-data; even so, they may disagree on whether the normative RDF/XML
serialization or an alternative terse form such as Manchester OWL
should be used.  Others may want to build on RFC 3466.   And I am sure
there are other alternatives.

If you are actively working in the area of content networking, please
propose concrete metadata syntax/semantics that builds on Susan's
metadata extension block that covers your requirements.   Multiple
proposals -- e.g., one focused on Space and another on Defense
applications -- may be useful to help determine how much generality is
needed in the metadata extension block.

Since this is an RG, an ObResearchyIdea:  Is an approach  based on
Encrypted Functions (http://en.wikipedia.org/wiki/Encrypted_function)
feasible here, in which the content routing function yields no
information about the content?

I wonder if one-way mappings f:Content -> Metadata are possible that
preserve certain semantics without giving any information about the
domain of discourse.  For example, given metadata for Content_A and
Content_B, can we permit inferences such as:

Node_1 wants Content_A
Metadata_B isA Metadata_A => Content_B isA Content_A
Conclude: Node_1 wants Content_B
(without uncovering anything further about Content_A or Content_B)

Best Regards,
Rajesh

On Thu Apr 2, 2009 at 2:51 PM, Symington, Susan F. <[email-masked]> wrote:
> My responses are below.
>
> -susan
>
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
>
>>-----Original Message-----
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of Ignacio
>>Solis
>>Sent: Thursday, April 02, 2009 1:49 PM
>>To: dtn interest
>>Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-
>>dtnrg-bundle-metadata-block-02
>>
>>A few things.
>>
>>I assume the "make this information available for use" includes some way
>>for
>>the node to make this information available to apps. Maybe that should
>>be more
>>explicit? Or is this covered by another RFC?
>>
> [Susan] It isn't the intent that this be covered by another RFC. The intent is that the DTN BPA processing the metadata block be able to extract the metadata from the metadata block and use this metadata as it was intended (which is somewhat dependent on the metadata type being used and the metadata itself, and may also depend on local policy). It is really difficult to envision how we can be more specific than this unless we want to talk about the particulars of a specific metadata type. (The I-D already mentions bundle storage or forwarding decisions as examples of how the metadata could be used.)
>
> The purpose of the metadata is to enable DTN nodes to make network-level decisions regarding how to process bundles. I wasn't thinking that this metadata would be or would need to be made available to an application, unless perhaps the application is the destination of the bundle.
>
>>Shouldn't we define a "user-defined" meta-data type just like we are
>>defining
>>the URI (0x01) type? Or do we want to leave this to IANA?  Also,
>>initially I
>>thought that we might need to specify the encoding of the URI, but I
>>guess RFC
>>3986 says that percentage encoded octets might be used for non-ascii
>>characters (depending on schema).
>>
> [Susan]I envision lots of different user-defined metadata types, and those types can be identified by 0x02, 0x03, .... As someone defines a new metadata type, they would use the "next" number to identify it. Registration with IANA can ensure global uniqueness.  (This is basically what we are doing now as we define new block types.)
>
>
>>Nacho
>>
>>Symington, Susan F. wrote:
>>> All,
>>>
>>> I just posted a revision to the DTN Metadata Block I-D.  I tried to
>>respond to the many good comments and suggestions that I got from Joerg,
>>Stephen, and Kevin. Both the discussion that we had recently at Mountain
>>View and recent email exchanges in response to postings from Armando and
>>Nacho also helped.
>>>
>>> As you will see, I am trying to strike a compromise between Kevin's
>>desire to use URIs as THE metadata type and competing desires for a more
>>efficient alternative. I defined a URI metadata type in this I-D and if
>>someone wants, they can just use that. But if someone wants to define
>>their own metadata type, that's okay too.
>>>
>>> I also added some text about what the appropriate (and inappropriate)
>>uses of the block might be, since folks seemed to want this. Thank you,
>>Nacho, for your good examples.
>>>
>>> Please let me know what you think. Thanks!
>>>
>>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-metadata-
>>block-02.txt
>>>
>>> -susan
>>>
>>> *****************************************************************
>>> Susan Symington
>>> The MITRE Corporation
>>> [email-masked]
>>> 703-983-7209 (voice)
>>> 703-983-7142 (fax)
>>> ******************************************************************
>>>
>>>> -----Original Message-----
>>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>>>> Sent: Tuesday, March 31, 2009 4:38 PM
>>>> To: Symington, Susan F.
>>>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-
>>metadata-
>>>> block-02
>>>>
>>>>
>>>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt
>>has
>>>> been successfuly submitted by Susan Symington and posted to the IETF
>>>> repository.
>>>>
>>>> Filename:    draft-irtf-dtnrg-bundle-metadata-block
>>>> Revision:    02
>>>> Title:               Delay-Tolerant Networking Metadata Extension Block
>>>> Creation_date:       2009-03-31
>>>> WG ID:               Independent Submission
>>>> Number_of_pages: 12
>>>>
>>>> Abstract:
>>>> This document defines an extension block that may be used with the
>>>> Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>>>> Network architecture [refs.DTNarch].  This Metadata Extension Block
>>>> is designed to be used to carry application-level information that
>>>> DTN nodes can use to make DTN-level processing decisions regarding
>>>> bundles, such as deciding whether to store a bundle or determining to
>>>> which nodes to forward a bundle.  The actual metadata that is carried
>>>> in a metadata block must be formatted according to the metadata type
>>>> that is identified in the block's metadata type field.  One specific
>>>> metadata type, for encoding metadata as URIs, is defined in this
>>>> document.  Other metadata types may be defined in separate documents.
>>>>
>>>>
>>>>
>>>> The IETF Secretariat.
>>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Thu, 02 Apr 2009 18:06:57 -0400
From: Armando Caro <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] FW: New Version Notification	for	draft-irtf-dtnrg-bundle-metadata-block-02

Symington, Susan F. wrote:
> I see, are you suggesting that in the I-d we should define a segment of numbers that people are free to use to experiment with?  I'm happy to do that if that's what you want. Do you have a specific suggestion for wording I should put in? That might be the easiest way to make sure the text is suitable to you. Even with a segment of IDs that users can use for their user-defined metadata types, though, isn't it is still possible that two different users will select the same number and collide with each other? 

I think Nacho's idea is meant for isolated/private DTNs where users are 
free to do what they want, because there are no other users.

Armando

Date: Thu, 2 Apr 2009 15:02:15 PDT
From: Ignacio Solis <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] FW: New Version Notification for	draft-irtf-dtnrg-bundle-metadata-block-02

Symington, Susan F. wrote:
>>>> I assume the "make this information available for use" includes
>>>> some way
>>>> for
>>>> the node to make this information available to apps. Maybe that
>>>> should
>>>> be more
>>>> explicit? Or is this covered by another RFC?
>>>>
>>> [Susan] It isn't the intent that this be covered by another RFC. The
>>> intent is that the DTN BPA processing the metadata block be able to
>>> extract the metadata from the metadata block and use this metadata
>>> as it was intended (which is somewhat dependent on the metadata type
>>> being used and the metadata itself, and may also depend on local
>>> policy). It is really difficult to envision how we can be more
>>> specific than this unless we want to talk about the particulars of a
>>> specific metadata type. (The I-D already mentions bundle storage or
>>> forwarding decisions as examples of how the metadata could be used.)
>>>
>>> The purpose of the metadata is to enable DTN nodes to make network-
>>> level decisions regarding how to process bundles. I wasn't thinking
>>> that this metadata would be or would need to be made available to an
>>> application, unless perhaps the application is the destination of
>>> the bundle.
>> Well, at some point there will be an application that wants to add
>> metadata.  Is this not covered by this I-D or is it covered by
>>  - Generating a Metadata Block and inserting it into a bundle
>>
>> Or do we envision that only the internals of the routing will be the
>> one adding metadata? If the metadata is "application-level
>> information" then it seems appropriate that applications have access
>> to it.
>>
> [Susan] 
> When a bundle is forwarded from node to node within a DTN, the forwarding nodes at each hop don't typically deliver that bundle to applications that they may have running on them unless those applications are the destination of the bundle.  It is hard for me to imagine how you envision applications at these intermediate-hop nodes becoming involved with a bundle that is passing through them. How would they even become aware of the bundle? 

I was actually thinking of end-to-end apps.

> I do envision that in some cases the BPAs of intermediate nodes that support both the metadata block and the metadata type being used may want to add metadata, and yes, I see this as being covered by the ability to insert a metadata block into the bundle (and delete an old block if need be).

That's probably fine with the current I-D.

>>>> Shouldn't we define a "user-defined" meta-data type just like we are
>>>> defining
>>>> the URI (0x01) type? Or do we want to leave this to IANA?  Also,
>>>> initially I
>>>> thought that we might need to specify the encoding of the URI, but I
>>>> guess RFC
>>>> 3986 says that percentage encoded octets might be used for non-ascii
>>>> characters (depending on schema).
>>>>
>>> [Susan]I envision lots of different user-defined metadata types, and
>>> those types can be identified by 0x02, 0x03, .... As someone defines
>>> a new metadata type, they would use the "next" number to identify
>>> it. Registration with IANA can ensure global uniqueness.  (This is
>>> basically what we are doing now as we define new block types.)
>> Well, to me something that requires IANA participation is not
>> considered user-defined.   If anything IANA could define which type
>> counts as user defined, just like we have 10/8 or 192.168/16.  I can
>> use this without fear to collide with official definitions within my
>> own network.
>>
> [Susan] 
> I see, are you suggesting that in the I-d we should define a segment of numbers that people are free to use to experiment with?  I'm happy to do that if that's what you want. Do you have a specific suggestion for wording I should put in? That might be the easiest way to make sure the text is suitable to you. Even with a segment of IDs that users can use for their user-defined metadata types, though, isn't it is still possible that two different users will select the same number and collide with each other? 

It is true that they might collide. We suffer the same problem with 10/8 and
the like. But for testing I think this is useful and doesn't carry a high cost.

I have no idea what the best wording is. I assume it would require modifying
section 4.

4. Predefined Metadata Types
   As mentioned in the previous section, any number of different
   metadata types may be defined to indicate the format of both the
   metadata field and the EID references in the optional EID Reference
   Count and List field (if present) and, if necessary, how metadata of
   this type should be processed. Two metadata types are predefined in
   this document, URI Metadata Type (0x01) and Private Metadata Type (0x02).

4.1  URI Metadata Type (0x01)
   It is believed that use of URIs will ...

4.2  Private Metadata Type (0x02)
   The metadata type 0x02 has been reserved as Private Metadata Type.
   It can be used for private, testing, experimental or local metadata
   without registration with IANA.  Local policy will define how the
   metadata type 0x02 is handled. Processing, generating, forwarding,
   storing and deleting metadata type 0x02 is OPTIONAL.

BTW, I'm not one of the URI supporters, though I don't mind it being one of
the types.

-------
Nacho

>>>> Symington, Susan F. wrote:
>>>>> All,
>>>>>
>>>>> I just posted a revision to the DTN Metadata Block I-D.  I tried to
>>>> respond to the many good comments and suggestions that I got from
>>>> Joerg,
>>>> Stephen, and Kevin. Both the discussion that we had recently at
>>>> Mountain
>>>> View and recent email exchanges in response to postings from
>>>> Armando and
>>>> Nacho also helped.
>>>>> As you will see, I am trying to strike a compromise between Kevin's
>>>> desire to use URIs as THE metadata type and competing desires for a
>>>> more
>>>> efficient alternative. I defined a URI metadata type in this I-D
>>>> and if
>>>> someone wants, they can just use that. But if someone wants to define
>>>> their own metadata type, that's okay too.
>>>>> I also added some text about what the appropriate (and
>>>>> inappropriate)
>>>> uses of the block might be, since folks seemed to want this. Thank
>>>> you,
>>>> Nacho, for your good examples.
>>>>> Please let me know what you think. Thanks!
>>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-
>>>>> metadata-
>>>> block-02.txt
>>>>> -susan
>>>>>
>>>>> *****************************************************************
>>>>> Susan Symington
>>>>> The MITRE Corporation
>>>>> [email-masked]
>>>>> 703-983-7209 (voice)
>>>>> 703-983-7142 (fax)
>>>>> ******************************************************************
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>>>>>> Sent: Tuesday, March 31, 2009 4:38 PM
>>>>>> To: Symington, Susan F.
>>>>>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-
>>>> metadata-
>>>>>> block-02
>>>>>>
>>>>>>
>>>>>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt
>>>> has
>>>>>> been successfuly submitted by Susan Symington and posted to the
>>>>>> IETF
>>>>>> repository.
>>>>>>
>>>>>> Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>>>>>> Revision:	 02
>>>>>> Title:		 Delay-Tolerant Networking Metadata Extension Block
>>>>>> Creation_date:	 2009-03-31
>>>>>> WG ID:		 Independent Submission
>>>>>> Number_of_pages: 12
>>>>>>
>>>>>> Abstract:
>>>>>> This document defines an extension block that may be used with the
>>>>>> Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>>>>>> Network architecture [refs.DTNarch].  This Metadata Extension Block
>>>>>> is designed to be used to carry application-level information that
>>>>>> DTN nodes can use to make DTN-level processing decisions regarding
>>>>>> bundles, such as deciding whether to store a bundle or
>>>>>> determining to
>>>>>> which nodes to forward a bundle.  The actual metadata that is
>>>>>> carried
>>>>>> in a metadata block must be formatted according to the metadata
>>>>>> type
>>>>>> that is identified in the block's metadata type field.  One
>>>>>> specific
>>>>>> metadata type, for encoding metadata as URIs, is defined in this
>>>>>> document.  Other metadata types may be defined in separate
>>>>>> documents.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The IETF Secretariat.
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Symington, Susan F." <[email-masked]>
To: Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 2 Apr 2009 17:20:21 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] FW: New Version Notification for	draft-irtf-dtnrg-bundle-metadata-block-02

Responses below:

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ignacio
>Solis
>Sent: Thursday, April 02, 2009 3:27 PM
>To: dtn interest
>Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-
>dtnrg-bundle-metadata-block-02
>
>On Apr 2, 2009, at 11:51 AM, Symington, Susan F. wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Ignacio
>>> Solis
>>> Sent: Thursday, April 02, 2009 1:49 PM
>>> To: dtn interest
>>> Subject: Re: [dtn-interest] FW: New Version Notification for draft-
>>> irtf-
>>> dtnrg-bundle-metadata-block-02
>>>
>>> A few things.
>>>
>>> I assume the "make this information available for use" includes
>>> some way
>>> for
>>> the node to make this information available to apps. Maybe that
>>> should
>>> be more
>>> explicit? Or is this covered by another RFC?
>>>
>> [Susan] It isn't the intent that this be covered by another RFC. The
>> intent is that the DTN BPA processing the metadata block be able to
>> extract the metadata from the metadata block and use this metadata
>> as it was intended (which is somewhat dependent on the metadata type
>> being used and the metadata itself, and may also depend on local
>> policy). It is really difficult to envision how we can be more
>> specific than this unless we want to talk about the particulars of a
>> specific metadata type. (The I-D already mentions bundle storage or
>> forwarding decisions as examples of how the metadata could be used.)
>>
>> The purpose of the metadata is to enable DTN nodes to make network-
>> level decisions regarding how to process bundles. I wasn't thinking
>> that this metadata would be or would need to be made available to an
>> application, unless perhaps the application is the destination of
>> the bundle.
>
>Well, at some point there will be an application that wants to add
>metadata.  Is this not covered by this I-D or is it covered by
>  - Generating a Metadata Block and inserting it into a bundle
>
>Or do we envision that only the internals of the routing will be the
>one adding metadata? If the metadata is "application-level
>information" then it seems appropriate that applications have access
>to it.
>
[Susan] 
When a bundle is forwarded from node to node within a DTN, the forwarding nodes at each hop don't typically deliver that bundle to applications that they may have running on them unless those applications are the destination of the bundle.  It is hard for me to imagine how you envision applications at these intermediate-hop nodes becoming involved with a bundle that is passing through them. How would they even become aware of the bundle? 

I do envision that in some cases the BPAs of intermediate nodes that support both the metadata block and the metadata type being used may want to add metadata, and yes, I see this as being covered by the ability to insert a metadata block into the bundle (and delete an old block if need be).
>
>>> Shouldn't we define a "user-defined" meta-data type just like we are
>>> defining
>>> the URI (0x01) type? Or do we want to leave this to IANA?  Also,
>>> initially I
>>> thought that we might need to specify the encoding of the URI, but I
>>> guess RFC
>>> 3986 says that percentage encoded octets might be used for non-ascii
>>> characters (depending on schema).
>>>
>> [Susan]I envision lots of different user-defined metadata types, and
>> those types can be identified by 0x02, 0x03, .... As someone defines
>> a new metadata type, they would use the "next" number to identify
>> it. Registration with IANA can ensure global uniqueness.  (This is
>> basically what we are doing now as we define new block types.)
>
>Well, to me something that requires IANA participation is not
>considered user-defined.   If anything IANA could define which type
>counts as user defined, just like we have 10/8 or 192.168/16.  I can
>use this without fear to collide with official definitions within my
>own network.
>
[Susan] 
I see, are you suggesting that in the I-d we should define a segment of numbers that people are free to use to experiment with?  I'm happy to do that if that's what you want. Do you have a specific suggestion for wording I should put in? That might be the easiest way to make sure the text is suitable to you. Even with a segment of IDs that users can use for their user-defined metadata types, though, isn't it is still possible that two different users will select the same number and collide with each other? 

-susan

>Nacho
>
>
>>> Symington, Susan F. wrote:
>>>> All,
>>>>
>>>> I just posted a revision to the DTN Metadata Block I-D.  I tried to
>>> respond to the many good comments and suggestions that I got from
>>> Joerg,
>>> Stephen, and Kevin. Both the discussion that we had recently at
>>> Mountain
>>> View and recent email exchanges in response to postings from
>>> Armando and
>>> Nacho also helped.
>>>>
>>>> As you will see, I am trying to strike a compromise between Kevin's
>>> desire to use URIs as THE metadata type and competing desires for a
>>> more
>>> efficient alternative. I defined a URI metadata type in this I-D
>>> and if
>>> someone wants, they can just use that. But if someone wants to define
>>> their own metadata type, that's okay too.
>>>>
>>>> I also added some text about what the appropriate (and
>>>> inappropriate)
>>> uses of the block might be, since folks seemed to want this. Thank
>>> you,
>>> Nacho, for your good examples.
>>>>
>>>> Please let me know what you think. Thanks!
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-
>>>> metadata-
>>> block-02.txt
>>>>
>>>> -susan
>>>>
>>>> *****************************************************************
>>>> Susan Symington
>>>> The MITRE Corporation
>>>> [email-masked]
>>>> 703-983-7209 (voice)
>>>> 703-983-7142 (fax)
>>>> ******************************************************************
>>>>
>>>>> -----Original Message-----
>>>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>>>>> Sent: Tuesday, March 31, 2009 4:38 PM
>>>>> To: Symington, Susan F.
>>>>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-
>>> metadata-
>>>>> block-02
>>>>>
>>>>>
>>>>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt
>>> has
>>>>> been successfuly submitted by Susan Symington and posted to the
>>>>> IETF
>>>>> repository.
>>>>>
>>>>> Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>>>>> Revision:	 02
>>>>> Title:		 Delay-Tolerant Networking Metadata Extension Block
>>>>> Creation_date:	 2009-03-31
>>>>> WG ID:		 Independent Submission
>>>>> Number_of_pages: 12
>>>>>
>>>>> Abstract:
>>>>> This document defines an extension block that may be used with the
>>>>> Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>>>>> Network architecture [refs.DTNarch].  This Metadata Extension Block
>>>>> is designed to be used to carry application-level information that
>>>>> DTN nodes can use to make DTN-level processing decisions regarding
>>>>> bundles, such as deciding whether to store a bundle or
>>>>> determining to
>>>>> which nodes to forward a bundle.  The actual metadata that is
>>>>> carried
>>>>> in a metadata block must be formatted according to the metadata
>>>>> type
>>>>> that is identified in the block's metadata type field.  One
>>>>> specific
>>>>> metadata type, for encoding metadata as URIs, is defined in this
>>>>> document.  Other metadata types may be defined in separate
>>>>> documents.
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat.
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Ignacio Solis <[email-masked]>
To: dtn interest <[email-masked]>
Date: Thu, 2 Apr 2009 12:26:58 PDT
Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02

On Apr 2, 2009, at 11:51 AM, Symington, Susan F. wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Ignacio
>> Solis
>> Sent: Thursday, April 02, 2009 1:49 PM
>> To: dtn interest
>> Subject: Re: [dtn-interest] FW: New Version Notification for draft- 
>> irtf-
>> dtnrg-bundle-metadata-block-02
>>
>> A few things.
>>
>> I assume the "make this information available for use" includes  
>> some way
>> for
>> the node to make this information available to apps. Maybe that  
>> should
>> be more
>> explicit? Or is this covered by another RFC?
>>
> [Susan] It isn't the intent that this be covered by another RFC. The  
> intent is that the DTN BPA processing the metadata block be able to  
> extract the metadata from the metadata block and use this metadata  
> as it was intended (which is somewhat dependent on the metadata type  
> being used and the metadata itself, and may also depend on local  
> policy). It is really difficult to envision how we can be more  
> specific than this unless we want to talk about the particulars of a  
> specific metadata type. (The I-D already mentions bundle storage or  
> forwarding decisions as examples of how the metadata could be used.)
>
> The purpose of the metadata is to enable DTN nodes to make network- 
> level decisions regarding how to process bundles. I wasn't thinking  
> that this metadata would be or would need to be made available to an  
> application, unless perhaps the application is the destination of  
> the bundle.

Well, at some point there will be an application that wants to add  
metadata.  Is this not covered by this I-D or is it covered by
  - Generating a Metadata Block and inserting it into a bundle

Or do we envision that only the internals of the routing will be the  
one adding metadata? If the metadata is "application-level  
information" then it seems appropriate that applications have access  
to it.

>> Shouldn't we define a "user-defined" meta-data type just like we are
>> defining
>> the URI (0x01) type? Or do we want to leave this to IANA?  Also,
>> initially I
>> thought that we might need to specify the encoding of the URI, but I
>> guess RFC
>> 3986 says that percentage encoded octets might be used for non-ascii
>> characters (depending on schema).
>>
> [Susan]I envision lots of different user-defined metadata types, and  
> those types can be identified by 0x02, 0x03, .... As someone defines  
> a new metadata type, they would use the "next" number to identify  
> it. Registration with IANA can ensure global uniqueness.  (This is  
> basically what we are doing now as we define new block types.)

Well, to me something that requires IANA participation is not  
considered user-defined.   If anything IANA could define which type  
counts as user defined, just like we have 10/8 or 192.168/16.  I can  
use this without fear to collide with official definitions within my  
own network.

Nacho

>> Symington, Susan F. wrote:
>>> All,
>>>
>>> I just posted a revision to the DTN Metadata Block I-D.  I tried to
>> respond to the many good comments and suggestions that I got from  
>> Joerg,
>> Stephen, and Kevin. Both the discussion that we had recently at  
>> Mountain
>> View and recent email exchanges in response to postings from  
>> Armando and
>> Nacho also helped.
>>>
>>> As you will see, I am trying to strike a compromise between Kevin's
>> desire to use URIs as THE metadata type and competing desires for a  
>> more
>> efficient alternative. I defined a URI metadata type in this I-D  
>> and if
>> someone wants, they can just use that. But if someone wants to define
>> their own metadata type, that's okay too.
>>>
>>> I also added some text about what the appropriate (and  
>>> inappropriate)
>> uses of the block might be, since folks seemed to want this. Thank  
>> you,
>> Nacho, for your good examples.
>>>
>>> Please let me know what you think. Thanks!
>>>
>>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle- 
>>> metadata-
>> block-02.txt
>>>
>>> -susan
>>>
>>> *****************************************************************
>>> Susan Symington
>>> The MITRE Corporation
>>> [email-masked]
>>> 703-983-7209 (voice)
>>> 703-983-7142 (fax)
>>> ******************************************************************
>>>
>>>> -----Original Message-----
>>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>>>> Sent: Tuesday, March 31, 2009 4:38 PM
>>>> To: Symington, Susan F.
>>>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-
>> metadata-
>>>> block-02
>>>>
>>>>
>>>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt
>> has
>>>> been successfuly submitted by Susan Symington and posted to the  
>>>> IETF
>>>> repository.
>>>>
>>>> Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>>>> Revision:	 02
>>>> Title:		 Delay-Tolerant Networking Metadata Extension Block
>>>> Creation_date:	 2009-03-31
>>>> WG ID:		 Independent Submission
>>>> Number_of_pages: 12
>>>>
>>>> Abstract:
>>>> This document defines an extension block that may be used with the
>>>> Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>>>> Network architecture [refs.DTNarch].  This Metadata Extension Block
>>>> is designed to be used to carry application-level information that
>>>> DTN nodes can use to make DTN-level processing decisions regarding
>>>> bundles, such as deciding whether to store a bundle or  
>>>> determining to
>>>> which nodes to forward a bundle.  The actual metadata that is  
>>>> carried
>>>> in a metadata block must be formatted according to the metadata  
>>>> type
>>>> that is identified in the block's metadata type field.  One  
>>>> specific
>>>> metadata type, for encoding metadata as URIs, is defined in this
>>>> document.  Other metadata types may be defined in separate  
>>>> documents.
>>>>
>>>>
>>>>
>>>> The IETF Secretariat.
>>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Symington, Susan F." <[email-masked]>
To: Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 2 Apr 2009 14:51:25 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] FW: New Version Notification for	draft-irtf-dtnrg-bundle-metadata-block-02

My responses are below.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ignacio
>Solis
>Sent: Thursday, April 02, 2009 1:49 PM
>To: dtn interest
>Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-
>dtnrg-bundle-metadata-block-02
>
>A few things.
>
>I assume the "make this information available for use" includes some way
>for
>the node to make this information available to apps. Maybe that should
>be more
>explicit? Or is this covered by another RFC?
>
[Susan] It isn't the intent that this be covered by another RFC. The intent is that the DTN BPA processing the metadata block be able to extract the metadata from the metadata block and use this metadata as it was intended (which is somewhat dependent on the metadata type being used and the metadata itself, and may also depend on local policy). It is really difficult to envision how we can be more specific than this unless we want to talk about the particulars of a specific metadata type. (The I-D already mentions bundle storage or forwarding decisions as examples of how the metadata could be used.) 

The purpose of the metadata is to enable DTN nodes to make network-level decisions regarding how to process bundles. I wasn't thinking that this metadata would be or would need to be made available to an application, unless perhaps the application is the destination of the bundle. 

>Shouldn't we define a "user-defined" meta-data type just like we are
>defining
>the URI (0x01) type? Or do we want to leave this to IANA?  Also,
>initially I
>thought that we might need to specify the encoding of the URI, but I
>guess RFC
>3986 says that percentage encoded octets might be used for non-ascii
>characters (depending on schema).
>
[Susan]I envision lots of different user-defined metadata types, and those types can be identified by 0x02, 0x03, .... As someone defines a new metadata type, they would use the "next" number to identify it. Registration with IANA can ensure global uniqueness.  (This is basically what we are doing now as we define new block types.)  

>Nacho
>
>Symington, Susan F. wrote:
>> All,
>>
>> I just posted a revision to the DTN Metadata Block I-D.  I tried to
>respond to the many good comments and suggestions that I got from Joerg,
>Stephen, and Kevin. Both the discussion that we had recently at Mountain
>View and recent email exchanges in response to postings from Armando and
>Nacho also helped.
>>
>> As you will see, I am trying to strike a compromise between Kevin's
>desire to use URIs as THE metadata type and competing desires for a more
>efficient alternative. I defined a URI metadata type in this I-D and if
>someone wants, they can just use that. But if someone wants to define
>their own metadata type, that's okay too.
>>
>> I also added some text about what the appropriate (and inappropriate)
>uses of the block might be, since folks seemed to want this. Thank you,
>Nacho, for your good examples.
>>
>> Please let me know what you think. Thanks!
>>
>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-metadata-
>block-02.txt
>>
>> -susan
>>
>> *****************************************************************
>> Susan Symington
>> The MITRE Corporation
>> [email-masked]
>> 703-983-7209 (voice)
>> 703-983-7142 (fax)
>> ******************************************************************
>>
>>> -----Original Message-----
>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>>> Sent: Tuesday, March 31, 2009 4:38 PM
>>> To: Symington, Susan F.
>>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-
>metadata-
>>> block-02
>>>
>>>
>>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt
>has
>>> been successfuly submitted by Susan Symington and posted to the IETF
>>> repository.
>>>
>>> Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>>> Revision:	 02
>>> Title:		 Delay-Tolerant Networking Metadata Extension Block
>>> Creation_date:	 2009-03-31
>>> WG ID:		 Independent Submission
>>> Number_of_pages: 12
>>>
>>> Abstract:
>>> This document defines an extension block that may be used with the
>>> Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>>> Network architecture [refs.DTNarch].  This Metadata Extension Block
>>> is designed to be used to carry application-level information that
>>> DTN nodes can use to make DTN-level processing decisions regarding
>>> bundles, such as deciding whether to store a bundle or determining to
>>> which nodes to forward a bundle.  The actual metadata that is carried
>>> in a metadata block must be formatted according to the metadata type
>>> that is identified in the block's metadata type field.  One specific
>>> metadata type, for encoding metadata as URIs, is defined in this
>>> document.  Other metadata types may be defined in separate documents.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 2 Apr 2009 10:48:45 PDT
From: Ignacio Solis <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02

A few things.

I assume the "make this information available for use" includes some way for 
the node to make this information available to apps. Maybe that should be more 
explicit? Or is this covered by another RFC?

Shouldn't we define a "user-defined" meta-data type just like we are defining 
the URI (0x01) type? Or do we want to leave this to IANA?  Also, initially I 
thought that we might need to specify the encoding of the URI, but I guess RFC 
3986 says that percentage encoded octets might be used for non-ascii 
characters (depending on schema).

Nacho

Symington, Susan F. wrote:
> All,
> 
> I just posted a revision to the DTN Metadata Block I-D.  I tried to respond to the many good comments and suggestions that I got from Joerg, Stephen, and Kevin. Both the discussion that we had recently at Mountain View and recent email exchanges in response to postings from Armando and Nacho also helped.
> 
> As you will see, I am trying to strike a compromise between Kevin's desire to use URIs as THE metadata type and competing desires for a more efficient alternative. I defined a URI metadata type in this I-D and if someone wants, they can just use that. But if someone wants to define their own metadata type, that's okay too.
> 
> I also added some text about what the appropriate (and inappropriate) uses of the block might be, since folks seemed to want this. Thank you, Nacho, for your good examples.
> 
> Please let me know what you think. Thanks!
> 
> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-metadata-block-02.txt
> 
> -susan
> 
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
> 
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>> Sent: Tuesday, March 31, 2009 4:38 PM
>> To: Symington, Susan F.
>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-metadata-
>> block-02
>>
>>
>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt has
>> been successfuly submitted by Susan Symington and posted to the IETF
>> repository.
>>
>> Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>> Revision:	 02
>> Title:		 Delay-Tolerant Networking Metadata Extension Block
>> Creation_date:	 2009-03-31
>> WG ID:		 Independent Submission
>> Number_of_pages: 12
>>
>> Abstract:
>> This document defines an extension block that may be used with the
>> Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>> Network architecture [refs.DTNarch].  This Metadata Extension Block
>> is designed to be used to carry application-level information that
>> DTN nodes can use to make DTN-level processing decisions regarding
>> bundles, such as deciding whether to store a bundle or determining to
>> which nodes to forward a bundle.  The actual metadata that is carried
>> in a metadata block must be formatted according to the metadata type
>> that is identified in the block's metadata type field.  One specific
>> metadata type, for encoding metadata as URIs, is defined in this
>> document.  Other metadata types may be defined in separate documents.
>>
>>
>>
>> The IETF Secretariat.
>>
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 02 Apr 2009 09:59:11 -0600
From: Andrew James Jenkins <[email-masked]>
To: "G. Clark" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Wireshark + DTN

Here's an experimental version of a BP dissector from me:

http://bioserve.colorado.edu/~andrew/wiresharkbp/

It only attaches itself to UDP right now, and I haven't done much
testing with non-CBHE dictionaries.  But for CBHE over UDP, it's working
so far.  It's not in shape to be added to the official Wireshark by any
means, yet.

Andrew

G. Clark wrote:
> Hello,
> 
> Quick question for you folks.  Anybody know of somebody that's working 
> on adding or has added support for dissecting bundles into wireshark?   
> I did a bit of googling and couldn't really find much on the subject, so 
> figured somebody here might be able to point me in the right direction.
> 
> Thanks much!
> 
> Gilbert Clark
> Grad Student
> Ohio University
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 02 Apr 2009 11:40:48 +0000
From: "G. Clark" <[email-masked]>
To: dtn interest <[email-masked]>
Subject: [dtn-interest] Wireshark + DTN

Hello,

Quick question for you folks.  Anybody know of somebody that's working 
on adding or has added support for dissecting bundles into wireshark?   
I did a bit of googling and couldn't really find much on the subject, so 
figured somebody here might be able to point me in the right direction.

Thanks much!

Gilbert Clark
Grad Student
Ohio University

Date: Thu, 02 Apr 2009 10:52:55 -0400
From: Vikas Kawadia <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02

Susan,
I read this draft as a potential user of this extension block. Here are my comments:

 - This came across to me as basically providing another layer of indirection in
the extension block scheme. It does not lay down any rules at all about any sort
of meta-data. Perhaps, it should be called an "indirection extension block" or
an "extensible extension block". Or we should try to converge on some fields and
semantics common to all meta-data blocks.

- Section 4 on the URI meta-data type seems incomplete. It basically says
meta-data type 0x01 will use URI encoding. However that is not sufficient
information for me to parse a meta-data block of type 0x01.

thanks
-vikas

Symington, Susan F. wrote:
> All,
> 
> I just posted a revision to the DTN Metadata Block I-D.  I tried to respond to the many good comments and suggestions that I got from Joerg, Stephen, and Kevin. Both the discussion that we had recently at Mountain View and recent email exchanges in response to postings from Armando and Nacho also helped.
> 
> As you will see, I am trying to strike a compromise between Kevin's desire to use URIs as THE metadata type and competing desires for a more efficient alternative. I defined a URI metadata type in this I-D and if someone wants, they can just use that. But if someone wants to define their own metadata type, that's okay too.
> 
> I also added some text about what the appropriate (and inappropriate) uses of the block might be, since folks seemed to want this. Thank you, Nacho, for your good examples.
> 
> Please let me know what you think. Thanks!
> 
> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-metadata-block-02.txt
> 
> -susan
> 
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
> 
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>> Sent: Tuesday, March 31, 2009 4:38 PM
>> To: Symington, Susan F.
>> Subject: New Version Notification for draft-irtf-dtnrg-bundle-metadata-
>> block-02
>>
>>
>> A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt has
>> been successfuly submitted by Susan Symington and posted to the IETF
>> repository.
>>
>> Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>> Revision:	 02
>> Title:		 Delay-Tolerant Networking Metadata Extension Block
>> Creation_date:	 2009-03-31
>> WG ID:		 Independent Submission
>> Number_of_pages: 12
>>
>> Abstract:
>> This document defines an extension block that may be used with the
>> Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>> Network architecture [refs.DTNarch].  This Metadata Extension Block
>> is designed to be used to carry application-level information that
>> DTN nodes can use to make DTN-level processing decisions regarding
>> bundles, such as deciding whether to store a bundle or determining to
>> which nodes to forward a bundle.  The actual metadata that is carried
>> in a metadata block must be formatted according to the metadata type
>> that is identified in the block's metadata type field.  One specific
>> metadata type, for encoding metadata as URIs, is defined in this
>> document.  Other metadata types may be defined in separate documents.
>>
>>
>>
>> The IETF Secretariat.
>>
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Symington, Susan F." <[email-masked]>
To: Armando Caro <[email-masked]>
Date: Wed, 1 Apr 2009 13:58:40 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02

Yes.  That was the intention.  I had originally mentioned the ability to modify (edit) metadata blocks but Stephen pointed out that since the document doesn't specify anywhere HOW the metadata block would be edited, it kinds of doesn't make sense to require that a node be capable of editing.  (The HOW would need to be specified as part of the metadata type definition.)

Since the ability to delete and insert gives the same result, that's all I think we need to require.

Thanks for reading the new document!

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: Armando Caro [mailto:[email-masked]]
>Sent: Wednesday, April 01, 2009 1:54 PM
>To: Symington, Susan F.
>Cc: dtn interest
>Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-
>dtnrg-bundle-metadata-block-02
>
>Susan,
>
>I think the changes look good. I was going to comment that editing
>metadata blocks is another capability needed, but I realize that the
>ability to add and delete essentially gives you that. Was that the
>intention?
>
>--
>Armando

Date: Wed, 01 Apr 2009 13:53:40 -0400
From: Armando Caro <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02

Susan,

I think the changes look good. I was going to comment that editing 
metadata blocks is another capability needed, but I realize that the 
ability to add and delete essentially gives you that. Was that the 
intention?

-- 
Armando