Subject: Re: [dtn-interest] NeighborhoodRouter
From: Jakob Eriksson <[email-masked]>
To: [email-masked]
Date: Fri, 29 Apr 2005 15:19:17 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

You're right, under linux, root access is required to be able to send 
raw ethernet frames. If you got dtnping to work (you should be able to 
see lots of debug output on the remote side), then it seems likely your 
problem is with dtnsend. Perhaps you're specifying a bad destination 
address?

If you haven't tried it yet, make a file ~/.dtndebug with the content
/ debug

that should give you tons of debug output from the dtnd.

- Jakob

On Apr 29, 2005, at 3:07 PM, Jeff Wilson wrote:

> I got a little further in testing EthCL, but I'm still not able to get
> a bundle across using dtnsend/dtnrecv.  I figured out that I have to
> run dtnd as root for the Beacon to work (broadcast, I guess?).  I got
> dtnping running just fine (as far as I can tell).  I'll keep messing
> with it over the weekend and post what I find.
>
>     Regards,
>        jw
>
> On 4/29/05, Jakob Eriksson <[email-masked]> wrote:
>> Hey Jeff,
>>
>>
>> On Apr 29, 2005, at 7:26 AM, Jeff Wilson wrote:
>>
>>> Jakob, I'm very interested in your work on EthConvergenceLayer and
>>> NeighborhoodRouter.  Can you elaborate on what "router" commands you
>>> use to set this up?  For instance, after I specify
>>>
>>>     route set type neighborhood
>>>
>>> do I also need to set the following?
>>>
>>>     route local_region "neighborhood"
>>>
>>> Or how is it that I specify the address of the endpoints?
>>
>> Local_region doesn't matter, as long as it's the same on all your
>> machines, as far as I understand. Local tuple is very important 
>> though,
>> so far. That's the address the router puts as source address in all
>> bundles. I think we'll change that eventually (I don't like manually
>> configuring stuff), but for now, you'll have to suffer through it ;-)
>>
>> Attached is a copy of one of the dtn.conf files I'm using.
>>
>>
>>
>>
>>>  I saw, once
>>> upon a time, a trick using "bundle inject ... "  ... is that how you
>>> test your setup?
>>
>> You can do that. I've personally used dtnping or dtntunnel more,
>> because that uses a whole lot more of the functionality.
>>
>>> Thank you for all your hard work!  Sorry to pester you with so many
>>> questions ... ;)
>>
>> No, I very much appreciate your questions. My work is worth nothing if
>> no-one is using/testing it. Keep 'em coming.
>>
>> - Jakob
>>
>>
>>
>>
Jakob Eriksson
Ph.D. Candidate
http://www.cs.ucr.edu/~jeriksson

Date: Fri, 29 Apr 2005 09:26:19 -0500
From: Jeff Wilson <[email-masked]>
Reply-To: Jeff Wilson <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] NeighborhoodRouter
Sender: [email-masked]

Jakob, I'm very interested in your work on EthConvergenceLayer and
NeighborhoodRouter.  Can you elaborate on what "router" commands you
use to set this up?  For instance, after I specify

    route set type neighborhood

do I also need to set the following?

    route local_region "neighborhood"

Or how is it that I specify the address of the endpoints?  I saw, once
upon a time, a trick using "bundle inject ... "  ... is that how you
test your setup?

Thank you for all your hard work!  Sorry to pester you with so many
questions ... ;)

        Regards,
         jw

On 4/27/05, Jakob Eriksson <[email-masked]> wrote:
> Hello folks,
> 
> Some of you may have noticed that there is a new router in the CVS.
> 
> The NeighborhoodRouter is very simple. It listens to ContactUpEvent and
> ContactDownEvent, and automatically adds routes to all the detected
> next-hop neighbors. To set up a NeighborhoodRouter, put this in your
> dtn.conf:
> 
> route set type neighborhood
> 
> This router is embarrassingly simple in operation, and of course it
> works only for one-hop "routing", but at least it's handy for testing
> and the occasional demo.
> 
> Since NeighborhoodRouter inherits from BundleRouter (which has all the
> StaticBundleRouter functionality built in), one might hope that the
> NeighborhoodRouter also supports static routes. Haven't tested this
> yet.
> 
> Theoretically, the neighborhood router should make life a bit easier
> for other convergence layers than the Ethernet convergence layer too:
> as long as a link is declared for the next hop, there's no need to
> declare a route for the same next hop. Again, this only works for
> one-hop "routing", and again, I haven't attempted this sort of setup
> yet.
> 
> Enjoy,
> 
> Jakob Eriksson
> Ph.D. Candidate
> http://www.cs.ucr.edu/~jeriksson
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

To: [email-masked]
From: Jakob Eriksson <[email-masked]>
Date: Wed, 27 Apr 2005 16:19:12 -0700
Subject: [dtn-interest] dtntunnel UDP-over-DTN forwarder
Sender: [email-masked]

Hi there,

Some of you may have noticed that there's a new app in the CVS. 
dtntunnel can play two roles: sender or receiver. The naming is a bit 
confusing, please suggest better names if you have any ideas.

Sender: listens to a local UDP port, puts the entire UDP packet in a 
bundle, and sends it off to the specified DTN peer.

dtntunnel -r s -p <dtn peer>/dtntunnel -s <local port>

Receiver: registers with the local DTNServer, sends the content of any 
received bundles to the specified address:port, using UDP.

dtntunnel -r r -p <dtn peer>/dtntunnel -d <destination host:port>

This little app needs some polishing, perhaps more than "some", but at 
least it seems to do its job reasonably well. Should work on any 
router/convergence layer, have only tested on Neighborhood and 
Ethernet.

This app's reason for existence is that there are potential users of 
this implementation that have UDP sources and sinks, and using a tunnel 
is more expedient than rewriting their apps for explicit DTN support. 
It's ugly, but in their case, it will work.

Yours truly,

Jakob Eriksson
Ph.D. Candidate
http://www.cs.ucr.edu/~jeriksson

To: [email-masked]
From: Jakob Eriksson <[email-masked]>
Date: Wed, 27 Apr 2005 16:19:09 -0700
Subject: [dtn-interest] NeighborhoodRouter
Sender: [email-masked]

Hello folks,

Some of you may have noticed that there is a new router in the CVS.

The NeighborhoodRouter is very simple. It listens to ContactUpEvent and 
ContactDownEvent, and automatically adds routes to all the detected 
next-hop neighbors. To set up a NeighborhoodRouter, put this in your 
dtn.conf:

route set type neighborhood

This router is embarrassingly simple in operation, and of course it 
works only for one-hop "routing", but at least it's handy for testing 
and the occasional demo.

Since NeighborhoodRouter inherits from BundleRouter (which has all the 
StaticBundleRouter functionality built in), one might hope that the 
NeighborhoodRouter also supports static routes. Haven't tested this 
yet.

Theoretically, the neighborhood router should make life a bit easier 
for other convergence layers than the Ethernet convergence layer too: 
as long as a link is declared for the next hop, there's no need to 
declare a route for the same next hop. Again, this only works for 
one-hop "routing", and again, I haven't attempted this sort of setup 
yet.

Enjoy,

Jakob Eriksson
Ph.D. Candidate
http://www.cs.ucr.edu/~jeriksson

To: [email-masked]
From: Jakob Eriksson <[email-masked]>
Date: Wed, 27 Apr 2005 16:19:08 -0700
Subject: [dtn-interest] Ethernet convergence layer
Sender: [email-masked]

Hi folks,

As some of you may have noticed, there's a new convergence layer in the 
CVS.

For now, the Ethernet convergence layer takes an interface name as 
argument, and automatically discovers other DTN routers on the same 
network, generating a ContactUpEvent for each neighbor. To add an 
ethernet interface, put this in your dtn.conf:

interface add eth string://eth0

There's no need to add links, that's done automatically. Discovery is 
done through beaconing. When a beacon times out, a ContactDownEvent is 
generated. Theoretically, the EthConvergenceLayer works with any type 
of router. However, so far it's only been tested with the 
NeighborhoodRouter. More on that in the next email. Theoretically, this 
should also work with more than one ethernet interface. No guarantees 
=)

WARNING: For now, the EthConvergenceLayer only supports bundle sizes up 
to A SINGLE ETHERNET FRAME. This means if you send larger bundles than 
that, you can expect to get any amount of random errors. Sooner or 
later, multi-frame bundle sizes may be supported. This depends to some 
extent on where we decide the fragmentation should go: convergence 
layer or higher?

Stay tuned,

Jakob Eriksson
Ph.D. Candidate
http://www.cs.ucr.edu/~jeriksson

Date: Thu, 21 Apr 2005 14:52:58 -0500
From: Matt Bradbury <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] IPN and Vint Cerf mentioned on Slashdot
Sender: [email-masked]

http://science.slashdot.org/science/05/04/20/229250.shtml?tid=95&tid=14

-Matt

Date: Mon, 18 Apr 2005 15:01:09 -0400 (EDT)
From: "Brian D. Davison" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] mobility
Sender: [email-masked]

Now that we've had a few days break from this suddenly busy mailing list,
I'd like to ask a question.  It seems that the current schema-based
technique (schema-name + schema-specific info) is essentially the same as
the region technique (region-name + region-specific info), albeit without
the "what does a region mean anyway" question.  Please let me know if I'm
missing something here.

My question is whether there is any support for inter-schema mobility in
this approach.  If an entity that initially has a name/address (A) under
one schema moves to another location/network/employer and gets a new
name/address (B), will bundles destined for A be able to reach the node
at B?

While I can imagine that bundles destined for A might be able to be
temporarily forwarded to B, I don't see that as a good solution in the
long run -- multiple moves would require multiple forwarding, and a
breakdown at any point in that chain would cause problems.  And of course
there is the issue of efficiency, too.

Rather than forwarding, we could just return such bundles to the sender
with the last known forwarding address, and so a regular communicant might
be able to track the current location of the mobile entity, but an
occasional communicant would easily lose track.

What I'd like to see is the ability for (some) names to persist,
regardless of the current address of the referenced entity.  Our
group has some ideas regarding this, but first I want to understand
whether anyone else has tried to address it.

Thanks!  -- Brian

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

To: Matt Bradbury <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin 
Date: Thu, 14 Apr 2005 09:26:33 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Matt Bradbury <[email-masked]>
> To:    [email-masked]
> Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin
> Date:  Wed, 13 Apr 2005 10:30:35 CDT
>
> Stephen Farrell wrote:
> 
> >
> > Pardon me - I forgot there were no minutes. Sorry
> > about that.
> >
> > The DTNRG met at the IETF in Minneapolis and Susan
> > presented on DTN security, including BAH which
> > then (and now I guess) only authenticated headers
> > and not payload. I guess her slides are on the
> > DTNRG site somewhere.
> >
> > It was pointed out that this contradicts the
> > stated requirement that DTN security is mainly
> > about protecting the DTN - it allows a node (who's
> > not even a DTN router, just any old intermediary)
> > to insert bogus fragments or at least to increase
> > the length of fragments, or even if the length is
> > known to modify the payload bytes. I guess that's
> > what re-started all this discussion.
> >
> > Stephen.
> 
> Ok, I found the page with all the presentations from the meeting:
> http://www.dtnrg.org/wiki/IETF62

Yes, there were notes taken and posted, but they really should have
had much more detail.  We will work on that.  I submitted
some documents to IETF for the IETF62 official proceedings,
so you should be able to get to them there eventually as well.

Btw, the thing pointed out during that meeting was that if
you have a nasty party in the middle and a nasty party at
or near the intended endpoint they could collude in such a way as to
carry unauthorized traffic [if the payload isn't protected], as
long as the nasty merely used the correct size.  We 'sort of' realized
this all along, but raising it in that way made the idea
seem unattractive.  I'm beginning to think we should just go with
toilet paper until we have a better answer.

- K

> 
> I read through Susan's presentation.  What has changed between then and now?
> 
> As far as modification of payloads, is this something that is detected 
> at endpoints, and if it happens enough you go through the network and 
> find the link where packets are being corrupted and fix/secure that 
> link?  ( Wouldn't the party responsible for modifying the bundles be 
> liable under wiretapping laws as well?) Susan makes a good point in her 
> presentation that replay attacks are a pain and have to be done in near 
> real-time.  Plus routers will be able to detect duplicates if they're 
> willing to hold the state information to do so.
> 
> -Matt
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 13 Apr 2005 10:30:35 -0500
From: Matt Bradbury <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin
Sender: [email-masked]

Stephen Farrell wrote:

>
> Pardon me - I forgot there were no minutes. Sorry
> about that.
>
> The DTNRG met at the IETF in Minneapolis and Susan
> presented on DTN security, including BAH which
> then (and now I guess) only authenticated headers
> and not payload. I guess her slides are on the
> DTNRG site somewhere.
>
> It was pointed out that this contradicts the
> stated requirement that DTN security is mainly
> about protecting the DTN - it allows a node (who's
> not even a DTN router, just any old intermediary)
> to insert bogus fragments or at least to increase
> the length of fragments, or even if the length is
> known to modify the payload bytes. I guess that's
> what re-started all this discussion.
>
> Stephen.

Ok, I found the page with all the presentations from the meeting:
http://www.dtnrg.org/wiki/IETF62

I read through Susan's presentation.  What has changed between then and now?

As far as modification of payloads, is this something that is detected 
at endpoints, and if it happens enough you go through the network and 
find the link where packets are being corrupted and fix/secure that 
link?  ( Wouldn't the party responsible for modifying the bundles be 
liable under wiretapping laws as well?) Susan makes a good point in her 
presentation that replay attacks are a pain and have to be done in near 
real-time.  Plus routers will be able to detect duplicates if they're 
willing to hold the state information to do so.

-Matt

Date: Wed, 13 Apr 2005 15:44:23 +0100
From: Stephen Farrell <[email-masked]>
To: Matt Bradbury <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin
Sender: [email-masked]

Pardon me - I forgot there were no minutes. Sorry
about that.

The DTNRG met at the IETF in Minneapolis and Susan
presented on DTN security, including BAH which
then (and now I guess) only authenticated headers
and not payload. I guess her slides are on the
DTNRG site somewhere.

It was pointed out that this contradicts the
stated requirement that DTN security is mainly
about protecting the DTN - it allows a node (who's
not even a DTN router, just any old intermediary)
to insert bogus fragments or at least to increase
the length of fragments, or even if the length is
known to modify the payload bytes. I guess that's
what re-started all this discussion.

Stephen.

Matt Bradbury wrote:

> Stephen Farrell wrote:
> 
>>
>> Wasn't this the position pre-Minneapolis, which caused
>> (justifiable) concern in the audience?
>>
>> Stephen.
> 
> 
> What were the concerns then?
> 
> And what/when was Minneapolis?
> 
> -Matt
> 
> 
> 
>>
>> Scott Burleigh wrote:
>>
>>> Matt Bradbury wrote:
>>>
>>>> I've been watching the ebb and flow of this conversation and see 
>>>> that re-active fragmentation with bundle authentication is just 
>>>> going to be a mess and probably never work quite right, too many 
>>>> edge cases, too many situations where re-transmitting is easier than 
>>>> waiting, etc.  But most of these problems are due to the fact that 
>>>> Bundle Authentication is being applied to the whole Bundle.
>>>>
>>>> What if Bundle Authentication was only for the headers, not the 
>>>> entire bundle?
>>>> Advantages:   Re-active fragmentation will work just fine, since 
>>>> we're only authenticating the headers.
>>>>   Different fragments of a re-active fragmentation can take 
>>>> different routes.
>>>>
>>>> Disadvantage:
>>>>   Possible man in the middle insertion of bad data.  Though I think 
>>>> this can be solved at the endpoints using the Payload Security 
>>>> header, and can be detected by intermediate agents by checking for 
>>>> duplicate bundle headers.
>>>>
>>>> Thoughts?  Other advantages and disadvantages?
>>>
>>>
>>>
>>>
>>> I haven't been able to keep up with this thread, so it is likely that 
>>> I am missing some key points that would change my thinking.  But I 
>>> really like this approach.  It's true that we wouldn't be able to 
>>> detect alteration of payload until reassembly and validation against 
>>> the PSH, but could we maybe live with that so long as the 
>>> man-in-the-middle attack didn't threaten the network by injecting a 
>>> lot of additional (bogus) payload?  I'm thinking we could guard 
>>> against the latter somewhat by including original payload length in 
>>> one of the end-to-end immutable headers rather than in the Fragment 
>>> header, and ditching bundles with payload length in excess of that 
>>> value.
>>>
>>> Scott
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Date: Wed, 13 Apr 2005 09:20:21 -0500
From: Matt Bradbury <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin
Sender: [email-masked]

Stephen Farrell wrote:

>
> Wasn't this the position pre-Minneapolis, which caused
> (justifiable) concern in the audience?
>
> Stephen.

What were the concerns then?

And what/when was Minneapolis?

-Matt

>
> Scott Burleigh wrote:
>
>> Matt Bradbury wrote:
>>
>>> I've been watching the ebb and flow of this conversation and see 
>>> that re-active fragmentation with bundle authentication is just 
>>> going to be a mess and probably never work quite right, too many 
>>> edge cases, too many situations where re-transmitting is easier than 
>>> waiting, etc.  But most of these problems are due to the fact that 
>>> Bundle Authentication is being applied to the whole Bundle.
>>>
>>> What if Bundle Authentication was only for the headers, not the 
>>> entire bundle?
>>> Advantages:   Re-active fragmentation will work just fine, since 
>>> we're only authenticating the headers.
>>>   Different fragments of a re-active fragmentation can take 
>>> different routes.
>>>
>>> Disadvantage:
>>>   Possible man in the middle insertion of bad data.  Though I think 
>>> this can be solved at the endpoints using the Payload Security 
>>> header, and can be detected by intermediate agents by checking for 
>>> duplicate bundle headers.
>>>
>>> Thoughts?  Other advantages and disadvantages?
>>
>>
>>
>> I haven't been able to keep up with this thread, so it is likely that 
>> I am missing some key points that would change my thinking.  But I 
>> really like this approach.  It's true that we wouldn't be able to 
>> detect alteration of payload until reassembly and validation against 
>> the PSH, but could we maybe live with that so long as the 
>> man-in-the-middle attack didn't threaten the network by injecting a 
>> lot of additional (bogus) payload?  I'm thinking we could guard 
>> against the latter somewhat by including original payload length in 
>> one of the end-to-end immutable headers rather than in the Fragment 
>> header, and ditching bundles with payload length in excess of that 
>> value.
>>
>> Scott
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 13 Apr 2005 03:04:20 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Custody and Fragmentation
Sender: [email-masked]

Stephen Farrell wrote:
> 
> We've beaten ourselves up about reactive fragmentation & crypto
> for the last day or two.
> 
> Can I ask a different question:
> 
> How does reactive fragmentation interact with custody transfer?

In most cases there's nothing special to say: you transfer custody of a 
bundle, and a fragment is just a bundle.  All the normal custody transfer 
rules apply.

But there is one additional wrinkle.  Suppose the current custodian of a 
bundle is A and the next router is B, which fragments the bundle but does 
not take custody.  The next router, C, receives one of the fragments and 
decides to take custody of it; C sends a custody acceptance signal for this 
fragment to the current custodian, which is A [fragmentation didn't alter 
custodial responsibility].  Agent A receives a custody acceptance signal 
for a bundle that is a fragment and is therefore different from the one for 
which it is the custodian; A must do its own "responsive" fragmentation of 
the bundle on the boundaries defined by the fragment, so that it can 
relinquish custody of the fragment but retain custody of the remainder of 
the original bundle.

Scott

Date: Wed, 13 Apr 2005 10:56:02 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Custody and Fragmentation
Sender: [email-masked]

We've beaten opurselves up about reactive fragmentation & crypto
for the last day or two.

Can I ask a different question:

How does reactive fragmentation interact with custody transfer?

Stephen.

Date: Wed, 13 Apr 2005 10:54:01 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin
Sender: [email-masked]

Wasn't this the position pre-Minneapolis, which caused
(justifiable) concern in the audience?

Stephen.

Scott Burleigh wrote:

> Matt Bradbury wrote:
> 
>> I've been watching the ebb and flow of this conversation and see that 
>> re-active fragmentation with bundle authentication is just going to be 
>> a mess and probably never work quite right, too many edge cases, too 
>> many situations where re-transmitting is easier than waiting, etc.  
>> But most of these problems are due to the fact that Bundle 
>> Authentication is being applied to the whole Bundle.
>>
>> What if Bundle Authentication was only for the headers, not the entire 
>> bundle?
>> Advantages:   Re-active fragmentation will work just fine, since we're 
>> only authenticating the headers.
>>   Different fragments of a re-active fragmentation can take different 
>> routes.
>>
>> Disadvantage:
>>   Possible man in the middle insertion of bad data.  Though I think 
>> this can be solved at the endpoints using the Payload Security header, 
>> and can be detected by intermediate agents by checking for duplicate 
>> bundle headers.
>>
>> Thoughts?  Other advantages and disadvantages?
> 
> 
> I haven't been able to keep up with this thread, so it is likely that I 
> am missing some key points that would change my thinking.  But I really 
> like this approach.  It's true that we wouldn't be able to detect 
> alteration of payload until reassembly and validation against the PSH, 
> but could we maybe live with that so long as the man-in-the-middle 
> attack didn't threaten the network by injecting a lot of additional 
> (bogus) payload?  I'm thinking we could guard against the latter 
> somewhat by including original payload length in one of the end-to-end 
> immutable headers rather than in the Fragment header, and ditching 
> bundles with payload length in excess of that value.
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Date: Wed, 13 Apr 2005 10:52:54 +0100
From: Stephen Farrell <[email-masked]>
To: Howard Weiss <[email-masked]>
Cc: "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Howie,

Well if reactive fragmentation is to work, then the sender
has to know how much he thinks did get through, and has to
remember that, and the bytes that didn't get through, in
order to usefully re-tx with little or no duplication.

Practically that can be done by keeping a running digest
of (parts of) the lower-layer MTU-sized chunks that've
been Tx'd and checkpointing that whenever the bundle
layer considers that bytes have gotten through. So
there's very little additional state.

Not saying that this is very, very good, or anything, but
I don't believe it falls on the state maintenance issue,

Stephen.

Howard Weiss wrote:
> Stephen,
> 
> I'm finally catching up on all of the traffic (I'm off at the CCSDS 
> meeting in Athens)......
> 
> Your approach is problematic because of the extra state required in an 
> already potentially resource starved environment.  Won't the sender need 
> to keep the hash for X (where I have no idea what the value of X should 
> be) to cover any reactive fragementation issues?  So the sender would 
> have to calculate the hash and not just send it, but also store it 
> because it might need to use it later on a fragment.  Yech.... How would 
> we ever figure out how long to hang onto it?  Also, what happens if the 
> reactive fragmentation results in many fragments - then how long should 
> the sender have to hang onto the hash?
> 
> Howie
> 
> Stephen Farrell wrote:
> 
>>
>> Ok, here's another possibly despairing go at this thread:-)
>>
>> Am I right in assuming that reactive fragmentation requires
>> that the transmitter knows fairly well how much of the previous
>> fragment got through? (Otherwise it'll just have to re-Tx
>> everything, right?).
>>
>> In that case, couldn't we arrange that the 2nd fragment (which
>> could contain part of all of the remaining bundle bytes) contains
>> a hash/MAC that covers the 1st? As soon as the receiver gets
>> and checks this it can then forward the combined content of
>> the two bundles (together or not, I don't know!), and doesn't
>> have wait for the end of the payload.
>>
>> That way, we can forward without waiting for the last fragment,
>> which should often be somewhat better.
>>
>> More generally, we add a requirement that where hop-by-hop
>> security is in force, then the next bundle sent to the recipient
>> of a reactively fragmented bundle must authenticate the previous
>> fragment received by that recipient.
>>
>> The BAH on the first bundle sent can continue to optimistically
>> cover the entire payload.
>>
>> If this scheme works, it probably needs some tweaking so that
>> the new header in the 2nd fragment (previous-BAH?) will have
>> to indicate the range of payload (and implicitly which headers)
>> are covered by the hash/MAC. We'd also need to define a timer
>> for anti-DoS reasons and in case the transmitter never gets
>> to use that receiver again for that payload. If the 2nd bundle
>> is BAHed, (which I guess it probably ought to be, assuming
>> policies don't change that quickly) then including a hash,
>> rather than a signature or MAC, in the previous-BAH header
>> might be sufficient, at least until we figure out how BAH-keys
>> might rollover.
>>
>> And I guess if the fragment that got through is shorter than
>> the new crud we're adding then we should just re-tx the lot:-)
>>
>> If we're deliberatlely fragmenting, this is of course a non-issue
>> since you can BAH-protect each entire fragment-bundle before Txing.
>>
>> And just in case: this is all a non-issue for e2e security since
>> re-assembly at the destination can handle that (or not, if not
>> all fragments arrive). With e2e security and missing fragments,
>> toilet-paper is the only answer so far.
>>
>> Stephen.
>>
>> Rajesh Krishnan wrote:
>>
>>> Susan,
>>>
>>> Thank you for explaining the "toilet paper" approach, the issues with 
>>> it, and that my proposal is a variant of that approach.
>>>
>>> It is not clear that there is a universal method (across all networks 
>>> and applications) that can determine the optimum segment size, or 
>>> even whether it should be a fixed value (not all bundle parts may be 
>>> equally important).
>>>
>>> Best Regards,
>>> Rajesh
>>>
>>>
>>>> Rajesh,
>>>>
>>>> The suggestion that you are making is essentially what we have been 
>>>> calling
>>>> the "toilet paper" approach --a name that was chosen to be descriptive,
>>>> rather than dismissive of the approach, and we keep coming back to 
>>>> it, but
>>>> it is ugly and complicated.  The toilet paper proposal was made 
>>>> before I got
>>>> involved in the project; basically, it involves formatting the 
>>>> payload as a
>>>> series of segments followed by authentication information of those 
>>>> segments.
>>>> This way, if transmission of a bundle is interrupted before the entire
>>>> payload makes it across the link, all those segments that did make 
>>>> it with
>>>> their accompanying authentication information could be authenticated 
>>>> and
>>>> forwarded immediately, and only the segment that was interrupted, its
>>>> accompanying hash value, and all following segments of the payload 
>>>> would
>>>> have to be resent.  The reason it is called the toilet paper 
>>>> approach is
>>>> that the payload is essentially perforated after every
>>>> segment,authentication information pair.
>>>>
>>>> Note that this approach differs slightly from your suggestion 
>>>> because it
>>>> involves putting the hash(es) in a header rather than embedded in the
>>>> payload. If the hashes are in the header, then you would be sending 
>>>> all the
>>>> hashes before sending even a bit of the payload. It is more 
>>>> efficient to
>>>> send the hashes only when you know they will be useful, as in right 
>>>> after
>>>> the payload they protect.
>>>> One of the problems that we have had with considering the toilet paper
>>>> approach before has been how we would know what a good segment size 
>>>> would
>>>> be. Determining this size according to the natural concept of what 
>>>> the next
>>>> safely usable increment at the destination is, as you suggest, is 
>>>> appealing.
>>>> I like it.
>>>>
>>>> One problem with it, however, might be that it isn't related to the
>>>> capabilities of the network. If a link cannot routinetly stay up 
>>>> long enough
>>>> to transmit data of that length, then there's no way to use reactive
>>>> fragmentation to move data along that link. If a link routinely 
>>>> stays up for
>>>> much longer than it takes to transmit data of that length, then 
>>>> there is a
>>>> lot of wasted bandwidth carrying all those embedded hashes. If 
>>>> segments are
>>>> too large, then lots of data is lost in the "interrupted" segment 
>>>> when a
>>>> connection is lost and that data needs to be resent.  If segments 
>>>> are too
>>>> small, lots of bits are wasted with the many signed hash values that 
>>>> are
>>>> interspersed throughout the payload.
>>>> So even though mechanically we understand how we could enable 
>>>> authentication
>>>> and immediate forwarding to coexist by using the toilet paper 
>>>> mechanim, we
>>>> don't really don't know how to use this mechanism effectively, 
>>>> because we
>>>> don't know how to select an optimal segment size.  If you have any 
>>>> ideas it
>>>> would be great to hear them.
>>>>
>>>> -susan
>>>>
>>>> -----Original Message-----
>>>> From: Rajesh Krishnan [mailto:[email-masked]] Sent: Monday, April 11, 
>>>> 2005 2:12 PM
>>>> To: Susan F. Symington
>>>> Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>> Subject: Re: [dtn-interest] on ditching fragmentation
>>>>
>>>> Susan and Mike,
>>>>
>>>> In some applications, there is a natural concept of what the next 
>>>> safely
>>>> usable increment at the destination is (e.g. a video frame).
>>>>
>>>> Suppose a bundle could include a second hash covering the first 
>>>> usable increment in addition to the usual hash over the entire 
>>>> bundle.  Under reactive fragmentation, the first usable increment 
>>>> can be forwarded
>>>> if/when available.
>>>>
>>>> The additional hash could go on an optional fragmentation header to 
>>>> be used if immediate forwarding (upon reactive fragmentation) is 
>>>> desired.  Hashes that protect subsequent increments can also be 
>>>> included in such
>>>> a header if one is willing to expend the header overhead. 
>>>> Proactive addition of fragment hashes in anticipation of reactive 
>>>> fragmentation is a possible medium between the proactive 
>>>> fragmentation and reactive fragmentation schemes presented.
>>>>
>>>> Best Regards,
>>>> Rajesh
>>>>
>>>>
>>>>> Mike,
>>>>>
>>>>> I see your point that there may be some utility in a bundle agent 
>>>>> being
>>>>
>>>>
>>>> able
>>>>
>>>>> to reactively fragment even if it is precluded from immediately
>>>>
>>>>
>>>> forwarding.
>>>>
>>>>> Here is how our dilemma seems to look right now:
>>>>>
>>>>>> From a security standpoint, we really want to be able to calculate 
>>>>>> the
>>>>>
>>>>> authentication information in the Bundle Authentication Header over 
>>>>> the
>>>>> entire bundle, including the payload. We can have this security 
>>>>> that we
>>>>
>>>>
>>>> want
>>>>
>>>>> and we can also have reactive fragmentation, as long as we require 
>>>>> that if
>>>>
>>>>
>>>> a
>>>>
>>>>> bundle is reactively fragmented then its "tail" (which may arrive as
>>>>> multiple bundle fragments) is forwarded through the same bundle 
>>>>> agent that
>>>>> did the reactive fragmentation and is holding on to the head. 
>>>>> However, we
>>>>> cannot forward the reactively fragmented head until the "tail" is
>>>>
>>>>
>>>> received.
>>>>
>>>>> My questions for everyone who cares are:
>>>>>
>>>>> 1. Is it feasible to require the tails of reactively fragmented 
>>>>> bundles to
>>>>> be forwarded through the same bundle agent as the head?  Is this 
>>>>> something
>>>>> people are willing to put up with in order to be able to have both the
>>>>> security that we want and reactive fragmentation? Or do some people 
>>>>> out
>>>>> there feel that restricting the bundle's path in this way would be
>>>>> unacceptable?
>>>>>
>>>>> 2. Is being able to reactively fragment but not immediately forward
>>>>
>>>>
>>>> bundles
>>>>
>>>>> that have Bundle Authentication Headers good enough for people?  We 
>>>>> still
>>>>
>>>>
>>>> do
>>>>
>>>>> get some utility out of being able to reactively fragment, as Mike 
>>>>> points
>>>>> out, but we don't get the full efficiency of "cut-through routing" 
>>>>> because
>>>>> the receiving bundle agent can't forward the head until the tail 
>>>>> arrives.
>>>>
>>>>
>>>> I
>>>>
>>>>> think this means that from the viewpoint of the bundle agent that 
>>>>> performs
>>>>> the reactive fragmentation, the link on which it receives the 
>>>>> bundle is
>>>>> being used as efficiently as possible (no data that makes it 
>>>>> through once
>>>>> has to be resent) but the link on which it must forward the data 
>>>>> may not
>>>>
>>>>
>>>> be
>>>>
>>>>> used efficiently, because even though this link may be up and able 
>>>>> to be
>>>>> used to send data, it may be idle because the bundle agent isn't 
>>>>> able to
>>>>> send the head until the tail of the bundle has arrived. Is this good
>>>>
>>>>
>>>> enough?
>>>>
>>>>> Can we settle for this or is the "cut-through" feature that enables 
>>>>> both
>>>>> links to be used efficiently something that our solution absolutely 
>>>>> must
>>>>> provide?
>>>>>
>>>>> Remember, we only run into this problem if security is being used, 
>>>>> and, in
>>>>> particular, if hop by hop security is being provided by the 
>>>>> presence of a
>>>>> Bundle Authentication Header in the bundle. If security is not 
>>>>> being used,
>>>>> or if security is being used and the security features of the 
>>>>> underlying
>>>>> network are being relied on so that the bundle doesn't have a Bundle
>>>>> Authentication Header, then the tails of bundles don't have to have 
>>>>> their
>>>>> routes restricted and cut-through routing is possible.
>>>>>
>>>>> If the above compromises are unacceptable, I think we are stuck 
>>>>> with the
>>>>> toilet paper approach or something like it. What do people think?
>>>>>
>>>>> -susan
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Michael 
>>>>> Demmer
>>>>> Sent: Monday, April 11, 2005 12:09 PM
>>>>> To: Susan F. Symington
>>>>> Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>>> Subject: Re: [dtn-interest] on ditching fragmentation
>>>>>
>>>>>
>>>>>
>>>>>> If you choose option (b) below, which is to enable rective
>>>>>> fragmentation but make sure that all fragments of a given bundle
>>>>>> follow the same path, you are doing this because you are requiring
>>>>>> the receiving intermediate bundle agent to wait until the entire
>>>>>> original bundle is received so that it can authenticate the bundle
>>>>>> before forwarding any part of it. But what would be the point of
>>>>>> this? Aren't you losing the benefit that the reactive fragmentation
>>>>>> is supposed to provide, which is to enable the part of the orignal
>>>>>> bundle that was received before the connection went down to be
>>>>>> forwarded immediately, without having to wait?
>>>>>
>>>>>
>>>>> Not necessarily. If I have a connection that is only ever up for a
>>>>> window of 1/2 the time that it takes to transmit a large bundle, then
>>>>> even if I can't forward the first half of the bundle until I get the
>>>>> second half, I've still gotten a win out of reactive fragmentation.
>>>>>
>>>>>
>>>>>> We have been saying that we want "reactive fragmentation", but I
>>>>>> think that what we really want is to be able to reactively fragment
>>>>>> and then immediately forward.
>>>>>
>>>>>
>>>>> This is, I agree, the "touchy" part about reactive fragmentation, and
>>>>> the part that makes it tricky wrt authentication. We should come up
>>>>> with a name for this (I believe one term tossed around was
>>>>> 'cut-thru-routing') as distinct from reactive fragmentation which in
>>>>> my mind just handles the connection interruption.
>>>>>
>>>>>
>>>>>> In my mind there is no point in reactively fragmenting if we are
>>>>>> going to have to wait to reassemble the bundle before we will be
>>>>>> able to forward it or any part of it. 
>>>>>
>>>>>
>>>>> As I said before, I disagree with this.
>>>>>
>>>>>
>>>>>> If what we really want is "reactive fragmentation and immediate
>>>>>> forwarding" (which is what I think we want, but we might not all
>>>>>> agree on that, I don't know), then option (b) is misleading, because
>>>>>> it only enables reactive fragmentation; it precludes immediate
>>>>>> forwarding.
>>>>>
>>>>>
>>>>> Agreed -- restate b) to "enable reactive fragmentation but not
>>>>> XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
>>>>> before the tail arrives).
>>>>>
>>>>>
>>>>>> Reactive fragmentation and immediate forwarding *is* incompatible
>>>>>> with the type of bundle authentication that is now defined as being
>>>>>> provided in the Bundle Authentication Header.
>>>>>
>>>>>
>>>>> Yes, I agree with that.
>>>>>
>>>>> -m
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> -- 
> Howard Weiss
> SPARTA, Inc.
> 7075 Samuel Morse Drive
> Columbia, MD 21046
> 410.872.1515 x201
> 410.872.8079 (fax)
> 
> 

Date: Tue, 12 Apr 2005 22:34:40 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin
Sender: [email-masked]

Matt Bradbury wrote:
> I've been watching the ebb and flow of this conversation and see that 
> re-active fragmentation with bundle authentication is just going to be a 
> mess and probably never work quite right, too many edge cases, too many 
> situations where re-transmitting is easier than waiting, etc.  But most 
> of these problems are due to the fact that Bundle Authentication is 
> being applied to the whole Bundle.
> 
> What if Bundle Authentication was only for the headers, not the entire 
> bundle?
> Advantages:   Re-active fragmentation will work just fine, since we're 
> only authenticating the headers.
>   Different fragments of a re-active fragmentation can take different 
> routes.
> 
> Disadvantage:
>   Possible man in the middle insertion of bad data.  Though I think this 
> can be solved at the endpoints using the Payload Security header, and 
> can be detected by intermediate agents by checking for duplicate bundle 
> headers.
> 
> Thoughts?  Other advantages and disadvantages?

I haven't been able to keep up with this thread, so it is likely that I am 
missing some key points that would change my thinking.  But I really like 
this approach.  It's true that we wouldn't be able to detect alteration of 
payload until reassembly and validation against the PSH, but could we maybe 
live with that so long as the man-in-the-middle attack didn't threaten the 
network by injecting a lot of additional (bogus) payload?  I'm thinking we 
could guard against the latter somewhat by including original payload 
length in one of the end-to-end immutable headers rather than in the 
Fragment header, and ditching bundles with payload length in excess of that 
value.

Scott

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Bundle Authentication and Fragmentatoin
To: [email-masked] (Matt Bradbury)
Date: Tue, 12 Apr 2005 16:47:56 -0400 (EDT)
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

I think a separate header hash (or header plus first usable increment ;) 
will be useful in reactive routing situations.

> I've been watching the ebb and flow of this conversation and see that 
> re-active fragmentation with bundle authentication is just going to be a 
> mess and probably never work quite right, too many edge cases, too many 
> situations where re-transmitting is easier than waiting, etc.  But most 
> of these problems are due to the fact that Bundle Authentication is 
> being applied to the whole Bundle.
> 
> What if Bundle Authentication was only for the headers, not the entire 
> bundle? 
> 
> Advantages: 
>    Re-active fragmentation will work just fine, since we're only 
> authenticating the headers.
>    Different fragments of a re-active fragmentation can take different 
> routes.
> 
> Disadvantage:
>    Possible man in the middle insertion of bad data.  Though I think 
> this can be solved at the endpoints using the Payload Security header, 
> and can be detected by intermediate agents by checking for duplicate 
> bundle headers.
> 
> Thoughts?  Other advantages and disadvantages?
> 
> -Matt
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Tue, 12 Apr 2005 15:39:56 -0500
From: Matt Bradbury <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Bundle Authentication and Fragmentatoin
Sender: [email-masked]

I've been watching the ebb and flow of this conversation and see that 
re-active fragmentation with bundle authentication is just going to be a 
mess and probably never work quite right, too many edge cases, too many 
situations where re-transmitting is easier than waiting, etc.  But most 
of these problems are due to the fact that Bundle Authentication is 
being applied to the whole Bundle.

What if Bundle Authentication was only for the headers, not the entire 
bundle? 

Advantages: 
   Re-active fragmentation will work just fine, since we're only 
authenticating the headers.
   Different fragments of a re-active fragmentation can take different 
routes.

Disadvantage:
   Possible man in the middle insertion of bad data.  Though I think 
this can be solved at the endpoints using the Payload Security header, 
and can be detected by intermediate agents by checking for duplicate 
bundle headers.

Thoughts?  Other advantages and disadvantages?

-Matt

Date: Tue, 12 Apr 2005 15:02:41 -0400
From: Howard Weiss <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: [email-masked], "Susan F. Symington" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

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

Stephen,

I'm finally catching up on all of the traffic (I'm off at the CCSDS 
meeting in Athens)......

Your approach is problematic because of the extra state required in an 
already potentially resource starved environment.  Won't the sender need 
to keep the hash for X (where I have no idea what the value of X should 
be) to cover any reactive fragementation issues?  So the sender would 
have to calculate the hash and not just send it, but also store it 
because it might need to use it later on a fragment.  Yech.... How would 
we ever figure out how long to hang onto it?  Also, what happens if the 
reactive fragmentation results in many fragments - then how long should 
the sender have to hang onto the hash?

Howie

Stephen Farrell wrote:

>
> Ok, here's another possibly despairing go at this thread:-)
>
> Am I right in assuming that reactive fragmentation requires
> that the transmitter knows fairly well how much of the previous
> fragment got through? (Otherwise it'll just have to re-Tx
> everything, right?).
>
> In that case, couldn't we arrange that the 2nd fragment (which
> could contain part of all of the remaining bundle bytes) contains
> a hash/MAC that covers the 1st? As soon as the receiver gets
> and checks this it can then forward the combined content of
> the two bundles (together or not, I don't know!), and doesn't
> have wait for the end of the payload.
>
> That way, we can forward without waiting for the last fragment,
> which should often be somewhat better.
>
> More generally, we add a requirement that where hop-by-hop
> security is in force, then the next bundle sent to the recipient
> of a reactively fragmented bundle must authenticate the previous
> fragment received by that recipient.
>
> The BAH on the first bundle sent can continue to optimistically
> cover the entire payload.
>
> If this scheme works, it probably needs some tweaking so that
> the new header in the 2nd fragment (previous-BAH?) will have
> to indicate the range of payload (and implicitly which headers)
> are covered by the hash/MAC. We'd also need to define a timer
> for anti-DoS reasons and in case the transmitter never gets
> to use that receiver again for that payload. If the 2nd bundle
> is BAHed, (which I guess it probably ought to be, assuming
> policies don't change that quickly) then including a hash,
> rather than a signature or MAC, in the previous-BAH header
> might be sufficient, at least until we figure out how BAH-keys
> might rollover.
>
> And I guess if the fragment that got through is shorter than
> the new crud we're adding then we should just re-tx the lot:-)
>
> If we're deliberatlely fragmenting, this is of course a non-issue
> since you can BAH-protect each entire fragment-bundle before Txing.
>
> And just in case: this is all a non-issue for e2e security since
> re-assembly at the destination can handle that (or not, if not
> all fragments arrive). With e2e security and missing fragments,
> toilet-paper is the only answer so far.
>
> Stephen.
>
> Rajesh Krishnan wrote:
>
>> Susan,
>>
>> Thank you for explaining the "toilet paper" approach, the issues with 
>> it, and that my proposal is a variant of that approach.
>>
>> It is not clear that there is a universal method (across all networks 
>> and applications) that can determine the optimum segment size, or 
>> even whether it should be a fixed value (not all bundle parts may be 
>> equally important).
>>
>> Best Regards,
>> Rajesh
>>
>>
>>> Rajesh,
>>>
>>> The suggestion that you are making is essentially what we have been 
>>> calling
>>> the "toilet paper" approach --a name that was chosen to be descriptive,
>>> rather than dismissive of the approach, and we keep coming back to 
>>> it, but
>>> it is ugly and complicated.  The toilet paper proposal was made 
>>> before I got
>>> involved in the project; basically, it involves formatting the 
>>> payload as a
>>> series of segments followed by authentication information of those 
>>> segments.
>>> This way, if transmission of a bundle is interrupted before the entire
>>> payload makes it across the link, all those segments that did make 
>>> it with
>>> their accompanying authentication information could be authenticated 
>>> and
>>> forwarded immediately, and only the segment that was interrupted, its
>>> accompanying hash value, and all following segments of the payload 
>>> would
>>> have to be resent.  The reason it is called the toilet paper 
>>> approach is
>>> that the payload is essentially perforated after every
>>> segment,authentication information pair.
>>>
>>> Note that this approach differs slightly from your suggestion 
>>> because it
>>> involves putting the hash(es) in a header rather than embedded in the
>>> payload. If the hashes are in the header, then you would be sending 
>>> all the
>>> hashes before sending even a bit of the payload. It is more 
>>> efficient to
>>> send the hashes only when you know they will be useful, as in right 
>>> after
>>> the payload they protect.
>>> One of the problems that we have had with considering the toilet paper
>>> approach before has been how we would know what a good segment size 
>>> would
>>> be. Determining this size according to the natural concept of what 
>>> the next
>>> safely usable increment at the destination is, as you suggest, is 
>>> appealing.
>>> I like it.
>>>
>>> One problem with it, however, might be that it isn't related to the
>>> capabilities of the network. If a link cannot routinetly stay up 
>>> long enough
>>> to transmit data of that length, then there's no way to use reactive
>>> fragmentation to move data along that link. If a link routinely 
>>> stays up for
>>> much longer than it takes to transmit data of that length, then 
>>> there is a
>>> lot of wasted bandwidth carrying all those embedded hashes. If 
>>> segments are
>>> too large, then lots of data is lost in the "interrupted" segment 
>>> when a
>>> connection is lost and that data needs to be resent.  If segments 
>>> are too
>>> small, lots of bits are wasted with the many signed hash values that 
>>> are
>>> interspersed throughout the payload.
>>> So even though mechanically we understand how we could enable 
>>> authentication
>>> and immediate forwarding to coexist by using the toilet paper 
>>> mechanim, we
>>> don't really don't know how to use this mechanism effectively, 
>>> because we
>>> don't know how to select an optimal segment size.  If you have any 
>>> ideas it
>>> would be great to hear them.
>>>
>>> -susan
>>>
>>> -----Original Message-----
>>> From: Rajesh Krishnan [mailto:[email-masked]] Sent: Monday, April 11, 
>>> 2005 2:12 PM
>>> To: Susan F. Symington
>>> Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>> Subject: Re: [dtn-interest] on ditching fragmentation
>>>
>>> Susan and Mike,
>>>
>>> In some applications, there is a natural concept of what the next 
>>> safely
>>> usable increment at the destination is (e.g. a video frame).
>>>
>>> Suppose a bundle could include a second hash covering the first 
>>> usable increment in addition to the usual hash over the entire 
>>> bundle.  Under reactive fragmentation, the first usable increment 
>>> can be forwarded
>>> if/when available.
>>>
>>> The additional hash could go on an optional fragmentation header to 
>>> be used if immediate forwarding (upon reactive fragmentation) is 
>>> desired.  Hashes that protect subsequent increments can also be 
>>> included in such
>>> a header if one is willing to expend the header overhead. 
>>> Proactive addition of fragment hashes in anticipation of reactive 
>>> fragmentation is a possible medium between the proactive 
>>> fragmentation and reactive fragmentation schemes presented.
>>>
>>> Best Regards,
>>> Rajesh
>>>
>>>
>>>> Mike,
>>>>
>>>> I see your point that there may be some utility in a bundle agent 
>>>> being
>>>
>>>
>>> able
>>>
>>>> to reactively fragment even if it is precluded from immediately
>>>
>>>
>>> forwarding.
>>>
>>>> Here is how our dilemma seems to look right now:
>>>>
>>>>> From a security standpoint, we really want to be able to calculate 
>>>>> the
>>>>
>>>> authentication information in the Bundle Authentication Header over 
>>>> the
>>>> entire bundle, including the payload. We can have this security 
>>>> that we
>>>
>>>
>>> want
>>>
>>>> and we can also have reactive fragmentation, as long as we require 
>>>> that if
>>>
>>>
>>> a
>>>
>>>> bundle is reactively fragmented then its "tail" (which may arrive as
>>>> multiple bundle fragments) is forwarded through the same bundle 
>>>> agent that
>>>> did the reactive fragmentation and is holding on to the head. 
>>>> However, we
>>>> cannot forward the reactively fragmented head until the "tail" is
>>>
>>>
>>> received.
>>>
>>>> My questions for everyone who cares are:
>>>>
>>>> 1. Is it feasible to require the tails of reactively fragmented 
>>>> bundles to
>>>> be forwarded through the same bundle agent as the head?  Is this 
>>>> something
>>>> people are willing to put up with in order to be able to have both the
>>>> security that we want and reactive fragmentation? Or do some people 
>>>> out
>>>> there feel that restricting the bundle's path in this way would be
>>>> unacceptable?
>>>>
>>>> 2. Is being able to reactively fragment but not immediately forward
>>>
>>>
>>> bundles
>>>
>>>> that have Bundle Authentication Headers good enough for people?  We 
>>>> still
>>>
>>>
>>> do
>>>
>>>> get some utility out of being able to reactively fragment, as Mike 
>>>> points
>>>> out, but we don't get the full efficiency of "cut-through routing" 
>>>> because
>>>> the receiving bundle agent can't forward the head until the tail 
>>>> arrives.
>>>
>>>
>>> I
>>>
>>>> think this means that from the viewpoint of the bundle agent that 
>>>> performs
>>>> the reactive fragmentation, the link on which it receives the 
>>>> bundle is
>>>> being used as efficiently as possible (no data that makes it 
>>>> through once
>>>> has to be resent) but the link on which it must forward the data 
>>>> may not
>>>
>>>
>>> be
>>>
>>>> used efficiently, because even though this link may be up and able 
>>>> to be
>>>> used to send data, it may be idle because the bundle agent isn't 
>>>> able to
>>>> send the head until the tail of the bundle has arrived. Is this good
>>>
>>>
>>> enough?
>>>
>>>> Can we settle for this or is the "cut-through" feature that enables 
>>>> both
>>>> links to be used efficiently something that our solution absolutely 
>>>> must
>>>> provide?
>>>>
>>>> Remember, we only run into this problem if security is being used, 
>>>> and, in
>>>> particular, if hop by hop security is being provided by the 
>>>> presence of a
>>>> Bundle Authentication Header in the bundle. If security is not 
>>>> being used,
>>>> or if security is being used and the security features of the 
>>>> underlying
>>>> network are being relied on so that the bundle doesn't have a Bundle
>>>> Authentication Header, then the tails of bundles don't have to have 
>>>> their
>>>> routes restricted and cut-through routing is possible.
>>>>
>>>> If the above compromises are unacceptable, I think we are stuck 
>>>> with the
>>>> toilet paper approach or something like it. What do people think?
>>>>
>>>> -susan
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Michael 
>>>> Demmer
>>>> Sent: Monday, April 11, 2005 12:09 PM
>>>> To: Susan F. Symington
>>>> Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>> Subject: Re: [dtn-interest] on ditching fragmentation
>>>>
>>>>
>>>>
>>>>> If you choose option (b) below, which is to enable rective
>>>>> fragmentation but make sure that all fragments of a given bundle
>>>>> follow the same path, you are doing this because you are requiring
>>>>> the receiving intermediate bundle agent to wait until the entire
>>>>> original bundle is received so that it can authenticate the bundle
>>>>> before forwarding any part of it. But what would be the point of
>>>>> this? Aren't you losing the benefit that the reactive fragmentation
>>>>> is supposed to provide, which is to enable the part of the orignal
>>>>> bundle that was received before the connection went down to be
>>>>> forwarded immediately, without having to wait?
>>>>
>>>>
>>>> Not necessarily. If I have a connection that is only ever up for a
>>>> window of 1/2 the time that it takes to transmit a large bundle, then
>>>> even if I can't forward the first half of the bundle until I get the
>>>> second half, I've still gotten a win out of reactive fragmentation.
>>>>
>>>>
>>>>> We have been saying that we want "reactive fragmentation", but I
>>>>> think that what we really want is to be able to reactively fragment
>>>>> and then immediately forward.
>>>>
>>>>
>>>> This is, I agree, the "touchy" part about reactive fragmentation, and
>>>> the part that makes it tricky wrt authentication. We should come up
>>>> with a name for this (I believe one term tossed around was
>>>> 'cut-thru-routing') as distinct from reactive fragmentation which in
>>>> my mind just handles the connection interruption.
>>>>
>>>>
>>>>> In my mind there is no point in reactively fragmenting if we are
>>>>> going to have to wait to reassemble the bundle before we will be
>>>>> able to forward it or any part of it. 
>>>>
>>>>
>>>> As I said before, I disagree with this.
>>>>
>>>>
>>>>> If what we really want is "reactive fragmentation and immediate
>>>>> forwarding" (which is what I think we want, but we might not all
>>>>> agree on that, I don't know), then option (b) is misleading, because
>>>>> it only enables reactive fragmentation; it precludes immediate
>>>>> forwarding.
>>>>
>>>>
>>>> Agreed -- restate b) to "enable reactive fragmentation but not
>>>> XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
>>>> before the tail arrives).
>>>>
>>>>
>>>>> Reactive fragmentation and immediate forwarding *is* incompatible
>>>>> with the type of bundle authentication that is now defined as being
>>>>> provided in the Bundle Authentication Header.
>>>>
>>>>
>>>> Yes, I agree with that.
>>>>
>>>> -m
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Stephen,<br>
<br>
I'm finally catching up on all of the traffic (I'm off at the CCSDS
meeting in Athens)......<br>
<br>
Your approach is problematic because of the extra state required in an
already potentially resource starved environment.&nbsp; Won't the sender
need to keep the hash for X (where I have no idea what the value of X
should be) to cover any reactive fragementation issues?&nbsp; So the sender
would have to calculate the hash and not just send it, but also store
it because it might need to use it later on a fragment.&nbsp; Yech.... How
would we ever figure out how long to hang onto it?&nbsp; Also, what happens
if the reactive fragmentation results in many fragments - then how long
should the sender have to hang onto the hash?<br>
<br>
Howie<br>
</font></font><br>
Stephen Farrell wrote:<br>
<blockquote cite="[email-masked]" type="cite"><br>
Ok, here's another possibly despairing go at this thread:-)
  <br>
  <br>
Am I right in assuming that reactive fragmentation requires
  <br>
that the transmitter knows fairly well how much of the previous
  <br>
fragment got through? (Otherwise it'll just have to re-Tx
  <br>
everything, right?).
  <br>
  <br>
In that case, couldn't we arrange that the 2nd fragment (which
  <br>
could contain part of all of the remaining bundle bytes) contains
  <br>
a hash/MAC that covers the 1st? As soon as the receiver gets
  <br>
and checks this it can then forward the combined content of
  <br>
the two bundles (together or not, I don't know!), and doesn't
  <br>
have wait for the end of the payload.
  <br>
  <br>
That way, we can forward without waiting for the last fragment,
  <br>
which should often be somewhat better.
  <br>
  <br>
More generally, we add a requirement that where hop-by-hop
  <br>
security is in force, then the next bundle sent to the recipient
  <br>
of a reactively fragmented bundle must authenticate the previous
  <br>
fragment received by that recipient.
  <br>
  <br>
The BAH on the first bundle sent can continue to optimistically
  <br>
cover the entire payload.
  <br>
  <br>
If this scheme works, it probably needs some tweaking so that
  <br>
the new header in the 2nd fragment (previous-BAH?) will have
  <br>
to indicate the range of payload (and implicitly which headers)
  <br>
are covered by the hash/MAC. We'd also need to define a timer
  <br>
for anti-DoS reasons and in case the transmitter never gets
  <br>
to use that receiver again for that payload. If the 2nd bundle
  <br>
is BAHed, (which I guess it probably ought to be, assuming
  <br>
policies don't change that quickly) then including a hash,
  <br>
rather than a signature or MAC, in the previous-BAH header
  <br>
might be sufficient, at least until we figure out how BAH-keys
  <br>
might rollover.
  <br>
  <br>
And I guess if the fragment that got through is shorter than
  <br>
the new crud we're adding then we should just re-tx the lot:-)
  <br>
  <br>
If we're deliberatlely fragmenting, this is of course a non-issue
  <br>
since you can BAH-protect each entire fragment-bundle before Txing.
  <br>
  <br>
And just in case: this is all a non-issue for e2e security since
  <br>
re-assembly at the destination can handle that (or not, if not
  <br>
all fragments arrive). With e2e security and missing fragments,
  <br>
toilet-paper is the only answer so far.
  <br>
  <br>
Stephen.
  <br>
  <br>
Rajesh Krishnan wrote:
  <br>
  <br>
  <blockquote type="cite">Susan,
    <br>
    <br>
Thank you for explaining the "toilet paper" approach, the issues with
it, and that my proposal is a variant of that approach.
    <br>
    <br>
It is not clear that there is a universal method (across all networks
and applications) that can determine the optimum segment size, or even
whether it should be a fixed value (not all bundle parts may be equally
important).
    <br>
    <br>
Best Regards,
    <br>
Rajesh
    <br>
    <br>
    <br>
    <blockquote type="cite">Rajesh,
      <br>
      <br>
The suggestion that you are making is essentially what we have been
calling
      <br>
the "toilet paper" approach --a name that was chosen to be descriptive,
      <br>
rather than dismissive of the approach, and we keep coming back to it,
but
      <br>
it is ugly and complicated.&nbsp; The toilet paper proposal was made before
I got
      <br>
involved in the project; basically, it involves formatting the payload
as a
      <br>
series of segments followed by authentication information of those
segments.
      <br>
This way, if transmission of a bundle is interrupted before the entire
      <br>
payload makes it across the link, all those segments that did make it
with
      <br>
their accompanying authentication information could be authenticated
and
      <br>
forwarded immediately, and only the segment that was interrupted, its
      <br>
accompanying hash value, and all following segments of the payload
would
      <br>
have to be resent.&nbsp; The reason it is called the toilet paper approach
is
      <br>
that the payload is essentially perforated after every
      <br>
segment,authentication information pair.
      <br>
      <br>
Note that this approach differs slightly from your suggestion because
it
      <br>
involves putting the hash(es) in a header rather than embedded in the
      <br>
payload. If the hashes are in the header, then you would be sending all
the
      <br>
hashes before sending even a bit of the payload. It is more efficient
to
      <br>
send the hashes only when you know they will be useful, as in right
after
      <br>
the payload they protect. <br>
One of the problems that we have had with considering the toilet paper
      <br>
approach before has been how we would know what a good segment size
would
      <br>
be. Determining this size according to the natural concept of what the
next
      <br>
safely usable increment at the destination is, as you suggest, is
appealing.
      <br>
I like it.
      <br>
      <br>
One problem with it, however, might be that it isn't related to the
      <br>
capabilities of the network. If a link cannot routinetly stay up long
enough
      <br>
to transmit data of that length, then there's no way to use reactive
      <br>
fragmentation to move data along that link. If a link routinely stays
up for
      <br>
much longer than it takes to transmit data of that length, then there
is a
      <br>
lot of wasted bandwidth carrying all those embedded hashes. If segments
are
      <br>
too large, then lots of data is lost in the "interrupted" segment when
a
      <br>
connection is lost and that data needs to be resent.&nbsp; If segments are
too
      <br>
small, lots of bits are wasted with the many signed hash values that
are
      <br>
interspersed throughout the payload. <br>
So even though mechanically we understand how we could enable
authentication
      <br>
and immediate forwarding to coexist by using the toilet paper mechanim,
we
      <br>
don't really don't know how to use this mechanism effectively, because
we
      <br>
don't know how to select an optimal segment size.&nbsp; If you have any
ideas it
      <br>
would be great to hear them.
      <br>
      <br>
-susan
      <br>
      <br>
-----Original Message-----
      <br>
From: Rajesh Krishnan [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] Sent: Monday, April 11,
2005 2:12 PM
      <br>
To: Susan F. Symington
      <br>
Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
      <br>
Subject: Re: [dtn-interest] on ditching fragmentation
      <br>
      <br>
Susan and Mike,
      <br>
      <br>
In some applications, there is a natural concept of what the next
safely
      <br>
usable increment at the destination is (e.g. a video frame).
      <br>
      <br>
Suppose a bundle could include a second hash covering the first usable
increment in addition to the usual hash over the entire bundle.&nbsp; Under
reactive fragmentation, the first usable increment can be forwarded
      <br>
if/when available.
      <br>
      <br>
The additional hash could go on an optional fragmentation header to be
used if immediate forwarding (upon reactive fragmentation) is desired.&nbsp;
Hashes that protect subsequent increments can also be included in such
      <br>
a header if one is willing to expend the header overhead.&nbsp; <br>
Proactive addition of fragment hashes in anticipation of reactive
fragmentation is a possible medium between the proactive fragmentation
and reactive fragmentation schemes presented.
      <br>
      <br>
Best Regards,
      <br>
Rajesh
      <br>
      <br>
      <br>
      <blockquote type="cite">Mike,
        <br>
        <br>
I see your point that there may be some utility in a bundle agent being
        <br>
      </blockquote>
      <br>
able
      <br>
      <br>
      <blockquote type="cite">to reactively fragment even if it is
precluded from immediately
        <br>
      </blockquote>
      <br>
forwarding. <br>
      <blockquote type="cite">Here is how our dilemma seems to look
right now:
        <br>
        <br>
        <blockquote type="cite">From a security standpoint, we really
want to be able to calculate the
          <br>
        </blockquote>
authentication information in the Bundle Authentication Header over the
        <br>
entire bundle, including the payload. We can have this security that we
        <br>
      </blockquote>
      <br>
want
      <br>
      <br>
      <blockquote type="cite">and we can also have reactive
fragmentation, as long as we require that if
        <br>
      </blockquote>
      <br>
a
      <br>
      <br>
      <blockquote type="cite">bundle is reactively fragmented then its
"tail" (which may arrive as
        <br>
multiple bundle fragments) is forwarded through the same bundle agent
that
        <br>
did the reactive fragmentation and is holding on to the head. However,
we
        <br>
cannot forward the reactively fragmented head until the "tail" is
        <br>
      </blockquote>
      <br>
received.
      <br>
      <br>
      <blockquote type="cite">My questions for everyone who cares are:
        <br>
        <br>
1. Is it feasible to require the tails of reactively fragmented bundles
to
        <br>
be forwarded through the same bundle agent as the head?&nbsp; Is this
something
        <br>
people are willing to put up with in order to be able to have both the
        <br>
security that we want and reactive fragmentation? Or do some people out
        <br>
there feel that restricting the bundle's path in this way would be
        <br>
unacceptable?
        <br>
        <br>
2. Is being able to reactively fragment but not immediately forward
        <br>
      </blockquote>
      <br>
bundles
      <br>
      <br>
      <blockquote type="cite">that have Bundle Authentication Headers
good enough for people?&nbsp; We still
        <br>
      </blockquote>
      <br>
do
      <br>
      <br>
      <blockquote type="cite">get some utility out of being able to
reactively fragment, as Mike points
        <br>
out, but we don't get the full efficiency of "cut-through routing"
because
        <br>
the receiving bundle agent can't forward the head until the tail
arrives.
        <br>
      </blockquote>
      <br>
I
      <br>
      <br>
      <blockquote type="cite">think this means that from the viewpoint
of the bundle agent that performs
        <br>
the reactive fragmentation, the link on which it receives the bundle is
        <br>
being used as efficiently as possible (no data that makes it through
once
        <br>
has to be resent) but the link on which it must forward the data may
not
        <br>
      </blockquote>
      <br>
be
      <br>
      <br>
      <blockquote type="cite">used efficiently, because even though
this link may be up and able to be
        <br>
used to send data, it may be idle because the bundle agent isn't able
to
        <br>
send the head until the tail of the bundle has arrived. Is this good
        <br>
      </blockquote>
      <br>
enough?
      <br>
      <br>
      <blockquote type="cite">Can we settle for this or is the
"cut-through" feature that enables both
        <br>
links to be used efficiently something that our solution absolutely
must
        <br>
provide?
        <br>
        <br>
Remember, we only run into this problem if security is being used, and,
in
        <br>
particular, if hop by hop security is being provided by the presence of
a
        <br>
Bundle Authentication Header in the bundle. If security is not being
used,
        <br>
or if security is being used and the security features of the
underlying
        <br>
network are being relied on so that the bundle doesn't have a Bundle
        <br>
Authentication Header, then the tails of bundles don't have to have
their
        <br>
routes restricted and cut-through routing is possible.
        <br>
        <br>
If the above compromises are unacceptable, I think we are stuck with
the
        <br>
toilet paper approach or something like it. What do people think?
        <br>
        <br>
-susan
        <br>
        <br>
-----Original Message-----
        <br>
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
        <br>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of Michael
Demmer
        <br>
Sent: Monday, April 11, 2005 12:09 PM
        <br>
To: Susan F. Symington
        <br>
Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
        <br>
Subject: Re: [dtn-interest] on ditching fragmentation
        <br>
        <br>
        <br>
        <br>
        <blockquote type="cite">If you choose option (b) below, which
is to enable rective
          <br>
fragmentation but make sure that all fragments of a given bundle
          <br>
follow the same path, you are doing this because you are requiring
          <br>
the receiving intermediate bundle agent to wait until the entire
          <br>
original bundle is received so that it can authenticate the bundle
          <br>
before forwarding any part of it. But what would be the point of
          <br>
this? Aren't you losing the benefit that the reactive fragmentation
          <br>
is supposed to provide, which is to enable the part of the orignal
          <br>
bundle that was received before the connection went down to be
          <br>
forwarded immediately, without having to wait?
          <br>
        </blockquote>
        <br>
Not necessarily. If I have a connection that is only ever up for a
        <br>
window of 1/2 the time that it takes to transmit a large bundle, then
        <br>
even if I can't forward the first half of the bundle until I get the
        <br>
second half, I've still gotten a win out of reactive fragmentation.
        <br>
        <br>
        <br>
        <blockquote type="cite">We have been saying that we want
"reactive fragmentation", but I
          <br>
think that what we really want is to be able to reactively fragment
          <br>
and then immediately forward.
          <br>
        </blockquote>
        <br>
This is, I agree, the "touchy" part about reactive fragmentation, and
        <br>
the part that makes it tricky wrt authentication. We should come up
        <br>
with a name for this (I believe one term tossed around was
        <br>
'cut-thru-routing') as distinct from reactive fragmentation which in
        <br>
my mind just handles the connection interruption.
        <br>
        <br>
        <br>
        <blockquote type="cite">In my mind there is no point in
reactively fragmenting if we are
          <br>
going to have to wait to reassemble the bundle before we will be
          <br>
able to forward it or any part of it. </blockquote>
        <br>
As I said before, I disagree with this.
        <br>
        <br>
        <br>
        <blockquote type="cite">If what we really want is "reactive
fragmentation and immediate
          <br>
forwarding" (which is what I think we want, but we might not all
          <br>
agree on that, I don't know), then option (b) is misleading, because
          <br>
it only enables reactive fragmentation; it precludes immediate
          <br>
forwarding.
          <br>
        </blockquote>
        <br>
Agreed -- restate b) to "enable reactive fragmentation but not
        <br>
XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
        <br>
before the tail arrives).
        <br>
        <br>
        <br>
        <blockquote type="cite">Reactive fragmentation and immediate
forwarding *is* incompatible
          <br>
with the type of bundle authentication that is now defined as being
          <br>
provided in the Bundle Authentication Header.
          <br>
        </blockquote>
        <br>
Yes, I agree with that.
        <br>
        <br>
-m
        <br>
_______________________________________________
        <br>
dtn-interest mailing list
        <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
        <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
        <br>
        <br>
        <br>
        <br>
_______________________________________________
        <br>
dtn-interest mailing list
        <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
        <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      <br>
      <br>
_______________________________________________
      <br>
dtn-interest mailing list
      <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
      <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
      <br>
      <br>
    </blockquote>
    <br>
    <br>
_______________________________________________
    <br>
dtn-interest mailing list
    <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
    <br>
    <br>
    <br>
  </blockquote>
_______________________________________________
  <br>
dtn-interest mailing list
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
  <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
  <br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

--------------020703030408090201050801--

Date: Tue, 12 Apr 2005 19:26:06 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Rajesh,

I'm entirely in agreement with your mail.

However, I don't have a better solution right now. Maybe
its time for me to think more and type less.

Stephen.

PS: Of course I can't resist this one:-)

      fantasy: "I like shooting at UAVs by faking a fragment so that
                from the summary fragment received, the sensor data looks
                important enough to fly a UAV and pick it up from the
                last custodian before the bundle expires"

Rajesh Krishnan wrote:

> Stephen,
> 
> I agree that the toilet paper and the 2nd contact reactive scheme you
> are both more general that the first usable increment hash. 
> 
> Nonetheless, I am interested in special cases of the e2e toilet paper 
> approach where some (not all) fragments are specially protected:
> 
>   - the first fragment may contain usable information or a summary as
>     I mentioned before
> 
>     arguably, proactive fragmentation (perhaps by the application) is 
>     an alternative.
> 
>   - the first fragment (perhaps even only the header) may double as a 
>     needle message and proceed to find routes through a network to the 
>     destination (waiting for the entire bundle or the second fragment 
>     to cross an intermediate hop may be less desirable in such 
>     reactive/wormhole/cut-through routing situations)
> 
>     arguably, separately issued administrative bundles are an alternative.
> 
>   - the first fragment can provide early signals to en route nodes and the
>     destination regarding a bundle experiencing fragmentation; if knowledge 
>     distribution in the network is asymmetric, some en route nodes or the 
>     destination may have more knowledge (or capabilities) at their disposal 
>     say, to instantiate network paths on demand to acquire this bundle from
>     the previous custodian
> 
>     arguably, separately issued administrative bundles are an alternative.
> 
>     (fantasy: "from the summary fragment received, the sensor data looks 
>      important enough to fly a UAV and pick it up from the last custodian 
>      before the bundle expires")
> 
>     (fantasy: "content gets pushed towards the destination at a trickle, 
>      but if there is a high enough interest gradient, destinations/subnets 
>      may be willing to pay for and set up reserved paths to pull the content 
>      faster")
> 
> The toilet paper subsumes all the above cases, but note that the above cases 
> I mention do not require that every fragment be uniformly protected; so,
> fewer hashes are needed.  In any case, episodically connected environments 
> will benefit greatly by any open-loop mechanisms we can include.
> 
> Best Regards,
> Rajesh
> 
> 
>>Rejesh,
>>
>>You're correct that if you need that single contact to suffice
>>while allowing reactive fragmentation then my proposal doesn't
>>help. But afaik you need toilet paper to meet the requirement
>>you've stated - which is after all an e2e requirement!
>>
>>Forward adding an extra MAC/signature just in case of reactive
>>fragmentation would seem wasteful generally - if such
>>fragmentation is that frequent, shouldn't you really do something
>>else, e.g. e2e toilet paper? Maybe I could just about buy it
>>for a network where each node somehow shares a MACing key
>>with each of its next-hop peers, but where there's no e2e key
>>management at all, however I'd first have to see how that key
>>management scheme works, since if its trivial for any-old-node
>>to join such a n/w then the DoS attack using fragments works
>>and there's maybe little or no point at all in BAHs!
>>
>>Adding a previous-BAH header after reactive fragmentation
>>is maybe the right thing but as you say, you do need
>>that 2nd contact for this to be effective. I think I'd
>>maintain that you need it anyway for reactive fragmentation
>>to be a useful general technique.
>>
>>If the 2nd contact is very likely not to be with the 1st
>>receiver, but the 2nd receiver is likely to be in non-delayed
>>comms. with the 1st receiver, then it'd be better for the
>>2nd contact to contain a header (3rd-party-previous-BAH?)
>>that can be extracted and then forwarded from the 2nd
>>receiver to the 1st receiver, either in a bundle of its
>>own, or else in the n/w below the bundling layer.
>>
>>There are so many contingencies here though that I'm not
>>sure any of this is worthwhile.
>>
>>Stephen.
>>
>>
>>Rajesh Krishnan wrote:
>>
>>
>>>The time of arrival of the 2nd fragment from the same previous hop (which 
>>>may not happen soon) is a gating fctor.  We cannot make a single contact 
>>>count.
>>>
>>>Forward addition of a hash for the first usable increment potentially gets 
>>>around this limitation (assuming we know the size of the first usable 
>>>increment and that a fragment of at least this size gets through).  I admit 
>>>that forward addition is not a sufficiently general fix.  The corner case 
>>>of interest to me was the ability to salvage a frame of video transferred 
>>>in a single contact when the bundle containing the rest of the frame sequence 
>>>expires.  
>>>
>>>-Rajesh
>>>
>>>
>>>
>>>>Ok, here's another possibly despairing go at this thread:-)
>>>>
>>>>Am I right in assuming that reactive fragmentation requires
>>>>that the transmitter knows fairly well how much of the previous
>>>>fragment got through? (Otherwise it'll just have to re-Tx
>>>>everything, right?).
>>>>
>>>>In that case, couldn't we arrange that the 2nd fragment (which
>>>>could contain part of all of the remaining bundle bytes) contains
>>>>a hash/MAC that covers the 1st? As soon as the receiver gets
>>>>and checks this it can then forward the combined content of
>>>>the two bundles (together or not, I don't know!), and doesn't
>>>>have wait for the end of the payload.
>>>>
>>>>That way, we can forward without waiting for the last fragment,
>>>>which should often be somewhat better.
>>>>
>>>>More generally, we add a requirement that where hop-by-hop
>>>>security is in force, then the next bundle sent to the recipient
>>>>of a reactively fragmented bundle must authenticate the previous
>>>>fragment received by that recipient.
>>>>
>>>>The BAH on the first bundle sent can continue to optimistically
>>>>cover the entire payload.
>>>>
>>>>If this scheme works, it probably needs some tweaking so that
>>>>the new header in the 2nd fragment (previous-BAH?) will have
>>>>to indicate the range of payload (and implicitly which headers)
>>>>are covered by the hash/MAC. We'd also need to define a timer
>>>>for anti-DoS reasons and in case the transmitter never gets
>>>>to use that receiver again for that payload. If the 2nd bundle
>>>>is BAHed, (which I guess it probably ought to be, assuming
>>>>policies don't change that quickly) then including a hash,
>>>>rather than a signature or MAC, in the previous-BAH header
>>>>might be sufficient, at least until we figure out how BAH-keys
>>>>might rollover.
>>>>
>>>>And I guess if the fragment that got through is shorter than
>>>>the new crud we're adding then we should just re-tx the lot:-)
>>>>
>>>>If we're deliberatlely fragmenting, this is of course a non-issue
>>>>since you can BAH-protect each entire fragment-bundle before Txing.
>>>>
>>>>And just in case: this is all a non-issue for e2e security since
>>>>re-assembly at the destination can handle that (or not, if not
>>>>all fragments arrive). With e2e security and missing fragments,
>>>>toilet-paper is the only answer so far.
>>>>
>>>>Stephen.
>>>>
>>>>Rajesh Krishnan wrote:
>>>>
>>>>
>>>>
>>>>>Susan,
>>>>>
>>>>>Thank you for explaining the "toilet paper" approach, the issues 
>>>>>with it, and that my proposal is a variant of that approach.
>>>>>
>>>>>It is not clear that there is a universal method (across all networks 
>>>>>and applications) that can determine the optimum segment size, or even 
>>>>>whether it should be a fixed value (not all bundle parts may be equally 
>>>>>important).
>>>>>
>>>>>Best Regards,
>>>>>Rajesh
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Rajesh,
>>>>>>
>>>>>>The suggestion that you are making is essentially what we have been calling
>>>>>>the "toilet paper" approach --a name that was chosen to be descriptive,
>>>>>>rather than dismissive of the approach, and we keep coming back to it, but
>>>>>>it is ugly and complicated.  The toilet paper proposal was made before I got
>>>>>>involved in the project; basically, it involves formatting the payload as a
>>>>>>series of segments followed by authentication information of those segments.
>>>>>>This way, if transmission of a bundle is interrupted before the entire
>>>>>>payload makes it across the link, all those segments that did make it with
>>>>>>their accompanying authentication information could be authenticated and
>>>>>>forwarded immediately, and only the segment that was interrupted, its
>>>>>>accompanying hash value, and all following segments of the payload would
>>>>>>have to be resent.  The reason it is called the toilet paper approach is
>>>>>>that the payload is essentially perforated after every
>>>>>>segment,authentication information pair.
>>>>>>
>>>>>>Note that this approach differs slightly from your suggestion because it
>>>>>>involves putting the hash(es) in a header rather than embedded in the
>>>>>>payload. If the hashes are in the header, then you would be sending all the
>>>>>>hashes before sending even a bit of the payload. It is more efficient to
>>>>>>send the hashes only when you know they will be useful, as in right after
>>>>>>the payload they protect. 
>>>>>>
>>>>>>One of the problems that we have had with considering the toilet paper
>>>>>>approach before has been how we would know what a good segment size would
>>>>>>be. Determining this size according to the natural concept of what the next
>>>>>>safely usable increment at the destination is, as you suggest, is appealing.
>>>>>>I like it.
>>>>>>
>>>>>>One problem with it, however, might be that it isn't related to the
>>>>>>capabilities of the network. If a link cannot routinetly stay up long enough
>>>>>>to transmit data of that length, then there's no way to use reactive
>>>>>>fragmentation to move data along that link. If a link routinely stays up for
>>>>>>much longer than it takes to transmit data of that length, then there is a
>>>>>>lot of wasted bandwidth carrying all those embedded hashes. If segments are
>>>>>>too large, then lots of data is lost in the "interrupted" segment when a
>>>>>>connection is lost and that data needs to be resent.  If segments are too
>>>>>>small, lots of bits are wasted with the many signed hash values that are
>>>>>>interspersed throughout the payload. 
>>>>>>
>>>>>>So even though mechanically we understand how we could enable authentication
>>>>>>and immediate forwarding to coexist by using the toilet paper mechanim, we
>>>>>>don't really don't know how to use this mechanism effectively, because we
>>>>>>don't know how to select an optimal segment size.  If you have any ideas it
>>>>>>would be great to hear them.
>>>>>>
>>>>>>-susan
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Rajesh Krishnan [mailto:[email-masked]] 
>>>>>>Sent: Monday, April 11, 2005 2:12 PM
>>>>>>To: Susan F. Symington
>>>>>>Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>>>>Subject: Re: [dtn-interest] on ditching fragmentation
>>>>>>
>>>>>>Susan and Mike,
>>>>>>
>>>>>>In some applications, there is a natural concept of what the next safely
>>>>>>usable increment at the destination is (e.g. a video frame).
>>>>>>
>>>>>>Suppose a bundle could include a second hash covering the first usable 
>>>>>>increment in addition to the usual hash over the entire bundle.  Under 
>>>>>>reactive fragmentation, the first usable increment can be forwarded
>>>>>>if/when available.
>>>>>>
>>>>>>The additional hash could go on an optional fragmentation header to be 
>>>>>>used if immediate forwarding (upon reactive fragmentation) is desired.  
>>>>>>Hashes that protect subsequent increments can also be included in such
>>>>>>a header if one is willing to expend the header overhead.  
>>>>>>
>>>>>>Proactive addition of fragment hashes in anticipation of reactive 
>>>>>>fragmentation is a possible medium between the proactive fragmentation 
>>>>>>and reactive fragmentation schemes presented.
>>>>>>
>>>>>>Best Regards,
>>>>>>Rajesh
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Mike,
>>>>>>>
>>>>>>>I see your point that there may be some utility in a bundle agent being
>>>>>>
>>>>>>able
>>>>>>
>>>>>>
>>>>>>
>>>>>>>to reactively fragment even if it is precluded from immediately
>>>>>>
>>>>>>forwarding. 
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Here is how our dilemma seems to look right now:
>>>>>>>
>>>>>>>>From a security standpoint, we really want to be able to calculate the
>>>>>>>authentication information in the Bundle Authentication Header over the
>>>>>>>entire bundle, including the payload. We can have this security that we
>>>>>>
>>>>>>want
>>>>>>
>>>>>>
>>>>>>
>>>>>>>and we can also have reactive fragmentation, as long as we require that if
>>>>>>
>>>>>>a
>>>>>>
>>>>>>
>>>>>>
>>>>>>>bundle is reactively fragmented then its "tail" (which may arrive as
>>>>>>>multiple bundle fragments) is forwarded through the same bundle agent that
>>>>>>>did the reactive fragmentation and is holding on to the head. However, we
>>>>>>>cannot forward the reactively fragmented head until the "tail" is
>>>>>>
>>>>>>received.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>My questions for everyone who cares are:
>>>>>>>
>>>>>>>1. Is it feasible to require the tails of reactively fragmented bundles to
>>>>>>>be forwarded through the same bundle agent as the head?  Is this something
>>>>>>>people are willing to put up with in order to be able to have both the
>>>>>>>security that we want and reactive fragmentation? Or do some people out
>>>>>>>there feel that restricting the bundle's path in this way would be
>>>>>>>unacceptable?
>>>>>>>
>>>>>>>2. Is being able to reactively fragment but not immediately forward
>>>>>>
>>>>>>bundles
>>>>>>
>>>>>>
>>>>>>
>>>>>>>that have Bundle Authentication Headers good enough for people?  We still
>>>>>>
>>>>>>do
>>>>>>
>>>>>>
>>>>>>
>>>>>>>get some utility out of being able to reactively fragment, as Mike points
>>>>>>>out, but we don't get the full efficiency of "cut-through routing" because
>>>>>>>the receiving bundle agent can't forward the head until the tail arrives.
>>>>>>
>>>>>>I
>>>>>>
>>>>>>
>>>>>>
>>>>>>>think this means that from the viewpoint of the bundle agent that performs
>>>>>>>the reactive fragmentation, the link on which it receives the bundle is
>>>>>>>being used as efficiently as possible (no data that makes it through once
>>>>>>>has to be resent) but the link on which it must forward the data may not
>>>>>>
>>>>>>be
>>>>>>
>>>>>>
>>>>>>
>>>>>>>used efficiently, because even though this link may be up and able to be
>>>>>>>used to send data, it may be idle because the bundle agent isn't able to
>>>>>>>send the head until the tail of the bundle has arrived. Is this good
>>>>>>
>>>>>>enough?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Can we settle for this or is the "cut-through" feature that enables both
>>>>>>>links to be used efficiently something that our solution absolutely must
>>>>>>>provide?
>>>>>>>
>>>>>>>Remember, we only run into this problem if security is being used, and, in
>>>>>>>particular, if hop by hop security is being provided by the presence of a
>>>>>>>Bundle Authentication Header in the bundle. If security is not being used,
>>>>>>>or if security is being used and the security features of the underlying
>>>>>>>network are being relied on so that the bundle doesn't have a Bundle
>>>>>>>Authentication Header, then the tails of bundles don't have to have their
>>>>>>>routes restricted and cut-through routing is possible.
>>>>>>>
>>>>>>>If the above compromises are unacceptable, I think we are stuck with the
>>>>>>>toilet paper approach or something like it. What do people think?
>>>>>>>
>>>>>>>-susan
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [email-masked]
>>>>>>>[mailto:[email-masked]] On Behalf Of Michael Demmer
>>>>>>>Sent: Monday, April 11, 2005 12:09 PM
>>>>>>>To: Susan F. Symington
>>>>>>>Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>>>>>Subject: Re: [dtn-interest] on ditching fragmentation
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>If you choose option (b) below, which is to enable rective
>>>>>>>>fragmentation but make sure that all fragments of a given bundle
>>>>>>>>follow the same path, you are doing this because you are requiring
>>>>>>>>the receiving intermediate bundle agent to wait until the entire
>>>>>>>>original bundle is received so that it can authenticate the bundle
>>>>>>>>before forwarding any part of it. But what would be the point of
>>>>>>>>this? Aren't you losing the benefit that the reactive fragmentation
>>>>>>>>is supposed to provide, which is to enable the part of the orignal
>>>>>>>>bundle that was received before the connection went down to be
>>>>>>>>forwarded immediately, without having to wait?
>>>>>>>
>>>>>>>Not necessarily. If I have a connection that is only ever up for a
>>>>>>>window of 1/2 the time that it takes to transmit a large bundle, then
>>>>>>>even if I can't forward the first half of the bundle until I get the
>>>>>>>second half, I've still gotten a win out of reactive fragmentation.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>We have been saying that we want "reactive fragmentation", but I
>>>>>>>>think that what we really want is to be able to reactively fragment
>>>>>>>>and then immediately forward.
>>>>>>>
>>>>>>>This is, I agree, the "touchy" part about reactive fragmentation, and
>>>>>>>the part that makes it tricky wrt authentication. We should come up
>>>>>>>with a name for this (I believe one term tossed around was
>>>>>>>'cut-thru-routing') as distinct from reactive fragmentation which in
>>>>>>>my mind just handles the connection interruption.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>In my mind there is no point in reactively fragmenting if we are
>>>>>>>>going to have to wait to reassemble the bundle before we will be
>>>>>>>>able to forward it or any part of it. 
>>>>>>>
>>>>>>>As I said before, I disagree with this.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>If what we really want is "reactive fragmentation and immediate
>>>>>>>>forwarding" (which is what I think we want, but we might not all
>>>>>>>>agree on that, I don't know), then option (b) is misleading, because
>>>>>>>>it only enables reactive fragmentation; it precludes immediate
>>>>>>>>forwarding.
>>>>>>>
>>>>>>>Agreed -- restate b) to "enable reactive fragmentation but not
>>>>>>>XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
>>>>>>>before the tail arrives).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Reactive fragmentation and immediate forwarding *is* incompatible
>>>>>>>>with the type of bundle authentication that is now defined as being
>>>>>>>>provided in the Bundle Authentication Header.
>>>>>>>
>>>>>>>Yes, I agree with that.
>>>>>>>
>>>>>>>-m
>>>>>>>_______________________________________________
>>>>>>>dtn-interest mailing list
>>>>>>>[email-masked]
>>>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>dtn-interest mailing list
>>>>>>>[email-masked]
>>>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>dtn-interest mailing list
>>>>>>[email-masked]
>>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>dtn-interest mailing list
>>>>>[email-masked]
>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>
>>>>>
>>>>
>>>>_______________________________________________
>>>>dtn-interest mailing list
>>>>[email-masked]
>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>>
>>>
>>>
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
To: [email-masked] (Stephen Farrell)
Date: Tue, 12 Apr 2005 14:09:32 -0400 (EDT)
Cc: [email-masked], [email-masked] (Susan F. Symington), [email-masked] ('DTN')
Reply-to: [email-masked]
Sender: [email-masked]

Stephen,

I agree that the toilet paper and the 2nd contact reactive scheme you
are both more general that the first usable increment hash. 

Nonetheless, I am interested in special cases of the e2e toilet paper 
approach where some (not all) fragments are specially protected:

  - the first fragment may contain usable information or a summary as
    I mentioned before

    arguably, proactive fragmentation (perhaps by the application) is 
    an alternative.

  - the first fragment (perhaps even only the header) may double as a 
    needle message and proceed to find routes through a network to the 
    destination (waiting for the entire bundle or the second fragment 
    to cross an intermediate hop may be less desirable in such 
    reactive/wormhole/cut-through routing situations)

    arguably, separately issued administrative bundles are an alternative.

  - the first fragment can provide early signals to en route nodes and the
    destination regarding a bundle experiencing fragmentation; if knowledge 
    distribution in the network is asymmetric, some en route nodes or the 
    destination may have more knowledge (or capabilities) at their disposal 
    say, to instantiate network paths on demand to acquire this bundle from
    the previous custodian

    arguably, separately issued administrative bundles are an alternative.

    (fantasy: "from the summary fragment received, the sensor data looks 
     important enough to fly a UAV and pick it up from the last custodian 
     before the bundle expires")

    (fantasy: "content gets pushed towards the destination at a trickle, 
     but if there is a high enough interest gradient, destinations/subnets 
     may be willing to pay for and set up reserved paths to pull the content 
     faster")

The toilet paper subsumes all the above cases, but note that the above cases 
I mention do not require that every fragment be uniformly protected; so,
fewer hashes are needed.  In any case, episodically connected environments 
will benefit greatly by any open-loop mechanisms we can include.

Best Regards,
Rajesh

> Rejesh,
> 
> You're correct that if you need that single contact to suffice
> while allowing reactive fragmentation then my proposal doesn't
> help. But afaik you need toilet paper to meet the requirement
> you've stated - which is after all an e2e requirement!
> 
> Forward adding an extra MAC/signature just in case of reactive
> fragmentation would seem wasteful generally - if such
> fragmentation is that frequent, shouldn't you really do something
> else, e.g. e2e toilet paper? Maybe I could just about buy it
> for a network where each node somehow shares a MACing key
> with each of its next-hop peers, but where there's no e2e key
> management at all, however I'd first have to see how that key
> management scheme works, since if its trivial for any-old-node
> to join such a n/w then the DoS attack using fragments works
> and there's maybe little or no point at all in BAHs!
> 
> Adding a previous-BAH header after reactive fragmentation
> is maybe the right thing but as you say, you do need
> that 2nd contact for this to be effective. I think I'd
> maintain that you need it anyway for reactive fragmentation
> to be a useful general technique.
> 
> If the 2nd contact is very likely not to be with the 1st
> receiver, but the 2nd receiver is likely to be in non-delayed
> comms. with the 1st receiver, then it'd be better for the
> 2nd contact to contain a header (3rd-party-previous-BAH?)
> that can be extracted and then forwarded from the 2nd
> receiver to the 1st receiver, either in a bundle of its
> own, or else in the n/w below the bundling layer.
> 
> There are so many contingencies here though that I'm not
> sure any of this is worthwhile.
> 
> Stephen.
> 
> 
> Rajesh Krishnan wrote:
> 
> > The time of arrival of the 2nd fragment from the same previous hop (which 
> > may not happen soon) is a gating fctor.  We cannot make a single contact 
> > count.
> > 
> > Forward addition of a hash for the first usable increment potentially gets 
> > around this limitation (assuming we know the size of the first usable 
> > increment and that a fragment of at least this size gets through).  I admit 
> > that forward addition is not a sufficiently general fix.  The corner case 
> > of interest to me was the ability to salvage a frame of video transferred 
> > in a single contact when the bundle containing the rest of the frame sequence 
> > expires.  
> > 
> > -Rajesh
> > 
> > 
> >>Ok, here's another possibly despairing go at this thread:-)
> >>
> >>Am I right in assuming that reactive fragmentation requires
> >>that the transmitter knows fairly well how much of the previous
> >>fragment got through? (Otherwise it'll just have to re-Tx
> >>everything, right?).
> >>
> >>In that case, couldn't we arrange that the 2nd fragment (which
> >>could contain part of all of the remaining bundle bytes) contains
> >>a hash/MAC that covers the 1st? As soon as the receiver gets
> >>and checks this it can then forward the combined content of
> >>the two bundles (together or not, I don't know!), and doesn't
> >>have wait for the end of the payload.
> >>
> >>That way, we can forward without waiting for the last fragment,
> >>which should often be somewhat better.
> >>
> >>More generally, we add a requirement that where hop-by-hop
> >>security is in force, then the next bundle sent to the recipient
> >>of a reactively fragmented bundle must authenticate the previous
> >>fragment received by that recipient.
> >>
> >>The BAH on the first bundle sent can continue to optimistically
> >>cover the entire payload.
> >>
> >>If this scheme works, it probably needs some tweaking so that
> >>the new header in the 2nd fragment (previous-BAH?) will have
> >>to indicate the range of payload (and implicitly which headers)
> >>are covered by the hash/MAC. We'd also need to define a timer
> >>for anti-DoS reasons and in case the transmitter never gets
> >>to use that receiver again for that payload. If the 2nd bundle
> >>is BAHed, (which I guess it probably ought to be, assuming
> >>policies don't change that quickly) then including a hash,
> >>rather than a signature or MAC, in the previous-BAH header
> >>might be sufficient, at least until we figure out how BAH-keys
> >>might rollover.
> >>
> >>And I guess if the fragment that got through is shorter than
> >>the new crud we're adding then we should just re-tx the lot:-)
> >>
> >>If we're deliberatlely fragmenting, this is of course a non-issue
> >>since you can BAH-protect each entire fragment-bundle before Txing.
> >>
> >>And just in case: this is all a non-issue for e2e security since
> >>re-assembly at the destination can handle that (or not, if not
> >>all fragments arrive). With e2e security and missing fragments,
> >>toilet-paper is the only answer so far.
> >>
> >>Stephen.
> >>
> >>Rajesh Krishnan wrote:
> >>
> >>
> >>>Susan,
> >>>
> >>>Thank you for explaining the "toilet paper" approach, the issues 
> >>>with it, and that my proposal is a variant of that approach.
> >>>
> >>>It is not clear that there is a universal method (across all networks 
> >>>and applications) that can determine the optimum segment size, or even 
> >>>whether it should be a fixed value (not all bundle parts may be equally 
> >>>important).
> >>>
> >>>Best Regards,
> >>>Rajesh
> >>>
> >>>
> >>>
> >>>>Rajesh,
> >>>>
> >>>>The suggestion that you are making is essentially what we have been calling
> >>>>the "toilet paper" approach --a name that was chosen to be descriptive,
> >>>>rather than dismissive of the approach, and we keep coming back to it, but
> >>>>it is ugly and complicated.  The toilet paper proposal was made before I got
> >>>>involved in the project; basically, it involves formatting the payload as a
> >>>>series of segments followed by authentication information of those segments.
> >>>>This way, if transmission of a bundle is interrupted before the entire
> >>>>payload makes it across the link, all those segments that did make it with
> >>>>their accompanying authentication information could be authenticated and
> >>>>forwarded immediately, and only the segment that was interrupted, its
> >>>>accompanying hash value, and all following segments of the payload would
> >>>>have to be resent.  The reason it is called the toilet paper approach is
> >>>>that the payload is essentially perforated after every
> >>>>segment,authentication information pair.
> >>>>
> >>>>Note that this approach differs slightly from your suggestion because it
> >>>>involves putting the hash(es) in a header rather than embedded in the
> >>>>payload. If the hashes are in the header, then you would be sending all the
> >>>>hashes before sending even a bit of the payload. It is more efficient to
> >>>>send the hashes only when you know they will be useful, as in right after
> >>>>the payload they protect. 
> >>>>
> >>>>One of the problems that we have had with considering the toilet paper
> >>>>approach before has been how we would know what a good segment size would
> >>>>be. Determining this size according to the natural concept of what the next
> >>>>safely usable increment at the destination is, as you suggest, is appealing.
> >>>>I like it.
> >>>>
> >>>>One problem with it, however, might be that it isn't related to the
> >>>>capabilities of the network. If a link cannot routinetly stay up long enough
> >>>>to transmit data of that length, then there's no way to use reactive
> >>>>fragmentation to move data along that link. If a link routinely stays up for
> >>>>much longer than it takes to transmit data of that length, then there is a
> >>>>lot of wasted bandwidth carrying all those embedded hashes. If segments are
> >>>>too large, then lots of data is lost in the "interrupted" segment when a
> >>>>connection is lost and that data needs to be resent.  If segments are too
> >>>>small, lots of bits are wasted with the many signed hash values that are
> >>>>interspersed throughout the payload. 
> >>>>
> >>>>So even though mechanically we understand how we could enable authentication
> >>>>and immediate forwarding to coexist by using the toilet paper mechanim, we
> >>>>don't really don't know how to use this mechanism effectively, because we
> >>>>don't know how to select an optimal segment size.  If you have any ideas it
> >>>>would be great to hear them.
> >>>>
> >>>>-susan
> >>>>
> >>>>-----Original Message-----
> >>>>From: Rajesh Krishnan [mailto:[email-masked]] 
> >>>>Sent: Monday, April 11, 2005 2:12 PM
> >>>>To: Susan F. Symington
> >>>>Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> >>>>Subject: Re: [dtn-interest] on ditching fragmentation
> >>>>
> >>>>Susan and Mike,
> >>>>
> >>>>In some applications, there is a natural concept of what the next safely
> >>>>usable increment at the destination is (e.g. a video frame).
> >>>>
> >>>>Suppose a bundle could include a second hash covering the first usable 
> >>>>increment in addition to the usual hash over the entire bundle.  Under 
> >>>>reactive fragmentation, the first usable increment can be forwarded
> >>>>if/when available.
> >>>>
> >>>>The additional hash could go on an optional fragmentation header to be 
> >>>>used if immediate forwarding (upon reactive fragmentation) is desired.  
> >>>>Hashes that protect subsequent increments can also be included in such
> >>>>a header if one is willing to expend the header overhead.  
> >>>>
> >>>>Proactive addition of fragment hashes in anticipation of reactive 
> >>>>fragmentation is a possible medium between the proactive fragmentation 
> >>>>and reactive fragmentation schemes presented.
> >>>>
> >>>>Best Regards,
> >>>>Rajesh
> >>>>
> >>>>
> >>>>
> >>>>>Mike,
> >>>>>
> >>>>>I see your point that there may be some utility in a bundle agent being
> >>>>
> >>>>able
> >>>>
> >>>>
> >>>>>to reactively fragment even if it is precluded from immediately
> >>>>
> >>>>forwarding. 
> >>>>
> >>>>
> >>>>>Here is how our dilemma seems to look right now:
> >>>>>
> >>>>>>From a security standpoint, we really want to be able to calculate the
> >>>>>authentication information in the Bundle Authentication Header over the
> >>>>>entire bundle, including the payload. We can have this security that we
> >>>>
> >>>>want
> >>>>
> >>>>
> >>>>>and we can also have reactive fragmentation, as long as we require that if
> >>>>
> >>>>a
> >>>>
> >>>>
> >>>>>bundle is reactively fragmented then its "tail" (which may arrive as
> >>>>>multiple bundle fragments) is forwarded through the same bundle agent that
> >>>>>did the reactive fragmentation and is holding on to the head. However, we
> >>>>>cannot forward the reactively fragmented head until the "tail" is
> >>>>
> >>>>received.
> >>>>
> >>>>
> >>>>>My questions for everyone who cares are:
> >>>>>
> >>>>>1. Is it feasible to require the tails of reactively fragmented bundles to
> >>>>>be forwarded through the same bundle agent as the head?  Is this something
> >>>>>people are willing to put up with in order to be able to have both the
> >>>>>security that we want and reactive fragmentation? Or do some people out
> >>>>>there feel that restricting the bundle's path in this way would be
> >>>>>unacceptable?
> >>>>>
> >>>>>2. Is being able to reactively fragment but not immediately forward
> >>>>
> >>>>bundles
> >>>>
> >>>>
> >>>>>that have Bundle Authentication Headers good enough for people?  We still
> >>>>
> >>>>do
> >>>>
> >>>>
> >>>>>get some utility out of being able to reactively fragment, as Mike points
> >>>>>out, but we don't get the full efficiency of "cut-through routing" because
> >>>>>the receiving bundle agent can't forward the head until the tail arrives.
> >>>>
> >>>>I
> >>>>
> >>>>
> >>>>>think this means that from the viewpoint of the bundle agent that performs
> >>>>>the reactive fragmentation, the link on which it receives the bundle is
> >>>>>being used as efficiently as possible (no data that makes it through once
> >>>>>has to be resent) but the link on which it must forward the data may not
> >>>>
> >>>>be
> >>>>
> >>>>
> >>>>>used efficiently, because even though this link may be up and able to be
> >>>>>used to send data, it may be idle because the bundle agent isn't able to
> >>>>>send the head until the tail of the bundle has arrived. Is this good
> >>>>
> >>>>enough?
> >>>>
> >>>>
> >>>>>Can we settle for this or is the "cut-through" feature that enables both
> >>>>>links to be used efficiently something that our solution absolutely must
> >>>>>provide?
> >>>>>
> >>>>>Remember, we only run into this problem if security is being used, and, in
> >>>>>particular, if hop by hop security is being provided by the presence of a
> >>>>>Bundle Authentication Header in the bundle. If security is not being used,
> >>>>>or if security is being used and the security features of the underlying
> >>>>>network are being relied on so that the bundle doesn't have a Bundle
> >>>>>Authentication Header, then the tails of bundles don't have to have their
> >>>>>routes restricted and cut-through routing is possible.
> >>>>>
> >>>>>If the above compromises are unacceptable, I think we are stuck with the
> >>>>>toilet paper approach or something like it. What do people think?
> >>>>>
> >>>>>-susan
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: [email-masked]
> >>>>>[mailto:[email-masked]] On Behalf Of Michael Demmer
> >>>>>Sent: Monday, April 11, 2005 12:09 PM
> >>>>>To: Susan F. Symington
> >>>>>Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> >>>>>Subject: Re: [dtn-interest] on ditching fragmentation
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>If you choose option (b) below, which is to enable rective
> >>>>>>fragmentation but make sure that all fragments of a given bundle
> >>>>>>follow the same path, you are doing this because you are requiring
> >>>>>>the receiving intermediate bundle agent to wait until the entire
> >>>>>>original bundle is received so that it can authenticate the bundle
> >>>>>>before forwarding any part of it. But what would be the point of
> >>>>>>this? Aren't you losing the benefit that the reactive fragmentation
> >>>>>>is supposed to provide, which is to enable the part of the orignal
> >>>>>>bundle that was received before the connection went down to be
> >>>>>>forwarded immediately, without having to wait?
> >>>>>
> >>>>>Not necessarily. If I have a connection that is only ever up for a
> >>>>>window of 1/2 the time that it takes to transmit a large bundle, then
> >>>>>even if I can't forward the first half of the bundle until I get the
> >>>>>second half, I've still gotten a win out of reactive fragmentation.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>We have been saying that we want "reactive fragmentation", but I
> >>>>>>think that what we really want is to be able to reactively fragment
> >>>>>>and then immediately forward.
> >>>>>
> >>>>>This is, I agree, the "touchy" part about reactive fragmentation, and
> >>>>>the part that makes it tricky wrt authentication. We should come up
> >>>>>with a name for this (I believe one term tossed around was
> >>>>>'cut-thru-routing') as distinct from reactive fragmentation which in
> >>>>>my mind just handles the connection interruption.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>In my mind there is no point in reactively fragmenting if we are
> >>>>>>going to have to wait to reassemble the bundle before we will be
> >>>>>>able to forward it or any part of it. 
> >>>>>
> >>>>>As I said before, I disagree with this.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>If what we really want is "reactive fragmentation and immediate
> >>>>>>forwarding" (which is what I think we want, but we might not all
> >>>>>>agree on that, I don't know), then option (b) is misleading, because
> >>>>>>it only enables reactive fragmentation; it precludes immediate
> >>>>>>forwarding.
> >>>>>
> >>>>>Agreed -- restate b) to "enable reactive fragmentation but not
> >>>>>XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
> >>>>>before the tail arrives).
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Reactive fragmentation and immediate forwarding *is* incompatible
> >>>>>>with the type of bundle authentication that is now defined as being
> >>>>>>provided in the Bundle Authentication Header.
> >>>>>
> >>>>>Yes, I agree with that.
> >>>>>
> >>>>>-m
> >>>>>_______________________________________________
> >>>>>dtn-interest mailing list
> >>>>>[email-masked]
> >>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>dtn-interest mailing list
> >>>>>[email-masked]
> >>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>dtn-interest mailing list
> >>>>[email-masked]
> >>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>>
> >>>
> >>>
> >>>_______________________________________________
> >>>dtn-interest mailing list
> >>>[email-masked]
> >>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>
> >>>
> >>
> >>_______________________________________________
> >>dtn-interest mailing list
> >>[email-masked]
> >>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>
> > 
> > 
> > 
> 

Date: Tue, 12 Apr 2005 18:05:37 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Rejesh,

You're correct that if you need that single contact to suffice
while allowing reactive fragmentation then my proposal doesn't
help. But afaik you need toilet paper to meet the requirement
you've stated - which is after all an e2e requirement!

Forward adding an extra MAC/signature just in case of reactive
fragmentation would seem wasteful generally - if such
fragmentation is that frequent, shouldn't you really do something
else, e.g. e2e toilet paper? Maybe I could just about buy it
for a network where each node somehow shares a MACing key
with each of its next-hop peers, but where there's no e2e key
management at all, however I'd first have to see how that key
management scheme works, since if its trivial for any-old-node
to join such a n/w then the DoS attack using fragments works
and there's maybe little or no point at all in BAHs!

Adding a previous-BAH header after reactive fragmentation
is maybe the right thing but as you say, you do need
that 2nd contact for this to be effective. I think I'd
maintain that you need it anyway for reactive fragmentation
to be a useful general technique.

If the 2nd contact is very likely not to be with the 1st
receiver, but the 2nd receiver is likely to be in non-delayed
comms. with the 1st receiver, then it'd be better for the
2nd contact to contain a header (3rd-party-previous-BAH?)
that can be extracted and then forwarded from the 2nd
receiver to the 1st receiver, either in a bundle of its
own, or else in the n/w below the bundling layer.

There are so many contingencies here though that I'm not
sure any of this is worthwhile.

Stephen.

Rajesh Krishnan wrote:

> The time of arrival of the 2nd fragment from the same previous hop (which 
> may not happen soon) is a gating fctor.  We cannot make a single contact 
> count.
> 
> Forward addition of a hash for the first usable increment potentially gets 
> around this limitation (assuming we know the size of the first usable 
> increment and that a fragment of at least this size gets through).  I admit 
> that forward addition is not a sufficiently general fix.  The corner case 
> of interest to me was the ability to salvage a frame of video transferred 
> in a single contact when the bundle containing the rest of the frame sequence 
> expires.  
> 
> -Rajesh
> 
> 
>>Ok, here's another possibly despairing go at this thread:-)
>>
>>Am I right in assuming that reactive fragmentation requires
>>that the transmitter knows fairly well how much of the previous
>>fragment got through? (Otherwise it'll just have to re-Tx
>>everything, right?).
>>
>>In that case, couldn't we arrange that the 2nd fragment (which
>>could contain part of all of the remaining bundle bytes) contains
>>a hash/MAC that covers the 1st? As soon as the receiver gets
>>and checks this it can then forward the combined content of
>>the two bundles (together or not, I don't know!), and doesn't
>>have wait for the end of the payload.
>>
>>That way, we can forward without waiting for the last fragment,
>>which should often be somewhat better.
>>
>>More generally, we add a requirement that where hop-by-hop
>>security is in force, then the next bundle sent to the recipient
>>of a reactively fragmented bundle must authenticate the previous
>>fragment received by that recipient.
>>
>>The BAH on the first bundle sent can continue to optimistically
>>cover the entire payload.
>>
>>If this scheme works, it probably needs some tweaking so that
>>the new header in the 2nd fragment (previous-BAH?) will have
>>to indicate the range of payload (and implicitly which headers)
>>are covered by the hash/MAC. We'd also need to define a timer
>>for anti-DoS reasons and in case the transmitter never gets
>>to use that receiver again for that payload. If the 2nd bundle
>>is BAHed, (which I guess it probably ought to be, assuming
>>policies don't change that quickly) then including a hash,
>>rather than a signature or MAC, in the previous-BAH header
>>might be sufficient, at least until we figure out how BAH-keys
>>might rollover.
>>
>>And I guess if the fragment that got through is shorter than
>>the new crud we're adding then we should just re-tx the lot:-)
>>
>>If we're deliberatlely fragmenting, this is of course a non-issue
>>since you can BAH-protect each entire fragment-bundle before Txing.
>>
>>And just in case: this is all a non-issue for e2e security since
>>re-assembly at the destination can handle that (or not, if not
>>all fragments arrive). With e2e security and missing fragments,
>>toilet-paper is the only answer so far.
>>
>>Stephen.
>>
>>Rajesh Krishnan wrote:
>>
>>
>>>Susan,
>>>
>>>Thank you for explaining the "toilet paper" approach, the issues 
>>>with it, and that my proposal is a variant of that approach.
>>>
>>>It is not clear that there is a universal method (across all networks 
>>>and applications) that can determine the optimum segment size, or even 
>>>whether it should be a fixed value (not all bundle parts may be equally 
>>>important).
>>>
>>>Best Regards,
>>>Rajesh
>>>
>>>
>>>
>>>>Rajesh,
>>>>
>>>>The suggestion that you are making is essentially what we have been calling
>>>>the "toilet paper" approach --a name that was chosen to be descriptive,
>>>>rather than dismissive of the approach, and we keep coming back to it, but
>>>>it is ugly and complicated.  The toilet paper proposal was made before I got
>>>>involved in the project; basically, it involves formatting the payload as a
>>>>series of segments followed by authentication information of those segments.
>>>>This way, if transmission of a bundle is interrupted before the entire
>>>>payload makes it across the link, all those segments that did make it with
>>>>their accompanying authentication information could be authenticated and
>>>>forwarded immediately, and only the segment that was interrupted, its
>>>>accompanying hash value, and all following segments of the payload would
>>>>have to be resent.  The reason it is called the toilet paper approach is
>>>>that the payload is essentially perforated after every
>>>>segment,authentication information pair.
>>>>
>>>>Note that this approach differs slightly from your suggestion because it
>>>>involves putting the hash(es) in a header rather than embedded in the
>>>>payload. If the hashes are in the header, then you would be sending all the
>>>>hashes before sending even a bit of the payload. It is more efficient to
>>>>send the hashes only when you know they will be useful, as in right after
>>>>the payload they protect. 
>>>>
>>>>One of the problems that we have had with considering the toilet paper
>>>>approach before has been how we would know what a good segment size would
>>>>be. Determining this size according to the natural concept of what the next
>>>>safely usable increment at the destination is, as you suggest, is appealing.
>>>>I like it.
>>>>
>>>>One problem with it, however, might be that it isn't related to the
>>>>capabilities of the network. If a link cannot routinetly stay up long enough
>>>>to transmit data of that length, then there's no way to use reactive
>>>>fragmentation to move data along that link. If a link routinely stays up for
>>>>much longer than it takes to transmit data of that length, then there is a
>>>>lot of wasted bandwidth carrying all those embedded hashes. If segments are
>>>>too large, then lots of data is lost in the "interrupted" segment when a
>>>>connection is lost and that data needs to be resent.  If segments are too
>>>>small, lots of bits are wasted with the many signed hash values that are
>>>>interspersed throughout the payload. 
>>>>
>>>>So even though mechanically we understand how we could enable authentication
>>>>and immediate forwarding to coexist by using the toilet paper mechanim, we
>>>>don't really don't know how to use this mechanism effectively, because we
>>>>don't know how to select an optimal segment size.  If you have any ideas it
>>>>would be great to hear them.
>>>>
>>>>-susan
>>>>
>>>>-----Original Message-----
>>>>From: Rajesh Krishnan [mailto:[email-masked]] 
>>>>Sent: Monday, April 11, 2005 2:12 PM
>>>>To: Susan F. Symington
>>>>Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>>Subject: Re: [dtn-interest] on ditching fragmentation
>>>>
>>>>Susan and Mike,
>>>>
>>>>In some applications, there is a natural concept of what the next safely
>>>>usable increment at the destination is (e.g. a video frame).
>>>>
>>>>Suppose a bundle could include a second hash covering the first usable 
>>>>increment in addition to the usual hash over the entire bundle.  Under 
>>>>reactive fragmentation, the first usable increment can be forwarded
>>>>if/when available.
>>>>
>>>>The additional hash could go on an optional fragmentation header to be 
>>>>used if immediate forwarding (upon reactive fragmentation) is desired.  
>>>>Hashes that protect subsequent increments can also be included in such
>>>>a header if one is willing to expend the header overhead.  
>>>>
>>>>Proactive addition of fragment hashes in anticipation of reactive 
>>>>fragmentation is a possible medium between the proactive fragmentation 
>>>>and reactive fragmentation schemes presented.
>>>>
>>>>Best Regards,
>>>>Rajesh
>>>>
>>>>
>>>>
>>>>>Mike,
>>>>>
>>>>>I see your point that there may be some utility in a bundle agent being
>>>>
>>>>able
>>>>
>>>>
>>>>>to reactively fragment even if it is precluded from immediately
>>>>
>>>>forwarding. 
>>>>
>>>>
>>>>>Here is how our dilemma seems to look right now:
>>>>>
>>>>>>From a security standpoint, we really want to be able to calculate the
>>>>>authentication information in the Bundle Authentication Header over the
>>>>>entire bundle, including the payload. We can have this security that we
>>>>
>>>>want
>>>>
>>>>
>>>>>and we can also have reactive fragmentation, as long as we require that if
>>>>
>>>>a
>>>>
>>>>
>>>>>bundle is reactively fragmented then its "tail" (which may arrive as
>>>>>multiple bundle fragments) is forwarded through the same bundle agent that
>>>>>did the reactive fragmentation and is holding on to the head. However, we
>>>>>cannot forward the reactively fragmented head until the "tail" is
>>>>
>>>>received.
>>>>
>>>>
>>>>>My questions for everyone who cares are:
>>>>>
>>>>>1. Is it feasible to require the tails of reactively fragmented bundles to
>>>>>be forwarded through the same bundle agent as the head?  Is this something
>>>>>people are willing to put up with in order to be able to have both the
>>>>>security that we want and reactive fragmentation? Or do some people out
>>>>>there feel that restricting the bundle's path in this way would be
>>>>>unacceptable?
>>>>>
>>>>>2. Is being able to reactively fragment but not immediately forward
>>>>
>>>>bundles
>>>>
>>>>
>>>>>that have Bundle Authentication Headers good enough for people?  We still
>>>>
>>>>do
>>>>
>>>>
>>>>>get some utility out of being able to reactively fragment, as Mike points
>>>>>out, but we don't get the full efficiency of "cut-through routing" because
>>>>>the receiving bundle agent can't forward the head until the tail arrives.
>>>>
>>>>I
>>>>
>>>>
>>>>>think this means that from the viewpoint of the bundle agent that performs
>>>>>the reactive fragmentation, the link on which it receives the bundle is
>>>>>being used as efficiently as possible (no data that makes it through once
>>>>>has to be resent) but the link on which it must forward the data may not
>>>>
>>>>be
>>>>
>>>>
>>>>>used efficiently, because even though this link may be up and able to be
>>>>>used to send data, it may be idle because the bundle agent isn't able to
>>>>>send the head until the tail of the bundle has arrived. Is this good
>>>>
>>>>enough?
>>>>
>>>>
>>>>>Can we settle for this or is the "cut-through" feature that enables both
>>>>>links to be used efficiently something that our solution absolutely must
>>>>>provide?
>>>>>
>>>>>Remember, we only run into this problem if security is being used, and, in
>>>>>particular, if hop by hop security is being provided by the presence of a
>>>>>Bundle Authentication Header in the bundle. If security is not being used,
>>>>>or if security is being used and the security features of the underlying
>>>>>network are being relied on so that the bundle doesn't have a Bundle
>>>>>Authentication Header, then the tails of bundles don't have to have their
>>>>>routes restricted and cut-through routing is possible.
>>>>>
>>>>>If the above compromises are unacceptable, I think we are stuck with the
>>>>>toilet paper approach or something like it. What do people think?
>>>>>
>>>>>-susan
>>>>>
>>>>>-----Original Message-----
>>>>>From: [email-masked]
>>>>>[mailto:[email-masked]] On Behalf Of Michael Demmer
>>>>>Sent: Monday, April 11, 2005 12:09 PM
>>>>>To: Susan F. Symington
>>>>>Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>>>Subject: Re: [dtn-interest] on ditching fragmentation
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>If you choose option (b) below, which is to enable rective
>>>>>>fragmentation but make sure that all fragments of a given bundle
>>>>>>follow the same path, you are doing this because you are requiring
>>>>>>the receiving intermediate bundle agent to wait until the entire
>>>>>>original bundle is received so that it can authenticate the bundle
>>>>>>before forwarding any part of it. But what would be the point of
>>>>>>this? Aren't you losing the benefit that the reactive fragmentation
>>>>>>is supposed to provide, which is to enable the part of the orignal
>>>>>>bundle that was received before the connection went down to be
>>>>>>forwarded immediately, without having to wait?
>>>>>
>>>>>Not necessarily. If I have a connection that is only ever up for a
>>>>>window of 1/2 the time that it takes to transmit a large bundle, then
>>>>>even if I can't forward the first half of the bundle until I get the
>>>>>second half, I've still gotten a win out of reactive fragmentation.
>>>>>
>>>>>
>>>>>
>>>>>>We have been saying that we want "reactive fragmentation", but I
>>>>>>think that what we really want is to be able to reactively fragment
>>>>>>and then immediately forward.
>>>>>
>>>>>This is, I agree, the "touchy" part about reactive fragmentation, and
>>>>>the part that makes it tricky wrt authentication. We should come up
>>>>>with a name for this (I believe one term tossed around was
>>>>>'cut-thru-routing') as distinct from reactive fragmentation which in
>>>>>my mind just handles the connection interruption.
>>>>>
>>>>>
>>>>>
>>>>>>In my mind there is no point in reactively fragmenting if we are
>>>>>>going to have to wait to reassemble the bundle before we will be
>>>>>>able to forward it or any part of it. 
>>>>>
>>>>>As I said before, I disagree with this.
>>>>>
>>>>>
>>>>>
>>>>>>If what we really want is "reactive fragmentation and immediate
>>>>>>forwarding" (which is what I think we want, but we might not all
>>>>>>agree on that, I don't know), then option (b) is misleading, because
>>>>>>it only enables reactive fragmentation; it precludes immediate
>>>>>>forwarding.
>>>>>
>>>>>Agreed -- restate b) to "enable reactive fragmentation but not
>>>>>XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
>>>>>before the tail arrives).
>>>>>
>>>>>
>>>>>
>>>>>>Reactive fragmentation and immediate forwarding *is* incompatible
>>>>>>with the type of bundle authentication that is now defined as being
>>>>>>provided in the Bundle Authentication Header.
>>>>>
>>>>>Yes, I agree with that.
>>>>>
>>>>>-m
>>>>>_______________________________________________
>>>>>dtn-interest mailing list
>>>>>[email-masked]
>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>dtn-interest mailing list
>>>>>[email-masked]
>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>dtn-interest mailing list
>>>>[email-masked]
>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>>
>>>
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>>
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> 
> 
> 

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
To: [email-masked] (Stephen Farrell)
Date: Tue, 12 Apr 2005 12:43:22 -0400 (EDT)
Cc: [email-masked], [email-masked] (Susan F. Symington), [email-masked] ('DTN')
Reply-to: [email-masked]
Sender: [email-masked]

The time of arrival of the 2nd fragment from the same previous hop (which 
may not happen soon) is a gating fctor.  We cannot make a single contact 
count.

Forward addition of a hash for the first usable increment potentially gets 
around this limitation (assuming we know the size of the first usable 
increment and that a fragment of at least this size gets through).  I admit 
that forward addition is not a sufficiently general fix.  The corner case 
of interest to me was the ability to salvage a frame of video transferred 
in a single contact when the bundle containing the rest of the frame sequence 
expires.  

-Rajesh

> Ok, here's another possibly despairing go at this thread:-)
> 
> Am I right in assuming that reactive fragmentation requires
> that the transmitter knows fairly well how much of the previous
> fragment got through? (Otherwise it'll just have to re-Tx
> everything, right?).
> 
> In that case, couldn't we arrange that the 2nd fragment (which
> could contain part of all of the remaining bundle bytes) contains
> a hash/MAC that covers the 1st? As soon as the receiver gets
> and checks this it can then forward the combined content of
> the two bundles (together or not, I don't know!), and doesn't
> have wait for the end of the payload.
> 
> That way, we can forward without waiting for the last fragment,
> which should often be somewhat better.
> 
> More generally, we add a requirement that where hop-by-hop
> security is in force, then the next bundle sent to the recipient
> of a reactively fragmented bundle must authenticate the previous
> fragment received by that recipient.
> 
> The BAH on the first bundle sent can continue to optimistically
> cover the entire payload.
> 
> If this scheme works, it probably needs some tweaking so that
> the new header in the 2nd fragment (previous-BAH?) will have
> to indicate the range of payload (and implicitly which headers)
> are covered by the hash/MAC. We'd also need to define a timer
> for anti-DoS reasons and in case the transmitter never gets
> to use that receiver again for that payload. If the 2nd bundle
> is BAHed, (which I guess it probably ought to be, assuming
> policies don't change that quickly) then including a hash,
> rather than a signature or MAC, in the previous-BAH header
> might be sufficient, at least until we figure out how BAH-keys
> might rollover.
> 
> And I guess if the fragment that got through is shorter than
> the new crud we're adding then we should just re-tx the lot:-)
> 
> If we're deliberatlely fragmenting, this is of course a non-issue
> since you can BAH-protect each entire fragment-bundle before Txing.
> 
> And just in case: this is all a non-issue for e2e security since
> re-assembly at the destination can handle that (or not, if not
> all fragments arrive). With e2e security and missing fragments,
> toilet-paper is the only answer so far.
> 
> Stephen.
> 
> Rajesh Krishnan wrote:
> 
> > Susan,
> > 
> > Thank you for explaining the "toilet paper" approach, the issues 
> > with it, and that my proposal is a variant of that approach.
> > 
> > It is not clear that there is a universal method (across all networks 
> > and applications) that can determine the optimum segment size, or even 
> > whether it should be a fixed value (not all bundle parts may be equally 
> > important).
> > 
> > Best Regards,
> > Rajesh
> > 
> > 
> >>Rajesh,
> >>
> >>The suggestion that you are making is essentially what we have been calling
> >>the "toilet paper" approach --a name that was chosen to be descriptive,
> >>rather than dismissive of the approach, and we keep coming back to it, but
> >>it is ugly and complicated.  The toilet paper proposal was made before I got
> >>involved in the project; basically, it involves formatting the payload as a
> >>series of segments followed by authentication information of those segments.
> >>This way, if transmission of a bundle is interrupted before the entire
> >>payload makes it across the link, all those segments that did make it with
> >>their accompanying authentication information could be authenticated and
> >>forwarded immediately, and only the segment that was interrupted, its
> >>accompanying hash value, and all following segments of the payload would
> >>have to be resent.  The reason it is called the toilet paper approach is
> >>that the payload is essentially perforated after every
> >>segment,authentication information pair.
> >>
> >>Note that this approach differs slightly from your suggestion because it
> >>involves putting the hash(es) in a header rather than embedded in the
> >>payload. If the hashes are in the header, then you would be sending all the
> >>hashes before sending even a bit of the payload. It is more efficient to
> >>send the hashes only when you know they will be useful, as in right after
> >>the payload they protect. 
> >>
> >>One of the problems that we have had with considering the toilet paper
> >>approach before has been how we would know what a good segment size would
> >>be. Determining this size according to the natural concept of what the next
> >>safely usable increment at the destination is, as you suggest, is appealing.
> >>I like it.
> >>
> >>One problem with it, however, might be that it isn't related to the
> >>capabilities of the network. If a link cannot routinetly stay up long enough
> >>to transmit data of that length, then there's no way to use reactive
> >>fragmentation to move data along that link. If a link routinely stays up for
> >>much longer than it takes to transmit data of that length, then there is a
> >>lot of wasted bandwidth carrying all those embedded hashes. If segments are
> >>too large, then lots of data is lost in the "interrupted" segment when a
> >>connection is lost and that data needs to be resent.  If segments are too
> >>small, lots of bits are wasted with the many signed hash values that are
> >>interspersed throughout the payload. 
> >>
> >>So even though mechanically we understand how we could enable authentication
> >>and immediate forwarding to coexist by using the toilet paper mechanim, we
> >>don't really don't know how to use this mechanism effectively, because we
> >>don't know how to select an optimal segment size.  If you have any ideas it
> >>would be great to hear them.
> >>
> >>-susan
> >>
> >>-----Original Message-----
> >>From: Rajesh Krishnan [mailto:[email-masked]] 
> >>Sent: Monday, April 11, 2005 2:12 PM
> >>To: Susan F. Symington
> >>Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> >>Subject: Re: [dtn-interest] on ditching fragmentation
> >>
> >>Susan and Mike,
> >>
> >>In some applications, there is a natural concept of what the next safely
> >>usable increment at the destination is (e.g. a video frame).
> >>
> >>Suppose a bundle could include a second hash covering the first usable 
> >>increment in addition to the usual hash over the entire bundle.  Under 
> >>reactive fragmentation, the first usable increment can be forwarded
> >>if/when available.
> >>
> >>The additional hash could go on an optional fragmentation header to be 
> >>used if immediate forwarding (upon reactive fragmentation) is desired.  
> >>Hashes that protect subsequent increments can also be included in such
> >>a header if one is willing to expend the header overhead.  
> >>
> >>Proactive addition of fragment hashes in anticipation of reactive 
> >>fragmentation is a possible medium between the proactive fragmentation 
> >>and reactive fragmentation schemes presented.
> >>
> >>Best Regards,
> >>Rajesh
> >>
> >>
> >>>Mike,
> >>>
> >>>I see your point that there may be some utility in a bundle agent being
> >>
> >>able
> >>
> >>>to reactively fragment even if it is precluded from immediately
> >>
> >>forwarding. 
> >>
> >>>Here is how our dilemma seems to look right now:
> >>>
> >>>>From a security standpoint, we really want to be able to calculate the
> >>>authentication information in the Bundle Authentication Header over the
> >>>entire bundle, including the payload. We can have this security that we
> >>
> >>want
> >>
> >>>and we can also have reactive fragmentation, as long as we require that if
> >>
> >>a
> >>
> >>>bundle is reactively fragmented then its "tail" (which may arrive as
> >>>multiple bundle fragments) is forwarded through the same bundle agent that
> >>>did the reactive fragmentation and is holding on to the head. However, we
> >>>cannot forward the reactively fragmented head until the "tail" is
> >>
> >>received.
> >>
> >>>My questions for everyone who cares are:
> >>>
> >>>1. Is it feasible to require the tails of reactively fragmented bundles to
> >>>be forwarded through the same bundle agent as the head?  Is this something
> >>>people are willing to put up with in order to be able to have both the
> >>>security that we want and reactive fragmentation? Or do some people out
> >>>there feel that restricting the bundle's path in this way would be
> >>>unacceptable?
> >>>
> >>>2. Is being able to reactively fragment but not immediately forward
> >>
> >>bundles
> >>
> >>>that have Bundle Authentication Headers good enough for people?  We still
> >>
> >>do
> >>
> >>>get some utility out of being able to reactively fragment, as Mike points
> >>>out, but we don't get the full efficiency of "cut-through routing" because
> >>>the receiving bundle agent can't forward the head until the tail arrives.
> >>
> >>I
> >>
> >>>think this means that from the viewpoint of the bundle agent that performs
> >>>the reactive fragmentation, the link on which it receives the bundle is
> >>>being used as efficiently as possible (no data that makes it through once
> >>>has to be resent) but the link on which it must forward the data may not
> >>
> >>be
> >>
> >>>used efficiently, because even though this link may be up and able to be
> >>>used to send data, it may be idle because the bundle agent isn't able to
> >>>send the head until the tail of the bundle has arrived. Is this good
> >>
> >>enough?
> >>
> >>>Can we settle for this or is the "cut-through" feature that enables both
> >>>links to be used efficiently something that our solution absolutely must
> >>>provide?
> >>>
> >>>Remember, we only run into this problem if security is being used, and, in
> >>>particular, if hop by hop security is being provided by the presence of a
> >>>Bundle Authentication Header in the bundle. If security is not being used,
> >>>or if security is being used and the security features of the underlying
> >>>network are being relied on so that the bundle doesn't have a Bundle
> >>>Authentication Header, then the tails of bundles don't have to have their
> >>>routes restricted and cut-through routing is possible.
> >>>
> >>>If the above compromises are unacceptable, I think we are stuck with the
> >>>toilet paper approach or something like it. What do people think?
> >>>
> >>>-susan
> >>>
> >>>-----Original Message-----
> >>>From: [email-masked]
> >>>[mailto:[email-masked]] On Behalf Of Michael Demmer
> >>>Sent: Monday, April 11, 2005 12:09 PM
> >>>To: Susan F. Symington
> >>>Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> >>>Subject: Re: [dtn-interest] on ditching fragmentation
> >>>
> >>>
> >>>
> >>>>If you choose option (b) below, which is to enable rective
> >>>>fragmentation but make sure that all fragments of a given bundle
> >>>>follow the same path, you are doing this because you are requiring
> >>>>the receiving intermediate bundle agent to wait until the entire
> >>>>original bundle is received so that it can authenticate the bundle
> >>>>before forwarding any part of it. But what would be the point of
> >>>>this? Aren't you losing the benefit that the reactive fragmentation
> >>>>is supposed to provide, which is to enable the part of the orignal
> >>>>bundle that was received before the connection went down to be
> >>>>forwarded immediately, without having to wait?
> >>>
> >>>Not necessarily. If I have a connection that is only ever up for a
> >>>window of 1/2 the time that it takes to transmit a large bundle, then
> >>>even if I can't forward the first half of the bundle until I get the
> >>>second half, I've still gotten a win out of reactive fragmentation.
> >>>
> >>>
> >>>>We have been saying that we want "reactive fragmentation", but I
> >>>>think that what we really want is to be able to reactively fragment
> >>>>and then immediately forward.
> >>>
> >>>This is, I agree, the "touchy" part about reactive fragmentation, and
> >>>the part that makes it tricky wrt authentication. We should come up
> >>>with a name for this (I believe one term tossed around was
> >>>'cut-thru-routing') as distinct from reactive fragmentation which in
> >>>my mind just handles the connection interruption.
> >>>
> >>>
> >>>>In my mind there is no point in reactively fragmenting if we are
> >>>>going to have to wait to reassemble the bundle before we will be
> >>>>able to forward it or any part of it. 
> >>>
> >>>As I said before, I disagree with this.
> >>>
> >>>
> >>>>If what we really want is "reactive fragmentation and immediate
> >>>>forwarding" (which is what I think we want, but we might not all
> >>>>agree on that, I don't know), then option (b) is misleading, because
> >>>>it only enables reactive fragmentation; it precludes immediate
> >>>>forwarding.
> >>>
> >>>Agreed -- restate b) to "enable reactive fragmentation but not
> >>>XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
> >>>before the tail arrives).
> >>>
> >>>
> >>>>Reactive fragmentation and immediate forwarding *is* incompatible
> >>>>with the type of bundle authentication that is now defined as being
> >>>>provided in the Bundle Authentication Header.
> >>>
> >>>Yes, I agree with that.
> >>>
> >>>-m
> >>>_______________________________________________
> >>>dtn-interest mailing list
> >>>[email-masked]
> >>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>dtn-interest mailing list
> >>>[email-masked]
> >>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>dtn-interest mailing list
> >>[email-masked]
> >>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>
> > 
> > 
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> > 
> > 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Tue, 12 Apr 2005 11:25:41 -0400 (EDT)
Subject: RE: [dtn-interest] on ditching fragmentation
From: "Peter TB Brett" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Importance: Normal
Sender: [email-masked]

Ouch, looks like I missed the point again.

Peter TB Brett wrote:
>
> Susan F. Symington wrote:
>
>> The security issue that is plaguing us is that when D receives only
>> the first 0.6 part of the 1 MB fragment, it cannot use the
>> authentication
>> information in the Bundle Authentication Header of that fragment to
>> authenticate the portion of the fragment it received, because the
>> authentication information was calculated over the entire original 1 MB
>> fragment and so the entire original 1 MB fragment must be accessible to
>> D in order for D to validate the correctness of the
>> authentication information.
>
> I understand that being able to forward unauthenticated fragments of
> fragments ("meta-fragments"?) is a DoS risk.  OTOH, I can think of
> situations where this behaviour would be really useful.
>
> My immediate reaction is that perhaps it would be a good idea for
> forwarding of unauthenticated fragments to be enabled on a node by node
> basis at the discretion of the bundle agent.  I'm not at all sure what
> sort of decision-making algorithm would be suitable though.
>
> Having had the situation clarified (thanks, Susan) I'm in favour of
> keeping reactive fragmentation, but on a discretionary basis.

I didn't spot that you were discussing the situation where hop-by-hop
security was in force -- in which case, each node MUST NOT forward
unauthenticated fragments.  Which precludes reactive fragmentation in the
situation I described.

Aargh.

Peter Brett

-- 
E-mail:       [email-masked]
Website:      http://www.peter-b.co.uk

Date: Tue, 12 Apr 2005 11:16:48 -0400 (EDT)
Subject: RE: [dtn-interest] on ditching fragmentation
From: "Peter TB Brett" <[email-masked]>
To: "Susan F. Symington" <[email-masked]>, [email-masked]
Importance: Normal
Sender: [email-masked]

Susan F. Symington wrote:

> The security issue that is plaguing us is that when D receives only
> the first 0.6 part of the 1 MB fragment, it cannot use the authentication
> information in the Bundle Authentication Header of that fragment to
> authenticate the portion of the fragment it received, because the
> authentication information was calculated over the entire original 1 MB
> fragment and so the entire original 1 MB fragment must be accessible to
> D in order for D to validate the correctness of the
> authentication information.

... and if contacts between D and the source node are random, D cannot
predict whether or not it will be able to get hold of the rest of the 1 MB
fragment, so it must either[1]:

(a) forward what it does have towards the sink node, unauthenticated.
(b) drop the fragment.

I understand that being able to forward unauthenticated fragments of
fragments ("meta-fragments"?) is a DoS risk.  OTOH, I can think of
situations where this behaviour would be really useful.

My immediate reaction is that perhaps it would be a good idea for
forwarding of unauthenticated fragments to be enabled on a node by node
basis at the discretion of the bundle agent.  I'm not at all sure what
sort of decision-making algorithm would be suitable though.

Having had the situation clarified (thanks, Susan) I'm in favour of
keeping reactive fragmentation, but on a discretionary basis.

Peter Brett

[1] Drifting off-topic again into implementation details, maybe D should
have told the source node what its behaviour would be before starting to
receive the fragment, although IIRC DTN makes no allowance for that...

-- 
E-mail:       [email-masked]
Website:      http://www.peter-b.co.uk

Date: Tue, 12 Apr 2005 15:40:55 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Ok, here's another possibly despairing go at this thread:-)

Am I right in assuming that reactive fragmentation requires
that the transmitter knows fairly well how much of the previous
fragment got through? (Otherwise it'll just have to re-Tx
everything, right?).

In that case, couldn't we arrange that the 2nd fragment (which
could contain part of all of the remaining bundle bytes) contains
a hash/MAC that covers the 1st? As soon as the receiver gets
and checks this it can then forward the combined content of
the two bundles (together or not, I don't know!), and doesn't
have wait for the end of the payload.

That way, we can forward without waiting for the last fragment,
which should often be somewhat better.

More generally, we add a requirement that where hop-by-hop
security is in force, then the next bundle sent to the recipient
of a reactively fragmented bundle must authenticate the previous
fragment received by that recipient.

The BAH on the first bundle sent can continue to optimistically
cover the entire payload.

If this scheme works, it probably needs some tweaking so that
the new header in the 2nd fragment (previous-BAH?) will have
to indicate the range of payload (and implicitly which headers)
are covered by the hash/MAC. We'd also need to define a timer
for anti-DoS reasons and in case the transmitter never gets
to use that receiver again for that payload. If the 2nd bundle
is BAHed, (which I guess it probably ought to be, assuming
policies don't change that quickly) then including a hash,
rather than a signature or MAC, in the previous-BAH header
might be sufficient, at least until we figure out how BAH-keys
might rollover.

And I guess if the fragment that got through is shorter than
the new crud we're adding then we should just re-tx the lot:-)

If we're deliberatlely fragmenting, this is of course a non-issue
since you can BAH-protect each entire fragment-bundle before Txing.

And just in case: this is all a non-issue for e2e security since
re-assembly at the destination can handle that (or not, if not
all fragments arrive). With e2e security and missing fragments,
toilet-paper is the only answer so far.

Stephen.

Rajesh Krishnan wrote:

> Susan,
> 
> Thank you for explaining the "toilet paper" approach, the issues 
> with it, and that my proposal is a variant of that approach.
> 
> It is not clear that there is a universal method (across all networks 
> and applications) that can determine the optimum segment size, or even 
> whether it should be a fixed value (not all bundle parts may be equally 
> important).
> 
> Best Regards,
> Rajesh
> 
> 
>>Rajesh,
>>
>>The suggestion that you are making is essentially what we have been calling
>>the "toilet paper" approach --a name that was chosen to be descriptive,
>>rather than dismissive of the approach, and we keep coming back to it, but
>>it is ugly and complicated.  The toilet paper proposal was made before I got
>>involved in the project; basically, it involves formatting the payload as a
>>series of segments followed by authentication information of those segments.
>>This way, if transmission of a bundle is interrupted before the entire
>>payload makes it across the link, all those segments that did make it with
>>their accompanying authentication information could be authenticated and
>>forwarded immediately, and only the segment that was interrupted, its
>>accompanying hash value, and all following segments of the payload would
>>have to be resent.  The reason it is called the toilet paper approach is
>>that the payload is essentially perforated after every
>>segment,authentication information pair.
>>
>>Note that this approach differs slightly from your suggestion because it
>>involves putting the hash(es) in a header rather than embedded in the
>>payload. If the hashes are in the header, then you would be sending all the
>>hashes before sending even a bit of the payload. It is more efficient to
>>send the hashes only when you know they will be useful, as in right after
>>the payload they protect. 
>>
>>One of the problems that we have had with considering the toilet paper
>>approach before has been how we would know what a good segment size would
>>be. Determining this size according to the natural concept of what the next
>>safely usable increment at the destination is, as you suggest, is appealing.
>>I like it.
>>
>>One problem with it, however, might be that it isn't related to the
>>capabilities of the network. If a link cannot routinetly stay up long enough
>>to transmit data of that length, then there's no way to use reactive
>>fragmentation to move data along that link. If a link routinely stays up for
>>much longer than it takes to transmit data of that length, then there is a
>>lot of wasted bandwidth carrying all those embedded hashes. If segments are
>>too large, then lots of data is lost in the "interrupted" segment when a
>>connection is lost and that data needs to be resent.  If segments are too
>>small, lots of bits are wasted with the many signed hash values that are
>>interspersed throughout the payload. 
>>
>>So even though mechanically we understand how we could enable authentication
>>and immediate forwarding to coexist by using the toilet paper mechanim, we
>>don't really don't know how to use this mechanism effectively, because we
>>don't know how to select an optimal segment size.  If you have any ideas it
>>would be great to hear them.
>>
>>-susan
>>
>>-----Original Message-----
>>From: Rajesh Krishnan [mailto:[email-masked]] 
>>Sent: Monday, April 11, 2005 2:12 PM
>>To: Susan F. Symington
>>Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>Subject: Re: [dtn-interest] on ditching fragmentation
>>
>>Susan and Mike,
>>
>>In some applications, there is a natural concept of what the next safely
>>usable increment at the destination is (e.g. a video frame).
>>
>>Suppose a bundle could include a second hash covering the first usable 
>>increment in addition to the usual hash over the entire bundle.  Under 
>>reactive fragmentation, the first usable increment can be forwarded
>>if/when available.
>>
>>The additional hash could go on an optional fragmentation header to be 
>>used if immediate forwarding (upon reactive fragmentation) is desired.  
>>Hashes that protect subsequent increments can also be included in such
>>a header if one is willing to expend the header overhead.  
>>
>>Proactive addition of fragment hashes in anticipation of reactive 
>>fragmentation is a possible medium between the proactive fragmentation 
>>and reactive fragmentation schemes presented.
>>
>>Best Regards,
>>Rajesh
>>
>>
>>>Mike,
>>>
>>>I see your point that there may be some utility in a bundle agent being
>>
>>able
>>
>>>to reactively fragment even if it is precluded from immediately
>>
>>forwarding. 
>>
>>>Here is how our dilemma seems to look right now:
>>>
>>>>From a security standpoint, we really want to be able to calculate the
>>>authentication information in the Bundle Authentication Header over the
>>>entire bundle, including the payload. We can have this security that we
>>
>>want
>>
>>>and we can also have reactive fragmentation, as long as we require that if
>>
>>a
>>
>>>bundle is reactively fragmented then its "tail" (which may arrive as
>>>multiple bundle fragments) is forwarded through the same bundle agent that
>>>did the reactive fragmentation and is holding on to the head. However, we
>>>cannot forward the reactively fragmented head until the "tail" is
>>
>>received.
>>
>>>My questions for everyone who cares are:
>>>
>>>1. Is it feasible to require the tails of reactively fragmented bundles to
>>>be forwarded through the same bundle agent as the head?  Is this something
>>>people are willing to put up with in order to be able to have both the
>>>security that we want and reactive fragmentation? Or do some people out
>>>there feel that restricting the bundle's path in this way would be
>>>unacceptable?
>>>
>>>2. Is being able to reactively fragment but not immediately forward
>>
>>bundles
>>
>>>that have Bundle Authentication Headers good enough for people?  We still
>>
>>do
>>
>>>get some utility out of being able to reactively fragment, as Mike points
>>>out, but we don't get the full efficiency of "cut-through routing" because
>>>the receiving bundle agent can't forward the head until the tail arrives.
>>
>>I
>>
>>>think this means that from the viewpoint of the bundle agent that performs
>>>the reactive fragmentation, the link on which it receives the bundle is
>>>being used as efficiently as possible (no data that makes it through once
>>>has to be resent) but the link on which it must forward the data may not
>>
>>be
>>
>>>used efficiently, because even though this link may be up and able to be
>>>used to send data, it may be idle because the bundle agent isn't able to
>>>send the head until the tail of the bundle has arrived. Is this good
>>
>>enough?
>>
>>>Can we settle for this or is the "cut-through" feature that enables both
>>>links to be used efficiently something that our solution absolutely must
>>>provide?
>>>
>>>Remember, we only run into this problem if security is being used, and, in
>>>particular, if hop by hop security is being provided by the presence of a
>>>Bundle Authentication Header in the bundle. If security is not being used,
>>>or if security is being used and the security features of the underlying
>>>network are being relied on so that the bundle doesn't have a Bundle
>>>Authentication Header, then the tails of bundles don't have to have their
>>>routes restricted and cut-through routing is possible.
>>>
>>>If the above compromises are unacceptable, I think we are stuck with the
>>>toilet paper approach or something like it. What do people think?
>>>
>>>-susan
>>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]] On Behalf Of Michael Demmer
>>>Sent: Monday, April 11, 2005 12:09 PM
>>>To: Susan F. Symington
>>>Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
>>>Subject: Re: [dtn-interest] on ditching fragmentation
>>>
>>>
>>>
>>>>If you choose option (b) below, which is to enable rective
>>>>fragmentation but make sure that all fragments of a given bundle
>>>>follow the same path, you are doing this because you are requiring
>>>>the receiving intermediate bundle agent to wait until the entire
>>>>original bundle is received so that it can authenticate the bundle
>>>>before forwarding any part of it. But what would be the point of
>>>>this? Aren't you losing the benefit that the reactive fragmentation
>>>>is supposed to provide, which is to enable the part of the orignal
>>>>bundle that was received before the connection went down to be
>>>>forwarded immediately, without having to wait?
>>>
>>>Not necessarily. If I have a connection that is only ever up for a
>>>window of 1/2 the time that it takes to transmit a large bundle, then
>>>even if I can't forward the first half of the bundle until I get the
>>>second half, I've still gotten a win out of reactive fragmentation.
>>>
>>>
>>>>We have been saying that we want "reactive fragmentation", but I
>>>>think that what we really want is to be able to reactively fragment
>>>>and then immediately forward.
>>>
>>>This is, I agree, the "touchy" part about reactive fragmentation, and
>>>the part that makes it tricky wrt authentication. We should come up
>>>with a name for this (I believe one term tossed around was
>>>'cut-thru-routing') as distinct from reactive fragmentation which in
>>>my mind just handles the connection interruption.
>>>
>>>
>>>>In my mind there is no point in reactively fragmenting if we are
>>>>going to have to wait to reassemble the bundle before we will be
>>>>able to forward it or any part of it. 
>>>
>>>As I said before, I disagree with this.
>>>
>>>
>>>>If what we really want is "reactive fragmentation and immediate
>>>>forwarding" (which is what I think we want, but we might not all
>>>>agree on that, I don't know), then option (b) is misleading, because
>>>>it only enables reactive fragmentation; it precludes immediate
>>>>forwarding.
>>>
>>>Agreed -- restate b) to "enable reactive fragmentation but not
>>>XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
>>>before the tail arrives).
>>>
>>>
>>>>Reactive fragmentation and immediate forwarding *is* incompatible
>>>>with the type of bundle authentication that is now defined as being
>>>>provided in the Bundle Authentication Header.
>>>
>>>Yes, I agree with that.
>>>
>>>-m
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>>
>>>
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>>
>>
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

From: "Susan F. Symington" <[email-masked]>
To: "'Peter TB Brett'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] on ditching fragmentation
Date: Tue, 12 Apr 2005 10:24:18 -0400
Sender: [email-masked]

Peter,

I don't see anything wrong with your description. In your scenario, all
fragmentation occurs "proactively".

You ask what would happen if D dies.  The answer to that depends on many
things, many of which aren't related to fragmentation.  Was custody transfer
reporting being used? Had D taken custody of the fragment? Was Bundle
reception reporting and/or bundle forwarding reporting in use? Did D die
before or after it got a chance to send back these reports, etc. Assuming
the source can be informed that the fragment that D received needs to be
retransmitted, it can retransmit it. Your question is more about how custody
and retransmission work, not fragmentation, and I'm not prepared to discuss
that. 

What would relate to fragmentation is what would happen if the link between
the source and D were to go down (but D doesn't die) after D had received
0.6 of the fragment. This is the situation in which we would want D to
reactively fragment the original 1 MB into the 0.6 MB portion it has
received. D would be able to immediately forward the 0.6 MB that it had
received and the source could (eventually, assuming all the retransmission
mechanisms work; I'm not concerned with how that works here) retransmit the
0.4 MB "tail" of the bundle later as its own fragment. 

In this scenario, (assuming no other fragmentation anywhere else) the sink
would receive 
11 fragments (Nine 1 MB fragments, one 0.6 MB fragment, and one 0.4 MB
fragment) instead of ten 1 MB fragments.

The security issue that is plaguing us is that when D receives only the
first 0.6 part of the 1 MB fragment, it cannot use the authentication
information in the Bundle Authentication Header of that fragment to
authenticate the portion of the fragment it received, because the
authentication information was calculated over the entire original 1 MB
fragment and so the entire original 1 MB fragment must be accessible to D in
order for D to validate the correctness of the authentication information. 

Hope this helps.

-susan

*****************************************************************
PLEASE NOTE: Starting April 15, 2005, the exchange for Susan Symington's
work numbers is changing from "883" to "983". So, her new office contact
information will be:
 
703-983-7209 (voice)
708-983-7142 (fax)
 
Please make a note of this change. Thanks!
******************************************************************

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter TB Brett
Sent: Monday, April 11, 2005 5:52 PM
To: [email-masked]
Subject: RE: [dtn-interest] on ditching fragmentation

Hi all,

Susan F. Symington wrote:

> One problem with it, however, might be that it isn't related to the
> capabilities of the network. If a link cannot routinetly stay up long
> enough to transmit data of that length, then there's no way to use
> reactive fragmentation to move data along that link. If a link routinely
> stays up for much longer than it takes to transmit data of that length,
> then there is a lot of wasted bandwidth carrying all those embedded
> hashes. If segments are too large, then lots of data is lost in the
> "interrupted" segment when a connection is lost and that data needs to be
> resent.  If segments are too small, lots of bits are wasted with the many
> signed hash values that are interspersed throughout the payload.

I'm really having trouble following the rational for fragmentation (please
excuse me if I don't use the correct terminology), so I thought I'd detail
an instance in which it would be useful as I see the argument:

- On the "source" node, there is an application that creates a 10 MB
bundle addressed to the "sink" node, and submits it to the local bundling
agent.

- The local agent has links to *many* different nodes that come into
contact intermittently and randomly (unpredictably).  There's never enough
time to transfer more than 1 MB of data during a single contact.

- Because the local agent doesn't know when a particular node will be in
contact again (or even *whether* that node will be in contact again) it
needs to fragment the original bundle into 10 or more fragments,
transferred independently, in order to transfer it to the outside world
successfully.

- It transfers each of these fragments to the nodes it comes into contact
with in order of contact: ABACDABCAE.  Now A has 4 fragments, B & C have 2
each and D & E have 1 each.

- A, B, C, D and E propagate the fragments through the network, and
eventually they come to the "sink" node, which waits until it has all 10
(or however many) fragments, collates them, and forwards the original 10
MB bundle.

In this scenario, the original bundle will not be transmitted across the
network at all without fragmentation.

Please correct me if I'm wrong in this interpretation. :)

Peter Brett

P.S. What happens if node D dies a horrible death sometime inbetween
collecting a fragment from the source and delivering it to the sink?

-- 
E-mail:       [email-masked]
Website:      http://www.peter-b.co.uk

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

Date: Mon, 11 Apr 2005 19:07:27 -0700
From: Melissa Ho <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] test
Sender: [email-masked]

Date: Mon, 11 Apr 2005 17:15:42 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Sender: [email-masked]

Michael Demmer wrote:
>>I see your point about the dictionary, so I would be willing to go
>>with the standard preamble approach in that case.
> 
>>For the Demux header, though, the whole point of the header is bit
>>efficiency; carrying a length field would tend to defeat that
>>purpose.  But I think I wouldn't object too strongly to a 1-byte
>>length field for this header.  This would enable parsing to proceed
>>rapidly for routers, who don't care about what's in the Demux header
>>(they're not doing the final delivery), and it would be plenty big
>>enough to cover the maximum possible size of this header (which I
>>proposed to be one next-header type [1 byte] and four SDNVs, none of
>>which can be more than 9 bytes long), and it only "wastes" 1 byte.
> 
> Ok...
> 
>>>There's the fragmentation header, which based on the other discussion
>>>thread, also seems like a ripe candidate to be made optional.
>>
>>I'm not so sure here.  It may be optional to a bundle agent that chooses 
>>not to fragment, but it's not optional to one that receives bundles that 
>>were fragmented by somebody else.  
> 
> Why? Can't the receiving bundle agent simply forward the fragment no
> differently than if it were a full bundle?

Maybe I misunderstand exactly what we mean by the term "optional". 
Certainly a bundle agent that is only forwarding a bundle doesn't need to 
do fragmentation or even recognize that a given bundle is a fragment.  But 
any given bundle agent is potentially the final destination agent for a 
given bundle, and if the final destination agent doesn't recognize 
fragments and reassemble original payloads from them then I would say 
you've got a failure of interoperability.  That is, we can certainly say 
that fragmentation is optional, but I would suggest that reassembly isn't. 
  (Nor is the -- what shall we call it? -- responsive fragmentation that a 
custodial agent must do when it receives a custody acceptance signal for a 
fragment of an original bundle for which it is the current custodian.)

>>And especially since this is a fixed-size header, I think I'd find
>>the mandatory length field an oppressive tax.
> 
> Yeah -- I would agree. The only argument here is whether support for
> fragmentation in any way (including parsing the header) is a
> requirement in the basic protocol spec.

Unfortunately I think it has to be.

>>I think the impulse here is right, but the Demux and Fragment
>>headers aren't really optional: if you receive one you can't ignore
>>it.  I'd argue for making them exceptions to the rule, along with
>>the Primary header.
> 
> Again, I think they are actually optional. If I'm convinced otherwise,
> then I would agree with you that they should be exceptions and have no
> need for the explicit length preamble, as they are actually fixed
> length.

Well, the proposed Demux header wouldn't be fixed-length (those SDNVs), but 
I think we can agree on that structure anyway: I'm fine with having an 
8-bit header length in the header.

Scott

Date: Mon, 11 Apr 2005 17:51:49 -0400 (EDT)
Subject: RE: [dtn-interest] on ditching fragmentation
From: "Peter TB Brett" <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

Hi all,

Susan F. Symington wrote:

> One problem with it, however, might be that it isn't related to the
> capabilities of the network. If a link cannot routinetly stay up long
> enough to transmit data of that length, then there's no way to use
> reactive fragmentation to move data along that link. If a link routinely
> stays up for much longer than it takes to transmit data of that length,
> then there is a lot of wasted bandwidth carrying all those embedded
> hashes. If segments are too large, then lots of data is lost in the
> "interrupted" segment when a connection is lost and that data needs to be
> resent.  If segments are too small, lots of bits are wasted with the many
> signed hash values that are interspersed throughout the payload.

I'm really having trouble following the rational for fragmentation (please
excuse me if I don't use the correct terminology), so I thought I'd detail
an instance in which it would be useful as I see the argument:

- On the "source" node, there is an application that creates a 10 MB
bundle addressed to the "sink" node, and submits it to the local bundling
agent.

- The local agent has links to *many* different nodes that come into
contact intermittently and randomly (unpredictably).  There's never enough
time to transfer more than 1 MB of data during a single contact.

- Because the local agent doesn't know when a particular node will be in
contact again (or even *whether* that node will be in contact again) it
needs to fragment the original bundle into 10 or more fragments,
transferred independently, in order to transfer it to the outside world
successfully.

- It transfers each of these fragments to the nodes it comes into contact
with in order of contact: ABACDABCAE.  Now A has 4 fragments, B & C have 2
each and D & E have 1 each.

- A, B, C, D and E propagate the fragments through the network, and
eventually they come to the "sink" node, which waits until it has all 10
(or however many) fragments, collates them, and forwards the original 10
MB bundle.

In this scenario, the original bundle will not be transmitted across the
network at all without fragmentation.

Please correct me if I'm wrong in this interpretation. :)

Peter Brett

P.S. What happens if node D dies a horrible death sometime inbetween
collecting a fragment from the source and delivering it to the sink?

-- 
E-mail:       [email-masked]
Website:      http://www.peter-b.co.uk

Date: Mon, 11 Apr 2005 13:10:20 -0700
From: Michael Demmer <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Cc: "Susan F. Symington" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Mail-Followup-To: Rajesh Krishnan <[email-masked]>, "Susan F. Symington" <[email-masked]>, 'DTN' <[email-masked]>
Sender: [email-masked]

> It is not clear that there is a universal method (across all
> networks and applications) that can determine the optimum segment
> size, or even whether it should be a fixed value (not all bundle
> parts may be equally important).

Yes. This is one of the compelling (to me anyway) arguments for why
reactive fragmentation is useful.

-m

Date: Mon, 11 Apr 2005 13:09:15 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Mail-Followup-To: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Sender: [email-masked]

> I see your point about the dictionary, so I would be willing to go
> with the standard preamble approach in that case.

> For the Demux header, though, the whole point of the header is bit
> efficiency; carrying a length field would tend to defeat that
> purpose.  But I think I wouldn't object too strongly to a 1-byte
> length field for this header.  This would enable parsing to proceed
> rapidly for routers, who don't care about what's in the Demux header
> (they're not doing the final delivery), and it would be plenty big
> enough to cover the maximum possible size of this header (which I
> proposed to be one next-header type [1 byte] and four SDNVs, none of
> which can be more than 9 bytes long), and it only "wastes" 1 byte.

Ok...

> >There's the fragmentation header, which based on the other discussion
> >thread, also seems like a ripe candidate to be made optional.
> 
> I'm not so sure here.  It may be optional to a bundle agent that chooses 
> not to fragment, but it's not optional to one that receives bundles that 
> were fragmented by somebody else.  

Why? Can't the receiving bundle agent simply forward the fragment no
differently than if it were a full bundle?

> And especially since this is a fixed-size header, I think I'd find
> the mandatory length field an oppressive tax.

Yeah -- I would agree. The only argument here is whether support for
fragmentation in any way (including parsing the header) is a
requirement in the basic protocol spec.

> I think the impulse here is right, but the Demux and Fragment
> headers aren't really optional: if you receive one you can't ignore
> it.  I'd argue for making them exceptions to the rule, along with
> the Primary header.

Again, I think they are actually optional. If I'm convinced otherwise,
then I would agree with you that they should be exceptions and have no
need for the explicit length preamble, as they are actually fixed
length.

-m

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
To: [email-masked] (Susan F. Symington)
Date: Mon, 11 Apr 2005 15:58:59 -0400 (EDT)
Cc: [email-masked], [email-masked] ('DTN')
Reply-to: [email-masked]
Sender: [email-masked]

Susan,

Thank you for explaining the "toilet paper" approach, the issues 
with it, and that my proposal is a variant of that approach.

It is not clear that there is a universal method (across all networks 
and applications) that can determine the optimum segment size, or even 
whether it should be a fixed value (not all bundle parts may be equally 
important).

Best Regards,
Rajesh

> Rajesh,
> 
> The suggestion that you are making is essentially what we have been calling
> the "toilet paper" approach --a name that was chosen to be descriptive,
> rather than dismissive of the approach, and we keep coming back to it, but
> it is ugly and complicated.  The toilet paper proposal was made before I got
> involved in the project; basically, it involves formatting the payload as a
> series of segments followed by authentication information of those segments.
> This way, if transmission of a bundle is interrupted before the entire
> payload makes it across the link, all those segments that did make it with
> their accompanying authentication information could be authenticated and
> forwarded immediately, and only the segment that was interrupted, its
> accompanying hash value, and all following segments of the payload would
> have to be resent.  The reason it is called the toilet paper approach is
> that the payload is essentially perforated after every
> segment,authentication information pair.
> 
> Note that this approach differs slightly from your suggestion because it
> involves putting the hash(es) in a header rather than embedded in the
> payload. If the hashes are in the header, then you would be sending all the
> hashes before sending even a bit of the payload. It is more efficient to
> send the hashes only when you know they will be useful, as in right after
> the payload they protect. 
> 
> One of the problems that we have had with considering the toilet paper
> approach before has been how we would know what a good segment size would
> be. Determining this size according to the natural concept of what the next
> safely usable increment at the destination is, as you suggest, is appealing.
> I like it.
> 
> One problem with it, however, might be that it isn't related to the
> capabilities of the network. If a link cannot routinetly stay up long enough
> to transmit data of that length, then there's no way to use reactive
> fragmentation to move data along that link. If a link routinely stays up for
> much longer than it takes to transmit data of that length, then there is a
> lot of wasted bandwidth carrying all those embedded hashes. If segments are
> too large, then lots of data is lost in the "interrupted" segment when a
> connection is lost and that data needs to be resent.  If segments are too
> small, lots of bits are wasted with the many signed hash values that are
> interspersed throughout the payload. 
> 
> So even though mechanically we understand how we could enable authentication
> and immediate forwarding to coexist by using the toilet paper mechanim, we
> don't really don't know how to use this mechanism effectively, because we
> don't know how to select an optimal segment size.  If you have any ideas it
> would be great to hear them.
> 
> -susan
> 
> -----Original Message-----
> From: Rajesh Krishnan [mailto:[email-masked]] 
> Sent: Monday, April 11, 2005 2:12 PM
> To: Susan F. Symington
> Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> Subject: Re: [dtn-interest] on ditching fragmentation
> 
> Susan and Mike,
> 
> In some applications, there is a natural concept of what the next safely
> usable increment at the destination is (e.g. a video frame).
> 
> Suppose a bundle could include a second hash covering the first usable 
> increment in addition to the usual hash over the entire bundle.  Under 
> reactive fragmentation, the first usable increment can be forwarded
> if/when available.
> 
> The additional hash could go on an optional fragmentation header to be 
> used if immediate forwarding (upon reactive fragmentation) is desired.  
> Hashes that protect subsequent increments can also be included in such
> a header if one is willing to expend the header overhead.  
> 
> Proactive addition of fragment hashes in anticipation of reactive 
> fragmentation is a possible medium between the proactive fragmentation 
> and reactive fragmentation schemes presented.
> 
> Best Regards,
> Rajesh
> 
> > Mike,
> > 
> > I see your point that there may be some utility in a bundle agent being
> able
> > to reactively fragment even if it is precluded from immediately
> forwarding. 
> > 
> > Here is how our dilemma seems to look right now:
> > 
> > >From a security standpoint, we really want to be able to calculate the
> > authentication information in the Bundle Authentication Header over the
> > entire bundle, including the payload. We can have this security that we
> want
> > and we can also have reactive fragmentation, as long as we require that if
> a
> > bundle is reactively fragmented then its "tail" (which may arrive as
> > multiple bundle fragments) is forwarded through the same bundle agent that
> > did the reactive fragmentation and is holding on to the head. However, we
> > cannot forward the reactively fragmented head until the "tail" is
> received.
> > My questions for everyone who cares are:
> > 
> > 1. Is it feasible to require the tails of reactively fragmented bundles to
> > be forwarded through the same bundle agent as the head?  Is this something
> > people are willing to put up with in order to be able to have both the
> > security that we want and reactive fragmentation? Or do some people out
> > there feel that restricting the bundle's path in this way would be
> > unacceptable?
> > 
> > 2. Is being able to reactively fragment but not immediately forward
> bundles
> > that have Bundle Authentication Headers good enough for people?  We still
> do
> > get some utility out of being able to reactively fragment, as Mike points
> > out, but we don't get the full efficiency of "cut-through routing" because
> > the receiving bundle agent can't forward the head until the tail arrives.
> I
> > think this means that from the viewpoint of the bundle agent that performs
> > the reactive fragmentation, the link on which it receives the bundle is
> > being used as efficiently as possible (no data that makes it through once
> > has to be resent) but the link on which it must forward the data may not
> be
> > used efficiently, because even though this link may be up and able to be
> > used to send data, it may be idle because the bundle agent isn't able to
> > send the head until the tail of the bundle has arrived. Is this good
> enough?
> > Can we settle for this or is the "cut-through" feature that enables both
> > links to be used efficiently something that our solution absolutely must
> > provide?
> > 
> > Remember, we only run into this problem if security is being used, and, in
> > particular, if hop by hop security is being provided by the presence of a
> > Bundle Authentication Header in the bundle. If security is not being used,
> > or if security is being used and the security features of the underlying
> > network are being relied on so that the bundle doesn't have a Bundle
> > Authentication Header, then the tails of bundles don't have to have their
> > routes restricted and cut-through routing is possible.
> > 
> > If the above compromises are unacceptable, I think we are stuck with the
> > toilet paper approach or something like it. What do people think?
> > 
> > -susan
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Michael Demmer
> > Sent: Monday, April 11, 2005 12:09 PM
> > To: Susan F. Symington
> > Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> > Subject: Re: [dtn-interest] on ditching fragmentation
> > 
> > 
> > > If you choose option (b) below, which is to enable rective
> > > fragmentation but make sure that all fragments of a given bundle
> > > follow the same path, you are doing this because you are requiring
> > > the receiving intermediate bundle agent to wait until the entire
> > > original bundle is received so that it can authenticate the bundle
> > > before forwarding any part of it. But what would be the point of
> > > this? Aren't you losing the benefit that the reactive fragmentation
> > > is supposed to provide, which is to enable the part of the orignal
> > > bundle that was received before the connection went down to be
> > > forwarded immediately, without having to wait?
> > 
> > Not necessarily. If I have a connection that is only ever up for a
> > window of 1/2 the time that it takes to transmit a large bundle, then
> > even if I can't forward the first half of the bundle until I get the
> > second half, I've still gotten a win out of reactive fragmentation.
> > 
> > > We have been saying that we want "reactive fragmentation", but I
> > > think that what we really want is to be able to reactively fragment
> > > and then immediately forward.
> > 
> > This is, I agree, the "touchy" part about reactive fragmentation, and
> > the part that makes it tricky wrt authentication. We should come up
> > with a name for this (I believe one term tossed around was
> > 'cut-thru-routing') as distinct from reactive fragmentation which in
> > my mind just handles the connection interruption.
> > 
> > > In my mind there is no point in reactively fragmenting if we are
> > > going to have to wait to reassemble the bundle before we will be
> > > able to forward it or any part of it. 
> > 
> > As I said before, I disagree with this.
> > 
> > > If what we really want is "reactive fragmentation and immediate
> > > forwarding" (which is what I think we want, but we might not all
> > > agree on that, I don't know), then option (b) is misleading, because
> > > it only enables reactive fragmentation; it precludes immediate
> > > forwarding.
> > 
> > Agreed -- restate b) to "enable reactive fragmentation but not
> > XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
> > before the tail arrives).
> > 
> > > Reactive fragmentation and immediate forwarding *is* incompatible
> > > with the type of bundle authentication that is now defined as being
> > > provided in the Bundle Authentication Header.
> > 
> > Yes, I agree with that.
> > 
> > -m
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> > 
> > 
> > 
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> > 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Mon, 11 Apr 2005 12:19:31 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Schema names
Sender: [email-masked]

Stephen Farrell wrote:
> 
> I'll try be clearer.
> 
> I like it when the schema has both standard syntax and
> semantics, and I think that'll be the case for most useful
> things (e.g. EUNM, IP or DNS based stuff).
> 
> However, I'm not upset if someone somewhere can define
> a schema which only specifies the syntax. I'm not sure
> how generally useful it'll be, but its no harm really
> (e.g. some putative p2p routing scheme where some
> folks might implement a mix network and others might
> use a distributed DB running over IPsec links, perhaps
> in that case based on some common security/privacy/
> nymity requirements, but implemented as-you-like-it).

I don't see how that can work, but on the other hand I think at worst it's 
just a special instance of the general case where the semantics you've 
specified for a schema are incomplete, ambiguous, buggy, etc.

It will always be possible to devise a schema that can't work, and we 
shouldn't try to legislate against it.  Maybe, by some out-of-band 
mechanism (reliance on some unstated common nymity requirements, or 
whatever), it can be made to work; cool.  I just don't think we should 
declare that this is a good model for schema definitions, at least not 
until someone has tried it and demonstrated a success that I'm having 
trouble visualizing.  I think the norm for schema definitions should be an 
unambiguous set of syntactic rules coupled with an unambiguous set of 
semantic rules.

Scott

Date: Mon, 11 Apr 2005 12:09:33 -0700
From: Scott Burleigh <[email-masked]>
To: "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Susan F. Symington wrote:
> The scenario seems realistic enough. I am guessing that your point is that
> we should make sure that we define things so that a bundle agent could be
> configured to reactively fragment and immediately forward if network
> conditions are such that we are willing to allow this and risk wasting
> bandwidth in cases in which the part of the network beyond the bundle agent
> isn't very constrained.  If so, I think I agree with that. 
> 
> However, we are still faced with the dilemma of what to do in cases in which
> the network is constrained, so it really would do harm to forward a bundle
> without first authenticating it. 
> 
> I'm still interested in learning how people feel about the prospect of
> requiring bundle tails to be sent through the same agents as bundle heads,
> and deferring forwarding until the entire bundle has arrived, in order to be
> able to provide full-bundle authentication on constrained networks.

It seems to me like hard work for meager return and I doubt I'd implement 
it, but I don't see any harm in somebody else supporting that model.

Scott

Date: Mon, 11 Apr 2005 12:05:42 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Sender: [email-masked]

Michael Demmer wrote:

>>Now the question is how best to take advantage of this denseness.
>>
>>In order to make these string references do double duty as I was proposing, 
>>I think each of the four wants to be 12, 16, 20, or 24 bits long -- that 
>>is, taken together the four string references in Primary header occupy 
>>either 6, 8, 10, or 12 bytes: less than 12 bits is just not a big enough 
>>range for the catalog sizes I think we'll need, more than 12 bytes is too 
>>fat, and any sizes in between give us leftover bits and/or promise parsing 
>>complexity without significant offsetting economy.
>>
>>If string references are 12 bits long then the maximum length of the 
>>dictionary byte array is 2047 (you've got 11 representation bits in any 
>>non-negative string reference) and the maximum assured safe length of any 
>>single endpoint ID is 511 bytes.  That may be enough, but it also gives us 
>>only 2048 possible catalog entries for any single delay-tolerant network. 
>>I think a case can be made that this isn't really going to be enough even 
>>just for deep space, and it wouldn't leave any room for other applications 
>>that might want to use this trick.
>>
>>16-bit string references give you a maximum endpoint ID length of 8191 
>>(almost certainly more than anybody will need) and total catalogue size of 
>>32768 (still kind of stingy; you could have eight catalogs of 4096 entries 
>>each).
> 
> 
> My initial instinct is that this seems like the 'sweet-spot'. But
> that's really based on instinct, since most networks I'm thinking of
> will use string-based identifiers, and even 511 bytes is plenty
> big. This one is also byte-aligned which is slightly easier to
> implement.

Yes, this does have appeal.  My only reservation is the rather small number 
of catalogs.  I'm inclined toward the 20-bit references, even though they 
don't align cleanly on byte boundaries, because they save us 16 bits over 
the 24-bit option and yet seem to offer a reasonably large catalog space. 
But I'd still like to hear if anybody besides me has any particular 
interest in using the catalog trick; if so, even 128 catalogs might not be 
enough.

>>Yep.  Being bit-stingy, I reiterate my opposition to this.  It's
>>excellent -- in fact necessary -- for any extension headers, but I
>>think bandwidth-constrained environments shouldn't be required to
>>pay this tax on standard headers just to save a few cycles of
>>integer arithmetic in parsing.  Bundling is a hard enough sell as it
>>is.
> 
> 
> So which headers are we really talking about? I don't think anyone is
> advocating this for the primary header, at least I never intended
> to.

Okay, we're in agreement so far.

> For the bundle payload header, we need to know the length anyway, so
> we can use the standard header preamble for it.

Fair enough; we're just moving a length field.

> For the dictionary header, if present, we _could_ get away with
> inferring the length as the largest offset in the primary header, or
> the largest in either the primary or the demux header, if we go with
> the demux header approach. This seems kinda cumbersome to
> implement. Not impossible of course, but not easy. Plus, now we're
> targeting an environment that is willing to use N string-based
> identifiers but isn't willing to pay the cost of one length for the
> entire dictionary. So I'd say we should just use a standard preamble.

I see your point about the dictionary, so I would be willing to go with the 
standard preamble approach in that case.  For the Demux header, though, the 
whole point of the header is bit efficiency; carrying a length field would 
tend to defeat that purpose.  But I think I wouldn't object too strongly to 
a 1-byte length field for this header.  This would enable parsing to 
proceed rapidly for routers, who don't care about what's in the Demux 
header (they're not doing the final delivery), and it would be plenty big 
enough to cover the maximum possible size of this header (which I proposed 
to be one next-header type [1 byte] and four SDNVs, none of which can be 
more than 9 bytes long), and it only "wastes" 1 byte.

> There's also all the security headers, but I believe we've already
> agreed that those should be considered optional. And if it's optional,
> then it should conform to the generic header spec so it can be
> correctly handled in non-participating nodes (i.e. all authenticated
> bundles should be dropped at a router that doesn't implement security
> features).

Okay with me.

> There's the fragmentation header, which based on the other discussion
> thread, also seems like a ripe candidate to be made optional.

I'm not so sure here.  It may be optional to a bundle agent that chooses 
not to fragment, but it's not optional to one that receives bundles that 
were fragmented by somebody else.  And especially since this is a 
fixed-size header, I think I'd find the mandatory length field an 
oppressive tax.

> Now, as I mentioned above, we may have a demux header with an
> as-of-yet undefined format, but which will probably be fixed-length
> and therefore a good candidate for omitting an explicit length. But
> since there's no need to parse that header as an interior, perhaps it
> should be optional?
> 
> Am I forgetting anything? 
> 
> Does everyone buy the argument that for headers that aren't required
> to be implemented, even if they are "standard", we should use the
> common prefix so they can be correctly handled by implementations that
> don't support the given feature?

I think the impulse here is right, but the Demux and Fragment headers 
aren't really optional: if you receive one you can't ignore it.  I'd argue 
for making them exceptions to the rule, along with the Primary header.

Scott

From: "Susan F. Symington" <[email-masked]>
To: <[email-masked]>
Cc: "'DTN'" <[email-masked]>
Subject: RE: [dtn-interest] on ditching fragmentation
Date: Mon, 11 Apr 2005 14:47:08 -0400
Sender: [email-masked]

Rajesh,

The suggestion that you are making is essentially what we have been calling
the "toilet paper" approach --a name that was chosen to be descriptive,
rather than dismissive of the approach, and we keep coming back to it, but
it is ugly and complicated.  The toilet paper proposal was made before I got
involved in the project; basically, it involves formatting the payload as a
series of segments followed by authentication information of those segments.
This way, if transmission of a bundle is interrupted before the entire
payload makes it across the link, all those segments that did make it with
their accompanying authentication information could be authenticated and
forwarded immediately, and only the segment that was interrupted, its
accompanying hash value, and all following segments of the payload would
have to be resent.  The reason it is called the toilet paper approach is
that the payload is essentially perforated after every
segment,authentication information pair.

Note that this approach differs slightly from your suggestion because it
involves putting the hash(es) in a header rather than embedded in the
payload. If the hashes are in the header, then you would be sending all the
hashes before sending even a bit of the payload. It is more efficient to
send the hashes only when you know they will be useful, as in right after
the payload they protect. 

One of the problems that we have had with considering the toilet paper
approach before has been how we would know what a good segment size would
be. Determining this size according to the natural concept of what the next
safely usable increment at the destination is, as you suggest, is appealing.
I like it.

One problem with it, however, might be that it isn't related to the
capabilities of the network. If a link cannot routinetly stay up long enough
to transmit data of that length, then there's no way to use reactive
fragmentation to move data along that link. If a link routinely stays up for
much longer than it takes to transmit data of that length, then there is a
lot of wasted bandwidth carrying all those embedded hashes. If segments are
too large, then lots of data is lost in the "interrupted" segment when a
connection is lost and that data needs to be resent.  If segments are too
small, lots of bits are wasted with the many signed hash values that are
interspersed throughout the payload. 

So even though mechanically we understand how we could enable authentication
and immediate forwarding to coexist by using the toilet paper mechanim, we
don't really don't know how to use this mechanism effectively, because we
don't know how to select an optimal segment size.  If you have any ideas it
would be great to hear them.

-susan

-----Original Message-----
From: Rajesh Krishnan [mailto:[email-masked]] 
Sent: Monday, April 11, 2005 2:12 PM
To: Susan F. Symington
Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
Subject: Re: [dtn-interest] on ditching fragmentation

Susan and Mike,

In some applications, there is a natural concept of what the next safely
usable increment at the destination is (e.g. a video frame).

Suppose a bundle could include a second hash covering the first usable 
increment in addition to the usual hash over the entire bundle.  Under 
reactive fragmentation, the first usable increment can be forwarded
if/when available.

The additional hash could go on an optional fragmentation header to be 
used if immediate forwarding (upon reactive fragmentation) is desired.  
Hashes that protect subsequent increments can also be included in such
a header if one is willing to expend the header overhead.  

Proactive addition of fragment hashes in anticipation of reactive 
fragmentation is a possible medium between the proactive fragmentation 
and reactive fragmentation schemes presented.

Best Regards,
Rajesh

> Mike,
> 
> I see your point that there may be some utility in a bundle agent being
able
> to reactively fragment even if it is precluded from immediately
forwarding. 
> 
> Here is how our dilemma seems to look right now:
> 
> >From a security standpoint, we really want to be able to calculate the
> authentication information in the Bundle Authentication Header over the
> entire bundle, including the payload. We can have this security that we
want
> and we can also have reactive fragmentation, as long as we require that if
a
> bundle is reactively fragmented then its "tail" (which may arrive as
> multiple bundle fragments) is forwarded through the same bundle agent that
> did the reactive fragmentation and is holding on to the head. However, we
> cannot forward the reactively fragmented head until the "tail" is
received.
> My questions for everyone who cares are:
> 
> 1. Is it feasible to require the tails of reactively fragmented bundles to
> be forwarded through the same bundle agent as the head?  Is this something
> people are willing to put up with in order to be able to have both the
> security that we want and reactive fragmentation? Or do some people out
> there feel that restricting the bundle's path in this way would be
> unacceptable?
> 
> 2. Is being able to reactively fragment but not immediately forward
bundles
> that have Bundle Authentication Headers good enough for people?  We still
do
> get some utility out of being able to reactively fragment, as Mike points
> out, but we don't get the full efficiency of "cut-through routing" because
> the receiving bundle agent can't forward the head until the tail arrives.
I
> think this means that from the viewpoint of the bundle agent that performs
> the reactive fragmentation, the link on which it receives the bundle is
> being used as efficiently as possible (no data that makes it through once
> has to be resent) but the link on which it must forward the data may not
be
> used efficiently, because even though this link may be up and able to be
> used to send data, it may be idle because the bundle agent isn't able to
> send the head until the tail of the bundle has arrived. Is this good
enough?
> Can we settle for this or is the "cut-through" feature that enables both
> links to be used efficiently something that our solution absolutely must
> provide?
> 
> Remember, we only run into this problem if security is being used, and, in
> particular, if hop by hop security is being provided by the presence of a
> Bundle Authentication Header in the bundle. If security is not being used,
> or if security is being used and the security features of the underlying
> network are being relied on so that the bundle doesn't have a Bundle
> Authentication Header, then the tails of bundles don't have to have their
> routes restricted and cut-through routing is possible.
> 
> If the above compromises are unacceptable, I think we are stuck with the
> toilet paper approach or something like it. What do people think?
> 
> -susan
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Demmer
> Sent: Monday, April 11, 2005 12:09 PM
> To: Susan F. Symington
> Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> Subject: Re: [dtn-interest] on ditching fragmentation
> 
> 
> > If you choose option (b) below, which is to enable rective
> > fragmentation but make sure that all fragments of a given bundle
> > follow the same path, you are doing this because you are requiring
> > the receiving intermediate bundle agent to wait until the entire
> > original bundle is received so that it can authenticate the bundle
> > before forwarding any part of it. But what would be the point of
> > this? Aren't you losing the benefit that the reactive fragmentation
> > is supposed to provide, which is to enable the part of the orignal
> > bundle that was received before the connection went down to be
> > forwarded immediately, without having to wait?
> 
> Not necessarily. If I have a connection that is only ever up for a
> window of 1/2 the time that it takes to transmit a large bundle, then
> even if I can't forward the first half of the bundle until I get the
> second half, I've still gotten a win out of reactive fragmentation.
> 
> > We have been saying that we want "reactive fragmentation", but I
> > think that what we really want is to be able to reactively fragment
> > and then immediately forward.
> 
> This is, I agree, the "touchy" part about reactive fragmentation, and
> the part that makes it tricky wrt authentication. We should come up
> with a name for this (I believe one term tossed around was
> 'cut-thru-routing') as distinct from reactive fragmentation which in
> my mind just handles the connection interruption.
> 
> > In my mind there is no point in reactively fragmenting if we are
> > going to have to wait to reassemble the bundle before we will be
> > able to forward it or any part of it. 
> 
> As I said before, I disagree with this.
> 
> > If what we really want is "reactive fragmentation and immediate
> > forwarding" (which is what I think we want, but we might not all
> > agree on that, I don't know), then option (b) is misleading, because
> > it only enables reactive fragmentation; it precludes immediate
> > forwarding.
> 
> Agreed -- restate b) to "enable reactive fragmentation but not
> XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
> before the tail arrives).
> 
> > Reactive fragmentation and immediate forwarding *is* incompatible
> > with the type of bundle authentication that is now defined as being
> > provided in the Bundle Authentication Header.
> 
> Yes, I agree with that.
> 
> -m
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
To: [email-masked] (Susan F. Symington)
Date: Mon, 11 Apr 2005 14:11:37 -0400 (EDT)
Cc: [email-masked] ('Michael Demmer'), [email-masked] ('Howard Weiss'), [email-masked] ('Scott Burleigh'), [email-masked] ('DTN')
Reply-to: [email-masked]
Sender: [email-masked]

Susan and Mike,

In some applications, there is a natural concept of what the next safely
usable increment at the destination is (e.g. a video frame).

Suppose a bundle could include a second hash covering the first usable 
increment in addition to the usual hash over the entire bundle.  Under 
reactive fragmentation, the first usable increment can be forwarded
if/when available.

The additional hash could go on an optional fragmentation header to be 
used if immediate forwarding (upon reactive fragmentation) is desired.  
Hashes that protect subsequent increments can also be included in such
a header if one is willing to expend the header overhead.  

Proactive addition of fragment hashes in anticipation of reactive 
fragmentation is a possible medium between the proactive fragmentation 
and reactive fragmentation schemes presented.

Best Regards,
Rajesh

> Mike,
> 
> I see your point that there may be some utility in a bundle agent being able
> to reactively fragment even if it is precluded from immediately forwarding. 
> 
> Here is how our dilemma seems to look right now:
> 
> >From a security standpoint, we really want to be able to calculate the
> authentication information in the Bundle Authentication Header over the
> entire bundle, including the payload. We can have this security that we want
> and we can also have reactive fragmentation, as long as we require that if a
> bundle is reactively fragmented then its "tail" (which may arrive as
> multiple bundle fragments) is forwarded through the same bundle agent that
> did the reactive fragmentation and is holding on to the head. However, we
> cannot forward the reactively fragmented head until the "tail" is received.
> My questions for everyone who cares are:
> 
> 1. Is it feasible to require the tails of reactively fragmented bundles to
> be forwarded through the same bundle agent as the head?  Is this something
> people are willing to put up with in order to be able to have both the
> security that we want and reactive fragmentation? Or do some people out
> there feel that restricting the bundle's path in this way would be
> unacceptable?
> 
> 2. Is being able to reactively fragment but not immediately forward bundles
> that have Bundle Authentication Headers good enough for people?  We still do
> get some utility out of being able to reactively fragment, as Mike points
> out, but we don't get the full efficiency of "cut-through routing" because
> the receiving bundle agent can't forward the head until the tail arrives.  I
> think this means that from the viewpoint of the bundle agent that performs
> the reactive fragmentation, the link on which it receives the bundle is
> being used as efficiently as possible (no data that makes it through once
> has to be resent) but the link on which it must forward the data may not be
> used efficiently, because even though this link may be up and able to be
> used to send data, it may be idle because the bundle agent isn't able to
> send the head until the tail of the bundle has arrived. Is this good enough?
> Can we settle for this or is the "cut-through" feature that enables both
> links to be used efficiently something that our solution absolutely must
> provide?
> 
> Remember, we only run into this problem if security is being used, and, in
> particular, if hop by hop security is being provided by the presence of a
> Bundle Authentication Header in the bundle. If security is not being used,
> or if security is being used and the security features of the underlying
> network are being relied on so that the bundle doesn't have a Bundle
> Authentication Header, then the tails of bundles don't have to have their
> routes restricted and cut-through routing is possible.
> 
> If the above compromises are unacceptable, I think we are stuck with the
> toilet paper approach or something like it. What do people think?
> 
> -susan
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Demmer
> Sent: Monday, April 11, 2005 12:09 PM
> To: Susan F. Symington
> Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> Subject: Re: [dtn-interest] on ditching fragmentation
> 
> 
> > If you choose option (b) below, which is to enable rective
> > fragmentation but make sure that all fragments of a given bundle
> > follow the same path, you are doing this because you are requiring
> > the receiving intermediate bundle agent to wait until the entire
> > original bundle is received so that it can authenticate the bundle
> > before forwarding any part of it. But what would be the point of
> > this? Aren't you losing the benefit that the reactive fragmentation
> > is supposed to provide, which is to enable the part of the orignal
> > bundle that was received before the connection went down to be
> > forwarded immediately, without having to wait?
> 
> Not necessarily. If I have a connection that is only ever up for a
> window of 1/2 the time that it takes to transmit a large bundle, then
> even if I can't forward the first half of the bundle until I get the
> second half, I've still gotten a win out of reactive fragmentation.
> 
> > We have been saying that we want "reactive fragmentation", but I
> > think that what we really want is to be able to reactively fragment
> > and then immediately forward.
> 
> This is, I agree, the "touchy" part about reactive fragmentation, and
> the part that makes it tricky wrt authentication. We should come up
> with a name for this (I believe one term tossed around was
> 'cut-thru-routing') as distinct from reactive fragmentation which in
> my mind just handles the connection interruption.
> 
> > In my mind there is no point in reactively fragmenting if we are
> > going to have to wait to reassemble the bundle before we will be
> > able to forward it or any part of it. 
> 
> As I said before, I disagree with this.
> 
> > If what we really want is "reactive fragmentation and immediate
> > forwarding" (which is what I think we want, but we might not all
> > agree on that, I don't know), then option (b) is misleading, because
> > it only enables reactive fragmentation; it precludes immediate
> > forwarding.
> 
> Agreed -- restate b) to "enable reactive fragmentation but not
> XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
> before the tail arrives).
> 
> > Reactive fragmentation and immediate forwarding *is* incompatible
> > with the type of bundle authentication that is now defined as being
> > provided in the Bundle Authentication Header.
> 
> Yes, I agree with that.
> 
> -m
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

From: "Susan F. Symington" <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>
Cc: "'DTN'" <[email-masked]>
Subject: RE: [dtn-interest] on ditching fragmentation
Date: Mon, 11 Apr 2005 13:43:10 -0400
Sender: [email-masked]

The scenario seems realistic enough. I am guessing that your point is that
we should make sure that we define things so that a bundle agent could be
configured to reactively fragment and immediately forward if network
conditions are such that we are willing to allow this and risk wasting
bandwidth in cases in which the part of the network beyond the bundle agent
isn't very constrained.  If so, I think I agree with that. 

However, we are still faced with the dilemma of what to do in cases in which
the network is constrained, so it really would do harm to forward a bundle
without first authenticating it. 

I'm still interested in learning how people feel about the prospect of
requiring bundle tails to be sent through the same agents as bundle heads,
and deferring forwarding until the entire bundle has arrived, in order to be
able to provide full-bundle authentication on constrained networks. 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, April 11, 2005 1:24 PM
To: Susan F. Symington
Cc: 'Michael Demmer'; 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
Subject: Re: [dtn-interest] on ditching fragmentation

Susan,

Here's a scenario where forwarding before being
able to check the BAH might make sense.

An application/DTN combo. is such that bundles
have no harmful effect until the entire bundle has
arrived at the destination and, at least from the
receiving router onwards, the network is not very
constrained (e.g. plenty of power, bandwidth etc.),
and, the receiving router has very little persistent
storage for some reason, and, the inbound link to
the receiving router is likely to cause reactive
fragmentation for yet another reason, and, lastly
the receiving router is configured to insist on
BAH checking.

Maybe this is a little bit reminiscent of a VPN
gateway in a corporate network's DMZ, if you assume
that the next hop is to a firewall or similar.

In that case a router can sensibly forward fragments
knowing that so long as it doesn't forward the last
one (following a BAH-check failure), then no harm
will be done, other than some lost bandwith.

I've no idea if that's a realistic scenario, but it
does combine reactive frag. security and immediate
forwarding in an at least ostensibly sensible way.

Stephen.

Susan F. Symington wrote:

> Mike,
> 
> I see your point that there may be some utility in a bundle agent being
able
> to reactively fragment even if it is precluded from immediately
forwarding. 
> 
> Here is how our dilemma seems to look right now:
> 
>>From a security standpoint, we really want to be able to calculate the
> authentication information in the Bundle Authentication Header over the
> entire bundle, including the payload. We can have this security that we
want
> and we can also have reactive fragmentation, as long as we require that if
a
> bundle is reactively fragmented then its "tail" (which may arrive as
> multiple bundle fragments) is forwarded through the same bundle agent that
> did the reactive fragmentation and is holding on to the head. However, we
> cannot forward the reactively fragmented head until the "tail" is
received.
> My questions for everyone who cares are:
> 
> 1. Is it feasible to require the tails of reactively fragmented bundles to
> be forwarded through the same bundle agent as the head?  Is this something
> people are willing to put up with in order to be able to have both the
> security that we want and reactive fragmentation? Or do some people out
> there feel that restricting the bundle's path in this way would be
> unacceptable?
> 
> 2. Is being able to reactively fragment but not immediately forward
bundles
> that have Bundle Authentication Headers good enough for people?  We still
do
> get some utility out of being able to reactively fragment, as Mike points
> out, but we don't get the full efficiency of "cut-through routing" because
> the receiving bundle agent can't forward the head until the tail arrives.
I
> think this means that from the viewpoint of the bundle agent that performs
> the reactive fragmentation, the link on which it receives the bundle is
> being used as efficiently as possible (no data that makes it through once
> has to be resent) but the link on which it must forward the data may not
be
> used efficiently, because even though this link may be up and able to be
> used to send data, it may be idle because the bundle agent isn't able to
> send the head until the tail of the bundle has arrived. Is this good
enough?
> Can we settle for this or is the "cut-through" feature that enables both
> links to be used efficiently something that our solution absolutely must
> provide?
> 
> Remember, we only run into this problem if security is being used, and, in
> particular, if hop by hop security is being provided by the presence of a
> Bundle Authentication Header in the bundle. If security is not being used,
> or if security is being used and the security features of the underlying
> network are being relied on so that the bundle doesn't have a Bundle
> Authentication Header, then the tails of bundles don't have to have their
> routes restricted and cut-through routing is possible.
> 
> If the above compromises are unacceptable, I think we are stuck with the
> toilet paper approach or something like it. What do people think?
> 
> -susan
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Demmer
> Sent: Monday, April 11, 2005 12:09 PM
> To: Susan F. Symington
> Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> Subject: Re: [dtn-interest] on ditching fragmentation
> 
> 
> 
>>If you choose option (b) below, which is to enable rective
>>fragmentation but make sure that all fragments of a given bundle
>>follow the same path, you are doing this because you are requiring
>>the receiving intermediate bundle agent to wait until the entire
>>original bundle is received so that it can authenticate the bundle
>>before forwarding any part of it. But what would be the point of
>>this? Aren't you losing the benefit that the reactive fragmentation
>>is supposed to provide, which is to enable the part of the orignal
>>bundle that was received before the connection went down to be
>>forwarded immediately, without having to wait?
> 
> 
> Not necessarily. If I have a connection that is only ever up for a
> window of 1/2 the time that it takes to transmit a large bundle, then
> even if I can't forward the first half of the bundle until I get the
> second half, I've still gotten a win out of reactive fragmentation.
> 
> 
>>We have been saying that we want "reactive fragmentation", but I
>>think that what we really want is to be able to reactively fragment
>>and then immediately forward.
> 
> 
> This is, I agree, the "touchy" part about reactive fragmentation, and
> the part that makes it tricky wrt authentication. We should come up
> with a name for this (I believe one term tossed around was
> 'cut-thru-routing') as distinct from reactive fragmentation which in
> my mind just handles the connection interruption.
> 
> 
>>In my mind there is no point in reactively fragmenting if we are
>>going to have to wait to reassemble the bundle before we will be
>>able to forward it or any part of it. 
> 
> 
> As I said before, I disagree with this.
> 
> 
>>If what we really want is "reactive fragmentation and immediate
>>forwarding" (which is what I think we want, but we might not all
>>agree on that, I don't know), then option (b) is misleading, because
>>it only enables reactive fragmentation; it precludes immediate
>>forwarding.
> 
> 
> Agreed -- restate b) to "enable reactive fragmentation but not
> XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
> before the tail arrives).
> 
> 
>>Reactive fragmentation and immediate forwarding *is* incompatible
>>with the type of bundle authentication that is now defined as being
>>provided in the Bundle Authentication Header.
> 
> 
> Yes, I agree with that.
> 
> -m
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Date: Mon, 11 Apr 2005 18:23:56 +0100
From: Stephen Farrell <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Cc: "'Michael Demmer'" <[email-masked]>, "'Howard Weiss'" <[email-masked]>, "'Scott Burleigh'" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Susan,

Here's a scenario where forwarding before being
able to check the BAH might make sense.

An application/DTN combo. is such that bundles
have no harmful effect until the entire bundle has
arrived at the destination and, at least from the
receiving router onwards, the network is not very
constrained (e.g. plenty of power, bandwidth etc.),
and, the receiving router has very little persistent
storage for some reason, and, the inbound link to
the receiving router is likely to cause reactive
fragmentation for yet another reason, and, lastly
the receiving router is configured to insist on
BAH checking.

Maybe this is a little bit reminiscent of a VPN
gateway in a corporate network's DMZ, if you assume
that the next hop is to a firewall or similar.

In that case a router can sensibly forward fragments
knowing that so long as it doesn't forward the last
one (following a BAH-check failure), then no harm
will be done, other than some lost bandwith.

I've no idea if that's a realistic scenario, but it
does combine reactive frag. security and immediate
forwarding in an at least ostensibly sensible way.

Stephen.

Susan F. Symington wrote:

> Mike,
> 
> I see your point that there may be some utility in a bundle agent being able
> to reactively fragment even if it is precluded from immediately forwarding. 
> 
> Here is how our dilemma seems to look right now:
> 
>>From a security standpoint, we really want to be able to calculate the
> authentication information in the Bundle Authentication Header over the
> entire bundle, including the payload. We can have this security that we want
> and we can also have reactive fragmentation, as long as we require that if a
> bundle is reactively fragmented then its "tail" (which may arrive as
> multiple bundle fragments) is forwarded through the same bundle agent that
> did the reactive fragmentation and is holding on to the head. However, we
> cannot forward the reactively fragmented head until the "tail" is received.
> My questions for everyone who cares are:
> 
> 1. Is it feasible to require the tails of reactively fragmented bundles to
> be forwarded through the same bundle agent as the head?  Is this something
> people are willing to put up with in order to be able to have both the
> security that we want and reactive fragmentation? Or do some people out
> there feel that restricting the bundle's path in this way would be
> unacceptable?
> 
> 2. Is being able to reactively fragment but not immediately forward bundles
> that have Bundle Authentication Headers good enough for people?  We still do
> get some utility out of being able to reactively fragment, as Mike points
> out, but we don't get the full efficiency of "cut-through routing" because
> the receiving bundle agent can't forward the head until the tail arrives.  I
> think this means that from the viewpoint of the bundle agent that performs
> the reactive fragmentation, the link on which it receives the bundle is
> being used as efficiently as possible (no data that makes it through once
> has to be resent) but the link on which it must forward the data may not be
> used efficiently, because even though this link may be up and able to be
> used to send data, it may be idle because the bundle agent isn't able to
> send the head until the tail of the bundle has arrived. Is this good enough?
> Can we settle for this or is the "cut-through" feature that enables both
> links to be used efficiently something that our solution absolutely must
> provide?
> 
> Remember, we only run into this problem if security is being used, and, in
> particular, if hop by hop security is being provided by the presence of a
> Bundle Authentication Header in the bundle. If security is not being used,
> or if security is being used and the security features of the underlying
> network are being relied on so that the bundle doesn't have a Bundle
> Authentication Header, then the tails of bundles don't have to have their
> routes restricted and cut-through routing is possible.
> 
> If the above compromises are unacceptable, I think we are stuck with the
> toilet paper approach or something like it. What do people think?
> 
> -susan
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Demmer
> Sent: Monday, April 11, 2005 12:09 PM
> To: Susan F. Symington
> Cc: 'Howard Weiss'; 'Scott Burleigh'; 'DTN'
> Subject: Re: [dtn-interest] on ditching fragmentation
> 
> 
> 
>>If you choose option (b) below, which is to enable rective
>>fragmentation but make sure that all fragments of a given bundle
>>follow the same path, you are doing this because you are requiring
>>the receiving intermediate bundle agent to wait until the entire
>>original bundle is received so that it can authenticate the bundle
>>before forwarding any part of it. But what would be the point of
>>this? Aren't you losing the benefit that the reactive fragmentation
>>is supposed to provide, which is to enable the part of the orignal
>>bundle that was received before the connection went down to be
>>forwarded immediately, without having to wait?
> 
> 
> Not necessarily. If I have a connection that is only ever up for a
> window of 1/2 the time that it takes to transmit a large bundle, then
> even if I can't forward the first half of the bundle until I get the
> second half, I've still gotten a win out of reactive fragmentation.
> 
> 
>>We have been saying that we want "reactive fragmentation", but I
>>think that what we really want is to be able to reactively fragment
>>and then immediately forward.
> 
> 
> This is, I agree, the "touchy" part about reactive fragmentation, and
> the part that makes it tricky wrt authentication. We should come up
> with a name for this (I believe one term tossed around was
> 'cut-thru-routing') as distinct from reactive fragmentation which in
> my mind just handles the connection interruption.
> 
> 
>>In my mind there is no point in reactively fragmenting if we are
>>going to have to wait to reassemble the bundle before we will be
>>able to forward it or any part of it. 
> 
> 
> As I said before, I disagree with this.
> 
> 
>>If what we really want is "reactive fragmentation and immediate
>>forwarding" (which is what I think we want, but we might not all
>>agree on that, I don't know), then option (b) is misleading, because
>>it only enables reactive fragmentation; it precludes immediate
>>forwarding.
> 
> 
> Agreed -- restate b) to "enable reactive fragmentation but not
> XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
> before the tail arrives).
> 
> 
>>Reactive fragmentation and immediate forwarding *is* incompatible
>>with the type of bundle authentication that is now defined as being
>>provided in the Bundle Authentication Header.
> 
> 
> Yes, I agree with that.
> 
> -m
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Date: Mon, 11 Apr 2005 17:53:48 +0100
From: Stephen Farrell <[email-masked]>
To: Michael Demmer <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Schema names
Sender: [email-masked]

I'll try be clearer.

I like it when the schema has both standard syntax and
semantics, and I think that'll be the case for most useful
things (e.g. EUNM, IP or DNS based stuff).

However, I'm not upset if someone somewhere can define
a schema which only specifies the syntax. I'm not sure
how generally useful it'll be, but its no harm really
(e.g. some putative p2p routing scheme where some
folks might implement a mix network and others might
use a distributed DB running over IPsec links, perhaps
in that case based on some common security/privacy/
nymity requirements, but implemented as-you-like-it).

Stephen.

Michael Demmer wrote:

> I'm a little bit confused about what you're advocating here... This
> statement:
> 
> 
>>I do think we may sometimes want to be able to associated different
>>semantics with the same syntax, but it'll be the exception, and by
>>a long way too.
> 
> 
> Seems contradictory to this one:
> 
> 
>>I'm sure that there are schemata where we can and should define
>>common semantics (e.g. ENUM to turn Scott's example inside out:-).
>>If you want something syntacticallly like a phone number, but
>>which isn't then you can always roll a new schema definition.
>>
>>But, I don't see why they MUST all have the same semantics
>>everywhere.
> 
> 
> But I'm probably just misunderstanding you.
> 
> -m
> 
> 

From: "Susan F. Symington" <[email-masked]>
To: "'Michael Demmer'" <[email-masked]>
Cc: "'Howard Weiss'" <[email-masked]>, "'Scott Burleigh'" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: RE: [dtn-interest] on ditching fragmentation
Date: Mon, 11 Apr 2005 12:49:43 -0400
Sender: [email-masked]

Mike,

I see your point that there may be some utility in a bundle agent being able
to reactively fragment even if it is precluded from immediately forwarding. 

Here is how our dilemma seems to look right now:

Date: Mon, 11 Apr 2005 09:42:59 -0700
From: Michael Demmer <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Schema names
Mail-Followup-To: Stephen Farrell <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

I'm a little bit confused about what you're advocating here... This
statement:

> I do think we may sometimes want to be able to associated different
> semantics with the same syntax, but it'll be the exception, and by
> a long way too.

Seems contradictory to this one:

> I'm sure that there are schemata where we can and should define
> common semantics (e.g. ENUM to turn Scott's example inside out:-).
> If you want something syntacticallly like a phone number, but
> which isn't then you can always roll a new schema definition.
> 
> But, I don't see why they MUST all have the same semantics
> everywhere.

But I'm probably just misunderstanding you.

-m

Date: Mon, 11 Apr 2005 09:39:04 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Mail-Followup-To: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Sender: [email-masked]

> >In fact, to go one step further, we could define the offset as the
> >_last_ byte in the string,
> 
> Or, maybe easier, the offset of the first byte following the end of the 
> string.

Sure. That probably makes more sense.

>   thereby obviating the need to even know the
> >total length of the byte array, since implicitly, the start of the
> >first string is at offset zero.
> 
> Cleverer yet, and we can use zero to mean "none".  

I like that.

> Now the question is how best to take advantage of this denseness.
>
> In order to make these string references do double duty as I was proposing, 
> I think each of the four wants to be 12, 16, 20, or 24 bits long -- that 
> is, taken together the four string references in Primary header occupy 
> either 6, 8, 10, or 12 bytes: less than 12 bits is just not a big enough 
> range for the catalog sizes I think we'll need, more than 12 bytes is too 
> fat, and any sizes in between give us leftover bits and/or promise parsing 
> complexity without significant offsetting economy.
> 
> If string references are 12 bits long then the maximum length of the 
> dictionary byte array is 2047 (you've got 11 representation bits in any 
> non-negative string reference) and the maximum assured safe length of any 
> single endpoint ID is 511 bytes.  That may be enough, but it also gives us 
> only 2048 possible catalog entries for any single delay-tolerant network. 
> I think a case can be made that this isn't really going to be enough even 
> just for deep space, and it wouldn't leave any room for other applications 
> that might want to use this trick.
> 
> 16-bit string references give you a maximum endpoint ID length of 8191 
> (almost certainly more than anybody will need) and total catalogue size of 
> 32768 (still kind of stingy; you could have eight catalogs of 4096 entries 
> each).

My initial instinct is that this seems like the 'sweet-spot'. But
that's really based on instinct, since most networks I'm thinking of
will use string-based identifiers, and even 511 bytes is plenty
big. This one is also byte-aligned which is slightly easier to
implement.

> Yep.  Being bit-stingy, I reiterate my opposition to this.  It's
> excellent -- in fact necessary -- for any extension headers, but I
> think bandwidth-constrained environments shouldn't be required to
> pay this tax on standard headers just to save a few cycles of
> integer arithmetic in parsing.  Bundling is a hard enough sell as it
> is.

So which headers are we really talking about? I don't think anyone is
advocating this for the primary header, at least I never intended
to. 

For the bundle payload header, we need to know the length anyway, so
we can use the standard header preamble for it.

For the dictionary header, if present, we _could_ get away with
inferring the length as the largest offset in the primary header, or
the largest in either the primary or the demux header, if we go with
the demux header approach. This seems kinda cumbersome to
implement. Not impossible of course, but not easy. Plus, now we're
targeting an environment that is willing to use N string-based
identifiers but isn't willing to pay the cost of one length for the
entire dictionary. So I'd say we should just use a standard preamble.

There's also all the security headers, but I believe we've already
agreed that those should be considered optional. And if it's optional,
then it should conform to the generic header spec so it can be
correctly handled in non-participating nodes (i.e. all authenticated
bundles should be dropped at a router that doesn't implement security
features).

There's the fragmentation header, which based on the other discussion
thread, also seems like a ripe candidate to be made optional.

Now, as I mentioned above, we may have a demux header with an
as-of-yet undefined format, but which will probably be fixed-length
and therefore a good candidate for omitting an explicit length. But
since there's no need to parse that header as an interior, perhaps it
should be optional?

Am I forgetting anything? 

Does everyone buy the argument that for headers that aren't required
to be implemented, even if they are "standard", we should use the
common prefix so they can be correctly handled by implementations that
don't support the given feature?

-m

Date: Mon, 11 Apr 2005 17:33:57 +0100
From: Stephen Farrell <[email-masked]>
To: Michael Demmer <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Schema names
Sender: [email-masked]

> The case I was mostly thinking of is the one of guid-style names. In
> some cases like the ones Keshav has been using, the guid is used as a
> lookup into a DHT which resolves to something else to find the
> node. In other cases for the developing world, I'm planning on using
> GUIDs in a (mostly) static topology of very few nodes, so was planning
> on using a GUID per node, no aggregation in the route table, and
> simple per-node route entries.

There may be similar issues with things like Freenet where the
name is derived from the content regardless of its location.
I can imagine other forms of obscure p2p routing that might
involve different semantics within different domains.

> So what to do? We either define two schemas (DHT-guid, host-guid)
> which would be ok with me. Or, what I was advocating before, we have
> one set of definitions that describe the syntax of "what is a guid"
> and another set that defines "in this network, I use guids like this".

I do think we may sometimes want to be able to associated different
semantics with the same syntax, but it'll be the exception, and by
a long way too.

> But you (and others) make compelling arguments with regards to DTN
> network and implementation interoperability, so I'm inclined to say
> that the extra complexity and potential confusion implied by the above
> may not be worth the benefit of a (in my mind) cleaner separation
> between syntax and semantics.

I'm sure that there are schemata where we can and should define
common semantics (e.g. ENUM to turn Scott's example inside out:-).
If you want something syntacticallly like a phone number, but
which isn't then you can always roll a new schema definition.

But, I don't see why they MUST all have the same semantics
everywhere.

Stephen.

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] on ditching fragmentation
Date: Mon, 11 Apr 2005 09:17:29 -0700
From: "Bernard Peacock" <[email-masked]>
To: "Susan F. Symington" <[email-masked]>, "Michael Demmer" <[email-masked]>, "Howard Weiss" <[email-masked]>
Cc: "Scott Burleigh" <[email-masked]>, "DTN" <[email-masked]>
Sender: [email-masked]

The answer, may be, Flow-State routing.

In Flow-State, no packets are dropped.

To learn more.

www.caspian.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Susan F.
Symington
Sent: Monday, April 11, 2005 10:11 AM
To: 'Michael Demmer'; 'Howard Weiss'
Cc: 'Scott Burleigh'; 'DTN'
Subject: RE: [dtn-interest] on ditching fragmentation

Mike,

I don't see it as being as simple as you paint it.

If you choose option (b) below, which is to enable rective fragmentation
but make sure that all fragments of a given bundle follow the same path,
you are doing this because you are requiring the receiving intermediate
bundle agent to wait until the entire original bundle is received so
that it can authenticate the bundle before forwarding any part of it.
But what would be the point of this? Aren't you losing the benefit that
the reactive fragmentation is supposed to provide, which is to enable
the part of the orignal bundle that was received before the connection
went down to be forwarded immediately, without having to wait? 

We have been saying that we want "reactive fragmentation", but I think
that what we really want is to be able to reactively fragment and then
immediately forward. In my mind there is no point in reactively
fragmenting if we are going to have to wait to reassemble the bundle
before we will be able to forward it or any part of it. If what we
really want is "reactive fragmentation and immediate forwarding" (which
is what I think we want, but we might not all agree on that, I don't
know), then option (b) is misleading, because it only enables reactive
fragmentation; it precludes immediate forwarding. 

Reactive fragmentation and immediate forwarding *is* incompatible with
the type of bundle authentication that is now defined as being provided
in the Bundle Authentication Header.

-susan

[....lots of stuff snipped out]

> Reactive fragmentation is a performance optimization that is 
> Appropriate in some situations and not in others. There are cases in 
> which it makes security harder, everyone acknowledges that. So just 
> don't set up your network in such a way that it burns you later on.

> This means either a) don't enable reactive fragmentation, b) enable it

> and make sure all fragments of a given bundle follow the same path or
> c) don't enable bundle authentication if you want to forward parts of 
> a fragment independently.

> Perhaps some concerns would be allayed with a do-not-fragment bit?

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

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

Date: Mon, 11 Apr 2005 09:15:24 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Schema names
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> Michael Demmer wrote:
> >>I would agree with Scott. It seems to me that all implementations of a
> >>given schema should be required to conform both to syntactic and 
> >>semantic rules specified for that schema. Although correct parsing is
> >>the first step, many schemas are doomed to fail unless all nodes 
> >>operate under the same semantic rules.
> >
> >Perhaps. Perhaps not. What's to stop me from using guid's in a different
> >way in my DTN network from yours? As long as the places where our
> >networks peer with each other do the necessary translation so semantics
> >are preserved, then all is kosher, right? NAT boxes in effect do this
> >now -- I use 192.168.X.X addresses differently in my home network than
> >you do in yours. We're both using the IP address schema, though with
> >different semantics.
> 
> Mike, you're absolutely right that the semantic significance of a given 
> syntactical token -- in the context of a given schema -- might in theory be 
> altogether different in different wholly-disjoint delay-tolerant networks. 
>    I think it's a bad idea, though.
> 
> If I understand correctly, what you're arguing for is that syntactic rules 
> be bound to the schema and that semantic rules for that schema be bound 
> only to the network, so that the exact same schema could behave in an 
> entirely different way in different networks.  For example, 
> "schemaXYZ:125.142.154.251" could indicate use of IP in one network but 
> could mean "dial this phone number" in another.  I think this would play 
> havoc with DTN implementation and application portability.  That's why I 
> proposed (back on April 4) that we define a schema as "a named set of rules 
> for endpoint ID string syntax and semantics".

Ok -- I can see the counter-arguments, especially in the case of
something like IP.

> >I'm not saying we should have a free-for-all for deployments -- clearly
> >somewhere we should have operational semantics described for different
> >DTN networks.
> 
> But we don't yet have any such "somewhere", and I don't understand why it's
> useful to define different operational semantics for the same syntax on
> different networks.

The case I was mostly thinking of is the one of guid-style names. In
some cases like the ones Keshav has been using, the guid is used as a
lookup into a DHT which resolves to something else to find the
node. In other cases for the developing world, I'm planning on using
GUIDs in a (mostly) static topology of very few nodes, so was planning
on using a GUID per node, no aggregation in the route table, and
simple per-node route entries.

So what to do? We either define two schemas (DHT-guid, host-guid)
which would be ok with me. Or, what I was advocating before, we have
one set of definitions that describe the syntax of "what is a guid"
and another set that defines "in this network, I use guids like this".

But you (and others) make compelling arguments with regards to DTN
network and implementation interoperability, so I'm inclined to say
that the extra complexity and potential confusion implied by the above
may not be worth the benefit of a (in my mind) cleaner separation
between syntax and semantics.

> >I'm just not yet convinced that the architecture / protocol level is the
> >right place for these, nor am I convinced that we know how these
> >networks should even be operated. Thus my advocacy for schemas as
> >syntax.
> 
> I agree that architecture is the wrong place for a schema definition, and 
> in fact I think that nearly all schema definitions should be outside of 
> protcol definition documents -- the only reason to include one of them in 
> the Bundling spec is for convenience, so that implementers have something 
> basic to start with.
> 
> But I don't see how we can specify and implement anything at all without 
> "knowing how the network should be operated".  When we come up with a new 
> way of operating a network, I think we should devise a new schema 
> definition (with a new schema name) that encapsulates those new semantics 
> -- not overload an existing schema name with alternative semantics.  I 
> think the latter is a surefire prescription for obscurity and confusion, 
> and I can't see how it buys us anything at all.  What do you see as the 
> advantage?

I guess the main advantage was just to be able to re-use the syntax
definition. But there are other ways of accomplishing that.

-m

Date: Mon, 11 Apr 2005 09:08:38 -0700
From: Michael Demmer <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Cc: "'Howard Weiss'" <[email-masked]>, "'Scott Burleigh'" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Mail-Followup-To: "Susan F. Symington" <[email-masked]>, 'Howard Weiss' <[email-masked]>, 'Scott Burleigh' <[email-masked]>, 'DTN' <[email-masked]>
Sender: [email-masked]

> If you choose option (b) below, which is to enable rective
> fragmentation but make sure that all fragments of a given bundle
> follow the same path, you are doing this because you are requiring
> the receiving intermediate bundle agent to wait until the entire
> original bundle is received so that it can authenticate the bundle
> before forwarding any part of it. But what would be the point of
> this? Aren't you losing the benefit that the reactive fragmentation
> is supposed to provide, which is to enable the part of the orignal
> bundle that was received before the connection went down to be
> forwarded immediately, without having to wait?

Not necessarily. If I have a connection that is only ever up for a
window of 1/2 the time that it takes to transmit a large bundle, then
even if I can't forward the first half of the bundle until I get the
second half, I've still gotten a win out of reactive fragmentation.

> We have been saying that we want "reactive fragmentation", but I
> think that what we really want is to be able to reactively fragment
> and then immediately forward.

This is, I agree, the "touchy" part about reactive fragmentation, and
the part that makes it tricky wrt authentication. We should come up
with a name for this (I believe one term tossed around was
'cut-thru-routing') as distinct from reactive fragmentation which in
my mind just handles the connection interruption.

> In my mind there is no point in reactively fragmenting if we are
> going to have to wait to reassemble the bundle before we will be
> able to forward it or any part of it. 

As I said before, I disagree with this.

> If what we really want is "reactive fragmentation and immediate
> forwarding" (which is what I think we want, but we might not all
> agree on that, I don't know), then option (b) is misleading, because
> it only enables reactive fragmentation; it precludes immediate
> forwarding.

Agreed -- restate b) to "enable reactive fragmentation but not
XYZ-feature" (i.e. you can't forward the head of the fragmented bundle
before the tail arrives).

> Reactive fragmentation and immediate forwarding *is* incompatible
> with the type of bundle authentication that is now defined as being
> provided in the Bundle Authentication Header.

Yes, I agree with that.

-m

From: "Susan F. Symington" <[email-masked]>
To: "'Michael Demmer'" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Cc: "'Scott Burleigh'" <[email-masked]>, "'DTN'" <[email-masked]>
Subject: RE: [dtn-interest] on ditching fragmentation
Date: Mon, 11 Apr 2005 10:10:38 -0400
Sender: [email-masked]

Mike,

I don't see it as being as simple as you paint it.

If you choose option (b) below, which is to enable rective fragmentation but
make sure that all fragments of a given bundle follow the same path, you are
doing this because you are requiring the receiving intermediate bundle agent
to wait until the entire original bundle is received so that it can
authenticate the bundle before forwarding any part of it. But what would be
the point of this? Aren't you losing the benefit that the reactive
fragmentation is supposed to provide, which is to enable the part of the
orignal bundle that was received before the connection went down to be
forwarded immediately, without having to wait? 

We have been saying that we want "reactive fragmentation", but I think that
what we really want is to be able to reactively fragment and then
immediately forward. In my mind there is no point in reactively fragmenting
if we are going to have to wait to reassemble the bundle before we will be
able to forward it or any part of it. If what we really want is "reactive
fragmentation and immediate forwarding" (which is what I think we want, but
we might not all agree on that, I don't know), then option (b) is
misleading, because it only enables reactive fragmentation; it precludes
immediate forwarding. 

Reactive fragmentation and immediate forwarding *is* incompatible with the
type of bundle authentication that is now defined as being provided in the
Bundle Authentication Header.

-susan

[....lots of stuff snipped out]

> Reactive fragmentation is a performance optimization that is
> Appropriate in some situations and not in others. There are cases in
> which it makes security harder, everyone acknowledges that. So just
> don't set up your network in such a way that it burns you later on.

> This means either a) don't enable reactive fragmentation, b) enable it
> and make sure all fragments of a given bundle follow the same path or
> c) don't enable bundle authentication if you want to forward parts of
> a fragment independently.

> Perhaps some concerns would be allayed with a do-not-fragment bit?

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

Date: Mon, 11 Apr 2005 02:04:01 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Schema names
Sender: [email-masked]

Michael Demmer wrote:
>> I would agree with Scott. It seems to me that all implementations of a
>> given schema should be required to conform both to syntactic and 
>> semantic rules specified for that schema. Although correct parsing is
>> the first step, many schemas are doomed to fail unless all nodes 
>> operate under the same semantic rules.
> 
> Perhaps. Perhaps not. What's to stop me from using guid's in a different
> way in my DTN network from yours? As long as the places where our
> networks peer with each other do the necessary translation so semantics
> are preserved, then all is kosher, right? NAT boxes in effect do this
> now -- I use 192.168.X.X addresses differently in my home network than
> you do in yours. We're both using the IP address schema, though with
> different semantics.

Mike, you're absolutely right that the semantic significance of a given 
syntactical token -- in the context of a given schema -- might in theory be 
altogether different in different wholly-disjoint delay-tolerant networks. 
    I think it's a bad idea, though.

If I understand correctly, what you're arguing for is that syntactic rules 
be bound to the schema and that semantic rules for that schema be bound 
only to the network, so that the exact same schema could behave in an 
entirely different way in different networks.  For example, 
"schemaXYZ:125.142.154.251" could indicate use of IP in one network but 
could mean "dial this phone number" in another.  I think this would play 
havoc with DTN implementation and application portability.  That's why I 
proposed (back on April 4) that we define a schema as "a named set of rules 
for endpoint ID string syntax and semantics".

> I'm not saying we should have a free-for-all for deployments -- clearly
> somewhere we should have operational semantics described for different
> DTN networks.

But we don't yet have any such "somewhere", and I don't understand why it's
useful to define different operational semantics for the same syntax on
different networks.

> I'm just not yet convinced that the architecture / protocol level is the
> right place for these, nor am I convinced that we know how these
> networks should even be operated. Thus my advocacy for schemas as
> syntax.

I agree that architecture is the wrong place for a schema definition, and 
in fact I think that nearly all schema definitions should be outside of 
protcol definition documents -- the only reason to include one of them in 
the Bundling spec is for convenience, so that implementers have something 
basic to start with.

But I don't see how we can specify and implement anything at all without 
"knowing how the network should be operated".  When we come up with a new 
way of operating a network, I think we should devise a new schema 
definition (with a new schema name) that encapsulates those new semantics 
-- not overload an existing schema name with alternative semantics.  I 
think the latter is a surefire prescription for obscurity and confusion, 
and I can't see how it buys us anything at all.  What do you see as the 
advantage?

Scott

Date: Sun, 10 Apr 2005 21:17:14 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Sender: [email-masked]

Michael Demmer wrote:
>>>If we're really concerned about condensing bits, then isn't it true
>>>that all we need is a single value for the offset? The length of each
>>>string can then be inferred based on differences between the offsets.
>>
>>Very ingenious!  Of course that's right, so long as we know there's never 
>>any overlap in the strings and no gaps or padding between the string (and 
>>we know the total length of the byte array).
> 
> 
> In fact, to go one step further, we could define the offset as the
> _last_ byte in the string,

Or, maybe easier, the offset of the first byte following the end of the string.

   thereby obviating the need to even know the
> total length of the byte array, since implicitly, the start of the
> first string is at offset zero.

Cleverer yet, and we can use zero to mean "none".  Now the question is how 
best to take advantage of this denseness.

In order to make these string references do double duty as I was proposing, 
I think each of the four wants to be 12, 16, 20, or 24 bits long -- that 
is, taken together the four string references in Primary header occupy 
either 6, 8, 10, or 12 bytes: less than 12 bits is just not a big enough 
range for the catalog sizes I think we'll need, more than 12 bytes is too 
fat, and any sizes in between give us leftover bits and/or promise parsing 
complexity without significant offsetting economy.

If string references are 12 bits long then the maximum length of the 
dictionary byte array is 2047 (you've got 11 representation bits in any 
non-negative string reference) and the maximum assured safe length of any 
single endpoint ID is 511 bytes.  That may be enough, but it also gives us 
only 2048 possible catalog entries for any single delay-tolerant network. 
I think a case can be made that this isn't really going to be enough even 
just for deep space, and it wouldn't leave any room for other applications 
that might want to use this trick.

16-bit string references give you a maximum endpoint ID length of 8191 
(almost certainly more than anybody will need) and total catalogue size of 
32768 (still kind of stingy; you could have eight catalogs of 4096 entries 
each).

20-bit string references give you a maximum endpoint ID length of 131071 
(doesn't quite count as "unlimited", but close) and total catalogue size of 
2621440, which would offer 128 catalogs of 4096 entries each.

And with 24-bit string references we're back to where we started, except 
that maximum endpoint ID length is 2097151 (I'd call that "unlimited"); 
total catalogue size of 8388608, which would offer 2048 catalogs of 4096 
entries each.

Any thoughts on how much anybody besides deep space is going to be 
interested in this kind of compression?

> However, I think we _should_ know the total length because I think
> that all headers should have a common prelude that defines their
> header type and length, as in Keith's proposal several weeks ago. Is
> it time to reopen that discussion?

Yep.  Being bit-stingy, I reiterate my opposition to this.  It's excellent 
-- in fact necessary -- for any extension headers, but I think 
bandwidth-constrained environments shouldn't be required to pay this tax on 
standard headers just to save a few cycles of integer arithmetic in 
parsing.  Bundling is a hard enough sell as it is.

Scott

Date: Fri, 08 Apr 2005 14:57:45 -0400
From: Howard Weiss <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

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

Michael Demmer wrote:

>>I presume that when you say the "receiving daemon" you are talking
>>about the destination?
>>    
>>
>
>No, actually -- I meant any intermediate hop in the network. Without a
>complete bundle, you can't even forward it one hop if you're doing
>bundle authentication.
>  
>
Yeah, that too!  Its actually the same problem regardless of whether its 
in the middle or at the ends.

>  
>
>>If so, certainly that will be the case - essentially it has to
>>re-assemble the fragments and then authenticate the re-assembled
>>package.  The problem is, what happens if you required end-to-end
>>authentication, but you lose a fragment and it never shows up?  The
>>destination would never be able to authenticate the bundle because
>>it couldn't fully be re-assembled.
>>    
>>
>
>True...
>
>  
>
>>The usual response is to toss it in the bundle bucket.  But is this
>>the *right* response if the bundle contains an image of Mars and the
>>guys at the destination have a handy box of Crayolas with lots of
>>shades of red so that they could manually fill in the hole(s)? 
>>    
>>
>
>Perhaps not... but then why didn't they just send a bunch of smaller
>bundles that actually fit the standard 'adu' definition of being a
>unit of useful data to the applicaiton?
>  
>
They might have but maybe something else is broken and they get 
reactively fragmented anyway?

>  
>
>>So now these kinds of guys have to make the decision a priori -
>>security or mission data and potentially the two run counter to each
>>other.
>>    
>>
>
>They have to make some decision a priori, yes. But I would say that
>decision is whether or not to enable reactive fragmentation in the
>network, not whether they want security or not.
>
>Reactive fragmentation is a performance optimization that is
>appropriate in some situations and not in others. There are cases in
>which it makes security harder, everyone acknowledges that. So just
>don't set up your network in such a way that it burns you later on.
>
>This means either a) don't enable reactive fragmentation, b) enable it
>and make sure all fragments of a given bundle follow the same path or
>c) don't enable bundle authentication if you want to forward parts of
>a fragment independently.
>
>Perhaps some concerns would be allayed with a do-not-fragment bit?
>
>-m
>
>  
>
Yep - that might be an answer.

Howie

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body style="" bgcolor="#ffffff" text="#000000">
<br>
<br>
Michael Demmer wrote:<br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">I presume that when you say the "receiving daemon" you are talking
about the destination?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No, actually -- I meant any intermediate hop in the network. Without a
complete bundle, you can't even forward it one hop if you're doing
bundle authentication.
  </pre>
</blockquote>
Yeah, that too!&nbsp; Its actually the same problem regardless of whether
its in the middle or at the ends.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">If so, certainly that will be the case - essentially it has to
re-assemble the fragments and then authenticate the re-assembled
package.  The problem is, what happens if you required end-to-end
authentication, but you lose a fragment and it never shows up?  The
destination would never be able to authenticate the bundle because
it couldn't fully be re-assembled.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
True...

  </pre>
  <blockquote type="cite">
    <pre wrap="">The usual response is to toss it in the bundle bucket.  But is this
the *right* response if the bundle contains an image of Mars and the
guys at the destination have a handy box of Crayolas with lots of
shades of red so that they could manually fill in the hole(s)? 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Perhaps not... but then why didn't they just send a bunch of smaller
bundles that actually fit the standard 'adu' definition of being a
unit of useful data to the applicaiton?
  </pre>
</blockquote>
They might have but maybe something else is broken and they get
reactively fragmented anyway?<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">So now these kinds of guys have to make the decision a priori -
security or mission data and potentially the two run counter to each
other.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
They have to make some decision a priori, yes. But I would say that
decision is whether or not to enable reactive fragmentation in the
network, not whether they want security or not.

Reactive fragmentation is a performance optimization that is
appropriate in some situations and not in others. There are cases in
which it makes security harder, everyone acknowledges that. So just
don't set up your network in such a way that it burns you later on.

This means either a) don't enable reactive fragmentation, b) enable it
and make sure all fragments of a given bundle follow the same path or
c) don't enable bundle authentication if you want to forward parts of
a fragment independently.

Perhaps some concerns would be allayed with a do-not-fragment bit?

-m

  </pre>
</blockquote>
Yep - that might be an answer.<br>
<br>
Howie<br>
<pre class="moz-signature" cols="72">-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

--------------040403030207070102020604--

Date: Fri, 8 Apr 2005 10:58:52 -0700
From: Michael Demmer <[email-masked]>
To: Howard Weiss <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Mail-Followup-To: Howard Weiss <[email-masked]>, Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Sender: [email-masked]

> I presume that when you say the "receiving daemon" you are talking
> about the destination?

No, actually -- I meant any intermediate hop in the network. Without a
complete bundle, you can't even forward it one hop if you're doing
bundle authentication.

> If so, certainly that will be the case - essentially it has to
> re-assemble the fragments and then authenticate the re-assembled
> package.  The problem is, what happens if you required end-to-end
> authentication, but you lose a fragment and it never shows up?  The
> destination would never be able to authenticate the bundle because
> it couldn't fully be re-assembled.

True...

> The usual response is to toss it in the bundle bucket.  But is this
> the *right* response if the bundle contains an image of Mars and the
> guys at the destination have a handy box of Crayolas with lots of
> shades of red so that they could manually fill in the hole(s)? 

Perhaps not... but then why didn't they just send a bunch of smaller
bundles that actually fit the standard 'adu' definition of being a
unit of useful data to the applicaiton?

> So now these kinds of guys have to make the decision a priori -
> security or mission data and potentially the two run counter to each
> other.

They have to make some decision a priori, yes. But I would say that
decision is whether or not to enable reactive fragmentation in the
network, not whether they want security or not.

Reactive fragmentation is a performance optimization that is
appropriate in some situations and not in others. There are cases in
which it makes security harder, everyone acknowledges that. So just
don't set up your network in such a way that it burns you later on.

This means either a) don't enable reactive fragmentation, b) enable it
and make sure all fragments of a given bundle follow the same path or
c) don't enable bundle authentication if you want to forward parts of
a fragment independently.

Perhaps some concerns would be allayed with a do-not-fragment bit?

-m

Date: Fri, 08 Apr 2005 11:55:02 -0400
From: Howard Weiss <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

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

Mike

Michael Demmer wrote:

>>I still think it would make everyone's life easier if we did away
>>with reactive fragmentation specifically, but I will happily leave
>>that battle to somebody else.
>>    
>>
>
>Here's a proposal in favor of keeping fragmentation in the bundling
>layer, both proactive and reactive, that I hope will address the
>various concerns, specifically the security ones.
>
>The routing layer is the one that has information about the various
>connection opportunities to peers, perhaps over multiple convergence
>layers. As such, it is the best place to decide that it should send X%
>one way and Y% the other way, proactively.  However, there are times
>in which there is just no way to know how long a connection will stay
>open. As Keith put it, someone could start jamming my transmission at
>any time and for any duration. This is the situation which reactive
>fragmentation is geared for.
>
>Now, suppose we don't do any 'toilet-paper' style stuff for the bundle
>authentication header. The problem, concisely, is that with only the
>first fragment, the recieving daemon can't authenticate the bundle,
>and so can't forward it further.
>  
>
>But it could of course, hold onto the first part until it gets the
>rest. Note that the rest of the bundle could end up arriving over some
>other convergence layer, so we still want reactive fragmentation at
>the bundle layer. But, this presupposes that it _will_ get the rest at
>some point, which in some networks is not going to be likely.
>  
>
I presume that when you say the "receiving daemon" you are talking about 
the destination?  If so, certainly that will be the case - essentially 
it has to re-assemble the fragments and then authenticate the 
re-assembled package.  The problem is, what happens if you required 
end-to-end authentication, but you lose a fragment and it never shows 
up?  The destination would never be able to authenticate the bundle 
because it couldn't fully be re-assembled.  The usual response is to 
toss it in the bundle bucket.  But is this the *right* response if the 
bundle contains an image of Mars and the guys at the destination have a 
handy box of Crayolas with lots of shades of red so that they could 
manually fill in the hole(s)?   So now these kinds of guys have to make 
the decision a priori - security or mission data and potentially the two 
run counter to each other.

Howie

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Mike</font></font><br>
<br>
Michael Demmer wrote:<br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">I still think it would make everyone's life easier if we did away
with reactive fragmentation specifically, but I will happily leave
that battle to somebody else.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Here's a proposal in favor of keeping fragmentation in the bundling
layer, both proactive and reactive, that I hope will address the
various concerns, specifically the security ones.

The routing layer is the one that has information about the various
connection opportunities to peers, perhaps over multiple convergence
layers. As such, it is the best place to decide that it should send X%
one way and Y% the other way, proactively.  However, there are times
in which there is just no way to know how long a connection will stay
open. As Keith put it, someone could start jamming my transmission at
any time and for any duration. This is the situation which reactive
fragmentation is geared for.

Now, suppose we don't do any 'toilet-paper' style stuff for the bundle
authentication header. The problem, concisely, is that with only the
first fragment, the recieving daemon can't authenticate the bundle,
and so can't forward it further.
  </pre>
</blockquote>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">
But it could of course, hold onto the first part until it gets the
rest. Note that the rest of the bundle could end up arriving over some
other convergence layer, so we still want reactive fragmentation at
the bundle layer. But, this presupposes that it _will_ get the rest at
some point, which in some networks is not going to be likely.
  </pre>
</blockquote>
I presume that when you say the "receiving daemon" you are talking
about the destination?&nbsp; If so, certainly that will be the case -
essentially it has to re-assemble the fragments and then authenticate
the re-assembled package.&nbsp; The problem is, what happens if you required
end-to-end authentication, but you lose a fragment and it never shows
up?&nbsp; The destination would never be able to authenticate the bundle
because it couldn't fully be re-assembled.&nbsp; The usual response is to
toss it in the bundle bucket.&nbsp; But is this the *right* response if the
bundle contains an image of Mars and the guys at the destination have a
handy box of Crayolas with lots of shades of red so that they could
manually fill in the hole(s)?&nbsp;&nbsp; So now these kinds of guys have to make
the decision a priori - security or mission data and potentially the
two run counter to each other.<br>
<br>
Howie<br>
<pre class="moz-signature" cols="72">-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

--------------070902080000050804080608--

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Schema names
To: [email-masked] (Kevin Fall)
Date: Fri, 8 Apr 2005 09:38:58 -0400 (EDT)
Cc: [email-masked], [email-masked] (Michael Demmer), [email-masked] (Jakob Eriksson), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Kevin,

Sure.  RFC2396 has been obsoleted by RFC3986 (STD:0066) recently (Jan 05).
Should we just read the more recent one?

-Rajesh

> Just to make sure, I think RFC2396 is required reading
> at this point.  It provides some common language we may use for
> discussion on names.  Plus, hopefully, we could actually
> re-use the URI schema registry [or maybe extend it, etc].
> 
> - K
> 

To: [email-masked]
cc: [email-masked] (Michael Demmer), [email-masked] (Jakob Eriksson), [email-masked]
Subject: Re: [dtn-interest] Schema names 
Date: Fri, 08 Apr 2005 00:32:41 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

Just to make sure, I think RFC2396 is required reading
at this point.  It provides some common language we may use for
discussion on names.  Plus, hopefully, we could actually
re-use the URI schema registry [or maybe extend it, etc].

- K

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Schema names
To: [email-masked] (Michael Demmer)
Date: Thu, 7 Apr 2005 20:20:55 -0400 (EDT)
Cc: [email-masked] (Jakob Eriksson), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Mike,

> > I would agree with Scott. It seems to me that all implementations of
> > a given schema should be required to conform both to syntactic and
> > semantic rules specified for that schema. Although correct parsing
> > is the first step, many schemas are doomed to fail unless all nodes
> > operate under the same semantic rules.
> 
> Perhaps. Perhaps not. What's to stop me from using guid's in a
> different way in my DTN network from yours? As long as the places
> where our networks peer with each other do the necessary translation
> so semantics are preserved, then all is kosher, right? NAT boxes in
> effect do this now -- I use 192.168.X.X addresses differently in my
> home network than you do in yours. We're both using the IP address
> schema, though with different semantics.

Syntax transforms while certainly doable, can have unintended side effects 
if they are not semantics-preserving.  If semantics are not specified, then
it is hard to ensure we are semantics-preserving. Semantic specifications 
accompanied with (preferred) syntax IMO is a better way to go.  

NATs do not preserve (end-to-end addressing) semantics.  Nodes behind 
a schema-translator/NAT-equivalent are not directly reachable in the 
network, rather their "registrations" on the schema-translator are.
But my point is not about NATs per se. I do not want to start off 
NAT-good-not-good::proxy-good-not-good chains.

Some consequences of the loss of end-to-end identifier semantics are 
that it complicates diagnostics, and can have some unexpected interactions 
with other network functions (e.g. analogous to NAT-IPsec interactions).  

Mobility of the schema-translator is of potential concern here since the 
schema-translation function must be handed off.  It may be a bigger issue 
for transit networks than for stubs (if the rest of the network must 
black-box-approximate the dynamic transfer function of the translated 
subnetwork for routing purposes).

For now, I suppose we could leave how much semantics to specify up to 
individual schema designers though.  Clearly those not specifying any
semantics can crank it out sooner. :) That's not necessarily bad.  Having 
schema syntaxes may well provide concrete notational contexts to flesh 
out the semantics.

-Rajesh

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] Schema names
Date: Thu, 7 Apr 2005 16:39:05 -0700
To: [email-masked]
Sender: [email-masked]

On Apr 7, 2005, at 3:50 PM, Michael Demmer wrote:

>> I would agree with Scott. It seems to me that all implementations of
>> a given schema should be required to conform both to syntactic and
>> semantic rules specified for that schema. Although correct parsing
>> is the first step, many schemas are doomed to fail unless all nodes
>> operate under the same semantic rules.
>
> Perhaps. Perhaps not. What's to stop me from using guid's in a
> different way in my DTN network from yours? As long as the places
> where our networks peer with each other do the necessary translation
> so semantics are preserved, then all is kosher, right? NAT boxes in
> effect do this now -- I use 192.168.X.X addresses differently in my
> home network than you do in yours. We're both using the IP address
> schema, though with different semantics.

There's also a fairly common impression that NAT boxes, although 
unavoidable at this point, are a great plague haunting the 'net.

While it may seem, on the surface, that functionality and 
interoperability is preserved, it is not. Before the NAT's you 
describe, the semantics of the Internet were that every host has its 
own IP address, and is reachable through that address. With the NAT's, 
it's all of a sudden impossible for the network layer to send a general 
IP packet between my PC (behind my nat), to your PC (behind your nat), 
without adding middle-men.

If it was up to me, I'd much rather have our DTN future be devoid of 
anything remotely resembling what NAT's have become in the Internet 
today.

>> If I understand Mike's argument correctly, he would say that
>> different implementations/deployments might decide to use different
>> semantics for the same schema. I suppose this is a valid
>> argument. However, if they can change the semantics, why not allow
>> deployments to change the syntax as well? In fact, why have a
>> standard at all? ;-)
>
> I take from your emoticon that you aren't really arguing there's no
> place for a syntactic specification that doesn't get bundled (excuse
> the pun) with a full semantic description of a network operation?

Sorry about the confusion. My point was that if we are going to 
standardize schemas, we need to make sure the standards result in 
interoperable implementations. If implementations following a standard 
are not interoperable, then what is the use of the standard in the 
first place?

- Jakob

Date: Thu, 7 Apr 2005 15:50:22 -0700
From: Michael Demmer <[email-masked]>
To: Jakob Eriksson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Schema names
Mail-Followup-To: Jakob Eriksson <[email-masked]>, [email-masked]
Sender: [email-masked]

> I would agree with Scott. It seems to me that all implementations of
> a given schema should be required to conform both to syntactic and
> semantic rules specified for that schema. Although correct parsing
> is the first step, many schemas are doomed to fail unless all nodes
> operate under the same semantic rules.

Perhaps. Perhaps not. What's to stop me from using guid's in a
different way in my DTN network from yours? As long as the places
where our networks peer with each other do the necessary translation
so semantics are preserved, then all is kosher, right? NAT boxes in
effect do this now -- I use 192.168.X.X addresses differently in my
home network than you do in yours. We're both using the IP address
schema, though with different semantics.

I'm not saying we should have a free-for-all for deployments --
clearly somewhere we should have operational semantics described for
different DTN networks. I'm just not yet convinced that the
architecture / protocol level is the right place for these, nor am I
convinced that we know how these networks should even be
operated. Thus my advocacy for schemas as syntax.

> If I understand Mike's argument correctly, he would say that
> different implementations/deployments might decide to use different
> semantics for the same schema. I suppose this is a valid
> argument. However, if they can change the semantics, why not allow
> deployments to change the syntax as well? In fact, why have a
> standard at all? ;-)

I take from your emoticon that you aren't really arguing there's no
place for a syntactic specification that doesn't get bundled (excuse
the pun) with a full semantic description of a network operation?

-m

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] Schema names
Date: Thu, 7 Apr 2005 15:36:36 -0700
To: [email-masked]
Sender: [email-masked]

On Apr 7, 2005, at 2:44 PM, Michael Demmer wrote:

>> Right, let's not overload the schema name at all.  But if you've got
>> the same syntax being used in multiple different ways (multiple
>> semantics) then I think you've got to use multiple schema names if
>> you ever want to have any hope of getting anything to work.
>
> Perhaps. I just want there to be some clear distinction between the
> format specification for the identifier, and the deployment
> characteristics and assumptions of the network.

I would agree with Scott. It seems to me that all implementations of a 
given schema should be required to conform both to syntactic and 
semantic rules specified for that schema. Although correct parsing is 
the first step, many schemas are doomed to fail unless all nodes 
operate under the same semantic rules.

If I understand Mike's argument correctly, he would say that different 
implementations/deployments might decide to use different semantics for 
the same schema. I suppose this is a valid argument. However, if they 
can change the semantics, why not allow deployments to change the 
syntax as well? In fact, why have a standard at all? ;-)

- Jakob

Date: Thu, 7 Apr 2005 14:44:45 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Schema names
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> I agree with what I think is the sense of what Mike is saying here, but not 
> with the exact words.  I think the schema should be whatever set of 
> syntactic *and semantic* rules are needed in order to make sense of the 
> mark.
> 
> For example, I can imagine a weird schema that says (in effect; you'd 
> obviously want to tighten the language!) something like "Interpret 
> everything up to the first ';' character as a phone number.  You connect to 
> the bundle agent by dialing that number and opening a PPP connection for a 
> TCP convergence-layer link.  Everything after the first ';' character is 
> the demux string for delivering the bundle to the application client."
> 
> Okay, this example is probably stupid, but my point is that merely defining 
> the format -- strictly understood as only the syntax, not the semantics -- 
> of the mark is not enough.  The schema definition has to say exactly what 
> each of the tokens in the mark is used for, or else you've got to abandon 
> all hope of multiple interoperable implementations.

That seems ok to me.

> Meanwhile, I think we would do ourselves a favor if the name of each
> schema had some sort of meaningful, mnemonic significance, along the
> lines of Mike's examples.  I definitely don't think the name should
> be some sort of encoding of all of the schema's rules -- it's just a
> label -- but I think brief and easy-to-remember names will simplify
> development and will marginally help us explain this stuff to people
> who aren't involved on a day-to-day basis.

Agreed.

> Right, let's not overload the schema name at all.  But if you've got
> the same syntax being used in multiple different ways (multiple
> semantics) then I think you've got to use multiple schema names if
> you ever want to have any hope of getting anything to work.

Perhaps. I just want there to be some clear distinction between the
format specification for the identifier, and the deployment
characteristics and assumptions of the network.

-m

Date: Thu, 07 Apr 2005 13:24:22 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents
Sender: [email-masked]

Rajesh Krishnan wrote:
> Regarding service mobility/handoff, I was referring to the possibility that
> a node can leave/die but the application instance can live on in another 
> node (if properly handed off). In DTN terms, what gets handed off could be 
> the application registration (including the passive/active status of the 
> application and the delivery failure action), and possibly deferred bundles 
> if any. Other nodes must learn about this service handoff through a protocol, 
> the same way they must learn about a node having moved to a different 
> topological location.

Okay, I think I now understand what you're talking about.  We haven't seen 
a requirement for it yet, as far as I know, but it does sound doable and 
interesting and potentially valuable.  There might not even be any very 
profound architectural impact -- as you say, some companion protocol (maybe 
running between automatic "registration agents") could do the whole thing.

> Services/apps need not be collocated on DTN-forwarding-capable nodes, and
> the apps may need to actively live longer than the DTN nodes they are 
> registed on, or the apps may need to stay physically localized while DTN 
> nodes are required to move.  An unseverable binding between a node and 
> a service/application instance could make service handoff difficult.

Okay, I think this is a good argument against using the 
embedded-demux-token style of endpoint ID where this capability is needed.

> A summary of my preferences submitted for consideration:
> 
>   - names carried unmodified end-to-end on a bundle

I'm for that.

>   - allow syntactic distinctions between nodename, servicename, and groupname(s)
>     (request we do not mandate against this)

I think the schema approach gives us this, as you can always build whatever 
syntax you like into the schema you're defining.

>   - allow persistent bindings of nodenames to nodes across mobility and 
>     reconnection to various networks (request we allow both "MobileIP-style" 
>     and "DHCP-style" address persistence at least for now)

That sounds reasonable, though offhand I don't know how we do it.  I expect 
others among us have already figured this out.

>   - allow loose binding between service name and node name 
>     (request we do not mandate that registrations must stick with 
>      and die with the node)

Right, registration mobility as you describe above.  I agree, let's support it.

Scott

Date: Thu, 07 Apr 2005 12:59:35 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Michael Demmer wrote:
>> I still think it would make everyone's life easier if we did away with
>> reactive fragmentation specifically, but I will happily leave that
>> battle to somebody else.
> 
> 
> Here's a proposal in favor of keeping fragmentation in the bundling 
> layer, both proactive and reactive, that I hope will address the various
> concerns, specifically the security ones.
> 
> The routing layer is the one that has information about the various 
> connection opportunities to peers, perhaps over multiple convergence 
> layers. As such, it is the best place to decide that it should send X% 
> one way and Y% the other way, proactively.  However, there are times in
> which there is just no way to know how long a connection will stay open.
> As Keith put it, someone could start jamming my transmission at any time
> and for any duration. This is the situation which reactive fragmentation
> is geared for.
> 
> Now, suppose we don't do any 'toilet-paper' style stuff for the bundle 
> authentication header. The problem, concisely, is that with only the 
> first fragment, the recieving daemon can't authenticate the bundle, and
> so can't forward it further.
> 
> But it could of course, hold onto the first part until it gets the rest.
> Note that the rest of the bundle could end up arriving over some other
> convergence layer, so we still want reactive fragmentation at the bundle
> layer.

Yes, I think we've discussed this possibility before.  It still seems to me 
that we're talking about a fair amount of work, with (as you point out 
below) no assurance of success, for what strikes me as a corner case.  But 
as you say, where we don't want to do it we can just leave it disabled (in 
my case, unimplemented), so in that sense it does no harm.

> But, this presupposes that it _will_ get the rest at some point, which
> in some networks is not going to be likely.
> 
> So, in those networks where you a) enable bundle security and b) have 
> mobile or dynamic topologies, then don't rely on reactive fragmentation
> to deal with interrupted connections. Disable the feature if you want.
> Or proactively fragment so you can just discard any small bits you
> receive. Whatever you want to do.
> 
> The point is that there's nothing fundamentally incompatible between 
> reactive fragmentation and bundle authentication. I think it's just a 
> question of network design and deployment.

Date: Thu, 07 Apr 2005 12:50:29 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Schema names
Sender: [email-masked]

Michael Demmer wrote:
>>Hmm, I think we have differing views of the schema header.  My
>>thinking was that the schema was for denoting what format the mark
>>is in *and* what kind of dtn network the mark represents.
> 
> 
> I very much disagree here. This is a lot like the convolution of the
> term "region" that caused us trouble in the past. I think all the
> schema should do is define the format of the mark. End of story.

I agree with what I think is the sense of what Mike is saying here, but not 
with the exact words.  I think the schema should be whatever set of 
syntactic *and semantic* rules are needed in order to make sense of the mark.

For example, I can imagine a weird schema that says (in effect; you'd 
obviously want to tighten the language!) something like "Interpret 
everything up to the first ';' character as a phone number.  You connect to 
the bundle agent by dialing that number and opening a PPP connection for a 
TCP convergence-layer link.  Everything after the first ';' character is 
the demux string for delivering the bundle to the application client."

Okay, this example is probably stupid, but my point is that merely defining 
the format -- strictly understood as only the syntax, not the semantics -- 
of the mark is not enough.  The schema definition has to say exactly what 
each of the tokens in the mark is used for, or else you've got to abandon 
all hope of multiple interoperable implementations.

Meanwhile, I think we would do ourselves a favor if the name of each schema 
had some sort of meaningful, mnemonic significance, along the lines of 
Mike's examples.  I definitely don't think the name should be some sort of 
encoding of all of the schema's rules -- it's just a label -- but I think 
brief and easy-to-remember names will simplify development and will 
marginally help us explain this stuff to people who aren't involved on a 
day-to-day basis.

>>I can see many different ways of creating these overlay networks,
>>and I think that's where the schema identifier should come into play
>>by identifying these base assumptions that are being made.
> 
> To put this another way. I can see many different ways of creating
> these overlay networks. Many of which may use the same naming schema
> in different ways. So if we want to talk about some concise
> description of the properties of a network (i.e. uses DNS for lookups,
> XYZ for routing, etc), then let's talk about that. But that shouldn't
> be overloaded into the schema name.

Right, let's not overload the schema name at all.  But if you've got the 
same syntax being used in multiple different ways (multiple semantics) then 
I think you've got to use multiple schema names if you ever want to have 
any hope of getting anything to work.

Scott

Date: Thu, 07 Apr 2005 14:23:30 -0500
From: Matt Bradbury <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Schema names
Sender: [email-masked]

Michael Demmer wrote:

>>I can see many different ways of creating these overlay networks,
>>and I think that's where the schema identifier should come into play
>>by identifying these base assumptions that are being made.
>>    
>>
>
>To put this another way. I can see many different ways of creating
>these overlay networks. Many of which may use the same naming schema
>in different ways. So if we want to talk about some concise
>description of the properties of a network (i.e. uses DNS for lookups,
>XYZ for routing, etc), then let's talk about that. But that shouldn't
>be overloaded into the schema name.
>
>  
>
Ok, where should it go, if two very different routing architectures were 
to use the same schema since they use the same format of endpoint 
identifiers, how do we tell the two apart?

-Matt

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents
To: [email-masked] (Michael Demmer)
Date: Thu, 7 Apr 2005 15:19:09 -0400 (EDT)
Cc: [email-masked] (Rajesh Krishnan), [email-masked] (Scott Burleigh), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

> > I want to be able to use syntax to signal semantic distinctions between 
> > what is a node and a what is a service, what is a unicast desa regis
> > arity of communications.

Oops. I apologize.  I meant to type what is a unicast destination (vs.
other arity of communications).

> Uh -- what is a "unicast desa regis arity of communications" :-)
> 
> -mike
> 

Date: Thu, 7 Apr 2005 11:49:11 -0700
From: Michael Demmer <[email-masked]>
To: Matt Bradbury <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Schema names
Mail-Followup-To: Matt Bradbury <[email-masked]>, [email-masked]
Sender: [email-masked]

> Hmm, I think we have differing views of the schema header.  My
> thinking was that the schema was for denoting what format the mark
> is in *and* what kind of dtn network the mark represents.

I very much disagree here. This is a lot like the convolution of the
term "region" that caused us trouble in the past. I think all the
schema should do is define the format of the mark. End of story.

> Maybe it's the link-local nature of most of the examples, but I keep
> thinking that with DTN we want to mask the underlying layers and
> present a unified network layer on top.

I shouldn't have just used link-layer addresses (though anything else
might have sparked controversy). Bundling may very well provide a
unifying layer of addressing on top of multiple link layer
addresses. That could be done with a guid schema, or your dns-style
names, or whatever. But that's a deployment question, and not an
architectural one. 

> I can see many different ways of creating these overlay networks,
> and I think that's where the schema identifier should come into play
> by identifying these base assumptions that are being made.

To put this another way. I can see many different ways of creating
these overlay networks. Many of which may use the same naming schema
in different ways. So if we want to talk about some concise
description of the properties of a network (i.e. uses DNS for lookups,
XYZ for routing, etc), then let's talk about that. But that shouldn't
be overloaded into the schema name.

> Maybe I just don't like my scheme being summed up as a DNS scheme,
> since DNS would only be used in regions like the internet that have
> an existing DNS architecture, but other regions would have other
> means of doing nexthop lookups.  ie.  routing protocols,
> pre-distributed host files, static routes etc.

And my point is that you're using dns syntax. Not necessarily the DNS
service.

> In the schemas above, how do I connect to another bundling agent by
> just it's ethernet address?  What port/protocol do I use if I'm
> given an ipv4 address?  There's assumptions that lie under these
> schemas that needs to be fleshed out in experimental schemas before
> we promote them to core schemas.

I think these concerns go away if we agree on my definition of what is
a schema :)

> I agree with you, but we need to develop them first, I'm trying to
> get us a framework to start using different schemas today and when
> we get comfortable with a few we'll make them part of the canonical
> set as you put it.  We have to bootstrap some good schemas of our
> own before we can give good guidance to the future.

Isn't that what I said?

-m

Date: Thu, 07 Apr 2005 13:41:10 -0500
From: Matt Bradbury <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Schema names
Sender: [email-masked]

Michael Demmer wrote:

>>I propose that while the schemas are in their experimental stage we
>>use: dtnx1 dtnx2 dtnx3 and so on as the schema names.  I'd rather
>>not pollute the schema namespace too quickly and hopefully this will
>>help avoid that.
>>    
>>
>
>I like the intention behind this idea, however...
>
>  
>
>>When we feel that a schema is stable and not going to disappear, we
>>can allow it to have a freeform identifier.
>>    
>>
>
>I think there are _certain_ things that can be based on existing
>identifier namespaces that will not change and we could, by consensus
>maybe, agree on. Examples such as:
>
>dns:windu.com.in.earth.sol
>ipv4:192.168.10.1
>ether:00:0d:93:ff:fe:2e:f1:90
>int8:0x1b
>int32:0x8f782fa9
>  
>
Hmm, I think we have differing views of the schema header.  My thinking 
was that the schema was for denoting what format the mark is in *and* 
what kind of dtn network the mark represents.  Maybe it's the link-local 
nature of most of the examples, but I keep thinking that with DTN we 
want to mask the underlying layers and present a unified network layer 
on top.  I can see many different ways of creating these overlay 
networks, and I think that's where the schema identifier should come 
into play by identifying these base assumptions that are being made.

Maybe I just don't like my scheme being summed up as a DNS scheme, since 
DNS would only be used in regions like the internet that have an 
existing DNS architecture, but other regions would have other means of 
doing nexthop lookups.  ie.  routing protocols, pre-distributed host 
files, static routes etc.

In the schemas above, how do I connect to another bundling agent by just 
it's ethernet address?  What port/protocol do I use if I'm given an ipv4 
address?  There's assumptions that lie under these schemas that needs to 
be fleshed out in experimental schemas before we promote them to core 
schemas.

>  
>
>>I also don't think we should have a default schema in the bundling
>>spec, we should let some darwinistic forces decide what the
>>common/default schema is.
>>    
>>
>
>I disagree. I think that it's hard to provide guidance to future
>schemas without examples of current ones. Having a canonical set
>will both avoid people reinventing the wheel for people who define
>their own experimental schemas that may be syntactically equivalent.
>  
>
I agree with you, but we need to develop them first, I'm trying to get 
us a framework to start using different schemas today and when we get 
comfortable with a few we'll make them part of the canonical set as you 
put it.  We have to bootstrap some good schemas of our own before we can 
give good guidance to the future.

-Matt

Date: Thu, 7 Apr 2005 10:51:54 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Mail-Followup-To: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Sender: [email-masked]

> I still think it would make everyone's life easier if we did away
> with reactive fragmentation specifically, but I will happily leave
> that battle to somebody else.

Here's a proposal in favor of keeping fragmentation in the bundling
layer, both proactive and reactive, that I hope will address the
various concerns, specifically the security ones.

The routing layer is the one that has information about the various
connection opportunities to peers, perhaps over multiple convergence
layers. As such, it is the best place to decide that it should send X%
one way and Y% the other way, proactively.  However, there are times
in which there is just no way to know how long a connection will stay
open. As Keith put it, someone could start jamming my transmission at
any time and for any duration. This is the situation which reactive
fragmentation is geared for.

Now, suppose we don't do any 'toilet-paper' style stuff for the bundle
authentication header. The problem, concisely, is that with only the
first fragment, the recieving daemon can't authenticate the bundle,
and so can't forward it further.

But it could of course, hold onto the first part until it gets the
rest. Note that the rest of the bundle could end up arriving over some
other convergence layer, so we still want reactive fragmentation at
the bundle layer. But, this presupposes that it _will_ get the rest at
some point, which in some networks is not going to be likely.

So, in those networks where you a) enable bundle security and b) have
mobile or dynamic topologies, then don't rely on reactive
fragmentation to deal with interrupted connections. Disable the
feature if you want. Or proactively fragment so you can just discard
any small bits you receive. Whatever you want to do.

The point is that there's nothing fundamentally incompatible between
reactive fragmentation and bundle authentication. I think it's just a
question of network design and deployment.

-mike

Date: Thu, 7 Apr 2005 10:39:50 -0700
From: Michael Demmer <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents
Mail-Followup-To: Rajesh Krishnan <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> > >   - names carried unmodified end-to-end on a bundle
> > 
> > This seems a little vague. Which particular names are you speaking of?
> 
> I mean Source, Destination, Report-to: names recorded on the bundle header.  
> I mean the destination sees the exact string the source put in.

Ah ok. I agree.

> Yes unless the semantics is clearly specified and commonly
> understood, we can end up with different parts of the network all
> apparently saying the same thing but actually meaning different
> things and cause problems.

But see I think this is a deployment and network design question, not
an architectural one. If I decide to set up my DTN network to peer
with your DTN network, we should certainly make sure that we agree on
how the names are used. And oh by the way, also things like which
routing protocol to use, whether security is enabled, etc, etc.

> I want to be able to use syntax to signal semantic distinctions between 
> what is a node and a what is a service, what is a unicast desa regis
> arity of communications.

Uh -- what is a "unicast desa regis arity of communications" :-)

-mike

Date: Thu, 7 Apr 2005 10:37:04 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> >If we're really concerned about condensing bits, then isn't it true
> >that all we need is a single value for the offset? The length of each
> >string can then be inferred based on differences between the offsets.
> 
> Very ingenious!  Of course that's right, so long as we know there's never 
> any overlap in the strings and no gaps or padding between the string (and 
> we know the total length of the byte array).

In fact, to go one step further, we could define the offset as the
_last_ byte in the string, thereby obviating the need to even know the
total length of the byte array, since implicitly, the start of the
first string is at offset zero.

However, I think we _should_ know the total length because I think
that all headers should have a common prelude that defines their
header type and length, as in Keith's proposal several weeks ago. Is
it time to reopen that discussion?

-m

Date: Thu, 7 Apr 2005 10:34:33 -0700
From: Michael Demmer <[email-masked]>
To: Matt Bradbury <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Schema names
Mail-Followup-To: Matt Bradbury <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> I propose that while the schemas are in their experimental stage we
> use: dtnx1 dtnx2 dtnx3 and so on as the schema names.  I'd rather
> not pollute the schema namespace too quickly and hopefully this will
> help avoid that.

I like the intention behind this idea, however...

> When we feel that a schema is stable and not going to disappear, we
> can allow it to have a freeform identifier.

I think there are _certain_ things that can be based on existing
identifier namespaces that will not change and we could, by consensus
maybe, agree on. Examples such as:

dns:windu.com.in.earth.sol
ipv4:192.168.10.1
ether:00:0d:93:ff:fe:2e:f1:90
int8:0x1b
int32:0x8f782fa9

> I also don't think we should have a default schema in the bundling
> spec, we should let some darwinistic forces decide what the
> common/default schema is.

I disagree. I think that it's hard to provide guidance to future
schemas without examples of current ones. Having a canonical set
will both avoid people reinventing the wheel for people who define
their own experimental schemas that may be syntactically equivalent.

> So for example the endpoint for a region in the hierarchial regions that 
> I've mentioned before would look like:   dtnx21:windu.com.in.earth.sol   
> Assuming it's the 21st experimental schema.
> 
> I'd also like to propose that Demmer's DTN2 implementation get either 
> the dtnx1 or dtnx2 schema since it is the DTN2 software.

Aw shucks :)

> Also, as we're going about writing these different ways of routing and 
> structure of DTN networks, I ask that we try to keep convergence layers 
> re-usable between different schemas.  This will help with re-use and 
> enable new schemas to have a working codebase to build on.

Strongly in agreement.

-m

Date: Thu, 07 Apr 2005 10:26:59 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Sender: [email-masked]

Michael Demmer wrote:
> I generally like the general idea of allowing support for
> prepositioned string tables and think you're right that this is
> generally useful beyond just deep space. I have a couple comments
> inline below.
> 
>>-	We normally concatenate all the strings in a Dictionary header, in a 
>>single array of up to 2048 bytes.
>>
>>-	In the Primary bundle header we forward-reference the strings for 
>>source, destination, report-to, and current custodian by offset/length 
>>pairs.  Each offset (within the Dictionary header's byte array) is a 12-bit 
>>integer and each length is a 12-bit integer, so each string reference in 
>>the Primary bundle header occupies 3 bytes.
> 
> If we're really concerned about condensing bits, then isn't it true
> that all we need is a single value for the offset? The length of each
> string can then be inferred based on differences between the offsets.

Very ingenious!  Of course that's right, so long as we know there's never 
any overlap in the strings and no gaps or padding between the string (and 
we know the total length of the byte array).

>>-	But if the first bit of an offset is 1 (the offset is "negative"), 
>>then the remaining 11 bits of the offset are instead a number identifying 
>>one of 2048 possible naming authorities for pre-catalogued strings, and the 
>>12 bits of the accompanying length are actually a number identifying one of 
>>the 4096 possible strings that have been catalogued by that naming 
>>authority.  In this case, the actual string that is referred to must be 
>>looked up in a (nominally local) table of catalogued strings rather than 
>>extracted from the Dictionary header -- but it is still a string in the 
>>canonical <schema_name>:<mark> form
>>
>>In a bandwidth-rich environment, you carry all the strings in the 
>>Dictionary header much as we do now.  In a bandwidth-constrained 
>>environment, you pre-position your string catalogues and just carry 
>>catalogue numbers in the Primary header; you can omit the Dictionary header 
>>altogether.
> 
> All seems good. Except if we go with the byte-conserving approach I
> described above, we have fewer bytes to play with.

Well, there's that.  I fiddled with different sizes when I was dreaming up 
this idea, and having 24 bits to work with seemed to be a good compromise 
between minimizing bandwidth consumption, maximizing namespace size, and 
preserving simplicity (fixed lengths).  But this is an engineering tradeoff 
that I would be happy to revisit, so long as we don't lose the concept.

>>I propose that we add another optional header -- a Demux header -- that 
>>just carries a next-header type code and three numeric demux tokens 
>>(source, destination, report-to, in that order) in SDNV format:
>>
>>-	For schemas that embed demux token in the mark somehow, the demux 
>>token can be a string of whatever structure you like.  When the source, 
>>destination, and report-to endpoint IDs for a bundle are all encoded in 
>>this sort of schema, or in schemas that don't support demuxing to 
>>application clients at all, the Demux header is simply omitted.
>>
>>-	For schemas that support demuxing to application clients but don't 
>>embed the demux token in the mark, the demux token must be numeric.  If the 
>>source, destination, or report-to endpoint ID for a bundle is encoded in 
>>one of these schemas, the demux token for each such endpoint ID is carried 
>>separately in the corresponding SDNV of the Demux header (and the remaining 
>>SDNVs in the Demux header are set to zero).
>>
>>-	The Primary bundle header remains fixed-length.
> 
> 
> I'm not all that keen on the idea of having two mechanisms to
> accomplish the same goal. In particular, if we are going to support a
> DemuxHeader for some environments, then why have support for embedding
> a demux token in the mark? If we allow the entries in the DemuxHeader
> to be either SDNVs or indices into the DictionaryHeader, then there
> seems to me to be no need to embed the demux strings, other than
> that's how we've been doing it.

It's a little more complex, but giving people the option to omit the Demux 
header (or the Dictionary header; or, conceivably, both in some extreme 
cases) seems to me to be fair and efficient without costing much.  Though 
it is clearly possible to go overboard in offering multiple alternative 
ways to do things, I don't think we've done that yet -- we do have a lot 
very different constituencies (research, near-term ops, space, sensor nets, 
mobile tactical, underwater, reindeer) to try to satisfy concurrently.

Scott

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents
To: [email-masked] (Michael Demmer)
Date: Thu, 7 Apr 2005 13:25:37 -0400 (EDT)
Cc: [email-masked] (Rajesh Krishnan), [email-masked] (Scott Burleigh), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Mike,

> >   - names carried unmodified end-to-end on a bundle
> 
> This seems a little vague. Which particular names are you speaking of?

I mean Source, Destination, Report-to: names recorded on the bundle header.  
I mean the destination sees the exact string the source put in.

> >   - allow syntactic distinctions between nodename, servicename, and
> >   groupname(s) (request we do not mandate against this)
> 
> I think I agree, assuming I correctly understood your second
> statement. To rephrase, a particular naming schema may be used in
> different syntactic contexts, however we're clear in all documentation
> about which context we're using it in. The example is that I could be
> using guids as all three, where the name format is the same in each,
> but how I handle the value is different.

Yes unless the semantics is clearly specified and commonly understood, 
we can end up with different parts of the network all apparently saying 
the same thing but actually meaning different things and cause problems.

I want to be able to use syntax to signal semantic distinctions between 
what is a node and a what is a service, what is a unicast desa regis
arity of communications.

> >   - allow persistent bindings of nodenames to nodes across mobility
> >   and reconnection to various networks (request we allow both
> >   "MobileIP-style" and "DHCP-style" address persistence at least for
> >   now)
> >
> >   - allow loose binding between service name and node name 
> >     (request we do not mandate that registrations must stick with 
> >      and die with the node)
> 
> Sure -- I see no need to restrict how the bindings are handled. It's
> an implementation / deployment question.

Ok.

>  
> -mike

-Rajesh

Date: Thu, 07 Apr 2005 12:13:08 -0500
From: Matt Bradbury <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: [dtn-interest] Schema names
Sender: [email-masked]

Scott Burleigh wrote:

> Scott Burleigh wrote:
>
>> Michael Demmer wrote:
>>
>>>> Would we be willing to constrain these mux/demux tokens to numeric
>>>> values rather than ASCII strings?  
>>>
>>>
>>> Hmm -- maybe we could support both?
>>>
>>>> If they were always numeric then each one could be a self-defining
>>>> numeric value (as in LTP) that could be represented in as little as
>>>> a single byte but could range into the trillions as necessary.  We
>>>> could put three such SDNVs -- source client ID, destination client
>>>> ID, report-to client ID -- at the start of the Dictionary header,
>>>> which is required but is variable-length.  For environments in which
>>>> no muxing/demuxing is necessary, such as sensor networks, you'd only
>>>> waste three bytes per bundle.
>>>
>>>
>>> SDNV is fine with me -- perhaps we should also use them to help
>>> address the bundle length discussion from before.
>>
>
> Something else that came out of my conversation with Keith this morning:
>
> Suppose we go with the proposal to represent the source, destination, 
> report-to, and current custodian endpoint IDs of a bundle as strings 
> of the general form <schema_name>:<mark>, where <mark> is the portion 
> of the string that is constructed, parsed, looked-up, etc. according 
> to the set of syntactic and semantic rules identified by 
> <schema_name>.  [Please let's not have a blizzard of emails arguing 
> over the term "mark".  I just wanted a short name for this thing so I 
> could talk about it, something a little less cumbersome than "the part 
> of the string that is parsed according to the rules corresponding to 
> the schema_name".  Later we can pick a different term that everybody 
> likes better.]
>
This sounds good. 

I propose that while the schemas are in their experimental stage we use: 
dtnx1 dtnx2 dtnx3 and so on  as the schema names.  I'd rather not 
pollute the schema namespace too quickly and hopefully this will help 
avoid that.  When we feel that a schema is stable and not going to 
disappear, we can allow it to have a freeform identifier.  I also don't 
think we should have a default schema in the bundling spec, we should 
let some darwinistic forces decide what the common/default schema is.

So for example the endpoint for a region in the hierarchial regions that 
I've mentioned before would look like:   dtnx21:windu.com.in.earth.sol   
Assuming it's the 21st experimental schema.

I'd also like to propose that Demmer's DTN2 implementation get either 
the dtnx1 or dtnx2 schema since it is the DTN2 software.

Also, as we're going about writing these different ways of routing and 
structure of DTN networks, I ask that we try to keep convergence layers 
re-usable between different schemas.  This will help with re-use and 
enable new schemas to have a working codebase to build on.

-Matt  

-Matt

Date: Thu, 7 Apr 2005 09:58:15 -0700
From: Michael Demmer <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents
Mail-Followup-To: Rajesh Krishnan <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> Regarding service mobility/handoff, I was referring to the
> possibility that a node can leave/die but the application instance
> can live on in another node (if properly handed off). In DTN terms,
> what gets handed off could be the application registration
> (including the passive/active status of the application and the
> delivery failure action), and possibly deferred bundles if
> any. Other nodes must learn about this service handoff through a
> protocol, the same way they must learn about a node having moved to
> a different topological location.

I agree wholeheartedly with the last statement you make. I can
envision an application reconnecting with a new bundle router in some
new topological destination, and essentially making a route
announcement to advertise it's presence. The routing protocol would
then propagate this announcement through the network however it sees
fit. 

The important thing is that this is relatively transparent to _what_
is being announced -- it could be a new bundle router advertising
transit service to some subnetwork, or just an application advertising
one particular endpoint name (itself). The job of routing is to
propagate enough state to make the network "work". I fully acknowledge
that for aggregation reasons we may not want to simply flood
single-endpoint routes throughout the network, but that's up to a
particular deployment.

>   - names carried unmodified end-to-end on a bundle

This seems a little vague. Which particular names are you speaking of?

>   - allow syntactic distinctions between nodename, servicename, and
>   groupname(s) (request we do not mandate against this)

I think I agree, assuming I correctly understood your second
statement. To rephrase, a particular naming schema may be used in
different syntactic contexts, however we're clear in all documentation
about which context we're using it in. The example is that I could be
using guids as all three, where the name format is the same in each,
but how I handle the value is different.

>   - allow persistent bindings of nodenames to nodes across mobility
>   and reconnection to various networks (request we allow both
>   "MobileIP-style" and "DHCP-style" address persistence at least for
>   now)
>
>   - allow loose binding between service name and node name 
>     (request we do not mandate that registrations must stick with 
>      and die with the node)

Sure -- I see no need to restrict how the bindings are handled. It's
an implementation / deployment question.
 
-mike

Date: Thu, 7 Apr 2005 09:51:17 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

I generally like the general idea of allowing support for
prepositioned string tables and think you're right that this is
generally useful beyond just deep space. I have a couple comments
inline below.

> -	We normally concatenate all the strings in a Dictionary header, in a 
> single array of up to 2048 bytes.
> 
> -	In the Primary bundle header we forward-reference the strings for 
> source, destination, report-to, and current custodian by offset/length 
> pairs.  Each offset (within the Dictionary header's byte array) is a 12-bit 
> integer and each length is a 12-bit integer, so each string reference in 
> the Primary bundle header occupies 3 bytes.

If we're really concerned about condensing bits, then isn't it true
that all we need is a single value for the offset? The length of each
string can then be inferred based on differences between the offsets.

> -	But if the first bit of an offset is 1 (the offset is "negative"), 
> then the remaining 11 bits of the offset are instead a number identifying 
> one of 2048 possible naming authorities for pre-catalogued strings, and the 
> 12 bits of the accompanying length are actually a number identifying one of 
> the 4096 possible strings that have been catalogued by that naming 
> authority.  In this case, the actual string that is referred to must be 
> looked up in a (nominally local) table of catalogued strings rather than 
> extracted from the Dictionary header -- but it is still a string in the 
> canonical <schema_name>:<mark> form
>
> In a bandwidth-rich environment, you carry all the strings in the 
> Dictionary header much as we do now.  In a bandwidth-constrained 
> environment, you pre-position your string catalogues and just carry 
> catalogue numbers in the Primary header; you can omit the Dictionary header 
> altogether.

All seems good. Except if we go with the byte-conserving approach I
described above, we have fewer bytes to play with.

> I propose that we add another optional header -- a Demux header -- that 
> just carries a next-header type code and three numeric demux tokens 
> (source, destination, report-to, in that order) in SDNV format:
> 
> -	For schemas that embed demux token in the mark somehow, the demux 
> token can be a string of whatever structure you like.  When the source, 
> destination, and report-to endpoint IDs for a bundle are all encoded in 
> this sort of schema, or in schemas that don't support demuxing to 
> application clients at all, the Demux header is simply omitted.
> 
> -	For schemas that support demuxing to application clients but don't 
> embed the demux token in the mark, the demux token must be numeric.  If the 
> source, destination, or report-to endpoint ID for a bundle is encoded in 
> one of these schemas, the demux token for each such endpoint ID is carried 
> separately in the corresponding SDNV of the Demux header (and the remaining 
> SDNVs in the Demux header are set to zero).
> 
> -	The Primary bundle header remains fixed-length.

I'm not all that keen on the idea of having two mechanisms to
accomplish the same goal. In particular, if we are going to support a
DemuxHeader for some environments, then why have support for embedding
a demux token in the mark? If we allow the entries in the DemuxHeader
to be either SDNVs or indices into the DictionaryHeader, then there
seems to me to be no need to embed the demux strings, other than
that's how we've been doing it.

-m

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents
To: [email-masked] (Scott Burleigh)
Date: Thu, 7 Apr 2005 12:24:59 -0400 (EDT)
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Scott,

The plan to have a simple schema mandated (with others optional) sounds 
good.  I agree with your assessments.  

I agree that rewriting bundle destination names en route will be a security 
(and possibly diagnostics) nightmare.  This is an architectural issue.

Regarding service mobility/handoff, I was referring to the possibility that
a node can leave/die but the application instance can live on in another 
node (if properly handed off). In DTN terms, what gets handed off could be 
the application registration (including the passive/active status of the 
application and the delivery failure action), and possibly deferred bundles 
if any. Other nodes must learn about this service handoff through a protocol, 
the same way they must learn about a node having moved to a different 
topological location.

Services/apps need not be collocated on DTN-forwarding-capable nodes, and
the apps may need to actively live longer than the DTN nodes they are 
registed on, or the apps may need to stay physically localized while DTN 
nodes are required to move.  An unseverable binding between a node and 
a service/application instance could make service handoff difficult. 

A summary of my preferences submitted for consideration:

  - names carried unmodified end-to-end on a bundle

  - allow syntactic distinctions between nodename, servicename, and groupname(s)
    (request we do not mandate against this)

  - allow persistent bindings of nodenames to nodes across mobility and 
    reconnection to various networks (request we allow both "MobileIP-style" 
    and "DHCP-style" address persistence at least for now)

  - allow loose binding between service name and node name 
    (request we do not mandate that registrations must stick with 
     and die with the node)

Best Regards,
Rajesh

> > I think schema:mark is so wide open that no one can quite complain about
> > its expressiveness.
> > 
> > I am concerned about how many schemas would a typical DTN node need to
> > know in practice to have enough (interoper)ability (despite your 
> > assurance in this regard) to make end-to-end "sense" of a name.  Will we
> > mandate a non-empty subset?  Will we mandate this subset only for nodes
> > designated as schema gateways?
> 
> I agree that this is a built-in peril of this kind of approach; with great
> power comes great danger.  I would propose that we start with a single
> *extremely simple* schema -- on the order of your "[email-masked]" -- that is
> documented in the Bundling spec itself and for which support is mandatory,
> and let other schemas and interoperation profiles emerge over time in
> additional RFCs.  Let's let people start experimenting right away, but with
> the recognition that nobody else is guaranteed to understand their
> experimental schemas any time soon, and in the meantime let's let other 
> work move ahead using the dead-simple standard schema.
>
> > Can names ever be rewritten en route (remapped from one schema to 
> > another)? Please confirm.
> 
> I would guess it would be a security nightmare, but that's not my area of
> expertise.
>
> Certainly an application-layer proxy could do this in any case.  If you
> really wanted, you could have some sort of application-level 
> store-and-forward protocol (like CFDP store-and-forward overlay [just
> kidding!]) that tunnels through Bundling, and nothing we built into the DTN
> architecture could prevent it.
> 
> Doing this inside Bundling itself makes me nervous, though.
> 
> > Fundamental architectural issues for DTN names seems to be related to 
> > trying to get the name do at once the job of a nodename, an address 
> > (i.e. topological location in network for routing purposes), and a 
> > service.  Given there is no separate addressing, a good understanding 
> > will not emerge until a few multi-domain routing, naming, location 
> > management, and service discovery architectures are worked out.
> 
> I think that's right.  My preference would be for a system that looks more
> Internet-like, but that's because I'm not really research-oriented.  I look
> forward to seeing what people come up with.
> 
> > My feeling is that since we have to route on names, useful schemas will
> >  end up encoding topological significance into the name.
> 
> Some certainly will, but I'll bet not all.
> 
> > Also service names will more likely than not end up as appendages to
> > node names for reasons of routing convenience.  (Using your terms, the
> > demux token will be embedded in the mark).
> 
> Though I'm trying to keep an open mind, I'm not persuaded that this will 
> really make routing more convenient.
> 
> > For now, schema:mark may be a good enough starting point, but do you see
> > schemas being specified/standardized later.
> 
> I think at least one has got to be standardized right away, with others to 
> follow as they mature.
> 
> > As a group, when we are thinking about schemas, we ought to consider 
> > which semantics we will encode into them:
> > 
> > * will we make syntactic and semantic distinctions in our schemas
> > between
> > 
> > - node name (ideally an end-to-end name independent of services,
> > interfaces, ports, and currently attached network type)
> > 
> > - service name (ideally an end-to-end token that explicitly binds to one
> > or more node names with non-local visibility and to a port name with
> > local visibility; if service name is a demux token appended to a node
> > name, then service mobility will require a name change)
> > 
> > - interface name (has local significance limited to DTN adjacencies /
> > convergence layers)
> > 
> > - port name (has DTN node local significance for demux; a node delivers
> > a bundle locally if it has the named service bound to a local port)
> > 
> > - other things such as network/MAC addresses, physical locations (also
> > of local significance)
> 
> I don't yet fully follow what you're saying about service name, but in 
> general I expect the rules in a schema will have to say how to denote or 
> connote all of these things, one way or another.
> 
> > * I have seen the type of network (sensors vs. MANETS vs. Internet) and
> > physical location (earth/mars) being discussed as means to drive
> > schemas, but does this mean then that if a node leaves one network and
> > joins another, its name (schema and/or mark) may have to change.
> 
> I don't think so; I would hope we'd be able to handle this kind of thing 
> with routing table entries.  But it's very hard to say without considering 
> a specific, concrete case and walking through it in detail.  We need to do 
> that, probably in a face-to-face meeting, though I don't think it's 
> critically urgent.
>
> > Also, will it have multiple names when it is on multiple networks?
> 
> Maybe.  Again, I think the idea of each bundle agent having multiple 
> aliases for its one true name gives us a lot of power at very little cost.
> 
> > How do nodes acquire a name? If dynamically, then does the name change
> > when a node disconnects, moves, and then reconnects?
> 
> I think a node acquires a name when (or as) one or more routing protocols 
> propagate that name (and relevant associated routing information) to every 
> node that's likely to talk to it.
> 
> If by "moving" we mean that the node changes its topological location in 
> the network, then again I'd hope that the relevant routing protocols would 
> simply update everybody's routing information somehow -- the node wouldn't 
> have to acquire a new name.

> If by "moving" we mean something else, then I'd need to know what that was 
> before having any thoughts on what it would imply.  I can't think offhand 
> of any other sense in which a node can "move".
> 
> > * does the schema support aggregation and efficient exceptions to the 
> > aggregate to support network reorganization, node and subnetwork 
> > mobility
> 
> I expect some will and some (ones that are aimed at distributed hash 
> tables, for instance) will not.
> 
> > * will we take into account arity of the communication or the arity of 
> > the service binding to nodes in our schemas
> > 
> > - groupname: multicast/distribution-list, anycast, ...
> > 
> > (note: the earlier region concept had a very strong anycast flavor in 
> > the sense that we could deliver a bundle to any node in the region)
> 
> Okay, at this point I am even further out of my depth than usual.  Does 
> somebody else have a good answer?
> 
> > * will the schema take into account service mobility/handoff from one
> > node to another
> 
> I might have an opinion on this, but I'd need a better understanding of 
> just what we're handing off.

> > * does the schema allow for global uniqueness of the name?
> 
> I think that each individual <schema_name>:<mark> will have to be globally 
> unique; otherwise you get routing ambiguity.  [Which is not to say that it 
> will have to be one-for-one with bundle agents -- you could still have 
> anycast.]
> 
> > Perhaps some architectural considerations/guidelines for what a schema 
> > ought to encode belongs in the architecture document.
> 
> Yes, I think that's right.
> 
> > -Rajesh (who hopes eventually for [email-masked] schema clarity for the
> > name instead of mutiple hop!hop!hop schemas :)
> 
> Well, I am of course inclined to agree, but let's let a thousand flowers bloom.
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Thu, 07 Apr 2005 11:39:34 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: Howard Weiss <[email-masked]>, Jakob Eriksson <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
Sender: [email-masked]

Rajesh,

Rajesh Krishnan wrote:

> Hi Stephen,
> 
> As you say, it really comes down to assessing 
> 
>  1. the cost of carrying and processing hint headers in the network, and 
>  2. the cost of accessing trust information for authenticating the hint
>     providers.

Agreed. And as soon as we've some concrete proposals documented,
we can start to make that assessment. I guess such a proposal
will fall out of the recent discussion at some point (probably
without the security primitives though:-)

> Such an assessment should take into account the benefits in proposed use 
> cases for resolution/location/forwarding hints. 

Agreed again.

Stephen.

Date: Wed, 06 Apr 2005 21:09:59 -0700
From: Melissa Ho <[email-masked]>
To: Sushant Jain <[email-masked]>
CC: [email-masked], Kevin Fall <[email-masked]>, Yong Wang <[email-masked]>, Srinivasan Keshav <[email-masked]>, Michael Demmer <[email-masked]>, Arun Agrahara Somasundara <[email-masked]>, dtn-interest <[email-masked]>
Subject: [dtn-interest] Re: wdtn deadline
Sender: [email-masked]

There's been some confusion with the WDTN deadline. I'm waiting for 
Keshav to confirm...

The submission site is set for midnight Eastern Time, but dtnrg.org (and 
the announcement on dtn-interest) said 11.59pm Pacific.

Keshav? Kevin?

Melissa

Sushant Jain wrote:

>hey guys
>
>looks like there is some confusion on when is the  wdtn deadline ...
>as in 9pm PST or 12pm PST...
>
>anyone with a better idea please let us know,
>
>thanks,
>sushant
>
>  
>

Date: Wed, 06 Apr 2005 20:23:56 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE
Sender: [email-masked]

Rajesh Krishnan wrote:
> Scott,
> 
> I think schema:mark is so wide open that no one can quite complain about
> its expressiveness.
> 
> I am concerned about how many schemas would a typical DTN node need to
> know in practice to have enough (interoper)ability (despite your 
> assurance in this regard) to make end-to-end "sense" of a name.  Will we
> mandate a non-empty subset?  Will we mandate this subset only for nodes
> designated as schema gateways?

I agree that this is a built-in peril of this kind of approach; with great
power comes great danger.  I would propose that we start with a single
*extremely simple* schema -- on the order of your "[email-masked]" -- that is
documented in the Bundling spec itself and for which support is mandatory,
and let other schemas and interoperation profiles emerge over time in
additional RFCs.  Let's let people start experimenting right away, but with
the recognition that nobody else is guaranteed to understand their
experimental schemas any time soon, and in the meantime let's let other 
work move ahead using the dead-simple standard schema.

> Can names ever be rewritten en route (remapped from one schema to 
> another)? Please confirm.

I would guess it would be a security nightmare, but that's not my area of
expertise.

Certainly an application-layer proxy could do this in any case.  If you
really wanted, you could have some sort of application-level 
store-and-forward protocol (like CFDP store-and-forward overlay [just
kidding!]) that tunnels through Bundling, and nothing we built into the DTN
architecture could prevent it.

Doing this inside Bundling itself makes me nervous, though.

> Fundamental architectural issues for DTN names seems to be related to 
> trying to get the name do at once the job of a nodename, an address 
> (i.e. topological location in network for routing purposes), and a 
> service.  Given there is no separate addressing, a good understanding 
> will not emerge until a few multi-domain routing, naming, location 
> management, and service discovery architectures are worked out.

I think that's right.  My preference would be for a system that looks more
Internet-like, but that's because I'm not really research-oriented.  I look
forward to seeing what people come up with.

> My feeling is that since we have to route on names, useful schemas will
>  end up encoding topological significance into the name.

Some certainly will, but I'll bet not all.

> Also service names will more likely than not end up as appendages to
> node names for reasons of routing convenience.  (Using your terms, the
> demux token will be embedded in the mark).

Though I'm trying to keep an open mind, I'm not persuaded that this will 
really make routing more convenient.

> For now, schema:mark may be a good enough starting point, but do you see
> schemas being specified/standardized later.

I think at least one has got to be standardized right away, with others to 
follow as they mature.

> As a group, when we are thinking about schemas, we ought to consider 
> which semantics we will encode into them:
> 
> * will we make syntactic and semantic distinctions in our schemas
> between
> 
> - node name (ideally an end-to-end name independent of services,
> interfaces, ports, and currently attached network type)
> 
> - service name (ideally an end-to-end token that explicitly binds to one
> or more node names with non-local visibility and to a port name with
> local visibility; if service name is a demux token appended to a node
> name, then service mobility will require a name change)
> 
> - interface name (has local significance limited to DTN adjacencies /
> convergence layers)
> 
> - port name (has DTN node local significance for demux; a node delivers
> a bundle locally if it has the named service bound to a local port)
> 
> - other things such as network/MAC addresses, physical locations (also
> of local significance)

I don't yet fully follow what you're saying about service name, but in 
general I expect the rules in a schema will have to say how to denote or 
connote all of these things, one way or another.

> * I have seen the type of network (sensors vs. MANETS vs. Internet) and
> physical location (earth/mars) being discussed as means to drive
> schemas, but does this mean then that if a node leaves one network and
> joins another, its name (schema and/or mark) may have to change.

I don't think so; I would hope we'd be able to handle this kind of thing 
with routing table entries.  But it's very hard to say without considering 
a specific, concrete case and walking through it in detail.  We need to do 
that, probably in a face-to-face meeting, though I don't think it's 
critically urgent.

> Also, will it have multiple names when it is on multiple networks?

Maybe.  Again, I think the idea of each bundle agent having multiple 
aliases for its one true name gives us a lot of power at very little cost.

> How do nodes acquire a name? If dynamically, then does the name change
> when a node disconnects, moves, and then reconnects?

I think a node acquires a name when (or as) one or more routing protocols 
propagate that name (and relevant associated routing information) to every 
node that's likely to talk to it.

If by "moving" we mean that the node changes its topological location in 
the network, then again I'd hope that the relevant routing protocols would 
simply update everybody's routing information somehow -- the node wouldn't 
have to acquire a new name.

If by "moving" we mean something else, then I'd need to know what that was 
before having any thoughts on what it would imply.  I can't think offhand 
of any other sense in which a node can "move".

> * does the schema support aggregation and efficient exceptions to the 
> aggregate to support network reorganization, node and subnetwork 
> mobility

I expect some will and some (ones that are aimed at distributed hash 
tables, for instance) will not.

> * will we take into account arity of the communication or the arity of 
> the service binding to nodes in our schemas
> 
> - groupname: multicast/distribution-list, anycast, ...
> 
> (note: the earlier region concept had a very strong anycast flavor in 
> the sense that we could deliver a bundle to any node in the region)

Okay, at this point I am even further out of my depth than usual.  Does 
somebody else have a good answer?

> * will the schema take into account service mobility/handoff from one
> node to another

I might have an opinion on this, but I'd need a better understanding of 
just what we're handing off.

> * does the schema allow for global uniqueness of the name?

I think that each individual <schema_name>:<mark> will have to be globally 
unique; otherwise you get routing ambiguity.  [Which is not to say that it 
will have to be one-for-one with bundle agents -- you could still have 
anycast.]

> Perhaps some architectural considerations/guidelines for what a schema 
> ought to encode belongs in the architecture document.

Yes, I think that's right.

> -Rajesh (who hopes eventually for [email-masked] schema clarity for the
> name instead of mutiple hop!hop!hop schemas :)

Well, I am of course inclined to agree, but let's let a thousand flowers bloom.

Scott

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE
To: [email-masked] (Scott Burleigh)
Date: Wed, 6 Apr 2005 21:20:53 -0400 (EDT)
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Scott,

I think schema:mark is so wide open that no one can quite complain
about its expressiveness.

I am concerned about how many schemas would a typical DTN node need 
to know in practice to have enough (interoper)ability (despite your
assurance in this regard) to make end-to-end "sense" of a name.  Will 
we mandate a non-empty subset?  Will we mandate this subset only for 
nodes designated as schema gateways?  

Can names ever be rewritten en route (remapped from one schema to
another)? Please confirm.

Fundamental architectural issues for DTN names seems to be related to 
trying to get the name do at once the job of a nodename, an address 
(i.e. topological location in network for routing purposes), and a 
service.  Given there is no separate addressing, a good understanding 
will not emerge until a few multi-domain routing, naming, location
management, and service discovery architectures are worked out. My
feeling is that since we have to route on names, useful schemas will 
end up encoding topological significance into the name.  Also service 
names will more likely than not end up as appendages to node names for 
reasons of routing convenience.  (Using your terms, the demux token
will be embedded in the mark).

For now, schema:mark may be a good enough starting point, but do you 
see schemas being specified/standardized later.

As a group, when we are thinking about schemas, we ought to consider 
which semantics we will encode into them:

 * will we make syntactic and semantic distinctions in our schemas between

   - node name      
     (ideally an end-to-end name independent of services, interfaces, 
      ports, and currently attached network type)

   - service name   
     (ideally an end-to-end token that explicitly binds to one or more 
      node names with non-local visibility and to a port name with local 
      visibility; if service name is a demux token appended to a node name, 
      then service mobility will require a name change)

   - interface name 
     (has local significance limited to DTN adjacencies / convergence layers)

   - port name 
     (has DTN node local significance for demux; a node delivers a bundle 
      locally if it has the named service bound to a local port)

   - other things such as network/MAC addresses, physical locations
     (also of local significance)

 * I have seen the type of network (sensors vs. MANETS vs. Internet)
   and physical location (erath/mars) being discussed as means to 
   drive schemas, but does this mean then that if a node leaves one
   network and joins another, it's name (schema and/or mark) may
   have to change.  Also, will it have multiple names when it is 
   on multiple networks? 

   How do nodes acquire a name? If dynamically, then does the name 
   change when a node disconnects, moves, and then reconnects?

 * does the schema support aggregation and efficient exceptions to the 
   aggregate to support network reorganization, node and subnetwork
   mobility
 
 * will we take into account arity of the communication or the arity of 
   the service binding to nodes in our schemas

   - groupname: multicast/distribution-list, anycast, ...

   (note: the earlier region concept had a very strong anycast flavor in
    the sense that we could deliver a bundle to any node in the region)

 * will the schema take into account service mobility/handoff from one node 
   to another

 * does the schema allow for global uniqueness of the name?

Perhaps some architectural considerations/guidelines for what a schema 
ought to encode belongs in the architecture document. 

-Rajesh 
(who hopes eventually for [email-masked] schema clarity for the name
 instead of mutiple hop!hop!hop schemas :)

> Scott Burleigh wrote:
> > Michael Demmer wrote:
> > 
> >>> Would we be willing to constrain these mux/demux tokens to numeric
> >>> values rather than ASCII strings?  
> >>
> >> Hmm -- maybe we could support both? 
> >>
> >>> If they were always numeric then each one could be a self-defining
> >>> numeric value (as in LTP) that could be represented in as little as
> >>> a single byte but could range into the trillions as necessary.  We
> >>> could put three such SDNVs -- source client ID, destination client
> >>> ID, report-to client ID -- at the start of the Dictionary header,
> >>> which is required but is variable-length.  For environments in which
> >>> no muxing/demuxing is necessary, such as sensor networks, you'd only
> >>> waste three bytes per bundle.
> >>
> >> SDNV is fine with me -- perhaps we should also use them to help
> >> address the bundle length discussion from before.
> 
> Something else that came out of my conversation with Keith this morning:
> 
> Suppose we go with the proposal to represent the source, destination, report-to, and current custodian endpoint IDs of a bundle as strings of the general form <schema_name>:<mark>, where <mark> is the portion of the string that is constructed, parsed, looked-up, etc. according to the set of syntactic and semantic rules identified by <schema_name>.  [Please let's not have a blizzard of emails arguing over the term "mark".  I just wanted a short name for this thing so I could talk about it, something a little less cumbersome than "the part of the string that is parsed according to the rules corresponding to the schema_name".  Later we can pick a different term that everybody likes better.]
> 
> For some environments (like deep space, but possibly others as well), I think we'll need to be able to abbreviate these representations radically, to minimize header overhead.  The header structure proposal from my March 18 email aims to do that.  Basically:
> 
> -	We normally concatenate all the strings in a Dictionary header, in a single array of up to 2048 bytes.
> 
> -	In the Primary bundle header we forward-reference the strings for source, destination, report-to, and current custodian by offset/length pairs.  Each offset (within the Dictionary header's byte array) is a 12-bit integer and each length is a 12-bit integer, so each string reference in the Primary bundle header occupies 3 bytes.
> 
> -	But if the first bit of an offset is 1 (the offset is "negative"), then the remaining 11 bits of the offset are instead a number identifying one of 2048 possible naming authorities for pre-catalogued strings, and the 12 bits of the accompanying length are actually a number identifying one of the 4096 possible strings that have been catalogued by that naming authority.  In this case, the actual string that is referred to must be looked up in a (nominally local) table of catalogued strings rather than extracted from the Dictionary header -- but it is still a string in the canonical <schema_name>:<mark> form.
> 
> In a bandwidth-rich environment, you carry all the strings in the Dictionary header much as we do now.  In a bandwidth-constrained environment, you pre-position your string catalogues and just carry catalogue numbers in the Primary header; you can omit the Dictionary header altogether.
> 
> [Yes, when communicating between one endpoint in a bandwidth-rich environment (A) and another in an environment that's bandwidth poor (B), you have a combination: the bundle carries the (A) endpoint ID in the Dictionary header and carries the (B) endpoint ID only as a catalogue number in the Primary header.  In that case some subset of bundle agents in (A) need the catalogue entries that the (B) bundle agents use; this is obviously an interoperability issue, just as distributing knowledge about the various schemas is an interoperability issue.  If worse comes to worst, we need gateways that mediate between the two types of environment, but I think simply distributing the catalogue entries is easier and safer.  Something to discuss later.]
> 
> As Keith points out, some schemas may be designed in such a way that the application delivery point -- "demux token", "client ID" (for environments in which you have these things and do need to mux/demux among multiple application clients) -- is encoded into or implicit in the mark itself.  When this is true, the endpoint ID for a source, destination, or report-to isn't merely the ID of a bundle agent (the endpoint of the Bundling protocol) but is instead a combination routing token and demux token (the endpoint of the application-layer protocol).  I think this is fine.  I figure we can still call it "endpoint ID", the rule being that the endpoint ID plus relevant context is always enough to get the bundle to the destination bundle agent -- and it may be enough to get the bundle to the application client as well.
> 
> But if this were the only way to encode demux tokens in a bundle header then there would be a problem for bandwidth-poor environments: because all usable endpoint IDs would be in the catalogue rather than the Dictionary header, and because the number of catalogue entries is limited, encoding the demux token within the mark would severely limit not just the number of bundle agents but the number of application clients.
> 
> I'd like to provide an alternative mechanism for encoding demux tokens, for use when you've got a schema that doesn't embed demux tokens in the mark.  I won't try to argue that this is "cleaner" because it separates the two functionally different tokens into two representations (though I happen to believe that this is true), and I won't try to argue that it should be the "normal" mechanism and that the other approach is "special".  But I do think we need it in order to make DTN palatable in these bandwidth-constrained application environments.
> 
> At the same time, just as I don't think constrained environments should be forced to carry a lot of header overhead that supports features that only rich environments will use, I wouldn't want rich environments to carry a lot of header overhead that supports features that are useful only in the constrained environments.
> 
> I propose that we add another optional header -- a Demux header -- that just carries a next-header type code and three numeric demux tokens (source, destination, report-to, in that order) in SDNV format:
> 
> -	For schemas that embed demux token in the mark somehow, the demux token can be a string of whatever structure you like.  When the source, destination, and report-to endpoint IDs for a bundle are all encoded in this sort of schema, or in schemas that don't support demuxing to application clients at all, the Demux header is simply omitted.
> 
> -	For schemas that support demuxing to application clients but don't embed the demux token in the mark, the demux token must be numeric.  If the source, destination, or report-to endpoint ID for a bundle is encoded in one of these schemas, the demux token for each such endpoint ID is carried separately in the corresponding SDNV of the Demux header (and the remaining SDNVs in the Demux header are set to zero).
> 
> -	The Primary bundle header remains fixed-length.
> 
> I know this sounds a bit complex; I think it's actually easier to code than to describe.  But I believe it gives all of us the features we need for the environments that matter to us, with a lot of flexibility and no very huge impediments to interoperability, without imposing much unnecessary overhead.
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Wed, 06 Apr 2005 14:16:42 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Demux tokens (was Re: Comments on DTNRG documents from BBN SPINDLE project)
Sender: [email-masked]

Scott Burleigh wrote:
> Michael Demmer wrote:
> 
>>> Would we be willing to constrain these mux/demux tokens to numeric
>>> values rather than ASCII strings?  
>>
>> Hmm -- maybe we could support both? 
>>
>>> If they were always numeric then each one could be a self-defining
>>> numeric value (as in LTP) that could be represented in as little as
>>> a single byte but could range into the trillions as necessary.  We
>>> could put three such SDNVs -- source client ID, destination client
>>> ID, report-to client ID -- at the start of the Dictionary header,
>>> which is required but is variable-length.  For environments in which
>>> no muxing/demuxing is necessary, such as sensor networks, you'd only
>>> waste three bytes per bundle.
>>
>> SDNV is fine with me -- perhaps we should also use them to help
>> address the bundle length discussion from before.

Something else that came out of my conversation with Keith this morning:

Suppose we go with the proposal to represent the source, destination, report-to, and current custodian endpoint IDs of a bundle as strings of the general form <schema_name>:<mark>, where <mark> is the portion of the string that is constructed, parsed, looked-up, etc. according to the set of syntactic and semantic rules identified by <schema_name>.  [Please let's not have a blizzard of emails arguing over the term "mark".  I just wanted a short name for this thing so I could talk about it, something a little less cumbersome than "the part of the string that is parsed according to the rules corresponding to the schema_name".  Later we can pick a different term that everybody likes better.]

For some environments (like deep space, but possibly others as well), I think we'll need to be able to abbreviate these representations radically, to minimize header overhead.  The header structure proposal from my March 18 email aims to do that.  Basically:

-	We normally concatenate all the strings in a Dictionary header, in a single array of up to 2048 bytes.

-	In the Primary bundle header we forward-reference the strings for source, destination, report-to, and current custodian by offset/length pairs.  Each offset (within the Dictionary header's byte array) is a 12-bit integer and each length is a 12-bit integer, so each string reference in the Primary bundle header occupies 3 bytes.

-	But if the first bit of an offset is 1 (the offset is "negative"), then the remaining 11 bits of the offset are instead a number identifying one of 2048 possible naming authorities for pre-catalogued strings, and the 12 bits of the accompanying length are actually a number identifying one of the 4096 possible strings that have been catalogued by that naming authority.  In this case, the actual string that is referred to must be looked up in a (nominally local) table of catalogued strings rather than extracted from the Dictionary header -- but it is still a string in the canonical <schema_name>:<mark> form.

In a bandwidth-rich environment, you carry all the strings in the Dictionary header much as we do now.  In a bandwidth-constrained environment, you pre-position your string catalogues and just carry catalogue numbers in the Primary header; you can omit the Dictionary header altogether.

[Yes, when communicating between one endpoint in a bandwidth-rich environment (A) and another in an environment that's bandwidth poor (B), you have a combination: the bundle carries the (A) endpoint ID in the Dictionary header and carries the (B) endpoint ID only as a catalogue number in the Primary header.  In that case some subset of bundle agents in (A) need the catalogue entries that the (B) bundle agents use; this is obviously an interoperability issue, just as distributing knowledge about the various schemas is an interoperability issue.  If worse comes to worst, we need gateways that mediate between the two types of environment, but I think simply distributing the catalogue entries is easier and safer.  Something to discuss later.]

As Keith points out, some schemas may be designed in such a way that the application delivery point -- "demux token", "client ID" (for environments in which you have these things and do need to mux/demux among multiple application clients) -- is encoded into or implicit in the mark itself.  When this is true, the endpoint ID for a source, destination, or report-to isn't merely the ID of a bundle agent (the endpoint of the Bundling protocol) but is instead a combination routing token and demux token (the endpoint of the application-layer protocol).  I think this is fine.  I figure we can still call it "endpoint ID", the rule being that the endpoint ID plus relevant context is always enough to get the bundle to the destination bundle agent -- and it may be enough to get the bundle to the application client as well.

But if this were the only way to encode demux tokens in a bundle header then there would be a problem for bandwidth-poor environments: because all usable endpoint IDs would be in the catalogue rather than the Dictionary header, and because the number of catalogue entries is limited, encoding the demux token within the mark would severely limit not just the number of bundle agents but the number of application clients.

I'd like to provide an alternative mechanism for encoding demux tokens, for use when you've got a schema that doesn't embed demux tokens in the mark.  I won't try to argue that this is "cleaner" because it separates the two functionally different tokens into two representations (though I happen to believe that this is true), and I won't try to argue that it should be the "normal" mechanism and that the other approach is "special".  But I do think we need it in order to make DTN palatable in these bandwidth-constrained application environments.

At the same time, just as I don't think constrained environments should be forced to carry a lot of header overhead that supports features that only rich environments will use, I wouldn't want rich environments to carry a lot of header overhead that supports features that are useful only in the constrained environments.

I propose that we add another optional header -- a Demux header -- that just carries a next-header type code and three numeric demux tokens (source, destination, report-to, in that order) in SDNV format:

-	For schemas that embed demux token in the mark somehow, the demux token can be a string of whatever structure you like.  When the source, destination, and report-to endpoint IDs for a bundle are all encoded in this sort of schema, or in schemas that don't support demuxing to application clients at all, the Demux header is simply omitted.

-	For schemas that support demuxing to application clients but don't embed the demux token in the mark, the demux token must be numeric.  If the source, destination, or report-to endpoint ID for a bundle is encoded in one of these schemas, the demux token for each such endpoint ID is carried separately in the corresponding SDNV of the Demux header (and the remaining SDNVs in the Demux header are set to zero).

-	The Primary bundle header remains fixed-length.

I know this sounds a bit complex; I think it's actually easier to code than to describe.  But I believe it gives all of us the features we need for the environments that matter to us, with a lot of flexibility and no very huge impediments to interoperability, without imposing much unnecessary overhead.

Scott

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
To: [email-masked] (Stephen Farrell)
Date: Wed, 6 Apr 2005 15:04:08 -0400 (EDT)
Cc: [email-masked], [email-masked] (Howard Weiss), [email-masked] (Jakob Eriksson), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Hi Stephen,

As you say, it really comes down to assessing 

 1. the cost of carrying and processing hint headers in the network, and 
 2. the cost of accessing trust information for authenticating the hint
    providers.

Such an assessment should take into account the benefits in proposed use 
cases for resolution/location/forwarding hints. 

A particular context of interest is tactical ad hoc networks plus episodic
connectivity (no guarantee of instant access to trusted third-parties).  
Securing the infrastructure proabably means pre-configuration with keying 
material without guaranteed means of online revocation.  My main point 
is that in this context potentially every node is a router too.  So, it 
is not clear why we would trust the routing infrastructure but not the 
hint-providers -- they are basically an equivalent set.  Also it is not 
clear that the number of updates received will always be significantly 
less than the number of data bundles (and therefore hints) received per 
unit time, so in dynamic networks, hints may not significantly increase 
the number of authentication ops.  Addresses 2. above.

Often the same environments also motivate on-demand reactive route discovery 
procedures such as Dynamic Source Routing. In this case, restriction of source 
routes to administrative bundles means the restriction that source routes be 
carried only in signaling bundles that are used for route (re-)discovery or 
for route pinning rather than on every bundle.  My main point here is that 
I believe it is possible to amortize hint headers across multiple bundles 
to a destination if indeed there is enough traffic.  Partially addresses 1. 
above.

I think it is useful to summarize why I think hint headers are useful:

Proposals for hints are motivated in part by the problem of dealing with 
partial knowledge -- of routing, location, and naming information --
induced by mobility and disconnections, and sometimes compounded by 
hierarchical routing information abstractions.

I can imagine mission logistics augmenting topology at a particular time 
and this schedule may have only been advertised to a select group of nodes, 
and not widely known to all potential next hop forwarders along the path.  
Also, it is not clear that an end-to-end route will be known to the source 
or to other nodes in the network a priori either.  Hints would be valuable 
in this case.

More generally, hint headers are a mechanism to feed-forward knowledge in 
a focused or localized manner along paths to a destination when a more 
widespread dissemination is either undesirable or inefficient e.g. networks 
with mobility or disconnection dynamics that exceed what proactive 
dissemination can typically deal with in a timely fashion.

I will wait for others to add their perspectives on this.  

Best Regards,
Rajesh

> Hi Rajesh,
> 
> Wel:  some yes'es, but some no's below:-)
> 
> Rajesh Krishnan wrote:
> 
> >>I agree with Stephen.  This is re-inventing loose source routing which, 
> >>from a security perspective, is quite evil.
> > 
> > 
> > 0. I agree that authentication of who modified the hint is necessary.  I 
> >    also agree that an examination of vulnerabilities is important both
> >    for routing information dissemination and route computation procedures.
> 
> Such an authentication scheme is quite complex, and would involve
> serious amounts of bloat.
> 
> > 
> > That said,
> > 
> > 1. Hints != Source-Routing: an intermediate node need not automatically
> >    apply the hint as a source route, but use it only in the absence of
> >    better knowledge.  I am not convinced that the next hop will always 
> >    have better information than earlier hops especially in a mobile,
> >    episodically connected environment.
> > 
> > 2. Not "re-inventing" source routing, but "applying" (a similar idea). ;)
> > 
> > 3. Not insisting on, but allowing (as opposed to prohibiting by dictum ;), 
> >    loose source routing approaches among others
> 
> All fair enough.
> 
> > 
> > 4. Not clear that proactive route dissemination to aid hop-by-hop routing 
> >    is particularly free of the attacks mentioned.
> 
> I didn't say that the problems were totally new, but this kind
> of routing does make them worse, as I'm sure you'd agree. Of
> course, that may be an acceptable cost.
> 
> >    - In Stephen's example, even with next hop routing, 'b' might misbehave 
> >      and send to a neighboring 'v' (which may be quite a remote victim in 
> >      the _underlying_ network btw).  I am not convinced the battery drain 
> >      attack is particularly related to the use of hints.
> 
> With next hop routing, its fairly likely that 'v' might not expect
> the bundle and will drop it, or else that 'c' would detect the
> strangeness and flag it. Point is, we're more likely to detect
> anomalies with next hop routing since such detection is easier
> in that context. (Battery depletion was just an example of a bad
> thing, take your pick.)
> 
> >    - Any dissemination of routing knowledge will expose the network topology
> >      to some extent.  
> > 
> >      [Perhaps we might be able advertise encrypted paths that remote routers 
> >      can use without decrypting, but which can only be deciphered within 
> >      particular "routing regions".  Rest of the network can have a partial 
> >      knwowledge of where some landmarks are w.r.t.  specific destinations, 
> >      and not nearly expose as much knowledge as BGP.]
> 
> Interesting idea. However, probably more practical would be to
> secure the distribution of routing information, as is (or ought be)
> done today. Doesn't necessarily need crypto though if its
> sufficiently out-of-band.
> 
> >    - It is also not clear that the DTN architecture is immune to DoS attacks 
> >      per se. 
> 
> Not the point. Nothing's immune to DoS. But depending on how we
> design things, we make it better or worse.
> 
> > 5. Source routes or hints need not be in every bundle and could be limited 
> >    to administrative bundles.  
> 
> True, but wearing my security hat, I get to say "weakest link" :-)
> 
> I don't see how this would work if only applied to administrative
> bundles. And anyway, surely we're trying to cut down on such
> artefacts in DTN.
> 
> > 6. Next hop forwarding or source routing, we have to trust intermediate 
> >    routers not to misbehave.  [Unless we have some blackballing mechanisms
> >    for routers in place within the DTN architecture.]
> 
> Yes but "trust" is too coarse-grained as you've used it there. Again,
> this is all a matter of degree, and "hints" or whatever, may be a
> great idea, but there's a cost - we have to define a pretty complex
> authentication scheme, which may be very hard to use (e.g. I think
> it'd require that any router using the hint be able to check the
> authentication stuff, which means signatures, which means multi-
> domain PKI which is hard.)
> 
> Stephen.
> 
> > 
> > -Rajesh
> > 
> > 
> >>Howie
> >>
> >>Stephen Farrell wrote:
> >>
> >>
> >>>Isn't this creating a new set of security problems, or at
> >>>least making it a good bit easier to exploit some existing
> >>>ones?
> >>>
> >>>Probably in order of how much we'd care:
> >>>
> >>>- this seems to make it trivial for a DTN router to (accidentally
> >>>  or deliberately) cause some other routers trouble, and in a
> >>>  way that won't be easily visible from looking at most of the
> >>>  bundles, e.g. if the best route is really a,b,c,d but 'b'
> >>>  stands for 'bold' then we might end up with a,b,v,c,d, where
> >>>  'v' stands for 'victim' and so that the bundles arriving at
> >>>  'd' show no trace of the misbehaviour...at some point 'v'
> >>>  runs out of battery...oops
> >>>- you may not want to expose this much internal network
> >>>  structure to the rest of the solar system, which is one
> >>>  of the reasons that firewalls are (justifiably) so popular,
> >>>  basically, each such header gives an on-path bad guy a
> >>>  new potential target
> >>>- it also offers misbehaving routers the opportunity to
> >>>  cause trouble for certain nodes/applications, e.g. by
> >>>  sending their bundles on long routes - say if a bundle
> >>>  contains the result of a horse-race and I slow it down
> >>>  enough to get that winning bet in (a *very* old fraud!),
> >>>  while setting up a policy for this and/or detecting is
> >>>  always fairly hard, we're making the attack easier and
> >>>  the detection harder
> >>>- pushing and popping headers like this creates a few really
> >>>  cute covert channels, which might not make the tactical
> >>>  networking folks too happy - there is even enough
> >>>  flexibility there to actually run another DTN layer
> >>>  between co-operating routers by piggybacking on real
> >>>  traffic using those headers!
> >>>- I could probably go on, but I won't!
> >>>
> >>>So, if you're adding all these routing headers, then I believe
> >>>you have to provide ways to authenticate them. Now that can be
> >>>done, but it bloats the headers again and fairly dramatically
> >>>increases the complexity of what were formerly the relatively
> >>>simple hop-by-hop security structures (the BAH I guess).
> >>>
> >>>I guess I'd question whether that much complexity is really
> >>>worth it.
> >>>
> >>>Stephen.
> >>>
> >>>Rajesh Krishnan wrote:
> >>>
> >>>
> >>>>>As discussed earlier, in addition to source-specified EID's that 
> >>>>>determine where the bundle finally ends up, there needs to be a way 
> >>>>>to provide "hints", "care-of addresses", 
> >>>>>"intermediate-destinations", or "loose source-routes". As it turns 
> >>>>>out, these all fit nicely into the same concept.
> >>>>>
> >>>>>Given the previous discussion, here is a header structure example 
> >>>>>that would seem to make everybody happy:
> >>>>>
> >>>>>destination: pgp://<public key here>
> >>>>>reachable-thru: region://in.earth.sol
> >>>>>reachable-thru: region://relay.marineris.mars.sol
> >>>>
> >>>>
> >>>>
> >>>>I will make a distinction between "resolvable-at" and reachable-thru
> >>>>(i.e. distinguish who knows where a node might be from who might 
> >>>>deliver bundles to the node).
> >>>>
> >>>>In some network scenarios (as with the Internet today) some 
> >>>>authoritative
> >>>>naming infrastructure may be present. In other scenarios, some 
> >>>>servers may be
> >>>>elected to aggregate name resolution information (e.g. so that we may 
> >>>>be able
> >>>>to reconcile name KBs upon reconnection after a partitioning more 
> >>>>efficiently
> >>>>than having all nodes trying to reconcile).  There is some benefit to 
> >>>>aggregating location hints at ``fixed points'' in the network.
> >>>>
> >>>>In the above cases, these "resolver" nodes may not necessarily be 
> >>>>appropriate
> >>>>nodes to route the bundle through.  An en route node that is strongly 
> >>>>connected
> >>>>to such a resolver may be able to send a query to it to resolve the 
> >>>>name rather
> >>>>than forward a large bundle to it.  The result of the query can be 
> >>>>one or more
> >>>>reachable-thru (or further resolvable-at) nodes.
> >>>>
> >>>>
> >>>>
> >>>>>The "reachable-thru" name, used here instead of "care-of", seems to 
> >>>>>me to more precisely describe the function of the header. I suppose 
> >>>>>that's up for debate.
> >>>>>
> >>>>>More importantly, I would like to discuss whether ordering should 
> >>>>>have significance. Intuitively, I think significance makes sense, 
> >>>>>but I'm certainly open to enlightenment on this issue.
> >>>>
> >>>>
> >>>>
> >>>>Order is perhaps useful for "route-pinning".
> >>>>
> >>>>
> >>>>
> >>>>>If ordering is significant, the example above says that the 
> >>>>>destination is reachable through the internet, and the internet is 
> >>>>>reachable through the marineris relay. If there is no significance, 
> >>>>>it says that the destination is reachable both through the relay, 
> >>>>>and through the in.earth region.
> >>>>>
> >>>>>I can see benefits to both approaches. However, let's say a node 
> >>>>>along the path to the marineris relay happens to have a short route 
> >>>>>to a deep space antenna that can send direct to luna.earth.sol. With 
> >>>>>significance in ordering, it can know that the luna route to the 
> >>>>>internet is shorter than the marineris route. Thus, it would POP the 
> >>>>>marineris relay, and PUSH
> >>>>
> >>>>
> >>>>
> >>>>Regarding source routes and more generally reachability advertisements,
> >>>>I agree there is benefit to both approaches. I would recommend 
> >>>>considering an wider range (something analogous to the range of path 
> >>>>vectors specified by BGP).
> >>>>
> >>>>  - full path
> >>>>  - a subset of nodes on path, that must be visited in specified 
> >>>>sequence
> >>>>  - a subset of nodes on path, all of which must be visited but in 
> >>>>any order
> >>>>  - a subset of nodes on path, some of which may be visited (hints, 
> >>>>where
> >>>>    significance is perhaps more helpful than ordering)
> >>>>
> >>>>I suppose a vector of resolvers could also be specified similarly.
> >>>>
> >>>>
> >>>>
> >>>>>reachable-thru: region://luna.earth.sol
> >>>>>
> >>>>>Without significance, the reachable-thru header says the final 
> >>>>>destination is reachable through the marineris relay, _and_ through 
> >>>>>the internet. Unless every node has routes to every EID, the current 
> >>>>>node cannot know whether the marineris relay route is any better 
> >>>>>than the in.earth route (without ordering, we don't know that the 
> >>>>>marineris route actually also goes through the in.earth region). 
> >>>>>Thus, it cannot remove the marineris relay from the list. Instead, 
> >>>>>it will simply add another reachable-thru header. This might end up 
> >>>>>being messy, perhaps even create loops.
> >>>>>
> >>>>>Thoughts?
> >>>>>
> >>>>>- Jakob
> >>>>
> >>>>
> >>>>
> >>>>Best Regards,
> >>>>Rajesh
> >>>>_______________________________________________
> >>>>dtn-interest mailing list
> >>>>[email-masked]
> >>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>>
> >>>>
> >>>
> >>>_______________________________________________
> >>>dtn-interest mailing list
> >>>[email-masked]
> >>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>
> >>
> >>-- 
> >>Howard Weiss
> >>SPARTA, Inc.
> >>7075 Samuel Morse Drive
> >>Columbia, MD 21046
> >>410.872.1515 x201
> >>410.872.8079 (fax)
> >>
> >>
> >>
> >>--------------090001070406030704030306
> >>Content-Type: text/html; charset=us-ascii
> >>Content-Transfer-Encoding: 7bit
> >>
> >><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> >><html>
> >><head>
> >>  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> >>  <title></title>
> >></head>
> >><body bgcolor="#ffffff" text="#000000">
> >><font size="-1"><font face="Helvetica, Arial, sans-serif">I agree with
> >>Stephen.&nbsp; This is re-inventing loose source routing which, from a
> >>security perspective, is quite evil.<br>
> >><br>
> >>Howie<br>
> >></font></font><br>
> >>Stephen Farrell wrote:<br>
> >><blockquote cite="[email-masked]" type="cite"><br>
> >>Isn't this creating a new set of security problems, or at
> >>  <br>
> >>least making it a good bit easier to exploit some existing
> >>  <br>
> >>ones?
> >>  <br>
> >>  <br>
> >>Probably in order of how much we'd care:
> >>  <br>
> >>  <br>
> >>- this seems to make it trivial for a DTN router to (accidentally
> >>  <br>
> >>&nbsp; or deliberately) cause some other routers trouble, and in a
> >>  <br>
> >>&nbsp; way that won't be easily visible from looking at most of the
> >>  <br>
> >>&nbsp; bundles, e.g. if the best route is really a,b,c,d but 'b'
> >>  <br>
> >>&nbsp; stands for 'bold' then we might end up with a,b,v,c,d, where
> >>  <br>
> >>&nbsp; 'v' stands for 'victim' and so that the bundles arriving at
> >>  <br>
> >>&nbsp; 'd' show no trace of the misbehaviour...at some point 'v'
> >>  <br>
> >>&nbsp; runs out of battery...oops
> >>  <br>
> >>- you may not want to expose this much internal network
> >>  <br>
> >>&nbsp; structure to the rest of the solar system, which is one
> >>  <br>
> >>&nbsp; of the reasons that firewalls are (justifiably) so popular,
> >>  <br>
> >>&nbsp; basically, each such header gives an on-path bad guy a
> >>  <br>
> >>&nbsp; new potential target
> >>  <br>
> >>- it also offers misbehaving routers the opportunity to
> >>  <br>
> >>&nbsp; cause trouble for certain nodes/applications, e.g. by
> >>  <br>
> >>&nbsp; sending their bundles on long routes - say if a bundle
> >>  <br>
> >>&nbsp; contains the result of a horse-race and I slow it down
> >>  <br>
> >>&nbsp; enough to get that winning bet in (a *very* old fraud!),
> >>  <br>
> >>&nbsp; while setting up a policy for this and/or detecting is
> >>  <br>
> >>&nbsp; always fairly hard, we're making the attack easier and
> >>  <br>
> >>&nbsp; the detection harder
> >>  <br>
> >>- pushing and popping headers like this creates a few really
> >>  <br>
> >>&nbsp; cute covert channels, which might not make the tactical
> >>  <br>
> >>&nbsp; networking folks too happy - there is even enough
> >>  <br>
> >>&nbsp; flexibility there to actually run another DTN layer
> >>  <br>
> >>&nbsp; between co-operating routers by piggybacking on real
> >>  <br>
> >>&nbsp; traffic using those headers!
> >>  <br>
> >>- I could probably go on, but I won't!
> >>  <br>
> >>  <br>
> >>So, if you're adding all these routing headers, then I believe
> >>  <br>
> >>you have to provide ways to authenticate them. Now that can be
> >>  <br>
> >>done, but it bloats the headers again and fairly dramatically
> >>  <br>
> >>increases the complexity of what were formerly the relatively
> >>  <br>
> >>simple hop-by-hop security structures (the BAH I guess).
> >>  <br>
> >>  <br>
> >>I guess I'd question whether that much complexity is really
> >>  <br>
> >>worth it.
> >>  <br>
> >>  <br>
> >>Stephen.
> >>  <br>
> >>  <br>
> >>Rajesh Krishnan wrote:
> >>  <br>
> >>  <br>
> >>  <blockquote type="cite">
> >>    <blockquote type="cite">As discussed earlier, in addition to
> >>source-specified EID's that determine where the bundle finally ends up,
> >>there needs to be a way to provide "hints", "care-of addresses",
> >>"intermediate-destinations", or "loose source-routes". As it turns out,
> >>these all fit nicely into the same concept.
> >>      <br>
> >>      <br>
> >>Given the previous discussion, here is a header structure example that
> >>would seem to make everybody happy:
> >>      <br>
> >>      <br>
> >>destination: pgp://&lt;public key here&gt;
> >>      <br>
> >>reachable-thru: region://in.earth.sol
> >>      <br>
> >>reachable-thru: region://relay.marineris.mars.sol
> >>      <br>
> >>    </blockquote>
> >>    <br>
> >>    <br>
> >>I will make a distinction between "resolvable-at" and reachable-thru
> >>    <br>
> >>(i.e. distinguish who knows where a node might be from who might
> >>deliver bundles to the node).
> >>    <br>
> >>    <br>
> >>In some network scenarios (as with the Internet today) some
> >>authoritative
> >>    <br>
> >>naming infrastructure may be present. In other scenarios, some servers
> >>may be
> >>    <br>
> >>elected to aggregate name resolution information (e.g. so that we may
> >>be able
> >>    <br>
> >>to reconcile name KBs upon reconnection after a partitioning more
> >>efficiently
> >>    <br>
> >>than having all nodes trying to reconcile).&nbsp; There is some benefit to
> >>aggregating location hints at ``fixed points'' in the network.
> >>    <br>
> >>    <br>
> >>In the above cases, these "resolver" nodes may not necessarily be
> >>appropriate
> >>    <br>
> >>nodes to route the bundle through.&nbsp; An en route node that is strongly
> >>connected
> >>    <br>
> >>to such a resolver may be able to send a query to it to resolve the
> >>name rather
> >>    <br>
> >>than forward a large bundle to it.&nbsp; The result of the query can be one
> >>or more
> >>    <br>
> >>reachable-thru (or further resolvable-at) nodes.
> >>    <br>
> >>    <br>
> >>    <br>
> >>    <blockquote type="cite">The "reachable-thru" name, used here
> >>instead of "care-of", seems to me to more precisely describe the
> >>function of the header. I suppose that's up for debate.
> >>      <br>
> >>      <br>
> >>More importantly, I would like to discuss whether ordering should have
> >>significance. Intuitively, I think significance makes sense, but I'm
> >>certainly open to enlightenment on this issue.
> >>      <br>
> >>    </blockquote>
> >>    <br>
> >>    <br>
> >>Order is perhaps useful for "route-pinning".
> >>    <br>
> >>    <br>
> >>    <br>
> >>    <blockquote type="cite">If ordering is significant, the example
> >>above says that the destination is reachable through the internet, and
> >>the internet is reachable through the marineris relay. If there is no
> >>significance, it says that the destination is reachable both through
> >>the relay, and through the in.earth region.
> >>      <br>
> >>      <br>
> >>I can see benefits to both approaches. However, let's say a node along
> >>the path to the marineris relay happens to have a short route to a deep
> >>space antenna that can send direct to luna.earth.sol. With significance
> >>in ordering, it can know that the luna route to the internet is shorter
> >>than the marineris route. Thus, it would POP the marineris relay, and
> >>PUSH
> >>      <br>
> >>    </blockquote>
> >>    <br>
> >>    <br>
> >>Regarding source routes and more generally reachability advertisements,
> >>    <br>
> >>I agree there is benefit to both approaches. I would recommend
> >>considering an wider range (something analogous to the range of path
> >>vectors specified by BGP).
> >>    <br>
> >>    <br>
> >>&nbsp; - full path
> >>    <br>
> >>&nbsp; - a subset of nodes on path, that must be visited in specified
> >>sequence
> >>    <br>
> >>&nbsp; - a subset of nodes on path, all of which must be visited but in any
> >>order
> >>    <br>
> >>&nbsp; - a subset of nodes on path, some of which may be visited (hints,
> >>where
> >>    <br>
> >>&nbsp;&nbsp;&nbsp; significance is perhaps more helpful than ordering)
> >>    <br>
> >>    <br>
> >>I suppose a vector of resolvers could also be specified similarly.
> >>    <br>
> >>    <br>
> >>    <br>
> >>    <blockquote type="cite">reachable-thru: region://luna.earth.sol
> >>      <br>
> >>      <br>
> >>Without significance, the reachable-thru header says the final
> >>destination is reachable through the marineris relay, _and_ through the
> >>internet. Unless every node has routes to every EID, the current node
> >>cannot know whether the marineris relay route is any better than the
> >>in.earth route (without ordering, we don't know that the marineris
> >>route actually also goes through the in.earth region). Thus, it cannot
> >>remove the marineris relay from the list. Instead, it will simply add
> >>another reachable-thru header. This might end up being messy, perhaps
> >>even create loops.
> >>      <br>
> >>      <br>
> >>Thoughts?
> >>      <br>
> >>      <br>
> >>- Jakob
> >>      <br>
> >>    </blockquote>
> >>    <br>
> >>    <br>
> >>Best Regards,
> >>    <br>
> >>Rajesh
> >>    <br>
> >>_______________________________________________
> >>    <br>
> >>dtn-interest mailing list
> >>    <br>
> >><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
> >>    <br>
> >><a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
> >>    <br>
> >>    <br>
> >>    <br>
> >>  </blockquote>
> >>_______________________________________________
> >>  <br>
> >>dtn-interest mailing list
> >>  <br>
> >><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
> >>  <br>
> >><a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
> >>  <br>
> >></blockquote>
> >><br>
> >><pre class="moz-signature" cols="72">-- 
> >>Howard Weiss
> >>SPARTA, Inc.
> >>7075 Samuel Morse Drive
> >>Columbia, MD 21046
> >>410.872.1515 x201
> >>410.872.8079 (fax)
> >>
> >></pre>
> >></body>
> >></html>
> >>
> >>--------------090001070406030704030306--
> >>
> >>_______________________________________________
> >>dtn-interest mailing list
> >>[email-masked]
> >>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>
> > 
> > 
> > 
> 

Date: Wed, 06 Apr 2005 09:38:54 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Hi.  Many of us will be relieved to hear that Keith has succeeded in talking me out of pursuing the extraction of fragmentation from the Bundling protocol.

Though I'm still not enthusiastic, I agree that retaining the ability to do additional fragmentation at intermediate points along a given end-to-end Bundling path may be important for some environments, and moving fragmentation up to a higher-level "DTN Segmentation" protocol would take away that flexibility.

I still think it would make everyone's life easier if we did away with reactive fragmentation specifically, but I will happily leave that battle to somebody else.

Scott

Date: Wed, 06 Apr 2005 16:32:38 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: Howard Weiss <[email-masked]>, Jakob Eriksson <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
Sender: [email-masked]

Hi Rajesh,

Wel:  some yes'es, but some no's below:-)

Rajesh Krishnan wrote:

>>I agree with Stephen.  This is re-inventing loose source routing which, 
>>from a security perspective, is quite evil.
> 
> 
> 0. I agree that authentication of who modified the hint is necessary.  I 
>    also agree that an examination of vulnerabilities is important both
>    for routing information dissemination and route computation procedures.

Such an authentication scheme is quite complex, and would involve
serious amounts of bloat.

> 
> That said,
> 
> 1. Hints != Source-Routing: an intermediate node need not automatically
>    apply the hint as a source route, but use it only in the absence of
>    better knowledge.  I am not convinced that the next hop will always 
>    have better information than earlier hops especially in a mobile,
>    episodically connected environment.
> 
> 2. Not "re-inventing" source routing, but "applying" (a similar idea). ;)
> 
> 3. Not insisting on, but allowing (as opposed to prohibiting by dictum ;), 
>    loose source routing approaches among others

All fair enough.

> 
> 4. Not clear that proactive route dissemination to aid hop-by-hop routing 
>    is particularly free of the attacks mentioned.

I didn't say that the problems were totally new, but this kind
of routing does make them worse, as I'm sure you'd agree. Of
course, that may be an acceptable cost.

>    - In Stephen's example, even with next hop routing, 'b' might misbehave 
>      and send to a neighboring 'v' (which may be quite a remote victim in 
>      the _underlying_ network btw).  I am not convinced the battery drain 
>      attack is particularly related to the use of hints.

With next hop routing, its fairly likely that 'v' might not expect
the bundle and will drop it, or else that 'c' would detect the
strangeness and flag it. Point is, we're more likely to detect
anomalies with next hop routing since such detection is easier
in that context. (Battery depletion was just an example of a bad
thing, take your pick.)

>    - Any dissemination of routing knowledge will expose the network topology
>      to some extent.  
> 
>      [Perhaps we might be able advertise encrypted paths that remote routers 
>      can use without decrypting, but which can only be deciphered within 
>      particular "routing regions".  Rest of the network can have a partial 
>      knwowledge of where some landmarks are w.r.t.  specific destinations, 
>      and not nearly expose as much knowledge as BGP.]

Interesting idea. However, probably more practical would be to
secure the distribution of routing information, as is (or ought be)
done today. Doesn't necessarily need crypto though if its
sufficiently out-of-band.

>    - It is also not clear that the DTN architecture is immune to DoS attacks 
>      per se. 

Not the point. Nothing's immune to DoS. But depending on how we
design things, we make it better or worse.

> 5. Source routes or hints need not be in every bundle and could be limited 
>    to administrative bundles.  

True, but wearing my security hat, I get to say "weakest link" :-)

I don't see how this would work if only applied to administrative
bundles. And anyway, surely we're trying to cut down on such
artefacts in DTN.

> 6. Next hop forwarding or source routing, we have to trust intermediate 
>    routers not to misbehave.  [Unless we have some blackballing mechanisms
>    for routers in place within the DTN architecture.]

Yes but "trust" is too coarse-grained as you've used it there. Again,
this is all a matter of degree, and "hints" or whatever, may be a
great idea, but there's a cost - we have to define a pretty complex
authentication scheme, which may be very hard to use (e.g. I think
it'd require that any router using the hint be able to check the
authentication stuff, which means signatures, which means multi-
domain PKI which is hard.)

Stephen.

> 
> -Rajesh
> 
> 
>>Howie
>>
>>Stephen Farrell wrote:
>>
>>
>>>Isn't this creating a new set of security problems, or at
>>>least making it a good bit easier to exploit some existing
>>>ones?
>>>
>>>Probably in order of how much we'd care:
>>>
>>>- this seems to make it trivial for a DTN router to (accidentally
>>>  or deliberately) cause some other routers trouble, and in a
>>>  way that won't be easily visible from looking at most of the
>>>  bundles, e.g. if the best route is really a,b,c,d but 'b'
>>>  stands for 'bold' then we might end up with a,b,v,c,d, where
>>>  'v' stands for 'victim' and so that the bundles arriving at
>>>  'd' show no trace of the misbehaviour...at some point 'v'
>>>  runs out of battery...oops
>>>- you may not want to expose this much internal network
>>>  structure to the rest of the solar system, which is one
>>>  of the reasons that firewalls are (justifiably) so popular,
>>>  basically, each such header gives an on-path bad guy a
>>>  new potential target
>>>- it also offers misbehaving routers the opportunity to
>>>  cause trouble for certain nodes/applications, e.g. by
>>>  sending their bundles on long routes - say if a bundle
>>>  contains the result of a horse-race and I slow it down
>>>  enough to get that winning bet in (a *very* old fraud!),
>>>  while setting up a policy for this and/or detecting is
>>>  always fairly hard, we're making the attack easier and
>>>  the detection harder
>>>- pushing and popping headers like this creates a few really
>>>  cute covert channels, which might not make the tactical
>>>  networking folks too happy - there is even enough
>>>  flexibility there to actually run another DTN layer
>>>  between co-operating routers by piggybacking on real
>>>  traffic using those headers!
>>>- I could probably go on, but I won't!
>>>
>>>So, if you're adding all these routing headers, then I believe
>>>you have to provide ways to authenticate them. Now that can be
>>>done, but it bloats the headers again and fairly dramatically
>>>increases the complexity of what were formerly the relatively
>>>simple hop-by-hop security structures (the BAH I guess).
>>>
>>>I guess I'd question whether that much complexity is really
>>>worth it.
>>>
>>>Stephen.
>>>
>>>Rajesh Krishnan wrote:
>>>
>>>
>>>>>As discussed earlier, in addition to source-specified EID's that 
>>>>>determine where the bundle finally ends up, there needs to be a way 
>>>>>to provide "hints", "care-of addresses", 
>>>>>"intermediate-destinations", or "loose source-routes". As it turns 
>>>>>out, these all fit nicely into the same concept.
>>>>>
>>>>>Given the previous discussion, here is a header structure example 
>>>>>that would seem to make everybody happy:
>>>>>
>>>>>destination: pgp://<public key here>
>>>>>reachable-thru: region://in.earth.sol
>>>>>reachable-thru: region://relay.marineris.mars.sol
>>>>
>>>>
>>>>
>>>>I will make a distinction between "resolvable-at" and reachable-thru
>>>>(i.e. distinguish who knows where a node might be from who might 
>>>>deliver bundles to the node).
>>>>
>>>>In some network scenarios (as with the Internet today) some 
>>>>authoritative
>>>>naming infrastructure may be present. In other scenarios, some 
>>>>servers may be
>>>>elected to aggregate name resolution information (e.g. so that we may 
>>>>be able
>>>>to reconcile name KBs upon reconnection after a partitioning more 
>>>>efficiently
>>>>than having all nodes trying to reconcile).  There is some benefit to 
>>>>aggregating location hints at ``fixed points'' in the network.
>>>>
>>>>In the above cases, these "resolver" nodes may not necessarily be 
>>>>appropriate
>>>>nodes to route the bundle through.  An en route node that is strongly 
>>>>connected
>>>>to such a resolver may be able to send a query to it to resolve the 
>>>>name rather
>>>>than forward a large bundle to it.  The result of the query can be 
>>>>one or more
>>>>reachable-thru (or further resolvable-at) nodes.
>>>>
>>>>
>>>>
>>>>>The "reachable-thru" name, used here instead of "care-of", seems to 
>>>>>me to more precisely describe the function of the header. I suppose 
>>>>>that's up for debate.
>>>>>
>>>>>More importantly, I would like to discuss whether ordering should 
>>>>>have significance. Intuitively, I think significance makes sense, 
>>>>>but I'm certainly open to enlightenment on this issue.
>>>>
>>>>
>>>>
>>>>Order is perhaps useful for "route-pinning".
>>>>
>>>>
>>>>
>>>>>If ordering is significant, the example above says that the 
>>>>>destination is reachable through the internet, and the internet is 
>>>>>reachable through the marineris relay. If there is no significance, 
>>>>>it says that the destination is reachable both through the relay, 
>>>>>and through the in.earth region.
>>>>>
>>>>>I can see benefits to both approaches. However, let's say a node 
>>>>>along the path to the marineris relay happens to have a short route 
>>>>>to a deep space antenna that can send direct to luna.earth.sol. With 
>>>>>significance in ordering, it can know that the luna route to the 
>>>>>internet is shorter than the marineris route. Thus, it would POP the 
>>>>>marineris relay, and PUSH
>>>>
>>>>
>>>>
>>>>Regarding source routes and more generally reachability advertisements,
>>>>I agree there is benefit to both approaches. I would recommend 
>>>>considering an wider range (something analogous to the range of path 
>>>>vectors specified by BGP).
>>>>
>>>>  - full path
>>>>  - a subset of nodes on path, that must be visited in specified 
>>>>sequence
>>>>  - a subset of nodes on path, all of which must be visited but in 
>>>>any order
>>>>  - a subset of nodes on path, some of which may be visited (hints, 
>>>>where
>>>>    significance is perhaps more helpful than ordering)
>>>>
>>>>I suppose a vector of resolvers could also be specified similarly.
>>>>
>>>>
>>>>
>>>>>reachable-thru: region://luna.earth.sol
>>>>>
>>>>>Without significance, the reachable-thru header says the final 
>>>>>destination is reachable through the marineris relay, _and_ through 
>>>>>the internet. Unless every node has routes to every EID, the current 
>>>>>node cannot know whether the marineris relay route is any better 
>>>>>than the in.earth route (without ordering, we don't know that the 
>>>>>marineris route actually also goes through the in.earth region). 
>>>>>Thus, it cannot remove the marineris relay from the list. Instead, 
>>>>>it will simply add another reachable-thru header. This might end up 
>>>>>being messy, perhaps even create loops.
>>>>>
>>>>>Thoughts?
>>>>>
>>>>>- Jakob
>>>>
>>>>
>>>>
>>>>Best Regards,
>>>>Rajesh
>>>>_______________________________________________
>>>>dtn-interest mailing list
>>>>[email-masked]
>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>>>
>>>
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
>>-- 
>>Howard Weiss
>>SPARTA, Inc.
>>7075 Samuel Morse Drive
>>Columbia, MD 21046
>>410.872.1515 x201
>>410.872.8079 (fax)
>>
>>
>>
>>--------------090001070406030704030306
>>Content-Type: text/html; charset=us-ascii
>>Content-Transfer-Encoding: 7bit
>>
>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>><html>
>><head>
>>  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>>  <title></title>
>></head>
>><body bgcolor="#ffffff" text="#000000">
>><font size="-1"><font face="Helvetica, Arial, sans-serif">I agree with
>>Stephen.&nbsp; This is re-inventing loose source routing which, from a
>>security perspective, is quite evil.<br>
>><br>
>>Howie<br>
>></font></font><br>
>>Stephen Farrell wrote:<br>
>><blockquote cite="[email-masked]" type="cite"><br>
>>Isn't this creating a new set of security problems, or at
>>  <br>
>>least making it a good bit easier to exploit some existing
>>  <br>
>>ones?
>>  <br>
>>  <br>
>>Probably in order of how much we'd care:
>>  <br>
>>  <br>
>>- this seems to make it trivial for a DTN router to (accidentally
>>  <br>
>>&nbsp; or deliberately) cause some other routers trouble, and in a
>>  <br>
>>&nbsp; way that won't be easily visible from looking at most of the
>>  <br>
>>&nbsp; bundles, e.g. if the best route is really a,b,c,d but 'b'
>>  <br>
>>&nbsp; stands for 'bold' then we might end up with a,b,v,c,d, where
>>  <br>
>>&nbsp; 'v' stands for 'victim' and so that the bundles arriving at
>>  <br>
>>&nbsp; 'd' show no trace of the misbehaviour...at some point 'v'
>>  <br>
>>&nbsp; runs out of battery...oops
>>  <br>
>>- you may not want to expose this much internal network
>>  <br>
>>&nbsp; structure to the rest of the solar system, which is one
>>  <br>
>>&nbsp; of the reasons that firewalls are (justifiably) so popular,
>>  <br>
>>&nbsp; basically, each such header gives an on-path bad guy a
>>  <br>
>>&nbsp; new potential target
>>  <br>
>>- it also offers misbehaving routers the opportunity to
>>  <br>
>>&nbsp; cause trouble for certain nodes/applications, e.g. by
>>  <br>
>>&nbsp; sending their bundles on long routes - say if a bundle
>>  <br>
>>&nbsp; contains the result of a horse-race and I slow it down
>>  <br>
>>&nbsp; enough to get that winning bet in (a *very* old fraud!),
>>  <br>
>>&nbsp; while setting up a policy for this and/or detecting is
>>  <br>
>>&nbsp; always fairly hard, we're making the attack easier and
>>  <br>
>>&nbsp; the detection harder
>>  <br>
>>- pushing and popping headers like this creates a few really
>>  <br>
>>&nbsp; cute covert channels, which might not make the tactical
>>  <br>
>>&nbsp; networking folks too happy - there is even enough
>>  <br>
>>&nbsp; flexibility there to actually run another DTN layer
>>  <br>
>>&nbsp; between co-operating routers by piggybacking on real
>>  <br>
>>&nbsp; traffic using those headers!
>>  <br>
>>- I could probably go on, but I won't!
>>  <br>
>>  <br>
>>So, if you're adding all these routing headers, then I believe
>>  <br>
>>you have to provide ways to authenticate them. Now that can be
>>  <br>
>>done, but it bloats the headers again and fairly dramatically
>>  <br>
>>increases the complexity of what were formerly the relatively
>>  <br>
>>simple hop-by-hop security structures (the BAH I guess).
>>  <br>
>>  <br>
>>I guess I'd question whether that much complexity is really
>>  <br>
>>worth it.
>>  <br>
>>  <br>
>>Stephen.
>>  <br>
>>  <br>
>>Rajesh Krishnan wrote:
>>  <br>
>>  <br>
>>  <blockquote type="cite">
>>    <blockquote type="cite">As discussed earlier, in addition to
>>source-specified EID's that determine where the bundle finally ends up,
>>there needs to be a way to provide "hints", "care-of addresses",
>>"intermediate-destinations", or "loose source-routes". As it turns out,
>>these all fit nicely into the same concept.
>>      <br>
>>      <br>
>>Given the previous discussion, here is a header structure example that
>>would seem to make everybody happy:
>>      <br>
>>      <br>
>>destination: pgp://&lt;public key here&gt;
>>      <br>
>>reachable-thru: region://in.earth.sol
>>      <br>
>>reachable-thru: region://relay.marineris.mars.sol
>>      <br>
>>    </blockquote>
>>    <br>
>>    <br>
>>I will make a distinction between "resolvable-at" and reachable-thru
>>    <br>
>>(i.e. distinguish who knows where a node might be from who might
>>deliver bundles to the node).
>>    <br>
>>    <br>
>>In some network scenarios (as with the Internet today) some
>>authoritative
>>    <br>
>>naming infrastructure may be present. In other scenarios, some servers
>>may be
>>    <br>
>>elected to aggregate name resolution information (e.g. so that we may
>>be able
>>    <br>
>>to reconcile name KBs upon reconnection after a partitioning more
>>efficiently
>>    <br>
>>than having all nodes trying to reconcile).&nbsp; There is some benefit to
>>aggregating location hints at ``fixed points'' in the network.
>>    <br>
>>    <br>
>>In the above cases, these "resolver" nodes may not necessarily be
>>appropriate
>>    <br>
>>nodes to route the bundle through.&nbsp; An en route node that is strongly
>>connected
>>    <br>
>>to such a resolver may be able to send a query to it to resolve the
>>name rather
>>    <br>
>>than forward a large bundle to it.&nbsp; The result of the query can be one
>>or more
>>    <br>
>>reachable-thru (or further resolvable-at) nodes.
>>    <br>
>>    <br>
>>    <br>
>>    <blockquote type="cite">The "reachable-thru" name, used here
>>instead of "care-of", seems to me to more precisely describe the
>>function of the header. I suppose that's up for debate.
>>      <br>
>>      <br>
>>More importantly, I would like to discuss whether ordering should have
>>significance. Intuitively, I think significance makes sense, but I'm
>>certainly open to enlightenment on this issue.
>>      <br>
>>    </blockquote>
>>    <br>
>>    <br>
>>Order is perhaps useful for "route-pinning".
>>    <br>
>>    <br>
>>    <br>
>>    <blockquote type="cite">If ordering is significant, the example
>>above says that the destination is reachable through the internet, and
>>the internet is reachable through the marineris relay. If there is no
>>significance, it says that the destination is reachable both through
>>the relay, and through the in.earth region.
>>      <br>
>>      <br>
>>I can see benefits to both approaches. However, let's say a node along
>>the path to the marineris relay happens to have a short route to a deep
>>space antenna that can send direct to luna.earth.sol. With significance
>>in ordering, it can know that the luna route to the internet is shorter
>>than the marineris route. Thus, it would POP the marineris relay, and
>>PUSH
>>      <br>
>>    </blockquote>
>>    <br>
>>    <br>
>>Regarding source routes and more generally reachability advertisements,
>>    <br>
>>I agree there is benefit to both approaches. I would recommend
>>considering an wider range (something analogous to the range of path
>>vectors specified by BGP).
>>    <br>
>>    <br>
>>&nbsp; - full path
>>    <br>
>>&nbsp; - a subset of nodes on path, that must be visited in specified
>>sequence
>>    <br>
>>&nbsp; - a subset of nodes on path, all of which must be visited but in any
>>order
>>    <br>
>>&nbsp; - a subset of nodes on path, some of which may be visited (hints,
>>where
>>    <br>
>>&nbsp;&nbsp;&nbsp; significance is perhaps more helpful than ordering)
>>    <br>
>>    <br>
>>I suppose a vector of resolvers could also be specified similarly.
>>    <br>
>>    <br>
>>    <br>
>>    <blockquote type="cite">reachable-thru: region://luna.earth.sol
>>      <br>
>>      <br>
>>Without significance, the reachable-thru header says the final
>>destination is reachable through the marineris relay, _and_ through the
>>internet. Unless every node has routes to every EID, the current node
>>cannot know whether the marineris relay route is any better than the
>>in.earth route (without ordering, we don't know that the marineris
>>route actually also goes through the in.earth region). Thus, it cannot
>>remove the marineris relay from the list. Instead, it will simply add
>>another reachable-thru header. This might end up being messy, perhaps
>>even create loops.
>>      <br>
>>      <br>
>>Thoughts?
>>      <br>
>>      <br>
>>- Jakob
>>      <br>
>>    </blockquote>
>>    <br>
>>    <br>
>>Best Regards,
>>    <br>
>>Rajesh
>>    <br>
>>_______________________________________________
>>    <br>
>>dtn-interest mailing list
>>    <br>
>><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
>>    <br>
>><a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
>>    <br>
>>    <br>
>>    <br>
>>  </blockquote>
>>_______________________________________________
>>  <br>
>>dtn-interest mailing list
>>  <br>
>><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
>>  <br>
>><a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
>>  <br>
>></blockquote>
>><br>
>><pre class="moz-signature" cols="72">-- 
>>Howard Weiss
>>SPARTA, Inc.
>>7075 Samuel Morse Drive
>>Columbia, MD 21046
>>410.872.1515 x201
>>410.872.8079 (fax)
>>
>></pre>
>></body>
>></html>
>>
>>--------------090001070406030704030306--
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> 
> 
> 

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
To: [email-masked] (Howard Weiss)
Date: Wed, 6 Apr 2005 11:11:14 -0400 (EDT)
Cc: [email-masked] (Stephen Farrell), [email-masked], [email-masked] (Jakob Eriksson), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

> I agree with Stephen.  This is re-inventing loose source routing which, 
> from a security perspective, is quite evil.

0. I agree that authentication of who modified the hint is necessary.  I 
   also agree that an examination of vulnerabilities is important both
   for routing information dissemination and route computation procedures.

That said,

1. Hints != Source-Routing: an intermediate node need not automatically
   apply the hint as a source route, but use it only in the absence of
   better knowledge.  I am not convinced that the next hop will always 
   have better information than earlier hops especially in a mobile,
   episodically connected environment.

2. Not "re-inventing" source routing, but "applying" (a similar idea). ;)

3. Not insisting on, but allowing (as opposed to prohibiting by dictum ;), 
   loose source routing approaches among others

4. Not clear that proactive route dissemination to aid hop-by-hop routing 
   is particularly free of the attacks mentioned.

   - In Stephen's example, even with next hop routing, 'b' might misbehave 
     and send to a neighboring 'v' (which may be quite a remote victim in 
     the _underlying_ network btw).  I am not convinced the battery drain 
     attack is particularly related to the use of hints.

   - Any dissemination of routing knowledge will expose the network topology
     to some extent.  

     [Perhaps we might be able advertise encrypted paths that remote routers 
     can use without decrypting, but which can only be deciphered within 
     particular "routing regions".  Rest of the network can have a partial 
     knwowledge of where some landmarks are w.r.t.  specific destinations, 
     and not nearly expose as much knowledge as BGP.]

   - It is also not clear that the DTN architecture is immune to DoS attacks 
     per se. 

5. Source routes or hints need not be in every bundle and could be limited 
   to administrative bundles.  

6. Next hop forwarding or source routing, we have to trust intermediate 
   routers not to misbehave.  [Unless we have some blackballing mechanisms
   for routers in place within the DTN architecture.]

-Rajesh

> Howie
> 
> Stephen Farrell wrote:
> 
> >
> > Isn't this creating a new set of security problems, or at
> > least making it a good bit easier to exploit some existing
> > ones?
> >
> > Probably in order of how much we'd care:
> >
> > - this seems to make it trivial for a DTN router to (accidentally
> >   or deliberately) cause some other routers trouble, and in a
> >   way that won't be easily visible from looking at most of the
> >   bundles, e.g. if the best route is really a,b,c,d but 'b'
> >   stands for 'bold' then we might end up with a,b,v,c,d, where
> >   'v' stands for 'victim' and so that the bundles arriving at
> >   'd' show no trace of the misbehaviour...at some point 'v'
> >   runs out of battery...oops
> > - you may not want to expose this much internal network
> >   structure to the rest of the solar system, which is one
> >   of the reasons that firewalls are (justifiably) so popular,
> >   basically, each such header gives an on-path bad guy a
> >   new potential target
> > - it also offers misbehaving routers the opportunity to
> >   cause trouble for certain nodes/applications, e.g. by
> >   sending their bundles on long routes - say if a bundle
> >   contains the result of a horse-race and I slow it down
> >   enough to get that winning bet in (a *very* old fraud!),
> >   while setting up a policy for this and/or detecting is
> >   always fairly hard, we're making the attack easier and
> >   the detection harder
> > - pushing and popping headers like this creates a few really
> >   cute covert channels, which might not make the tactical
> >   networking folks too happy - there is even enough
> >   flexibility there to actually run another DTN layer
> >   between co-operating routers by piggybacking on real
> >   traffic using those headers!
> > - I could probably go on, but I won't!
> >
> > So, if you're adding all these routing headers, then I believe
> > you have to provide ways to authenticate them. Now that can be
> > done, but it bloats the headers again and fairly dramatically
> > increases the complexity of what were formerly the relatively
> > simple hop-by-hop security structures (the BAH I guess).
> >
> > I guess I'd question whether that much complexity is really
> > worth it.
> >
> > Stephen.
> >
> > Rajesh Krishnan wrote:
> >
> >>> As discussed earlier, in addition to source-specified EID's that 
> >>> determine where the bundle finally ends up, there needs to be a way 
> >>> to provide "hints", "care-of addresses", 
> >>> "intermediate-destinations", or "loose source-routes". As it turns 
> >>> out, these all fit nicely into the same concept.
> >>>
> >>> Given the previous discussion, here is a header structure example 
> >>> that would seem to make everybody happy:
> >>>
> >>> destination: pgp://<public key here>
> >>> reachable-thru: region://in.earth.sol
> >>> reachable-thru: region://relay.marineris.mars.sol
> >>
> >>
> >>
> >> I will make a distinction between "resolvable-at" and reachable-thru
> >> (i.e. distinguish who knows where a node might be from who might 
> >> deliver bundles to the node).
> >>
> >> In some network scenarios (as with the Internet today) some 
> >> authoritative
> >> naming infrastructure may be present. In other scenarios, some 
> >> servers may be
> >> elected to aggregate name resolution information (e.g. so that we may 
> >> be able
> >> to reconcile name KBs upon reconnection after a partitioning more 
> >> efficiently
> >> than having all nodes trying to reconcile).  There is some benefit to 
> >> aggregating location hints at ``fixed points'' in the network.
> >>
> >> In the above cases, these "resolver" nodes may not necessarily be 
> >> appropriate
> >> nodes to route the bundle through.  An en route node that is strongly 
> >> connected
> >> to such a resolver may be able to send a query to it to resolve the 
> >> name rather
> >> than forward a large bundle to it.  The result of the query can be 
> >> one or more
> >> reachable-thru (or further resolvable-at) nodes.
> >>
> >>
> >>> The "reachable-thru" name, used here instead of "care-of", seems to 
> >>> me to more precisely describe the function of the header. I suppose 
> >>> that's up for debate.
> >>>
> >>> More importantly, I would like to discuss whether ordering should 
> >>> have significance. Intuitively, I think significance makes sense, 
> >>> but I'm certainly open to enlightenment on this issue.
> >>
> >>
> >>
> >> Order is perhaps useful for "route-pinning".
> >>
> >>
> >>> If ordering is significant, the example above says that the 
> >>> destination is reachable through the internet, and the internet is 
> >>> reachable through the marineris relay. If there is no significance, 
> >>> it says that the destination is reachable both through the relay, 
> >>> and through the in.earth region.
> >>>
> >>> I can see benefits to both approaches. However, let's say a node 
> >>> along the path to the marineris relay happens to have a short route 
> >>> to a deep space antenna that can send direct to luna.earth.sol. With 
> >>> significance in ordering, it can know that the luna route to the 
> >>> internet is shorter than the marineris route. Thus, it would POP the 
> >>> marineris relay, and PUSH
> >>
> >>
> >>
> >> Regarding source routes and more generally reachability advertisements,
> >> I agree there is benefit to both approaches. I would recommend 
> >> considering an wider range (something analogous to the range of path 
> >> vectors specified by BGP).
> >>
> >>   - full path
> >>   - a subset of nodes on path, that must be visited in specified 
> >> sequence
> >>   - a subset of nodes on path, all of which must be visited but in 
> >> any order
> >>   - a subset of nodes on path, some of which may be visited (hints, 
> >> where
> >>     significance is perhaps more helpful than ordering)
> >>
> >> I suppose a vector of resolvers could also be specified similarly.
> >>
> >>
> >>> reachable-thru: region://luna.earth.sol
> >>>
> >>> Without significance, the reachable-thru header says the final 
> >>> destination is reachable through the marineris relay, _and_ through 
> >>> the internet. Unless every node has routes to every EID, the current 
> >>> node cannot know whether the marineris relay route is any better 
> >>> than the in.earth route (without ordering, we don't know that the 
> >>> marineris route actually also goes through the in.earth region). 
> >>> Thus, it cannot remove the marineris relay from the list. Instead, 
> >>> it will simply add another reachable-thru header. This might end up 
> >>> being messy, perhaps even create loops.
> >>>
> >>> Thoughts?
> >>>
> >>> - Jakob
> >>
> >>
> >>
> >> Best Regards,
> >> Rajesh
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>
> >>
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> -- 
> Howard Weiss
> SPARTA, Inc.
> 7075 Samuel Morse Drive
> Columbia, MD 21046
> 410.872.1515 x201
> 410.872.8079 (fax)
> 
> 
> 
> --------------090001070406030704030306
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>   <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000">
> <font size="-1"><font face="Helvetica, Arial, sans-serif">I agree with
> Stephen.&nbsp; This is re-inventing loose source routing which, from a
> security perspective, is quite evil.<br>
> <br>
> Howie<br>
> </font></font><br>
> Stephen Farrell wrote:<br>
> <blockquote cite="[email-masked]" type="cite"><br>
> Isn't this creating a new set of security problems, or at
>   <br>
> least making it a good bit easier to exploit some existing
>   <br>
> ones?
>   <br>
>   <br>
> Probably in order of how much we'd care:
>   <br>
>   <br>
> - this seems to make it trivial for a DTN router to (accidentally
>   <br>
> &nbsp; or deliberately) cause some other routers trouble, and in a
>   <br>
> &nbsp; way that won't be easily visible from looking at most of the
>   <br>
> &nbsp; bundles, e.g. if the best route is really a,b,c,d but 'b'
>   <br>
> &nbsp; stands for 'bold' then we might end up with a,b,v,c,d, where
>   <br>
> &nbsp; 'v' stands for 'victim' and so that the bundles arriving at
>   <br>
> &nbsp; 'd' show no trace of the misbehaviour...at some point 'v'
>   <br>
> &nbsp; runs out of battery...oops
>   <br>
> - you may not want to expose this much internal network
>   <br>
> &nbsp; structure to the rest of the solar system, which is one
>   <br>
> &nbsp; of the reasons that firewalls are (justifiably) so popular,
>   <br>
> &nbsp; basically, each such header gives an on-path bad guy a
>   <br>
> &nbsp; new potential target
>   <br>
> - it also offers misbehaving routers the opportunity to
>   <br>
> &nbsp; cause trouble for certain nodes/applications, e.g. by
>   <br>
> &nbsp; sending their bundles on long routes - say if a bundle
>   <br>
> &nbsp; contains the result of a horse-race and I slow it down
>   <br>
> &nbsp; enough to get that winning bet in (a *very* old fraud!),
>   <br>
> &nbsp; while setting up a policy for this and/or detecting is
>   <br>
> &nbsp; always fairly hard, we're making the attack easier and
>   <br>
> &nbsp; the detection harder
>   <br>
> - pushing and popping headers like this creates a few really
>   <br>
> &nbsp; cute covert channels, which might not make the tactical
>   <br>
> &nbsp; networking folks too happy - there is even enough
>   <br>
> &nbsp; flexibility there to actually run another DTN layer
>   <br>
> &nbsp; between co-operating routers by piggybacking on real
>   <br>
> &nbsp; traffic using those headers!
>   <br>
> - I could probably go on, but I won't!
>   <br>
>   <br>
> So, if you're adding all these routing headers, then I believe
>   <br>
> you have to provide ways to authenticate them. Now that can be
>   <br>
> done, but it bloats the headers again and fairly dramatically
>   <br>
> increases the complexity of what were formerly the relatively
>   <br>
> simple hop-by-hop security structures (the BAH I guess).
>   <br>
>   <br>
> I guess I'd question whether that much complexity is really
>   <br>
> worth it.
>   <br>
>   <br>
> Stephen.
>   <br>
>   <br>
> Rajesh Krishnan wrote:
>   <br>
>   <br>
>   <blockquote type="cite">
>     <blockquote type="cite">As discussed earlier, in addition to
> source-specified EID's that determine where the bundle finally ends up,
> there needs to be a way to provide "hints", "care-of addresses",
> "intermediate-destinations", or "loose source-routes". As it turns out,
> these all fit nicely into the same concept.
>       <br>
>       <br>
> Given the previous discussion, here is a header structure example that
> would seem to make everybody happy:
>       <br>
>       <br>
> destination: pgp://&lt;public key here&gt;
>       <br>
> reachable-thru: region://in.earth.sol
>       <br>
> reachable-thru: region://relay.marineris.mars.sol
>       <br>
>     </blockquote>
>     <br>
>     <br>
> I will make a distinction between "resolvable-at" and reachable-thru
>     <br>
> (i.e. distinguish who knows where a node might be from who might
> deliver bundles to the node).
>     <br>
>     <br>
> In some network scenarios (as with the Internet today) some
> authoritative
>     <br>
> naming infrastructure may be present. In other scenarios, some servers
> may be
>     <br>
> elected to aggregate name resolution information (e.g. so that we may
> be able
>     <br>
> to reconcile name KBs upon reconnection after a partitioning more
> efficiently
>     <br>
> than having all nodes trying to reconcile).&nbsp; There is some benefit to
> aggregating location hints at ``fixed points'' in the network.
>     <br>
>     <br>
> In the above cases, these "resolver" nodes may not necessarily be
> appropriate
>     <br>
> nodes to route the bundle through.&nbsp; An en route node that is strongly
> connected
>     <br>
> to such a resolver may be able to send a query to it to resolve the
> name rather
>     <br>
> than forward a large bundle to it.&nbsp; The result of the query can be one
> or more
>     <br>
> reachable-thru (or further resolvable-at) nodes.
>     <br>
>     <br>
>     <br>
>     <blockquote type="cite">The "reachable-thru" name, used here
> instead of "care-of", seems to me to more precisely describe the
> function of the header. I suppose that's up for debate.
>       <br>
>       <br>
> More importantly, I would like to discuss whether ordering should have
> significance. Intuitively, I think significance makes sense, but I'm
> certainly open to enlightenment on this issue.
>       <br>
>     </blockquote>
>     <br>
>     <br>
> Order is perhaps useful for "route-pinning".
>     <br>
>     <br>
>     <br>
>     <blockquote type="cite">If ordering is significant, the example
> above says that the destination is reachable through the internet, and
> the internet is reachable through the marineris relay. If there is no
> significance, it says that the destination is reachable both through
> the relay, and through the in.earth region.
>       <br>
>       <br>
> I can see benefits to both approaches. However, let's say a node along
> the path to the marineris relay happens to have a short route to a deep
> space antenna that can send direct to luna.earth.sol. With significance
> in ordering, it can know that the luna route to the internet is shorter
> than the marineris route. Thus, it would POP the marineris relay, and
> PUSH
>       <br>
>     </blockquote>
>     <br>
>     <br>
> Regarding source routes and more generally reachability advertisements,
>     <br>
> I agree there is benefit to both approaches. I would recommend
> considering an wider range (something analogous to the range of path
> vectors specified by BGP).
>     <br>
>     <br>
> &nbsp; - full path
>     <br>
> &nbsp; - a subset of nodes on path, that must be visited in specified
> sequence
>     <br>
> &nbsp; - a subset of nodes on path, all of which must be visited but in any
> order
>     <br>
> &nbsp; - a subset of nodes on path, some of which may be visited (hints,
> where
>     <br>
> &nbsp;&nbsp;&nbsp; significance is perhaps more helpful than ordering)
>     <br>
>     <br>
> I suppose a vector of resolvers could also be specified similarly.
>     <br>
>     <br>
>     <br>
>     <blockquote type="cite">reachable-thru: region://luna.earth.sol
>       <br>
>       <br>
> Without significance, the reachable-thru header says the final
> destination is reachable through the marineris relay, _and_ through the
> internet. Unless every node has routes to every EID, the current node
> cannot know whether the marineris relay route is any better than the
> in.earth route (without ordering, we don't know that the marineris
> route actually also goes through the in.earth region). Thus, it cannot
> remove the marineris relay from the list. Instead, it will simply add
> another reachable-thru header. This might end up being messy, perhaps
> even create loops.
>       <br>
>       <br>
> Thoughts?
>       <br>
>       <br>
> - Jakob
>       <br>
>     </blockquote>
>     <br>
>     <br>
> Best Regards,
>     <br>
> Rajesh
>     <br>
> _______________________________________________
>     <br>
> dtn-interest mailing list
>     <br>
> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
>     <br>
> <a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
>     <br>
>     <br>
>     <br>
>   </blockquote>
> _______________________________________________
>   <br>
> dtn-interest mailing list
>   <br>
> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
>   <br>
> <a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
>   <br>
> </blockquote>
> <br>
> <pre class="moz-signature" cols="72">-- 
> Howard Weiss
> SPARTA, Inc.
> 7075 Samuel Morse Drive
> Columbia, MD 21046
> 410.872.1515 x201
> 410.872.8079 (fax)
> 
> </pre>
> </body>
> </html>
> 
> --------------090001070406030704030306--
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Wed, 06 Apr 2005 09:07:07 -0400
From: Howard Weiss <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: [email-masked], Jakob Eriksson <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
Sender: [email-masked]

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

I agree with Stephen.  This is re-inventing loose source routing which, 
from a security perspective, is quite evil.

Howie

Stephen Farrell wrote:

>
> Isn't this creating a new set of security problems, or at
> least making it a good bit easier to exploit some existing
> ones?
>
> Probably in order of how much we'd care:
>
> - this seems to make it trivial for a DTN router to (accidentally
>   or deliberately) cause some other routers trouble, and in a
>   way that won't be easily visible from looking at most of the
>   bundles, e.g. if the best route is really a,b,c,d but 'b'
>   stands for 'bold' then we might end up with a,b,v,c,d, where
>   'v' stands for 'victim' and so that the bundles arriving at
>   'd' show no trace of the misbehaviour...at some point 'v'
>   runs out of battery...oops
> - you may not want to expose this much internal network
>   structure to the rest of the solar system, which is one
>   of the reasons that firewalls are (justifiably) so popular,
>   basically, each such header gives an on-path bad guy a
>   new potential target
> - it also offers misbehaving routers the opportunity to
>   cause trouble for certain nodes/applications, e.g. by
>   sending their bundles on long routes - say if a bundle
>   contains the result of a horse-race and I slow it down
>   enough to get that winning bet in (a *very* old fraud!),
>   while setting up a policy for this and/or detecting is
>   always fairly hard, we're making the attack easier and
>   the detection harder
> - pushing and popping headers like this creates a few really
>   cute covert channels, which might not make the tactical
>   networking folks too happy - there is even enough
>   flexibility there to actually run another DTN layer
>   between co-operating routers by piggybacking on real
>   traffic using those headers!
> - I could probably go on, but I won't!
>
> So, if you're adding all these routing headers, then I believe
> you have to provide ways to authenticate them. Now that can be
> done, but it bloats the headers again and fairly dramatically
> increases the complexity of what were formerly the relatively
> simple hop-by-hop security structures (the BAH I guess).
>
> I guess I'd question whether that much complexity is really
> worth it.
>
> Stephen.
>
> Rajesh Krishnan wrote:
>
>>> As discussed earlier, in addition to source-specified EID's that 
>>> determine where the bundle finally ends up, there needs to be a way 
>>> to provide "hints", "care-of addresses", 
>>> "intermediate-destinations", or "loose source-routes". As it turns 
>>> out, these all fit nicely into the same concept.
>>>
>>> Given the previous discussion, here is a header structure example 
>>> that would seem to make everybody happy:
>>>
>>> destination: pgp://<public key here>
>>> reachable-thru: region://in.earth.sol
>>> reachable-thru: region://relay.marineris.mars.sol
>>
>>
>>
>> I will make a distinction between "resolvable-at" and reachable-thru
>> (i.e. distinguish who knows where a node might be from who might 
>> deliver bundles to the node).
>>
>> In some network scenarios (as with the Internet today) some 
>> authoritative
>> naming infrastructure may be present. In other scenarios, some 
>> servers may be
>> elected to aggregate name resolution information (e.g. so that we may 
>> be able
>> to reconcile name KBs upon reconnection after a partitioning more 
>> efficiently
>> than having all nodes trying to reconcile).  There is some benefit to 
>> aggregating location hints at ``fixed points'' in the network.
>>
>> In the above cases, these "resolver" nodes may not necessarily be 
>> appropriate
>> nodes to route the bundle through.  An en route node that is strongly 
>> connected
>> to such a resolver may be able to send a query to it to resolve the 
>> name rather
>> than forward a large bundle to it.  The result of the query can be 
>> one or more
>> reachable-thru (or further resolvable-at) nodes.
>>
>>
>>> The "reachable-thru" name, used here instead of "care-of", seems to 
>>> me to more precisely describe the function of the header. I suppose 
>>> that's up for debate.
>>>
>>> More importantly, I would like to discuss whether ordering should 
>>> have significance. Intuitively, I think significance makes sense, 
>>> but I'm certainly open to enlightenment on this issue.
>>
>>
>>
>> Order is perhaps useful for "route-pinning".
>>
>>
>>> If ordering is significant, the example above says that the 
>>> destination is reachable through the internet, and the internet is 
>>> reachable through the marineris relay. If there is no significance, 
>>> it says that the destination is reachable both through the relay, 
>>> and through the in.earth region.
>>>
>>> I can see benefits to both approaches. However, let's say a node 
>>> along the path to the marineris relay happens to have a short route 
>>> to a deep space antenna that can send direct to luna.earth.sol. With 
>>> significance in ordering, it can know that the luna route to the 
>>> internet is shorter than the marineris route. Thus, it would POP the 
>>> marineris relay, and PUSH
>>
>>
>>
>> Regarding source routes and more generally reachability advertisements,
>> I agree there is benefit to both approaches. I would recommend 
>> considering an wider range (something analogous to the range of path 
>> vectors specified by BGP).
>>
>>   - full path
>>   - a subset of nodes on path, that must be visited in specified 
>> sequence
>>   - a subset of nodes on path, all of which must be visited but in 
>> any order
>>   - a subset of nodes on path, some of which may be visited (hints, 
>> where
>>     significance is perhaps more helpful than ordering)
>>
>> I suppose a vector of resolvers could also be specified similarly.
>>
>>
>>> reachable-thru: region://luna.earth.sol
>>>
>>> Without significance, the reachable-thru header says the final 
>>> destination is reachable through the marineris relay, _and_ through 
>>> the internet. Unless every node has routes to every EID, the current 
>>> node cannot know whether the marineris relay route is any better 
>>> than the in.earth route (without ordering, we don't know that the 
>>> marineris route actually also goes through the in.earth region). 
>>> Thus, it cannot remove the marineris relay from the list. Instead, 
>>> it will simply add another reachable-thru header. This might end up 
>>> being messy, perhaps even create loops.
>>>
>>> Thoughts?
>>>
>>> - Jakob
>>
>>
>>
>> Best Regards,
>> Rajesh
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">I agree with
Stephen.&nbsp; This is re-inventing loose source routing which, from a
security perspective, is quite evil.<br>
<br>
Howie<br>
</font></font><br>
Stephen Farrell wrote:<br>
<blockquote cite="[email-masked]" type="cite"><br>
Isn't this creating a new set of security problems, or at
  <br>
least making it a good bit easier to exploit some existing
  <br>
ones?
  <br>
  <br>
Probably in order of how much we'd care:
  <br>
  <br>
- this seems to make it trivial for a DTN router to (accidentally
  <br>
&nbsp; or deliberately) cause some other routers trouble, and in a
  <br>
&nbsp; way that won't be easily visible from looking at most of the
  <br>
&nbsp; bundles, e.g. if the best route is really a,b,c,d but 'b'
  <br>
&nbsp; stands for 'bold' then we might end up with a,b,v,c,d, where
  <br>
&nbsp; 'v' stands for 'victim' and so that the bundles arriving at
  <br>
&nbsp; 'd' show no trace of the misbehaviour...at some point 'v'
  <br>
&nbsp; runs out of battery...oops
  <br>
- you may not want to expose this much internal network
  <br>
&nbsp; structure to the rest of the solar system, which is one
  <br>
&nbsp; of the reasons that firewalls are (justifiably) so popular,
  <br>
&nbsp; basically, each such header gives an on-path bad guy a
  <br>
&nbsp; new potential target
  <br>
- it also offers misbehaving routers the opportunity to
  <br>
&nbsp; cause trouble for certain nodes/applications, e.g. by
  <br>
&nbsp; sending their bundles on long routes - say if a bundle
  <br>
&nbsp; contains the result of a horse-race and I slow it down
  <br>
&nbsp; enough to get that winning bet in (a *very* old fraud!),
  <br>
&nbsp; while setting up a policy for this and/or detecting is
  <br>
&nbsp; always fairly hard, we're making the attack easier and
  <br>
&nbsp; the detection harder
  <br>
- pushing and popping headers like this creates a few really
  <br>
&nbsp; cute covert channels, which might not make the tactical
  <br>
&nbsp; networking folks too happy - there is even enough
  <br>
&nbsp; flexibility there to actually run another DTN layer
  <br>
&nbsp; between co-operating routers by piggybacking on real
  <br>
&nbsp; traffic using those headers!
  <br>
- I could probably go on, but I won't!
  <br>
  <br>
So, if you're adding all these routing headers, then I believe
  <br>
you have to provide ways to authenticate them. Now that can be
  <br>
done, but it bloats the headers again and fairly dramatically
  <br>
increases the complexity of what were formerly the relatively
  <br>
simple hop-by-hop security structures (the BAH I guess).
  <br>
  <br>
I guess I'd question whether that much complexity is really
  <br>
worth it.
  <br>
  <br>
Stephen.
  <br>
  <br>
Rajesh Krishnan wrote:
  <br>
  <br>
  <blockquote type="cite">
    <blockquote type="cite">As discussed earlier, in addition to
source-specified EID's that determine where the bundle finally ends up,
there needs to be a way to provide "hints", "care-of addresses",
"intermediate-destinations", or "loose source-routes". As it turns out,
these all fit nicely into the same concept.
      <br>
      <br>
Given the previous discussion, here is a header structure example that
would seem to make everybody happy:
      <br>
      <br>
destination: pgp://&lt;public key here&gt;
      <br>
reachable-thru: region://in.earth.sol
      <br>
reachable-thru: region://relay.marineris.mars.sol
      <br>
    </blockquote>
    <br>
    <br>
I will make a distinction between "resolvable-at" and reachable-thru
    <br>
(i.e. distinguish who knows where a node might be from who might
deliver bundles to the node).
    <br>
    <br>
In some network scenarios (as with the Internet today) some
authoritative
    <br>
naming infrastructure may be present. In other scenarios, some servers
may be
    <br>
elected to aggregate name resolution information (e.g. so that we may
be able
    <br>
to reconcile name KBs upon reconnection after a partitioning more
efficiently
    <br>
than having all nodes trying to reconcile).&nbsp; There is some benefit to
aggregating location hints at ``fixed points'' in the network.
    <br>
    <br>
In the above cases, these "resolver" nodes may not necessarily be
appropriate
    <br>
nodes to route the bundle through.&nbsp; An en route node that is strongly
connected
    <br>
to such a resolver may be able to send a query to it to resolve the
name rather
    <br>
than forward a large bundle to it.&nbsp; The result of the query can be one
or more
    <br>
reachable-thru (or further resolvable-at) nodes.
    <br>
    <br>
    <br>
    <blockquote type="cite">The "reachable-thru" name, used here
instead of "care-of", seems to me to more precisely describe the
function of the header. I suppose that's up for debate.
      <br>
      <br>
More importantly, I would like to discuss whether ordering should have
significance. Intuitively, I think significance makes sense, but I'm
certainly open to enlightenment on this issue.
      <br>
    </blockquote>
    <br>
    <br>
Order is perhaps useful for "route-pinning".
    <br>
    <br>
    <br>
    <blockquote type="cite">If ordering is significant, the example
above says that the destination is reachable through the internet, and
the internet is reachable through the marineris relay. If there is no
significance, it says that the destination is reachable both through
the relay, and through the in.earth region.
      <br>
      <br>
I can see benefits to both approaches. However, let's say a node along
the path to the marineris relay happens to have a short route to a deep
space antenna that can send direct to luna.earth.sol. With significance
in ordering, it can know that the luna route to the internet is shorter
than the marineris route. Thus, it would POP the marineris relay, and
PUSH
      <br>
    </blockquote>
    <br>
    <br>
Regarding source routes and more generally reachability advertisements,
    <br>
I agree there is benefit to both approaches. I would recommend
considering an wider range (something analogous to the range of path
vectors specified by BGP).
    <br>
    <br>
&nbsp; - full path
    <br>
&nbsp; - a subset of nodes on path, that must be visited in specified
sequence
    <br>
&nbsp; - a subset of nodes on path, all of which must be visited but in any
order
    <br>
&nbsp; - a subset of nodes on path, some of which may be visited (hints,
where
    <br>
&nbsp;&nbsp;&nbsp; significance is perhaps more helpful than ordering)
    <br>
    <br>
I suppose a vector of resolvers could also be specified similarly.
    <br>
    <br>
    <br>
    <blockquote type="cite">reachable-thru: region://luna.earth.sol
      <br>
      <br>
Without significance, the reachable-thru header says the final
destination is reachable through the marineris relay, _and_ through the
internet. Unless every node has routes to every EID, the current node
cannot know whether the marineris relay route is any better than the
in.earth route (without ordering, we don't know that the marineris
route actually also goes through the in.earth region). Thus, it cannot
remove the marineris relay from the list. Instead, it will simply add
another reachable-thru header. This might end up being messy, perhaps
even create loops.
      <br>
      <br>
Thoughts?
      <br>
      <br>
- Jakob
      <br>
    </blockquote>
    <br>
    <br>
Best Regards,
    <br>
Rajesh
    <br>
_______________________________________________
    <br>
dtn-interest mailing list
    <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
    <br>
    <br>
    <br>
  </blockquote>
_______________________________________________
  <br>
dtn-interest mailing list
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
  <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a>
  <br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

--------------090001070406030704030306--

Date: Wed, 06 Apr 2005 12:41:09 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: Jakob Eriksson <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
Sender: [email-masked]

Isn't this creating a new set of security problems, or at
least making it a good bit easier to exploit some existing
ones?

Probably in order of how much we'd care:

- this seems to make it trivial for a DTN router to (accidentally
   or deliberately) cause some other routers trouble, and in a
   way that won't be easily visible from looking at most of the
   bundles, e.g. if the best route is really a,b,c,d but 'b'
   stands for 'bold' then we might end up with a,b,v,c,d, where
   'v' stands for 'victim' and so that the bundles arriving at
   'd' show no trace of the misbehaviour...at some point 'v'
   runs out of battery...oops
- you may not want to expose this much internal network
   structure to the rest of the solar system, which is one
   of the reasons that firewalls are (justifiably) so popular,
   basically, each such header gives an on-path bad guy a
   new potential target
- it also offers misbehaving routers the opportunity to
   cause trouble for certain nodes/applications, e.g. by
   sending their bundles on long routes - say if a bundle
   contains the result of a horse-race and I slow it down
   enough to get that winning bet in (a *very* old fraud!),
   while setting up a policy for this and/or detecting is
   always fairly hard, we're making the attack easier and
   the detection harder
- pushing and popping headers like this creates a few really
   cute covert channels, which might not make the tactical
   networking folks too happy - there is even enough
   flexibility there to actually run another DTN layer
   between co-operating routers by piggybacking on real
   traffic using those headers!
- I could probably go on, but I won't!

So, if you're adding all these routing headers, then I believe
you have to provide ways to authenticate them. Now that can be
done, but it bloats the headers again and fairly dramatically
increases the complexity of what were formerly the relatively
simple hop-by-hop security structures (the BAH I guess).

I guess I'd question whether that much complexity is really
worth it.

Stephen.

Rajesh Krishnan wrote:

>>As discussed earlier, in addition to source-specified EID's that 
>>determine where the bundle finally ends up, there needs to be a way to 
>>provide "hints", "care-of addresses", "intermediate-destinations", or 
>>"loose source-routes". As it turns out, these all fit nicely into the 
>>same concept.
>>
>>Given the previous discussion, here is a header structure example that 
>>would seem to make everybody happy:
>>
>>destination: pgp://<public key here>
>>reachable-thru: region://in.earth.sol
>>reachable-thru: region://relay.marineris.mars.sol
> 
> 
> I will make a distinction between "resolvable-at" and reachable-thru
> (i.e. distinguish who knows where a node might be from who might deliver 
> bundles to the node).
> 
> In some network scenarios (as with the Internet today) some authoritative
> naming infrastructure may be present. In other scenarios, some servers may be
> elected to aggregate name resolution information (e.g. so that we may be able
> to reconcile name KBs upon reconnection after a partitioning more efficiently
> than having all nodes trying to reconcile).  There is some benefit to 
> aggregating location hints at ``fixed points'' in the network.
> 
> In the above cases, these "resolver" nodes may not necessarily be appropriate
> nodes to route the bundle through.  An en route node that is strongly connected
> to such a resolver may be able to send a query to it to resolve the name rather
> than forward a large bundle to it.  The result of the query can be one or more
> reachable-thru (or further resolvable-at) nodes.
> 
> 
>>The "reachable-thru" name, used here instead of "care-of", seems to me 
>>to more precisely describe the function of the header. I suppose that's 
>>up for debate.
>>
>>More importantly, I would like to discuss whether ordering should have 
>>significance. Intuitively, I think significance makes sense, but I'm 
>>certainly open to enlightenment on this issue.
> 
> 
> Order is perhaps useful for "route-pinning".
> 
> 
>>If ordering is significant, the example above says that the destination 
>>is reachable through the internet, and the internet is reachable 
>>through the marineris relay. If there is no significance, it says that 
>>the destination is reachable both through the relay, and through the 
>>in.earth region.
>>
>>I can see benefits to both approaches. However, let's say a node along 
>>the path to the marineris relay happens to have a short route to a deep 
>>space antenna that can send direct to luna.earth.sol. With significance 
>>in ordering, it can know that the luna route to the internet is shorter 
>>than the marineris route. Thus, it would POP the marineris relay, and 
>>PUSH
> 
> 
> Regarding source routes and more generally reachability advertisements,
> I agree there is benefit to both approaches. I would recommend considering 
> an wider range (something analogous to the range of path vectors specified 
> by BGP).
> 
>   - full path
>   - a subset of nodes on path, that must be visited in specified sequence
>   - a subset of nodes on path, all of which must be visited but in any order
>   - a subset of nodes on path, some of which may be visited (hints, where
>     significance is perhaps more helpful than ordering)
> 
> I suppose a vector of resolvers could also be specified similarly.
> 
> 
>>reachable-thru: region://luna.earth.sol
>>
>>Without significance, the reachable-thru header says the final 
>>destination is reachable through the marineris relay, _and_ through the 
>>internet. Unless every node has routes to every EID, the current node 
>>cannot know whether the marineris relay route is any better than the 
>>in.earth route (without ordering, we don't know that the marineris 
>>route actually also goes through the in.earth region). Thus, it cannot 
>>remove the marineris relay from the list. Instead, it will simply add 
>>another reachable-thru header. This might end up being messy, perhaps 
>>even create loops.
>>
>>Thoughts?
>>
>>- Jakob
> 
> 
> Best Regards,
> Rajesh
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Date: Tue, 05 Apr 2005 16:43:51 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Sender: [email-masked]

Rajesh Krishnan wrote:
> I can imagine future reprogrammable nodes (perhaps based on software 
> radios) that can replace an existing interface with another type of 
> interface instantiated dynamically.  Another reason to keep the node
> name free of the interface name.
> 
> The interface notion is perhaps still useful as you point out.  The CL, 
> the CLAddress, the network interface (and other lower layer parameters 
> governing the adjacency) are needed as attributes to the DTN adjacency.
> 
> I am not sure if one interface per CL may be sufficient though.  For 
> example, as part of the interface notion, we need to include not only 
> the CL (as in TCPCL), and the CL address (as in 192.1.1.100), but perhaps 
> also which physical interface (as in /dev/eth0, a 1000-Base-T or the slower 
> 10Base-T /dev/eth1 management Ethernet) to use.  This suggests multiple
> interfaces per CL as a more natural abstraction.

I agree.  You wouldn't even have to have different types of physical interface; you might just have ordinary multihoming at the convergence layer, i.e., multiple IP addresses for multiple NICs, all with their own IP addresses, all of which might be on 100-Base-T.

Scott

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] DTN without regions - I think I get it
To: [email-masked] (Scott Burleigh)
Date: Tue, 5 Apr 2005 19:32:31 -0400 (EDT)
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

I can imagine future reprogrammable nodes (perhaps based on software 
radios) that can replace an existing interface with another type of 
interface instantiated dynamically.  Another reason to keep the node
name free of the interface name.

The interface notion is perhaps still useful as you point out.  The CL, 
the CLAddress, the network interface (and other lower layer parameters 
governing the adjacency) are needed as attributes to the DTN adjacency.

I am not sure if one interface per CL may be sufficient though.  For 
example, as part of the interface notion, we need to include not only 
the CL (as in TCPCL), and the CL address (as in 192.1.1.100), but perhaps 
also which physical interface (as in /dev/eth0, a 1000-Base-T or the slower 
10Base-T /dev/eth1 management Ethernet) to use.  This suggests multiple
interfaces per CL as a more natural abstraction.

Best Regards,
Rajesh

> > Keith,
> > 
> > I agree that a set rather than a single care-of is useful.  
> > 
> > As you point out, the destination name on the bundle header should get 
> > carried unmodified (from what is specified by the source application) 
> > through the network until it reaches the destination(s); the name as
> > an end-to-end identifier has useful diagnostic purposes.  Ideally this 
> > name should not be overloaed with extraneous semantics.  Having a 
> > separate (optional) resolution hints header that is modifiable en route 
> > would be useful for trying out naming/resolution approaches.  Such a 
> > header can carry information about the location of node (or the most 
> > specific subregion that contains it) or it can carry information about 
> > potential resolvers (e.g. other nodes in the region the destination
> > node is visiting).
> 
> I completely agree.
> 
> > On the issue of endpoint IDs, however, personally I would prefer a model 
> > in which nodes rather than interfaces had canonical names.
> 
> Actually, so would I.  I think we needed the named-interface, multihomed model when we were thinking in terms of regions as routing domains, with the admin-part of each endpoint ID being opaque to a bundle agent that was "outside" of the indicated region, because being "in" a region seemed to mean that the agent had to have an identity -- a named interface -- in that region.  But if we're now moving toward a more relaxed routing system, this requirement largely goes away.
> 
> It may still make sense for a single bundle agent to be reachable (addressable) by multiple endpoint IDs (maybe expressed in different schemas), but I think we could think of these multiple IDs as aliases for a single address rather than as multiple addresses.  It may be that we don't need a DTN analog for multihoming at all.
> 
> > Identifying nodes rather than interfaces better suits an "opportunistic overlay 
> > network" IMO.  Interface identifiers can be made suffixes or qualifiers
> > to the node name if needed.  
> > 
> > Per-interface identifiers are relevant at the level of link or adjacency;
> > they do not have much relevance network-wide especially in a highly dynamic 
> > overlay network that spans a variety of technologies.  A node X several 
> > hops away only cares about whether node Y can talk to node Z (and how 
> > well), not particularly, which transfer modes (IR, Bluetooth, WiFi 
> > etc.) are currently working/active between X and Y.
> > 
> > (To consider an analogy, it is more natural to say 
> >     "He needs to catch Flight 123 <nodename>" 
> >  rather than 
> >     "He needs to catch Flight 123 -- Front Door <interface name>." 
> > 
> >  In case they may board through the rear of the aircraft, we need 
> >  to say (as with IP networks today)
> >     "He needs to catch Flight 123 -- Front Door" and 
> >     "Flight 123 -- Front Door" is reachable from "Flight 123 -- Back Door". 
> > :)
> 
> A reasonable analogy, which I think makes the point well.
> 
> > Irrespective of whether DTN names are tied to nodes or interfaces, I 
> > propose that we adopt a canoncial name for each node based on which
> > forwarding decisions can be made remotely and interfaces can be
> > use locally in an opportunistic fashion.  I further propose that
> > the canonical name must be allowed to persist even if all interfaces 
> > on the node are completely replaced with others.
> 
> I'm beginning to think that we still need an "interface" notion but that it need not necessarily be exposed at the Bundling layer of the architecture.  As you point out, per-interface identifiers are relevant at the level of link or adjacency; in DTN terms, I believe this means "at the convergence layer".
> 
> Each of the convergence layer adapters available to a given bundle agent is perhaps an "interface" in this sense, but they don't need to have their own DTN endpoint IDs -- they just need endpoint identifiers in the address spaces of the transport-ish convergence-layer protocols they invoke.  And implementations need some way to map a next-hop destination bundle agent endpoint-ID to the interface (both source and destination convergence layer endpoints) that must be used in order to communicate with that agent; maybe something in the routing table.
> 
> Scott 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
To: [email-masked] (Jakob Eriksson)
Date: Tue, 5 Apr 2005 18:31:51 -0400 (EDT)
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

> As discussed earlier, in addition to source-specified EID's that 
> determine where the bundle finally ends up, there needs to be a way to 
> provide "hints", "care-of addresses", "intermediate-destinations", or 
> "loose source-routes". As it turns out, these all fit nicely into the 
> same concept.
>
> Given the previous discussion, here is a header structure example that 
> would seem to make everybody happy:
> 
> destination: pgp://<public key here>
> reachable-thru: region://in.earth.sol
> reachable-thru: region://relay.marineris.mars.sol

I will make a distinction between "resolvable-at" and reachable-thru
(i.e. distinguish who knows where a node might be from who might deliver 
bundles to the node).

In some network scenarios (as with the Internet today) some authoritative
naming infrastructure may be present. In other scenarios, some servers may be
elected to aggregate name resolution information (e.g. so that we may be able
to reconcile name KBs upon reconnection after a partitioning more efficiently
than having all nodes trying to reconcile).  There is some benefit to 
aggregating location hints at ``fixed points'' in the network.

In the above cases, these "resolver" nodes may not necessarily be appropriate
nodes to route the bundle through.  An en route node that is strongly connected
to such a resolver may be able to send a query to it to resolve the name rather
than forward a large bundle to it.  The result of the query can be one or more
reachable-thru (or further resolvable-at) nodes.

> The "reachable-thru" name, used here instead of "care-of", seems to me 
> to more precisely describe the function of the header. I suppose that's 
> up for debate.
> 
> More importantly, I would like to discuss whether ordering should have 
> significance. Intuitively, I think significance makes sense, but I'm 
> certainly open to enlightenment on this issue.

Order is perhaps useful for "route-pinning".

> If ordering is significant, the example above says that the destination 
> is reachable through the internet, and the internet is reachable 
> through the marineris relay. If there is no significance, it says that 
> the destination is reachable both through the relay, and through the 
> in.earth region.
> 
> I can see benefits to both approaches. However, let's say a node along 
> the path to the marineris relay happens to have a short route to a deep 
> space antenna that can send direct to luna.earth.sol. With significance 
> in ordering, it can know that the luna route to the internet is shorter 
> than the marineris route. Thus, it would POP the marineris relay, and 
> PUSH

Regarding source routes and more generally reachability advertisements,
I agree there is benefit to both approaches. I would recommend considering 
an wider range (something analogous to the range of path vectors specified 
by BGP).

  - full path
  - a subset of nodes on path, that must be visited in specified sequence
  - a subset of nodes on path, all of which must be visited but in any order
  - a subset of nodes on path, some of which may be visited (hints, where
    significance is perhaps more helpful than ordering)

I suppose a vector of resolvers could also be specified similarly.

> reachable-thru: region://luna.earth.sol
> 
> Without significance, the reachable-thru header says the final 
> destination is reachable through the marineris relay, _and_ through the 
> internet. Unless every node has routes to every EID, the current node 
> cannot know whether the marineris relay route is any better than the 
> in.earth route (without ordering, we don't know that the marineris 
> route actually also goes through the in.earth region). Thus, it cannot 
> remove the marineris relay from the list. Instead, it will simply add 
> another reachable-thru header. This might end up being messy, perhaps 
> even create loops.
> 
> Thoughts?
> 
> - Jakob

Best Regards,
Rajesh

Date: Tue, 05 Apr 2005 15:16:34 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Kevin Fall wrote:
>>> This approach essentially moves the complexity of choosing good 
>>> sizes for bundles out to the application.
>> 
>> Not necessarily.  It moves responsibility for choosing good bundle
>>  payload sizes out of Bundling to a higher layer of protocol, which
>>  might be the application (in cases where the application knows how
>>  to make that kind of decision, as I described) or might be a
>> simple "DTN Segmentation" protocol or "DTN Erasure Coding"
>> protocol.  In the latter cases the function remains part of the DTN
>> arch itecture; it merely moves out of the Bundling protocol.
> 
> How does this hypothetical protocol reason about the contact volumes?

How does proactive fragmentation in bundling do it?  We're still in the DTN architecture, just in a different layer of protocol.

>>> It also appears to suggest there is some maximum size for 
>>> bundles.
>> 
>> I don't think so, at least not beyond the limit we already impose 
>> (4 GB).  It does suggest that for various reasons there is a 
>> maximum *useful* bundle size, which may vary according to 
>> circumstances, and I think that by defining fragmentation 
>> procedures the architecture already endorses that suggestion.
> 
> Seems to me 4GB is overly small. But beyond that, how does one 
> determine the 'useful size' [which varies in different 
> circumstances]?

Again, how does proactive fragmentation in bundling do it?  We're still in the DTN architecture, just in a different layer of protocol.

>>> My argument is that there are a number of entirely valid motives
>>>  for splintering transmitted data in various ways, but that all
>>> of those motives can and should - be addressed at other layers of
>>>  the stack.  If that is done, then by removing fragmentation from
>>>  Bundling we give up no meaningful functionality but gain 
>>> considerable simplicity and robustness.
>>> 
>>> I do not understand how an application can be expected to make a
>>>  good choice about the size of a bundle.  Your approach requires
>>>  this, right?
>> 
>> Not necessarily, as noted above.  But I already know of 
>> applications that know how to make a good choice about the size of 
>> a bundle payload.  As I mentioned , CFDP already does file 
>> segmentation on record boundaries, where the record structure of 
>> the file may vary according to the nature of the data.  A messaging
>> protocol like the proposed AMS would probably not segment messages
>> at all, but in my experience those messages are likely to be small
>> enough not to benefit from segmentation anyway.
> 
> But many apps will presumably have an adu size that could be big and
> the app doesn't [shouldn't] know enough about the network to make 
> good decisions about splitting across multiple paths, etc.

Okay, maybe in some environments the apps run on top of DTN Segmentation, which splits up ADUs that it knows are too big.

>> And as Matt Miller notes, video streaming effectively segments 
>> continuous video into video frames, the natural granularity of data
>>  delivery for this application.  Certainly the segments in this 
>> case might be very large, but I'm guessing that video streaming 
>> would likely be supported in environments where that large segment 
>> size isn't a problem: your data rate and processing rate are so 
>> high that you don't worry about bandwidth waste on loss of link, 
>> cut-through routing latency, etc.  The change I'm proposing doesn't
>>  limit bundle payload size, it just moves bundle payload size 
>> decisions out of Bundling itself.
> 
> i don't agree-- there are environments (I have seen) that is sending
>  video over underwater acoustic modems...  it is not interactive 
> video--

I don't understand what you're disagreeing with here.

> besides, removing the segmenting from the routing has the problems I
>  have mentioned above twice [and will say again next]

I don't think you've identified any problems.  The way you implement route computation and the way you implement proactive fragmentation may be related, or they may not; in the deep space environment, for example, I doubt that either will affect the other.  But if you do have that requirement then you just implement them that way.  That doesn't have any implications for the structure of the protocol data units.

>>> Unlike in the IP architecture, though, in the DTN architecture we
>>>  already have a well-established notion of an explicit 
>>> "convergence layer" at which mediation between the Bundling 
>>> protocol and the underlying transport protocol (e.g., TCP/IP or 
>>> LTP or Proximity-1) is implemented in a protocol-specific manner.
>>>  The convergence layer adapter for each convergence layer 
>>> protocol already splinters bundles into chunks small enough to be
>>>  conveyed in the PDUs of that specific protocol (as specifically 
>>> configured at that locale) and reassembles those chunks into the 
>>> original bundle at the next bundle agent in the end-to-end path. 
>>> There's no need for Bundling to do it.
> 
>>> This is not true.  If I have a large (or maybe even smallish) 
>>> message and wish to send it over multiple technologies [conv. 
>>> layers] simultaneously, this won't work.
>> 
>> Sure it will.  The TCP conversion layer adapter will transmit it in
>>  segments whose size is determined by the TCP implementation.  The 
>> UDP conversion layer a dapter will transmit it in UDP datagrams 
>> whose size is limited by the UDP protocol design (and usually also 
>> by the implementation).  The LTP conversion layer adapters will 
>> transmit it in segments whose size is determined by the LTP 
>> configuration.  Every one of these convergence layer adapters will 
>> splinter the original message into some number of smaller chunks 
>> and reassemble it in order to pass it up to the next-hop bundle 
>> agent.
> 
> We are not talking about the same thing I think.  Consider a bundle 
> of size M bytes. and I wish to send this over two contacts (which, 
> for this dicussion, will require 2 CLs).  The two CL's operate over 
> links with different capacities (say, approx Xbps and 10Xbps). I wish
>  to send the first .1*M bytes over the first CL/link and the other 
> .9*M bytes over the second CL/link -at the same time-. The reason I 
> am able to make this *routing and splitting* decision is because 
> bundling understands the idea of link capacities and dividing a 
> bundle into appropriate-sized parts that can be given to appropriate
>  CLs.

Okay, when you express the problem this way I agree that you can't place the segmentation responsibility on the convergence layer adapters.  I would suggest that in this case the hypothetical DTN Segmentation protocol operating above Bundling -- which is part of the DTN architecture, and which knows about link capacities -- notices that the dynamic range in link capacity is 1:10, so it segments the original payload into 10 ADUs which get encapsulated in 10 bundles.  The routing function of Bundling balances the load on the two links by sending one of the 10 bundles on the slow link and the other 9 on the fast link.

>>> In addition, if you have a set of contact volumes to fill, the 
>>> amount of data to send over which CL's will be dictated by the 
>>> volumes available and the CoS markings on the traffic to be sent.
>>>  That information will not typically be buried in the CL.
>> 
>> Sure, but that's a routing concern.  It's not affected by whatever
>> fragmentation will be done at the convergence layer.
> 
> !?!  Yes absolutely.  Its a routing concern.  Fragmentation is a 
> *routing* concern... {recall the discussions about optimal split 
> sizes and the sigcomm 04 paper}

Sure, I see your point now, and I agree that it's something that's appropriate for DTN to address.  Again, it doesn't have to happen in the Bundling protocol.

>>> -	In interplanetary internet deployments, I expect two protocols
>>>  to have direct interfaces to Bundling: AMS (Asynchronous Message
>>>  Service) and CFDP (CCSDS File Delivery Protocol).  AMS is likely
>>>  to be used for transmission of engineering telemetry samples and
>>>  "real-time" commands which are very likely to be brief, in the 
>>> range 0-64K bytes.  Large data objects such as software uploads 
>>> and camera images will almost certainly be stored in files before
>>>  transmission.  CFDP will likely be used for transmission of 
>>> those files, and CFDP does its own segmentation of files on 
>>> record boundaries that are meaningful to the application (so 
>>> that, for example, "quick look" review of individual complete 
>>> scan lines for a partially received image can begin long before 
>>> the complete picture arrives); CFDP file data segments will be 
>>> the payloads of bundles, and they are limited to 64K bytes each.
>>> 
>>> That's all fine, but 'so what?'  If you have a large data file 
>>> you want to move from one place to another, wouldn't it just be 
>>> nice to have the delivery system do it for you?  Couldn't you 
>>> just do away with cfdp then?  And wouldn't that be better?
>> 
>> No, no more than it would be better to put all of the functionality
>>  of FTP and SMTP into Bundling and just do away with those
>> protocols as well.  Reducing the number of protocols you use
>> doesn't simplify anything, it just makes the complexity harder to
>> manage.  It isn't nice at all.
> 
> Well, this is philosophical I guess.  But it relates to the question 
> "what goes in the kernel".  It used to be the answer was sort of 
> 'what you want to run fast'. As that is somewhat less of a concern 
> these days, the other big one is 'stuff you don't think applications
>  should have to re-invent'. Same goes here.

I don't understand why putting this stuff in a separate DTN Segmentation protocol, which applications don't have to re-invent, is any less effective than putting it into the Bundling protocol, which applications don't have to re-invent.  It just partitions the problem, making the architecture more flexible and more robust.  Which, I agree, is largely a matter of philosophical preference.

Scott

To: Scott Burleigh <[email-masked]>
cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation 
Date: Tue, 05 Apr 2005 14:27:36 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Scott Burleigh <[email-masked]>
> To:    DTN <[email-masked]>
> Subject: Re: [dtn-interest] on ditching fragmentation
> Date:  Tue, 05 Apr 2005 08:55:39 PDT
>
> Kevin Fall wrote:
> > *As threatened: I propose that we remove fragmentation, in all forms, from 
the 
> > *Bundling protocol.  I know, nobody wants to hear this, but I want to at le
ast 
> > *lay out the case.
> > 
> > This approach essentially moves the complexity of choosing good sizes
> > for bundles out to the application.
> 
> Not necessarily.  It moves responsibility for choosing good bundle payload si
zes out of Bundling to a higher layer of protocol, which might be the applicati
on (in cases where the application knows how to make that kind of decision, as 
I described) or might be a simple "DTN Segmentation" protocol or "DTN Erasure C
oding" protocol.  In the latter cases the function remains part of the DTN arch
itecture; it merely moves out of the Bundling protocol.

How does this hypothetical protocol reason about the contact volumes?

> 
> > It also appears to suggest there is some maximum size for bundles.
> 
> I don't think so, at least not beyond the limit we already impose (4 GB).  It
 does suggest that for various reasons there is a maximum *useful* bundle size,
 which may vary according to circumstances, and I think that by defining fragme
ntation procedures the architecture already endorses that suggestion.

Seems to me 4GB is overly small. But beyond that, how does one determine
the 'useful size' [which varies in different circumstances]?

> 
> > *
> > *My argument is that there are a number of entirely valid motives for 
> > * splintering transmitted data in various ways,
> > * but that all of those motives can
> > * and should - be addressed at other layers of the stack.  If that is done,
 
> > *then by removing fragmentation from Bundling we give up no meaningful 
> > *functionality but gain considerable simplicity and robustness.
> > 
> > I do not understand how an application can be expected to make
> > a good choice about the size of a bundle.  Your approach
> > requires this, right?
> 
> Not necessarily, as noted above.  But I already know of applications that kno
w how to make a good choice about the size of a bundle payload.  As I mentioned
, CFDP already does file segmentation on record boundaries, where the record st
ructure of the file may vary according to the nature of the data.  A messaging 
protocol like the proposed AMS would probably not segment messages at all, but 
in my experience those messages are likely to be small enough not to benefit fr
om segmentation anyway.

But many apps will presumably have an adu size that could be big and the
app doesn't [shouldn't] know enough about the network to make good decisions
about splitting across multiple paths, etc.
> 
> And as Matt Miller notes, video streaming effectively segments continuous vid
eo into video frames, the natural granularity of data delivery for this applica
tion.  Certainly the segments in this case might be very large, but I'm guessin
g that video streaming would likely be supported in environments where that lar
ge segment size isn't a problem: your data rate and processing rate are so high
 that you don't worry about bandwidth waste on loss of link, cut-through routin
g latency, etc.  The change I'm proposing doesn't limit bundle payload size, it
 just moves bundle payload size decisions out of Bundling itself.

i don't agree-- there are environments (I have seen) that is sending video
over underwater acoustic modems...  it is not interactive video--

besides, removing the segmenting from the routing has the problems I have
mentioned above twice [and will say again next]
> 
> > *is necessary because the protocol data units of the data-link-layer 
> > *protocols underneath IP may in some cases be too small to encapsulate enti
re IP
> > *datagrams: the datagram must be split into multiple fragments, each small 
> > *enough to fit into a link-layer protocol packet, and the original datagram
 must
> > *be reassembled from these fragments before delivery to the upper-layer pro
tocol
> > *(usually TCP).  IP itself performs this fragmentation and reassembly.
> > 
> > yup... and only at the source for ipv6
> > 
> > *
> > *DTN faces the same requirement: the protocol data units of the transport 
> > *protocols underneath Bundling may be too small to encapsulate entire bundl
es, 
> > *so the bundle must be fragmented for transmission.
> > 
> > in some cases this is true, but I don't think its the most
> > common or interesting cases
> 
> I think it happens in essentially every DTN demonstration we've executed to d
ate.  At this point we only convey bundles over Internet stacks, which means th
at every bundle of even moderate size gets chopped up into IP-datagram-sized pi
eces, one way or another.

Not really sure why this matters... just because we have only run over
tcp/ip doesn't mean we only wish to run over tcp/ip

> 
> > *Unlike in the IP 
> > *architecture, though, in the DTN architecture we already have a 
> > *well-established notion of an explicit "convergence layer" at which mediat
ion 
> > *between the Bundling protocol and the underlying transport protocol (e.g.,
 
> > *TCP/IP or LTP or Proximity-1) is implemented in a protocol-specific manner
.  
> > *The convergence layer adapter for each convergence
> > *layer protocol already splinters bundles into chunks small enough to be 
> > *conveyed in the PDUs of that specific protocol (as specifically configured
 at 
> > *that locale) and reassembles those chunks into the original bundle at the 
next 
> > *bundle agent in the end-to-end path.  There's no need for Bundling to do i
t.
> > 
> > This is not true.  If I have a large (or maybe even smallish) message
> > and wish to send it over multiple technologies [conv. layers]
> > simultaneously, this won't work.
> 
> Sure it will.  The TCP conversion layer adapter will transmit it in segments 
whose size is determined by the TCP implementation.  The UDP conversion layer a
dapter will transmit it in UDP datagrams whose size is limited by the UDP proto
col design (and usually also by the implementation).  The LTP conversion layer 
adapters will transmit it in segments whose size is determined by the LTP confi
guration.  Every one of these convergence layer adapters will splinter the orig
inal message into some number of smaller chunks and reassemble it in order to p
ass it up to the next-hop bundle agent.

We are not talking about the same thing I think.  Consider a bundle of size M bytes.
and I wish to send this over two contacts (which, for this dicussion, will require
2 CLs).  The two CL's operate over links with different capacities (say, approx Xbps and 10Xbps).
I wish to send the first .1*M bytes over the first CL/link and the
other .9*M bytes over the second CL/link -at the same time-.
The reason I am able to make this *routing and splitting* decision is because bundling
understands the idea of link capacities and dividing a bundle into appropriate-sized parts that
can be given to appropriate CLs.

> 
> > In addition, if you have a set of contact volumes to fill, the amount
> > of data to send over which CL's will be dictated by the volumes available
> > and the CoS markings on the traffic to be sent.  That information will not
> > typically be buried in the CL.
> 
> Sure, but that's a routing concern.  It's not affected by whatever fragmentat
ion will be done at the convergence layer.

!?!  Yes absolutely.  Its a routing concern.  Fragmentation is a *routing* concern...
{recall the discussions about optimal split sizes and the sigcomm 04 paper}

> > *-	In interplanetary internet deployments, I expect two protocols to have 
> > *direct interfaces to Bundling: AMS (Asynchronous Message Service) and CFDP
 
> > *(CCSDS File Delivery Protocol).  AMS is likely to be used for transmission
 of 
> > *engineering telemetry samples and "real-time" commands which are very like
ly to 
> > *be brief, in the range 0-64K bytes.  Large data objects such as software 
> > *uploads and camera images will almost certainly be stored in files before 
> > *transmission.  CFDP will likely be used for transmission of those files, a
nd 
> > *CFDP does its own segmentation of files on record boundaries that are 
> > *meaningful to the application (so that, for example, "quick look" review o
f 
> > *individual complete scan lines for a partially received image can begin lo
ng 
> > *before the complete picture arrives); CFDP file data segments will be the 
> > *payloads of bundles, and they are limited to 64K bytes each.
> > 
> > That's all fine, but 'so what?'  If you have a large data file
> > you want to move from one place to another, wouldn't it just
> > be nice to have the delivery system do it for you?  Couldn't you
> > just do away with cfdp then?  And wouldn't that be better?
> 
> No, no more than it would be better to put all of the functionality of FTP an
d SMTP into Bundling and just do away with those protocols as well.  Reducing t
he number of protocols you use doesn't simplify anything, it just makes the com
plexity harder to manage.  It isn't nice at all.

Well, this is philosophical I guess.  But it relates to the question
"what goes in the kernel".  It used to be the answer was sort of 'what you want to run fast'.
As that is somewhat less of a concern these days, the other big one is
'stuff you don't think applications should have to re-invent'.
Same goes here.
> 
> > *-	In sensor network deployments, I would again expect bundle payloads to 
> > *be small because the observations transmitted by participating motes are l
ikely 
> > *to be small, because resources on motes are limited.
> > 
> > This is not the only case.  There are sensors [e.g. sonar] that
> > provide much more data and do not operate in
> > bandwidth constrained networks.  Indeed the 'mule' scenarios might
> > provide vary large bandwidths.
> > 
> > *
> > *-	In mobile tactical network deployments, I would again expect bundle 
> > *payloads to be relatively small in many cases.  I think I've heard Bob men
tion 
> > *"100-bit messages" a number of times.
> > *
> > *Even in resource-rich environments I don't see any particular advantage to
 
> > *encapsulating a single huge data object within a single huge Bundle.  I th
ink 
> > *users might often want to invoke application-specific segmentation rules (
as in 
> > *CFDP) to control the granularity of data delivery.
> > *
> > *In any event it would not be difficult to insert a simple, general-purpose
 DTN 
> > *Fragmentation protocol -- above Bundling, not within it -- for environment
s in 
> > *which no application-specific mechanism limits payload size.  [And, 
> > *alternatively, it would be equally easy to insert a DTN Erasure Coding pro
tocol 
> > *at the same layer.  Erasure code blocks would be encapsulated in bundles f
or 
> > *forwarding through the network, in pretty much the same way that Digital 
> > *Fountain code blocks are encapsulated in IP datagrams for forwarding throu
gh 
> > *the Internet.]
> > *
> > *If bundle payloads were not huge, I think our remaining motivations for do
ing 
> > *fragmentation within Bundling would all go away.
> > 
> > I do not think that is true.  To me, fragmentation is intimitely
> > tied in with routing.  This is probably a restatement from
> > above, but for scheduled contacts, it is the mechanism
> > by which contacts are efficiently filled.  It is used by multi-path
> > routing to send chunks across multiple links simultaneously.
> > The size of the chunks are chosen by the router [bundle layer] and
> > may be sent over multiple convergence layers simultaneously [thus
> > suggesting it should be above them].
> 
> Okay but, as I think I showed above, transmitting the same data over a variet
y of different convergence-layer adapters is no problem.  In fact, I think you 
get better network utilization because the CL-specific adapters know what fragm
ent sizes work best in their specific environments; you avoid the one-size-fits
-all problem, where the CL adapter has to further fragment a fragmentary bundle
 because Bundling didn't pick a small enough fragment size for that CL's MTU.

See my clarification above.  I think we are talking about different things.

- K

From: Jakob Eriksson <[email-masked]>
Date: Tue, 5 Apr 2005 11:33:12 -0700
To: [email-masked]
Subject: [dtn-interest] Care-of / reachable-thru EIDs - is ordering significant?
Sender: [email-masked]

As discussed earlier, in addition to source-specified EID's that 
determine where the bundle finally ends up, there needs to be a way to 
provide "hints", "care-of addresses", "intermediate-destinations", or 
"loose source-routes". As it turns out, these all fit nicely into the 
same concept.

Given the previous discussion, here is a header structure example that 
would seem to make everybody happy:

destination: pgp://<public key here>
reachable-thru: region://in.earth.sol
reachable-thru: region://relay.marineris.mars.sol

The "reachable-thru" name, used here instead of "care-of", seems to me 
to more precisely describe the function of the header. I suppose that's 
up for debate.

More importantly, I would like to discuss whether ordering should have 
significance. Intuitively, I think significance makes sense, but I'm 
certainly open to enlightenment on this issue.

If ordering is significant, the example above says that the destination 
is reachable through the internet, and the internet is reachable 
through the marineris relay. If there is no significance, it says that 
the destination is reachable both through the relay, and through the 
in.earth region.

I can see benefits to both approaches. However, let's say a node along 
the path to the marineris relay happens to have a short route to a deep 
space antenna that can send direct to luna.earth.sol. With significance 
in ordering, it can know that the luna route to the internet is shorter 
than the marineris route. Thus, it would POP the marineris relay, and 
PUSH

reachable-thru: region://luna.earth.sol

Without significance, the reachable-thru header says the final 
destination is reachable through the marineris relay, _and_ through the 
internet. Unless every node has routes to every EID, the current node 
cannot know whether the marineris relay route is any better than the 
in.earth route (without ordering, we don't know that the marineris 
route actually also goes through the in.earth region). Thus, it cannot 
remove the marineris relay from the list. Instead, it will simply add 
another reachable-thru header. This might end up being messy, perhaps 
even create loops.

Thoughts?

- Jakob

Date: Tue, 05 Apr 2005 11:15:34 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Sender: [email-masked]

Rajesh Krishnan wrote:
> Keith,
> 
> I agree that a set rather than a single care-of is useful.  
> 
> As you point out, the destination name on the bundle header should get 
> carried unmodified (from what is specified by the source application) 
> through the network until it reaches the destination(s); the name as
> an end-to-end identifier has useful diagnostic purposes.  Ideally this 
> name should not be overloaed with extraneous semantics.  Having a 
> separate (optional) resolution hints header that is modifiable en route 
> would be useful for trying out naming/resolution approaches.  Such a 
> header can carry information about the location of node (or the most 
> specific subregion that contains it) or it can carry information about 
> potential resolvers (e.g. other nodes in the region the destination
> node is visiting).

I completely agree.

> On the issue of endpoint IDs, however, personally I would prefer a model 
> in which nodes rather than interfaces had canonical names.

Actually, so would I.  I think we needed the named-interface, multihomed model when we were thinking in terms of regions as routing domains, with the admin-part of each endpoint ID being opaque to a bundle agent that was "outside" of the indicated region, because being "in" a region seemed to mean that the agent had to have an identity -- a named interface -- in that region.  But if we're now moving toward a more relaxed routing system, this requirement largely goes away.

It may still make sense for a single bundle agent to be reachable (addressable) by multiple endpoint IDs (maybe expressed in different schemas), but I think we could think of these multiple IDs as aliases for a single address rather than as multiple addresses.  It may be that we don't need a DTN analog for multihoming at all.

> Identifying nodes rather than interfaces better suits an "opportunistic overlay 
> network" IMO.  Interface identifiers can be made suffixes or qualifiers
> to the node name if needed.  
> 
> Per-interface identifiers are relevant at the level of link or adjacency;
> they do not have much relevance network-wide especially in a highly dynamic 
> overlay network that spans a variety of technologies.  A node X several 
> hops away only cares about whether node Y can talk to node Z (and how 
> well), not particularly, which transfer modes (IR, Bluetooth, WiFi 
> etc.) are currently working/active between X and Y.
> 
> (To consider an analogy, it is more natural to say 
>     "He needs to catch Flight 123 <nodename>" 
>  rather than 
>     "He needs to catch Flight 123 -- Front Door <interface name>." 
> 
>  In case they may board through the rear of the aircraft, we need 
>  to say (as with IP networks today)
>     "He needs to catch Flight 123 -- Front Door" and 
>     "Flight 123 -- Front Door" is reachable from "Flight 123 -- Back Door". 
> :)

A reasonable analogy, which I think makes the point well.

> Irrespective of whether DTN names are tied to nodes or interfaces, I 
> propose that we adopt a canoncial name for each node based on which
> forwarding decisions can be made remotely and interfaces can be
> use locally in an opportunistic fashion.  I further propose that
> the canonical name must be allowed to persist even if all interfaces 
> on the node are completely replaced with others.

I'm beginning to think that we still need an "interface" notion but that it need not necessarily be exposed at the Bundling layer of the architecture.  As you point out, per-interface identifiers are relevant at the level of link or adjacency; in DTN terms, I believe this means "at the convergence layer".

Each of the convergence layer adapters available to a given bundle agent is perhaps an "interface" in this sense, but they don't need to have their own DTN endpoint IDs -- they just need endpoint identifiers in the address spaces of the transport-ish convergence-layer protocols they invoke.  And implementations need some way to map a next-hop destination bundle agent endpoint-ID to the interface (both source and destination convergence layer endpoints) that must be used in order to communicate with that agent; maybe something in the routing table.

Scott 

From: "franz" <[email-masked]>
To: <[email-masked]>
Date: Wed, 6 Apr 2005 20:15:41 +0200
Subject: [dtn-interest] DTN and Mobility/Security Paper
Sender: [email-masked]

Hi all,

my name is Franz and i am a working student at Siemens Munich.
A fellow student and me want to write a paper about
DTN and certain mobility and security issues.

Currently i am reading the document which are available on the main site and
combing through the mailing list archive.
The latter is the reason for my first question:
I've read that "regional identifiers" like they are described in the
official documents
will change. However i haven't found the description how exactly the new
definition will look like.

Could somebody please give a short description or point me to the
link in the mailing archive where it is described?
I haven't found any hard definition, just that it is "in the air" or
something

Thanx in advance

Regards
Franz Muenz

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] DTN without regions - I think I get it
To: [email-masked] (Scott, Keith L.)
Date: Tue, 5 Apr 2005 13:47:48 -0400 (EDT)
Cc: [email-masked], [email-masked] ('Matt Bradbury'), [email-masked] ('Jakob Eriksson'), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Keith,

I agree that a set rather than a single care-of is useful.  

As you point out, the destination name on the bundle header should get 
carried unmodified (from what is specified by the source application) 
through the network until it reaches the destination(s); the name as
an end-to-end identifier has useful diagnostic purposes.  Ideally this 
name should not be overloaed with extraneous semantics.  Having a 
separate (optional) resolution hints header that is modifiable en route 
would be useful for trying out naming/resolution approaches.  Such a 
header can carry information about the location of node (or the most 
specific subregion that contains it) or it can carry information about 
potential resolvers (e.g. other nodes in the region the destination
node is visiting).

On the issue of endpoint IDs, however, personally I would prefer a model 
in which nodes rather than interfaces had canonical names.  Identifying 
nodes rather than interfaces better suits an "opportunistic overlay 
network" IMO.  Interface identifiers can be made suffixes or qualifiers
to the node name if needed.  

Per-interface identifiers are relevant at the level of link or adjacency;
they do not have much relevance network-wide especially in a highly dynamic 
overlay network that spans a variety of technologies.  A node X several 
hops away only cares about whether node Y can talk to node Z (and how 
well), not particularly, which transfer modes (IR, Bluetooth, WiFi 
etc.) are currently working/active between X and Y.

(To consider an analogy, it is more natural to say 
    "He needs to catch Flight 123 <nodename>" 
 rather than 
    "He needs to catch Flight 123 -- Front Door <interface name>." 

 In case they may board through the rear of the aircraft, we need 
 to say (as with IP networks today)
    "He needs to catch Flight 123 -- Front Door" and 
    "Flight 123 -- Front Door" is reachable from "Flight 123 -- Back Door". 
:)

Irrespective of whether DTN names are tied to nodes or interfaces, I 
propose that we adopt a canoncial name for each node based on which
forwarding decisions can be made remotely and interfaces can be
use locally in an opportunistic fashion.  I further propose that
the canonical name must be allowed to persist even if all interfaces 
on the node are completely replaced with others.

Best Regards,
Rajesh

> Thanks Rajesh, this brings up something I wanted to avoid in my previous
> posting in order to preserve clarity.   If the endpoint identifier is not a
> _single_ URI but a set of them, then it should be easy to implement the
> hints notion you mention.  There would likely be (might be?) one 'main'
> endpoint identifier and a lot of 'ancillary' information, and whether all he
> ancillary information shows up with the main ID or in a separate header
> probably has security implications (as does anything in the bundle header
> that's mutable en-route).
> 
> Using this method, a bundle router could examine the set of URIs in the
> destination (or reply-to, etc.) identifier and make a routing decision based
> on whatever information it understood.  The reason for suggesting a set of
> URIs (at least conceptually) rather than piling all the ancillary
> information into a single URI along with the 'primary destination' (if such
> exists) is to make it clear that if there is some information that the
> router doesn't understand, it's free to ignore it.  [As an aside, yes, such
> a mechanism could be accommodated by using a single schema for endpoint
> identifiers that included semantics for encapsulating a set of URIs.
> Implementation not the point here.]
> 
> 		--keith
> 
> >-----Original Message-----
> >From: [email-masked] 
> >[mailto:[email-masked]] On Behalf Of 
> >Rajesh Krishnan
> >Sent: Monday, April 04, 2005 7:38 PM
> >To: Matt Bradbury
> >Cc: Jakob Eriksson; [email-masked]
> >Subject: Re: [dtn-interest] DTN without regions - I think I get it
> >
> >> > <snip>
> >> >
> >> > Note that this is different from the "care-of" address that Scott 
> >> > suggested, or the "reply-to" address that has also been suggested 
> >> > earlier. The intermediate-destination merely states that "this is 
> >> > where the packet is going right now". Once the packet gets 
> >there, it 
> >> > may very well be replaced by some new intermediate destination.
> >> >
> >> > - Jakob
> >> 
> >> What about some kind of encapsulation instead?  Tunneling I 
> >think will 
> >> have it's place.  But is it at a higher layer or in the bundle layer.
> >> 
> >> -Matt
> >
> >If using _strict_ encapsulation, every router en route will typically 
> >attempt to send it to the care-of destination.
> >
> >If using hints (to a potential care-of location, where further 
> >resolution 
> >of the name can take place, distinct from the destination), 
> >nodes en route 
> >to the care-of could change the care-of address based on 
> >better knowledge, 
> >e.g. of
> >
> >  - current location of the destination, 
> >  - current location/status of the indicated care-of, OR
> >  - a node known to be able to (or has access to a resolver that can) 
> >    resolve (more of) the destination name
> >
> >Suppose an en route node heard a recent location update for 
> >the destination 
> >(that was not yet known to the hint-provider/encapsulator when 
> >it forwarded 
> >the bundle), or the happenstance in which the en route node 
> >actually has 
> >an opportunsitic link/path to the destination.  If using 
> >encapsulation, the 
> >en route node must forward it to the specified intermediate 
> >endpoint even 
> >though it knows better.
> >
> >Hints may be useful to deal with the partial knowledge induced 
> >by mobililty, 
> >and potentially avoid some telescoping of routes.
> >
> >-Rajesh
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
> 
> 

Date: Tue, 05 Apr 2005 08:55:39 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Kevin Fall wrote:
> *As threatened: I propose that we remove fragmentation, in all forms, from the 
> *Bundling protocol.  I know, nobody wants to hear this, but I want to at least 
> *lay out the case.
> 
> This approach essentially moves the complexity of choosing good sizes
> for bundles out to the application.

Not necessarily.  It moves responsibility for choosing good bundle payload sizes out of Bundling to a higher layer of protocol, which might be the application (in cases where the application knows how to make that kind of decision, as I described) or might be a simple "DTN Segmentation" protocol or "DTN Erasure Coding" protocol.  In the latter cases the function remains part of the DTN architecture; it merely moves out of the Bundling protocol.

> It also appears to suggest there is some maximum size for bundles.

I don't think so, at least not beyond the limit we already impose (4 GB).  It does suggest that for various reasons there is a maximum *useful* bundle size, which may vary according to circumstances, and I think that by defining fragmentation procedures the architecture already endorses that suggestion.

> *
> *My argument is that there are a number of entirely valid motives for 
> * splintering transmitted data in various ways,
> * but that all of those motives can
> * and should - be addressed at other layers of the stack.  If that is done, 
> *then by removing fragmentation from Bundling we give up no meaningful 
> *functionality but gain considerable simplicity and robustness.
> 
> I do not understand how an application can be expected to make
> a good choice about the size of a bundle.  Your approach
> requires this, right?

Not necessarily, as noted above.  But I already know of applications that know how to make a good choice about the size of a bundle payload.  As I mentioned, CFDP already does file segmentation on record boundaries, where the record structure of the file may vary according to the nature of the data.  A messaging protocol like the proposed AMS would probably not segment messages at all, but in my experience those messages are likely to be small enough not to benefit from segmentation anyway.

And as Matt Miller notes, video streaming effectively segments continuous video into video frames, the natural granularity of data delivery for this application.  Certainly the segments in this case might be very large, but I'm guessing that video streaming would likely be supported in environments where that large segment size isn't a problem: your data rate and processing rate are so high that you don't worry about bandwidth waste on loss of link, cut-through routing latency, etc.  The change I'm proposing doesn't limit bundle payload size, it just moves bundle payload size decisions out of Bundling itself.

> *is necessary because the protocol data units of the data-link-layer 
> *protocols underneath IP may in some cases be too small to encapsulate entire IP
> *datagrams: the datagram must be split into multiple fragments, each small 
> *enough to fit into a link-layer protocol packet, and the original datagram must
> *be reassembled from these fragments before delivery to the upper-layer protocol
> *(usually TCP).  IP itself performs this fragmentation and reassembly.
> 
> yup... and only at the source for ipv6
> 
> *
> *DTN faces the same requirement: the protocol data units of the transport 
> *protocols underneath Bundling may be too small to encapsulate entire bundles, 
> *so the bundle must be fragmented for transmission.
> 
> in some cases this is true, but I don't think its the most
> common or interesting cases

I think it happens in essentially every DTN demonstration we've executed to date.  At this point we only convey bundles over Internet stacks, which means that every bundle of even moderate size gets chopped up into IP-datagram-sized pieces, one way or another.

> *Unlike in the IP 
> *architecture, though, in the DTN architecture we already have a 
> *well-established notion of an explicit "convergence layer" at which mediation 
> *between the Bundling protocol and the underlying transport protocol (e.g., 
> *TCP/IP or LTP or Proximity-1) is implemented in a protocol-specific manner.  
> *The convergence layer adapter for each convergence
> *layer protocol already splinters bundles into chunks small enough to be 
> *conveyed in the PDUs of that specific protocol (as specifically configured at 
> *that locale) and reassembles those chunks into the original bundle at the next 
> *bundle agent in the end-to-end path.  There's no need for Bundling to do it.
> 
> This is not true.  If I have a large (or maybe even smallish) message
> and wish to send it over multiple technologies [conv. layers]
> simultaneously, this won't work.

Sure it will.  The TCP conversion layer adapter will transmit it in segments whose size is determined by the TCP implementation.  The UDP conversion layer adapter will transmit it in UDP datagrams whose size is limited by the UDP protocol design (and usually also by the implementation).  The LTP conversion layer adapters will transmit it in segments whose size is determined by the LTP configuration.  Every one of these convergence layer adapters will splinter the original message into some number of smaller chunks and reassemble it in order to pass it up to the next-hop bundle agent.

> In addition, if you have a set of contact volumes to fill, the amount
> of data to send over which CL's will be dictated by the volumes available
> and the CoS markings on the traffic to be sent.  That information will not
> typically be buried in the CL.

Sure, but that's a routing concern.  It's not affected by whatever fragmentation will be done at the convergence layer.

> *-	In interplanetary internet deployments, I expect two protocols to have 
> *direct interfaces to Bundling: AMS (Asynchronous Message Service) and CFDP 
> *(CCSDS File Delivery Protocol).  AMS is likely to be used for transmission of 
> *engineering telemetry samples and "real-time" commands which are very likely to 
> *be brief, in the range 0-64K bytes.  Large data objects such as software 
> *uploads and camera images will almost certainly be stored in files before 
> *transmission.  CFDP will likely be used for transmission of those files, and 
> *CFDP does its own segmentation of files on record boundaries that are 
> *meaningful to the application (so that, for example, "quick look" review of 
> *individual complete scan lines for a partially received image can begin long 
> *before the complete picture arrives); CFDP file data segments will be the 
> *payloads of bundles, and they are limited to 64K bytes each.
> 
> That's all fine, but 'so what?'  If you have a large data file
> you want to move from one place to another, wouldn't it just
> be nice to have the delivery system do it for you?  Couldn't you
> just do away with cfdp then?  And wouldn't that be better?

No, no more than it would be better to put all of the functionality of FTP and SMTP into Bundling and just do away with those protocols as well.  Reducing the number of protocols you use doesn't simplify anything, it just makes the complexity harder to manage.  It isn't nice at all.

> *-	In sensor network deployments, I would again expect bundle payloads to 
> *be small because the observations transmitted by participating motes are likely 
> *to be small, because resources on motes are limited.
> 
> This is not the only case.  There are sensors [e.g. sonar] that
> provide much more data and do not operate in
> bandwidth constrained networks.  Indeed the 'mule' scenarios might
> provide vary large bandwidths.
> 
> *
> *-	In mobile tactical network deployments, I would again expect bundle 
> *payloads to be relatively small in many cases.  I think I've heard Bob mention 
> *"100-bit messages" a number of times.
> *
> *Even in resource-rich environments I don't see any particular advantage to 
> *encapsulating a single huge data object within a single huge Bundle.  I think 
> *users might often want to invoke application-specific segmentation rules (as in 
> *CFDP) to control the granularity of data delivery.
> *
> *In any event it would not be difficult to insert a simple, general-purpose DTN 
> *Fragmentation protocol -- above Bundling, not within it -- for environments in 
> *which no application-specific mechanism limits payload size.  [And, 
> *alternatively, it would be equally easy to insert a DTN Erasure Coding protocol 
> *at the same layer.  Erasure code blocks would be encapsulated in bundles for 
> *forwarding through the network, in pretty much the same way that Digital 
> *Fountain code blocks are encapsulated in IP datagrams for forwarding through 
> *the Internet.]
> *
> *If bundle payloads were not huge, I think our remaining motivations for doing 
> *fragmentation within Bundling would all go away.
> 
> I do not think that is true.  To me, fragmentation is intimitely
> tied in with routing.  This is probably a restatement from
> above, but for scheduled contacts, it is the mechanism
> by which contacts are efficiently filled.  It is used by multi-path
> routing to send chunks across multiple links simultaneously.
> The size of the chunks are chosen by the router [bundle layer] and
> may be sent over multiple convergence layers simultaneously [thus
> suggesting it should be above them].

Okay but, as I think I showed above, transmitting the same data over a variety of different convergence-layer adapters is no problem.  In fact, I think you get better network utilization because the CL-specific adapters know what fragment sizes work best in their specific environments; you avoid the one-size-fits-all problem, where the CL adapter has to further fragment a fragmentary bundle because Bundling didn't pick a small enough fragment size for that CL's MTU.

Scott

Date: Tue, 05 Apr 2005 08:12:25 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Howard Weiss wrote:
> Deja-Deja Vu.....  Where have we heard all of this before?

Yeah, I wouldn't claim that this position is new.  But I think some of the argument is new, informed by some of our implementation experience.  We know a bit more now about what we do at the convergence layer, for example.

> In the early IPN days we kept bringing up the idea of "bindling" which 
> was a cute catch phrase for fragmentation of bundles.  Everytime we 
> discussed this we quickly went down a rat-hole because of all the 
> problems that came along with it (the chief one closest to my heart was 
> security).  So we just kept shelving the issue hoping it would go away - 
> which it didn't.
> 
> But this is also terribly reminicent of the early Internet days when IP 
> fragmentation was needed because of the number of different types of 
> networks that were being lashed together - all with potentially 
> different MTUs.  MTU discovery didn't come along for a while, so IP 
> could fragment inside the network.  The one that I "fondly" remember is 
> the ARPAnet to SATNET demark where the SATNET had half the MTU of the 
> ARPAnet.  But I also remember that there was no way I could afford to 
> allow the network to fragment because then I had to pay the cost of 
> re-assembly.  Re-assembly caused performance to go down the toilet.  I 
> went out of my way to force a smaller MTU at the source so as not to 
> allow the SATNET to fragment.
> 
> Magically, all of these problems went away thanks to a de-facto MTU 
> standard as a result of the ubiquity of Ethernet.  It went away so much 
> that IPv6 said no more reactive fragmentation in the network - do it at 
> the source (gee, that sounds familiar).
> 
> So here we are again..... 
> 
> I can understand the need for reactive fragmentation if we have wildly 
> varying MTUs - and this may well be the case.  But we also have the 
> problem that reactive fragmentation does not play well with 
> authentication and confidentiality (among others).  If we slice and dice 
> a bundle in the middle of the network, and it has been MAC'd and/or 
> encrypted, the ultimate destination still can't do anything with the 
> fragments until they all arrive unless we make each fragment an atomic 
> entity, e.g., they are little, small bundles.  But this can't be done in 
> the middle of the network - only at the source.  Yes, we can do all 
> sorts of "heroic" things at the source like MAC small chunks of bundles 
> and send along the multiple MACs hoping that the fragmentation follows 
> along with the MAC slices and thereby gain some benefit from the 
> fragmentation.  But this is a costly exercise - both in terms of CPU 
> power to perform the multiple MAC calculations as well as the bandwidth 
> to transmit them.

Yep.  There are good reasons to banish fragmentation from the architecture.  Clearly there have also been a lot of very good reasons to preserve it; my argument is that I think we now know of other ways to satisfy those concerns (e.g., dealing with MTU issues at the convergence layer) that don't introduce as many problems.

Scott

Date: Tue, 05 Apr 2005 07:49:55 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Leigh Torgerson wrote:
> 
> Scott wrote:
> 
>> I think all of the other motivations we've identified for 
>> fragmentation in Bundling derive from our (usually unconscious) 
>> assumption that bundles may be very large.  I think this is an 
>> unhelpful assumption.
>>
> 
> Every time I hear someone argue about "large versus small" I remember 
> that at one time people thought 640K was all the memory a programmer 
> would ever need...
> 
> If whatever we do with DTN doesn't work equally well for any size 
> bundle, I would fear we are in danger of building in limited scalability 
> and eventual obsolescence.

I think what you actually mean is "for any size payload that we want to send using bundling", and of course I agree with that.  I'm pretty sure that nothing I said would be any more limiting than what we've got now.

In fact, the optional, general-purpose "DTN Fragmentation" protocol I proposed that we insert "above" bundling [maybe I should call it "DTN Segmentation" instead, since it's happening above the forwarding layer] could very much improve our ability to send extremely large payloads via bundling.  The current Bundling spec limits the size of any single *original* bundle payload to 4 Gbytes; no matter what you do about fragmentation, Bundling can't reassemble a payload that's any bigger than that -- it's a hard limit on bundle size.  But this notional DTN Segmentation protocol could use larger-than-32-bit integers (maybe SDNVs) to represent offsets and lengths within an original payload, so that (for example) a terabyte payload could be presented to it and split up into a gazillion payload fragments, each of which could be forwarded individually through the network in a single bundle of quite ordinary size, and the huge payload could be reassembled at the destination from the de
livered (fragmentary) payloads of all those bundles.  You can't do that now.

> Forcing a bundle to be restricted to a small maximum length (now you 
> have to define what is "small") risks ATM-like inefficiency as well.

No, you don't have to define "small" and you don't have to force a bundle to be restricted to any particular length.  You just segment your payloads (as CFDP does, for example) before presenting them to Bundling for shipment; when you do this, you segment at sizes that make sense for your application and for the network environment you're working in, exactly as you would if you were doing proactive fragmentation within Bundling itself.

As for ATM-like inefficiency: yes, as I said, you have more bundle header overhead if you've got more bundles.  You have this whether you fragment the payload within Bundling (generating multiple bundles) or segment it before presenting it to Bundling (and thereby generating multiple bundles).  I don't think there's a lot of additional cost here.

> If we take fragmentation out of bundling, we've just pushed the problem 
> into other layers,

Yes, that was what I was proposing.

> which might be OK - but if fragmentation is optional, and not implemented everywhere in a given network, we'd have efficiency 
> problems (only one route can take bundles of X size; other routes are 
> better connected, but your bundles are too big, so too bad...now we have 
> to do the DTN-equivalent of path MTU discovery..)

I don't think so.  As I said, fragmentation to suit the transmission characteristics of individual links is something we already do at the convergence layer, underneath bundling.  I quite carefully didn't say this requirement goes away.  I just said it's better done someplace else -- someplace where in fact we are already doing it.

> If we make fragmentation a required part of a convergence layer (or overlay), then 
> we still have to specify an interoperable standard.

Of course we do.  However, I guarantee that we already have to specify interoperable standards at the convergence layer.

This is kind of the beauty of layering, though: you do end up with more protocols, but each one individually is simpler, therefore easier and cheaper to design and implement and maintain, and usually more robust.  We can get arbitrarily complex and powerful behavior from the interaction of things that are individually simple enough to describe and reason about.

The idea that it is good to dump all possible functionality into a single protocol rather than break it apart into modules -- "layers" -- with clean interfaces is one that I hope we've gotten past by now.  Complexity doesn't go away when you put it all in one box.  It gets worse.

Scott

To: Scott Burleigh <[email-masked]>
cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation 
Date: Tue, 05 Apr 2005 06:19:34 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

*As threatened: I propose that we remove fragmentation, in all forms, from the 
*Bundling protocol.  I know, nobody wants to hear this, but I want to at least 
*lay out the case.

This approach essentially moves the complexity of choosing good sizes
for bundles out to the application.  It also appears to suggest
there is some maximum size for bundles.

I personally believe the fragmentation function is one of the
most important parts of the architecture [along with
naming and store/forward, maybe custody xfer].

*
*My argument is that there are a number of entirely valid motives for 
* splintering transmitted data in various ways,
* but that all of those motives can
* and should - be addressed at other layers of the stack.  If that is done, 
*then by removing fragmentation from Bundling we give up no meaningful 
*functionality but gain considerable simplicity and robustness.

I do not understand how an application can be expected to make
a good choice about the size of a bundle.  Your approach
requires this, right?

*
*DTN is clearly not just a restatement of the IP architecture, but the 
*functional analogies have been close enough to enable us to use the IP 
*architecture as a sort of checklist for things DTN has to address.  
*Fragmentation in IP (the IP architectural analog to the Bundling protocol in 
*DTN)

I don't fully agree with this parentetical premise.  Bundles
is more like some part of IP plus some parts of ftp or e-mail.
My thinking is that bundling is more like e-mail than IP.

*is necessary because the protocol data units of the data-link-layer 
*protocols underneath IP may in some cases be too small to encapsulate entire IP
*datagrams: the datagram must be split into multiple fragments, each small 
*enough to fit into a link-layer protocol packet, and the original datagram must
*be reassembled from these fragments before delivery to the upper-layer protocol
*(usually TCP).  IP itself performs this fragmentation and reassembly.

yup... and only at the source for ipv6

*
*DTN faces the same requirement: the protocol data units of the transport 
*protocols underneath Bundling may be too small to encapsulate entire bundles, 
*so the bundle must be fragmented for transmission.

in some cases this is true, but I don't think its the most
common or interesting cases

*Unlike in the IP 
*architecture, though, in the DTN architecture we already have a 
*well-established notion of an explicit "convergence layer" at which mediation 
*between the Bundling protocol and the underlying transport protocol (e.g., 
*TCP/IP or LTP or Proximity-1) is implemented in a protocol-specific manner.  
*The convergence layer adapter for each convergence
*layer protocol already splinters bundles into chunks small enough to be 
*conveyed in the PDUs of that specific protocol (as specifically configured at 
*that locale) and reassembles those chunks into the original bundle at the next 
*bundle agent in the end-to-end path.  There's no need for Bundling to do it.

This is not true.  If I have a large (or maybe even smallish) message
and wish to send it over multiple technologies [conv. layers]
simultaneously, this won't work.
In addition, if you have a set of contact volumes to fill, the amount
of data to send over which CL's will be dictated by the volumes available
and the CoS markings on the traffic to be sent.  That information will not
typically be buried in the CL.

*
*I think all of the other motivations we've identified for fragmentation in 
*Bundling derive from our (usually unconscious) assumption that bundles may be 
*very large.  I think this is an unhelpful assumption.

Ok, I don't... but I'll go on..

*
*-	In interplanetary internet deployments, I expect two protocols to have 
*direct interfaces to Bundling: AMS (Asynchronous Message Service) and CFDP 
*(CCSDS File Delivery Protocol).  AMS is likely to be used for transmission of 
*engineering telemetry samples and "real-time" commands which are very likely to 
*be brief, in the range 0-64K bytes.  Large data objects such as software 
*uploads and camera images will almost certainly be stored in files before 
*transmission.  CFDP will likely be used for transmission of those files, and 
*CFDP does its own segmentation of files on record boundaries that are 
*meaningful to the application (so that, for example, "quick look" review of 
*individual complete scan lines for a partially received image can begin long 
*before the complete picture arrives); CFDP file data segments will be the 
*payloads of bundles, and they are limited to 64K bytes each.

That's all fine, but 'so what?'  If you have a large data file
you want to move from one place to another, wouldn't it just
be nice to have the delivery system do it for you?  Couldn't you
just do away with cfdp then?  And wouldn't that be better?

*
*-	In sensor network deployments, I would again expect bundle payloads to 
*be small because the observations transmitted by participating motes are likely 
*to be small, because resources on motes are limited.

This is not the only case.  There are sensors [e.g. sonar] that
provide much more data and do not operate in
bandwidth constrained networks.  Indeed the 'mule' scenarios might
provide vary large bandwidths.

*
*-	In mobile tactical network deployments, I would again expect bundle 
*payloads to be relatively small in many cases.  I think I've heard Bob mention 
*"100-bit messages" a number of times.
*
*Even in resource-rich environments I don't see any particular advantage to 
*encapsulating a single huge data object within a single huge Bundle.  I think 
*users might often want to invoke application-specific segmentation rules (as in 
*CFDP) to control the granularity of data delivery.
*
*In any event it would not be difficult to insert a simple, general-purpose DTN 
*Fragmentation protocol -- above Bundling, not within it -- for environments in 
*which no application-specific mechanism limits payload size.  [And, 
*alternatively, it would be equally easy to insert a DTN Erasure Coding protocol 
*at the same layer.  Erasure code blocks would be encapsulated in bundles for 
*forwarding through the network, in pretty much the same way that Digital 
*Fountain code blocks are encapsulated in IP datagrams for forwarding through 
*the Internet.]
*
*If bundle payloads were not huge, I think our remaining motivations for doing 
*fragmentation within Bundling would all go away.

I do not think that is true.  To me, fragmentation is intimitely
tied in with routing.  This is probably a restatement from
above, but for scheduled contacts, it is the mechanism
by which contacts are efficiently filled.  It is used by multi-path
routing to send chunks across multiple links simultaneously.
The size of the chunks are chosen by the router [bundle layer] and
may be sent over multiple convergence layers simultaneously [thus
suggesting it should be above them].

*
*1.	Currently we figure we need to do "reactive fragmentation" because we 
*can't afford the waste of bandwidth that would result from losing link in the 
*middle of transmitting a bundle.  But suppose our transmission rate is 1 Mbps 
*(which is becoming commonplace for deep space links): if all bundles were less 
*than 128K bytes [twice the size of a CFDP file data PDU] then any unexpected 
*loss of link would cost us at most 1 second of wasted transmission time.  I 
*think that's likely to be a tolerable cost.  For other environments you can 
*limit wasted transmission even more sharply if you limit bundle size the same 
*way -- e.g., at most 1/10 of a second lost if you're at 10 Mbps -- or you can 
*send much larger bundles: at 10 Mbps, you never waste even 1 second of 
*transmission time if your bundles are always less than 1 Megabyte.

reactive fragmentation is an optimization you may or may not
wish to implement it.  I believe there are some scenarios where
it could be useful [e.g. LEO sat case where >1 sat is being used].

*
*2.	We need to do "cut-through" routing: we're at a router that is lucky 
*enough to have links open to upstream and downstream bundle agents at the same 
*time, so we don't want to have to wait for arrival of an entire bundle before 
*we start forwarding it.  But again, if bundles are small to start with, maximum 
*forwarding latency is controlled in the same manner that bandwidth waste due to 
*link loss is controlled: at 1 Mbps with bundles of size less than 128K bytes, 
*you're forwarding at most 1 second after arrival.  And so on.

yes, you can make small bundles

*
*3.	Maybe we need to be able to "interrupt" low-priority traffic with 
*newly-injected high-priority traffic: we want to be dealing with small 
*fragments so that transmission of a large low-priority bundle doesn't block 
*timely transmission of a small high-priority bundle.  But again, if the 
*application (or a DTN Fragmentation protocol at the same layer) is presenting 
*only smallish payloads for transmission in bundles, this is no problem.  The 
*effect is exactly the same as if the fragmentation were happening inside 
*Bundling.

But what is smallish?  Smallish is known by the router, not by
the end application.  In the internet the end app might conceivably
be told something like this (by pmtu discovery), but in a dtn
there is no reason to believe such signaling will be possible.
Because only the router knows the useful info here, and it
is the multiplexer, so it is the one who should be doing the
slicing and dicing.

*
*I don't think there's any significant net performance cost in going this way: 
*any additional bundle header overhead that is incurred would also be incurred 
*if the fragmentation were done by Bundling itself -- you end up with the same 
*number of bundles.

But, if your 'smallish' is more small than it needs to be, you
create a bunch of bundles that might not need to be.  Why is
that beneficial?

*
*On the other hand, I think the advantages in terms of protocol simplicity are 
*substantial.  There are a lot of places in the Bundling protocol spec where we 
*have to do special things to accommodate bundle fragmentation; one of the worst 
*is the special kind of reactive fragmentation we have to do when a bundle 
*custodian receives a Custody Transfer acceptance for a fragment -- but the 
*bundle that the custodian owns is the original bundle and the fragmentation was 
*done by a downstream non-custodial router.  And of course reactive 
*fragmentation presents security problems that we've wrestled over at length and 
*apparently still don't have any very satisfactory solution for.

my sense is that reactive fragmentation may ultimately prove to be
a problem, and we might wish to modify or delete it

*
*Okay, I know this suggestion will not be popular and I don't have any very high 
*hopes that we will collectively go for it.  It makes sense to me, though, and I 
*would be glad to hear a well-reasoned counter-argument.
*
*Scott

- Kevin

Cc: [email-masked]
From: Matt Miller <[email-masked]>
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Date: Tue, 5 Apr 2005 08:57:13 -0400
To: [email-masked]
Sender: [email-masked]

As an interested "outsider", let me offer a couple comments and perhaps 
fresh perspective on a couple of issues in the on-going discussion.

On Apr 4, 2005, at 6:24 PM, Jakob Eriksson wrote:

> I still believe we need to support an "intermediate-destination" 
> header, which of course is similar to loose source routing, except 
> that it is change potentially many ways along the way to the final 
> destination.

I very much concur with this.  We have discovered much value in the 
"intermediate-destination" idea.  I.e. a source sends data to the 
intermediate in-network address, knowing this is the best place to 
stage bundles for one or more ultimate destinations.  E.g. a Mars probe 
could know that the moon-station is where it needs to send its data, 
but not beyond that.

On Apr 4, 2005, at 7:21 PM, Scott Burleigh wrote:

> As threatened: I propose that we remove fragmentation, in all forms, 
> from the Bundling protocol.

On Apr 4, 2005, at 8:07 PM, Leigh Torgerson wrote:

> If whatever we do with DTN doesn't work equally well for any size 
> bundle, I would fear we are in danger of building in limited 
> scalability and eventual obsolescence.

Consider the case of video streaming.  Here, each integral data frame 
(a video image) may be larger than any particular predefined limit on 
bundle size.  Further, there is a natural connectedness between the 
video frames that could be considered a form of fragmentation.  You may 
abdicate responsibility for direct support of "streaming" data, but you 
should at minimum consider how it might be done, so as to provide a 
compatible network layer on which practical, scalable applications can 
reside.

We are working on a concept sort of like bundle-vectors.  A bundle can 
be a composite, sequenced (time-stamped) object that is buffered 
in-network.  Our work may be an application-layer relative to DTN, but 
of course we are interested in realizing an infrastructure that enables 
open-ended scalability and supports data streaming.  A simple first-cut 
interface between an implementation of our idea and DTN is to map the 
bundle "payloaddir" via WebDAV to a "RBNB" server.  I will provide more 
details about this as our prototype evolves.

In talking to a wide range of folks who do data distribution for a 
living (e.g. tactical data systems), every time I mention data 
streaming, e.g. video, I have gotten a "not my job" response.  That is 
fine, but since it is my job, I would love to hear from this community 
the best way we can proceed to make that happen.

Matt Miller
Creare

From: "Scott,Keith L." <[email-masked]>
To: "'Jakob Eriksson'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] DTN without regions - I think I get it
Date: Tue, 5 Apr 2005 08:49:18 -0400
Sender: [email-masked]

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Jakob Eriksson
>Sent: Monday, April 04, 2005 6:24 PM
>To: [email-masked]
>Subject: Re: [dtn-interest] DTN without regions - I think I get it
>
>
>It seems we are reaching agreement that end-point identifiers will be 
>very general beasts:
>
>>> Yes.  In a sense, the "schema" takes the place of the "region" in
>>> the architecture, with the important difference that we can say
>>> exactly what a schema is: it's a named set of rules for endpoint ID
>>> string syntax and semantics, period.
>>
>> Perfect.
>
>some of them will contain structure, some not, etc. Although I 
>initially argued for a distinction between addresses and 
>identifiers, I 
>can see the merit of a more generalized scheme (after much convincing 
>done by Mike and Kevin).
>
>However, if I could bring back another point that I was pushing for 
>earlier... I still believe we need to support an 
>"intermediate-destination" header, which of course is similar to loose 
>source routing, except that it is change potentially many ways along 
>the way to the final destination.
>
>The reason an intermediate-destination header is needed is that some 
>schemas will not have routing entries for every EID in every node. 
>Let's say node A somehow (dht, out-of-band, guess) knows that EID 
>pgp://xxxxxxxx is connected to the earth system internet. However, 
>other nodes on the path from A to pgp://xxxxxxxx, that are not 
>internet 
>connected, are not aware of this. A could then address its outgoing 
>bundle thus:
>
>destination: pgp://<key here>
>intermediate-destination: region://in.earth.sol

Maybe.  Or maybe the fact that other routers on the path from A to
pgp://xxxxxx don't know how to forward the bundle just means that their
routing is misconfigured.  Your example motivates the hints mechanism Rajesh
mentioned, though, and I'm beginning to warm up to that approach.

>Note that we cannot simply say destination = region://in.earth.sol, 
>because this is not specific enough. However, if we keep the pgp;// 
>destination, the first node connected to the internet will be able to 
>determine a new intermediate destination for the same pgp:// 
>identifier, perhaps something like ip://128.15.23.92.
>
>Note that this is different from the "care-of" address that Scott 
>suggested, or the "reply-to" address that has also been suggested 
>earlier. The intermediate-destination merely states that "this 
>is where 
>the packet is going right now". Once the packet gets there, it 
>may very 
>well be replaced by some new intermediate destination.
>
>- Jakob
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

From: "Scott,Keith L." <[email-masked]>
To: <[email-masked]>, "'Matt Bradbury'" <[email-masked]>
Cc: "'Jakob Eriksson'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] DTN without regions - I think I get it
Date: Tue, 5 Apr 2005 08:45:34 -0400
Sender: [email-masked]

Thanks Rajesh, this brings up something I wanted to avoid in my previous
posting in order to preserve clarity.   If the endpoint identifier is not a
_single_ URI but a set of them, then it should be easy to implement the
hints notion you mention.  There would likely be (might be?) one 'main'
endpoint identifier and a lot of 'ancillary' information, and whether all he
ancillary information shows up with the main ID or in a separate header
probably has security implications (as does anything in the bundle header
that's mutable en-route).

Using this method, a bundle router could examine the set of URIs in the
destination (or reply-to, etc.) identifier and make a routing decision based
on whatever information it understood.  The reason for suggesting a set of
URIs (at least conceptually) rather than piling all the ancillary
information into a single URI along with the 'primary destination' (if such
exists) is to make it clear that if there is some information that the
router doesn't understand, it's free to ignore it.  [As an aside, yes, such
a mechanism could be accommodated by using a single schema for endpoint
identifiers that included semantics for encapsulating a set of URIs.
Implementation not the point here.]

		--keith

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Rajesh Krishnan
>Sent: Monday, April 04, 2005 7:38 PM
>To: Matt Bradbury
>Cc: Jakob Eriksson; [email-masked]
>Subject: Re: [dtn-interest] DTN without regions - I think I get it
>
>> > <snip>
>> >
>> > Note that this is different from the "care-of" address that Scott 
>> > suggested, or the "reply-to" address that has also been suggested 
>> > earlier. The intermediate-destination merely states that "this is 
>> > where the packet is going right now". Once the packet gets 
>there, it 
>> > may very well be replaced by some new intermediate destination.
>> >
>> > - Jakob
>> 
>> What about some kind of encapsulation instead?  Tunneling I 
>think will 
>> have it's place.  But is it at a higher layer or in the bundle layer.
>> 
>> -Matt
>
>If using _strict_ encapsulation, every router en route will typically 
>attempt to send it to the care-of destination.
>
>If using hints (to a potential care-of location, where further 
>resolution 
>of the name can take place, distinct from the destination), 
>nodes en route 
>to the care-of could change the care-of address based on 
>better knowledge, 
>e.g. of
>
>  - current location of the destination, 
>  - current location/status of the indicated care-of, OR
>  - a node known to be able to (or has access to a resolver that can) 
>    resolve (more of) the destination name
>
>Suppose an en route node heard a recent location update for 
>the destination 
>(that was not yet known to the hint-provider/encapsulator when 
>it forwarded 
>the bundle), or the happenstance in which the en route node 
>actually has 
>an opportunsitic link/path to the destination.  If using 
>encapsulation, the 
>en route node must forward it to the specified intermediate 
>endpoint even 
>though it knows better.
>
>Hints may be useful to deal with the partial knowledge induced 
>by mobililty, 
>and potentially avoid some telescoping of routes.
>
>-Rajesh
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 05 Apr 2005 09:55:22 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Scott Burleigh wrote:

> As threatened: I propose that we remove fragmentation, in all forms, 
> from the Bundling protocol.  I know, nobody wants to hear this, but I 
> want to at least lay out the case.

[...lots of good stuff snipped...]

> Okay, I know this suggestion will not be popular and I don't have any 
> very high hopes that we will collectively go for it.  It makes sense to 
> me, though, and I would be glad to hear a well-reasoned counter-argument.

I'd also be in favour of dropping fragmentation, at least until
I see a comprehensive explanation of how fragmentation interacts
with all the other services that bundling offers.

I can understand the problems it causes for security and fairly
well imagine them for custody transfer, but I've no idea what'd
happen if say an ACK bundle of some sort were fragmented, nor
whether this is allowed, or has been considered. And while I've
some idea of the problems, I have to say I've very little idea
about good solutions!

If we can't get rid of fragmentation, is it worthwhile defining
a DF bit in the (probably) primary header, and perhaps limiting
some services to bundles with DF=1? (I'm not sure myself.)

Stephen.

Date: Mon, 4 Apr 2005 17:07:46 -0700
To: DTN <[email-masked]>
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

Scott wrote:

>I think all of the other motivations we've identified for 
>fragmentation in Bundling derive from our (usually unconscious) 
>assumption that bundles may be very large.  I think this is an 
>unhelpful assumption.
>

Every time I hear someone argue about "large versus small" I remember 
that at one time people thought 640K was all the memory a programmer 
would ever need...

If whatever we do with DTN doesn't work equally well for any size 
bundle, I would fear we are in danger of building in limited 
scalability and eventual obsolescence.

Forcing a bundle to be restricted to a small maximum length (now you 
have to define what is "small") risks ATM-like inefficiency as well.

If we take fragmentation out of bundling, we've just pushed the 
problem into other layers, which might be OK - but if fragmentation 
is optional, and not implemented everywhere in a given network, we'd 
have efficiency problems (only one route can take bundles of X size; 
other routes are better connected, but your bundles are too big, so 
too bad...now we have to do the DTN-equivalent of path MTU 
discovery..) If we make fragmentation a required part of a 
convergence layer (or overlay), then we still have to specify an 
interoperable standard.

I'm in favor of simplification, but not if it just pushes the problem 
in to someone else's lap. They won't do the right thing ;-)

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

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] DTN without regions - I think I get it
To: [email-masked] (Matt Bradbury)
Date: Mon, 4 Apr 2005 19:38:09 -0400 (EDT)
Cc: [email-masked] (Jakob Eriksson), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

> > <snip>
> >
> > Note that this is different from the "care-of" address that Scott 
> > suggested, or the "reply-to" address that has also been suggested 
> > earlier. The intermediate-destination merely states that "this is 
> > where the packet is going right now". Once the packet gets there, it 
> > may very well be replaced by some new intermediate destination.
> >
> > - Jakob
> 
> What about some kind of encapsulation instead?  Tunneling I think will 
> have it's place.  But is it at a higher layer or in the bundle layer.
> 
> -Matt

If using _strict_ encapsulation, every router en route will typically 
attempt to send it to the care-of destination.

If using hints (to a potential care-of location, where further resolution 
of the name can take place, distinct from the destination), nodes en route 
to the care-of could change the care-of address based on better knowledge, 
e.g. of

  - current location of the destination, 
  - current location/status of the indicated care-of, OR
  - a node known to be able to (or has access to a resolver that can) 
    resolve (more of) the destination name

Suppose an en route node heard a recent location update for the destination 
(that was not yet known to the hint-provider/encapsulator when it forwarded 
the bundle), or the happenstance in which the en route node actually has 
an opportunsitic link/path to the destination.  If using encapsulation, the 
en route node must forward it to the specified intermediate endpoint even 
though it knows better.

Hints may be useful to deal with the partial knowledge induced by mobililty, 
and potentially avoid some telescoping of routes.

-Rajesh

Date: Mon, 04 Apr 2005 16:21:59 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] on ditching fragmentation
Sender: [email-masked]

As threatened: I propose that we remove fragmentation, in all forms, from the Bundling protocol.  I know, nobody wants to hear this, but I want to at least lay out the case.

My argument is that there are a number of entirely valid motives for splintering transmitted data in various ways, but that all of those motives can - and should - be addressed at other layers of the stack.  If that is done, then by removing fragmentation from Bundling we give up no meaningful functionality but gain considerable simplicity and robustness.

DTN is clearly not just a restatement of the IP architecture, but the functional analogies have been close enough to enable us to use the IP architecture as a sort of checklist for things DTN has to address.  Fragmentation in IP (the IP architectural analog to the Bundling protocol in DTN) is necessary because the protocol data units of the data-link-layer protocols underneath IP may in some cases be too small to encapsulate entire IP datagrams: the datagram must be split into multiple fragments, each small enough to fit into a link-layer protocol packet, and the original datagram must be reassembled from these fragments before delivery to the upper-layer protocol (usually TCP).  IP itself performs this fragmentation and reassembly.

DTN faces the same requirement: the protocol data units of the transport protocols underneath Bundling may be too small to encapsulate entire bundles, so the bundle must be fragmented for transmission.  Unlike in the IP architecture, though, in the DTN architecture we already have a well-established notion of an explicit "convergence layer" at which mediation between the Bundling protocol and the underlying transport protocol (e.g., TCP/IP or LTP or Proximity-1) is implemented in a protocol-specific manner.  The convergence layer adapter for each convergence
layer protocol already splinters bundles into chunks small enough to be conveyed in the PDUs of that specific protocol (as specifically configured at that locale) and reassembles those chunks into the original bundle at the next bundle agent in the end-to-end path.  There's no need for Bundling to do it.

I think all of the other motivations we've identified for fragmentation in Bundling derive from our (usually unconscious) assumption that bundles may be very large.  I think this is an unhelpful assumption.

-	In interplanetary internet deployments, I expect two protocols to have direct interfaces to Bundling: AMS (Asynchronous Message Service) and CFDP (CCSDS File Delivery Protocol).  AMS is likely to be used for transmission of engineering telemetry samples and "real-time" commands which are very likely to be brief, in the range 0-64K bytes.  Large data objects such as software uploads and camera images will almost certainly be stored in files before transmission.  CFDP will likely be used for transmission of those files, and CFDP does its own segmentation of files on record boundaries that are meaningful to the application (so that, for example, "quick look" review of individual complete scan lines for a partially received image can begin long before the complete picture arrives); CFDP file data segments will be the payloads of bundles, and they are limited to 64K bytes each.

-	In sensor network deployments, I would again expect bundle payloads to be small because the observations transmitted by participating motes are likely to be small, because resources on motes are limited.

-	In mobile tactical network deployments, I would again expect bundle payloads to be relatively small in many cases.  I think I've heard Bob mention "100-bit messages" a number of times.

Even in resource-rich environments I don't see any particular advantage to encapsulating a single huge data object within a single huge Bundle.  I think users might often want to invoke application-specific segmentation rules (as in CFDP) to control the granularity of data delivery.

In any event it would not be difficult to insert a simple, general-purpose DTN Fragmentation protocol -- above Bundling, not within it -- for environments in which no application-specific mechanism limits payload size.  [And, alternatively, it would be equally easy to insert a DTN Erasure Coding protocol at the same layer.  Erasure code blocks would be encapsulated in bundles for forwarding through the network, in pretty much the same way that Digital Fountain code blocks are encapsulated in IP datagrams for forwarding through the Internet.]

If bundle payloads were not huge, I think our remaining motivations for doing fragmentation within Bundling would all go away.

1.	Currently we figure we need to do "reactive fragmentation" because we can't afford the waste of bandwidth that would result from losing link in the middle of transmitting a bundle.  But suppose our transmission rate is 1 Mbps (which is becoming commonplace for deep space links): if all bundles were less than 128K bytes [twice the size of a CFDP file data PDU] then any unexpected loss of link would cost us at most 1 second of wasted transmission time.  I think that's likely to be a tolerable cost.  For other environments you can limit wasted transmission even more sharply if you limit bundle size the same way -- e.g., at most 1/10 of a second lost if you're at 10 Mbps -- or you can send much larger bundles: at 10 Mbps, you never waste even 1 second of transmission time if your bundles are always less than 1 Megabyte.

2.	We need to do "cut-through" routing: we're at a router that is lucky enough to have links open to upstream and downstream bundle agents at the same time, so we don't want to have to wait for arrival of an entire bundle before we start forwarding it.  But again, if bundles are small to start with, maximum forwarding latency is controlled in the same manner that bandwidth waste due to link loss is controlled: at 1 Mbps with bundles of size less than 128K bytes, you're forwarding at most 1 second after arrival.  And so on.

3.	Maybe we need to be able to "interrupt" low-priority traffic with newly-injected high-priority traffic: we want to be dealing with small fragments so that transmission of a large low-priority bundle doesn't block timely transmission of a small high-priority bundle.  But again, if the application (or a DTN Fragmentation protocol at the same layer) is presenting only smallish payloads for transmission in bundles, this is no problem.  The effect is exactly the same as if the fragmentation were happening inside Bundling.

I don't think there's any significant net performance cost in going this way: any additional bundle header overhead that is incurred would also be incurred if the fragmentation were done by Bundling itself -- you end up with the same number of bundles.

On the other hand, I think the advantages in terms of protocol simplicity are substantial.  There are a lot of places in the Bundling protocol spec where we have to do special things to accommodate bundle fragmentation; one of the worst is the special kind of reactive fragmentation we have to do when a bundle custodian receives a Custody Transfer acceptance for a fragment -- but the bundle that the custodian owns is the original bundle and the fragmentation was done by a downstream non-custodial router.  And of course reactive fragmentation presents security problems that we've wrestled over at length and apparently still don't have any very satisfactory solution for.

Okay, I know this suggestion will not be popular and I don't have any very high hopes that we will collectively go for it.  It makes sense to me, though, and I would be glad to hear a well-reasoned counter-argument.

Scott

Date: Mon, 04 Apr 2005 15:58:30 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Sender: [email-masked]

Jakob Eriksson wrote:
> 
> It seems we are reaching agreement that end-point identifiers will be 
> very general beasts:
> 
>>> Yes.  In a sense, the "schema" takes the place of the "region" in
>>> the architecture, with the important difference that we can say
>>> exactly what a schema is: it's a named set of rules for endpoint ID
>>> string syntax and semantics, period.
>>
>>
>> Perfect.
> 
> 
> some of them will contain structure, some not, etc. Although I initially 
> argued for a distinction between addresses and identifiers, I can see 
> the merit of a more generalized scheme (after much convincing done by 
> Mike and Kevin).
> 
> However, if I could bring back another point that I was pushing for 
> earlier... I still believe we need to support an 
> "intermediate-destination" header, which of course is similar to loose 
> source routing, except that it is change potentially many ways along the 
> way to the final destination.
> 
> The reason an intermediate-destination header is needed is that some 
> schemas will not have routing entries for every EID in every node. Let's 
> say node A somehow (dht, out-of-band, guess) knows that EID 
> pgp://xxxxxxxx is connected to the earth system internet. However, other 
> nodes on the path from A to pgp://xxxxxxxx, that are not internet 
> connected, are not aware of this. A could then address its outgoing 
> bundle thus:
> 
> destination: pgp://<key here>
> intermediate-destination: region://in.earth.sol
> 
> Note that we cannot simply say destination = region://in.earth.sol, 
> because this is not specific enough. However, if we keep the pgp;// 
> destination, the first node connected to the internet will be able to 
> determine a new intermediate destination for the same pgp:// identifier, 
> perhaps something like ip://128.15.23.92.
> 
> Note that this is different from the "care-of" address that Scott 
> suggested, or the "reply-to" address that has also been suggested 
> earlier. The intermediate-destination merely states that "this is where 
> the packet is going right now". Once the packet gets there, it may very 
> well be replaced by some new intermediate destination.

I'm not at all sure that I see the utility yet, but I'm fine with defining a new, experimental, extension header that is used for this purpose; over time a light may dawn.

Scott

Date: Mon, 04 Apr 2005 17:52:12 -0500
From: Matt Bradbury <[email-masked]>
To: Jakob Eriksson <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Sender: [email-masked]

Jakob Eriksson wrote:

>
> It seems we are reaching agreement that end-point identifiers will be 
> very general beasts:
>
>>> Yes.  In a sense, the "schema" takes the place of the "region" in
>>> the architecture, with the important difference that we can say
>>> exactly what a schema is: it's a named set of rules for endpoint ID
>>> string syntax and semantics, period.
>>
>>
>> Perfect.
>
> <snip>
>
> Note that this is different from the "care-of" address that Scott 
> suggested, or the "reply-to" address that has also been suggested 
> earlier. The intermediate-destination merely states that "this is 
> where the packet is going right now". Once the packet gets there, it 
> may very well be replaced by some new intermediate destination.
>
> - Jakob

What about some kind of encapsulation instead?  Tunneling I think will 
have it's place.  But is it at a higher layer or in the bundle layer.

-Matt

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Date: Mon, 4 Apr 2005 15:24:01 -0700
To: [email-masked]
Sender: [email-masked]

It seems we are reaching agreement that end-point identifiers will be 
very general beasts:

>> Yes.  In a sense, the "schema" takes the place of the "region" in
>> the architecture, with the important difference that we can say
>> exactly what a schema is: it's a named set of rules for endpoint ID
>> string syntax and semantics, period.
>
> Perfect.

some of them will contain structure, some not, etc. Although I 
initially argued for a distinction between addresses and identifiers, I 
can see the merit of a more generalized scheme (after much convincing 
done by Mike and Kevin).

However, if I could bring back another point that I was pushing for 
earlier... I still believe we need to support an 
"intermediate-destination" header, which of course is similar to loose 
source routing, except that it is change potentially many ways along 
the way to the final destination.

The reason an intermediate-destination header is needed is that some 
schemas will not have routing entries for every EID in every node. 
Let's say node A somehow (dht, out-of-band, guess) knows that EID 
pgp://xxxxxxxx is connected to the earth system internet. However, 
other nodes on the path from A to pgp://xxxxxxxx, that are not internet 
connected, are not aware of this. A could then address its outgoing 
bundle thus:

destination: pgp://<key here>
intermediate-destination: region://in.earth.sol

Note that we cannot simply say destination = region://in.earth.sol, 
because this is not specific enough. However, if we keep the pgp;// 
destination, the first node connected to the internet will be able to 
determine a new intermediate destination for the same pgp:// 
identifier, perhaps something like ip://128.15.23.92.

Note that this is different from the "care-of" address that Scott 
suggested, or the "reply-to" address that has also been suggested 
earlier. The intermediate-destination merely states that "this is where 
the packet is going right now". Once the packet gets there, it may very 
well be replaced by some new intermediate destination.

- Jakob

Date: Mon, 04 Apr 2005 13:18:07 -0500
From: Matt Bradbury <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: [email-masked]
Subject: [dtn-interest] Architecture vs. Public DTN implementation
Sender: [email-masked]

>And this may very well emerge. But I'm hesitant to mandate that in the
>architecture documents. Think of it as the difference between IP that
>defines a protocol and the capital-I Internet. The latter is a
>particular embodiment of a set of architectural principles and
>protocols. The former is the what's actually specified in RFCs.
>
>-m
>  
>
Agreed, maybe we need to form a body to advocate and set policy for the 
Public DTN.  The earlier we can discover operational problems with the 
protocol, the easier it is to fix them.

-Matt

Date: Mon, 4 Apr 2005 11:07:38 -0700
From: Michael Demmer <[email-masked]>
To: Matt Bradbury <[email-masked]>
Cc: "Scott,Keith L." <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Mail-Followup-To: Matt Bradbury <[email-masked]>, "Scott,Keith L." <[email-masked]>, [email-masked]
Sender: [email-masked]

> I think the inter-schema routing issues are going to be complex.  

Perhaps. Perhaps not. Depends a lot on the particulars of the
environment and the yet-to-be-determined canonical DTN routing
protocol.

> I think it's more likely we'll have gateways that are similar to NAT
> between the various schemas.  I feel there should be a common schema
> that most hosts use that will be known as the public DTN.

And this may very well emerge. But I'm hesitant to mandate that in the
architecture documents. Think of it as the difference between IP that
defines a protocol and the capital-I Internet. The latter is a
particular embodiment of a set of architectural principles and
protocols. The former is the what's actually specified in RFCs.

-m

Date: Mon, 4 Apr 2005 11:03:14 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> Scott,Keith L. wrote:
> >Maybe this is what everyone else has understood all along.  If so,
> >I think I'm on board.  I will try to restate my understanding of
> >the currently proposed approach and would like to know if this
> >meshes with everyone else's.
>
> I think this is really close, but I would quibble with two points
> as noted in-line below.

I think so as well. A couple minor comments below.

> In the same way, I think we will make life easier for ourselves in
> the DTN world if the demux tokens ("client IDs" or whatever) that
> enable demuxing to applications are kept distinct from the endpoint
> IDs (which are these strings of the general form
> "<schema_name>:<schema-specific part>") that enable routing to the
> bundle agents at which the demuxing happens.
>
> That is, just as in the IP world we don't tack port number onto the
> end of IP address and route/demux on the whole thing, in the DTN
> world I think we shouldn't tack client ID onto the end of endpoint
> ID and route/demux on the whole thing.  These are tokens that are
> used for different purposes, and we would save ourselves many
> headaches by formally recognizing them as different things for which
> different representation principles might apply.  We would never
> have had to introduce the "administrative endpoint ID" concept, for
> example, if we had done this right from the start.

I agree with Scott here... let's keep these two concepts distinct as
in the IP world. I really think this will help us in the long
run. Any case where you would want to "route on the demux identifier"
you should instead look at it as routing on a distinct endpoint
identifier, several of which may map to the same bundle agent and then
be delivered to different applications.

> Yes.  In a sense, the "schema" takes the place of the "region" in
> the architecture, with the important difference that we can say
> exactly what a schema is: it's a named set of rules for endpoint ID
> string syntax and semantics, period.

Perfect.

-m

Date: Mon, 4 Apr 2005 10:54:32 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> I could easily be wrong, but this sounds to me like the loose source
> routing capability that people have talked about wanting for some
> time now.  I am still not quite convinced that it's a good idea to
> put an entire loose source route in a single endpoint ID (subject to
> an appropriately defined schema, etc.).  I think we get a simpler,
> more flexible, and more powerful architecture if a loose source
> route is expressed in a separate Loose Source Route header
> comprising multiple concatenated endpoint IDs, each of which might
> individually be represented in a different schema.  The security
> concern you raise might also be easier to deal with if loose A>
> source routing information were contained in this way, I dunno.

I agree with this 100%.

-m

Date: Mon, 04 Apr 2005 18:35:27 +0100
From: Stephen Farrell <[email-masked]>
To: Matt Bradbury <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

[snip]

 > > > Anyway, the net effect is that if we do include such
 > > > desirable mobility features in the DTN architecture (and
 > > > I think we ought to, if we can) then there's this
 > > > additional security issue to consider.

[snip]

> I think he may have been referring to the scenario I laid out with a 
> secondary destination endpoint AKA 'care-of' address.

That was the one,
Stephen.

Date: Mon, 04 Apr 2005 12:22:58 -0500
From: Matt Bradbury <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Scott Burleigh wrote:

> Stephen Farrell wrote:
>
>>
>> Wow - some burst of traffic over the weekend!
>>
>> Generally I think that the (derivation from the) proposal
>> that Michael D. made seems sensible and I'd love to see that
>> written up in a page or so all by itself (since I'm fairly
>> thoroughly confused by the 30+ messages I've just read;-)
>>
>> There is one possibly additional thing to consider which is
>> that if you support additional identifiers/addresses like
>> a "route-to" then you may have the same security problems
>> that have been difficult for MIPv6 with its care-of address.
>>
>> Basically, such features can make it easier (and sometimes
>> trivial) for an on-path node to try to route all future
>> traffic to some unwanted location - in MIPv6 the effect
>> was that once you visited a network, (and they see your
>> IP address) then they could use a binding update request
>> to assert that all packets for you should continue to
>> be routed via their network, (or to a bombing-victim),
>> even after you're finished visiting. You will eventually
>> figure out that something is wrong, but it may be too
>> late. This was considered a sufficiently significant
>> vulnerability that it delayed some telecomms groups from
>> picking up on MIPv6 for quite a while if I recall correctly.
>>
>> I haven't been tracking the solutions for that, but it
>> seems that all solutions require a fairly thoroughly
>> worked-out (i.e. incl. key management!) cryptographic
>> way of authenticating the binding(s) between the various
>> addresses/identifiers. I think that MIPv6 ended up
>> mandating IPSec/ESP or equivalent must be used for
>> the binding updates which is, of course, not terribly
>> Delay/Disruption friendly, but we need to define some
>> equivalent key managment functionality in any case
>> for the BAH/PSH fields - this just gives us another
>> reason to need that.
>>
>> Anyway, the net effect is that if we do include such
>> desirable mobility features in the DTN architecture (and
>> I think we ought to, if we can) then there's this
>> additional security issue to consider.
>
>
> I could easily be wrong, but this sounds to me like the loose source 
> routing capability that people have talked about wanting for some time 
> now.  I am still not quite convinced that it's a good idea to put an 
> entire loose source route in a single endpoint ID (subject to an 
> appropriately defined schema, etc.).  I think we get a simpler, more 
> flexible, and more powerful architecture if a loose source route is 
> expressed in a separate Loose Source Route header comprising multiple 
> concatenated endpoint IDs, each of which might individually be 
> represented in a different schema.  The security concern you raise 
> might also be easier to deal with if loose source routing information 
> were contained in this way, I dunno.
>
> Scott
>
I think he may have been referring to the scenario I laid out with a 
secondary destination endpoint AKA 'care-of' address.

-Matt

Date: Mon, 04 Apr 2005 10:11:45 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Stephen Farrell wrote:
> 
> Wow - some burst of traffic over the weekend!
> 
> Generally I think that the (derivation from the) proposal
> that Michael D. made seems sensible and I'd love to see that
> written up in a page or so all by itself (since I'm fairly
> thoroughly confused by the 30+ messages I've just read;-)
> 
> There is one possibly additional thing to consider which is
> that if you support additional identifiers/addresses like
> a "route-to" then you may have the same security problems
> that have been difficult for MIPv6 with its care-of address.
> 
> Basically, such features can make it easier (and sometimes
> trivial) for an on-path node to try to route all future
> traffic to some unwanted location - in MIPv6 the effect
> was that once you visited a network, (and they see your
> IP address) then they could use a binding update request
> to assert that all packets for you should continue to
> be routed via their network, (or to a bombing-victim),
> even after you're finished visiting. You will eventually
> figure out that something is wrong, but it may be too
> late. This was considered a sufficiently significant
> vulnerability that it delayed some telecomms groups from
> picking up on MIPv6 for quite a while if I recall correctly.
> 
> I haven't been tracking the solutions for that, but it
> seems that all solutions require a fairly thoroughly
> worked-out (i.e. incl. key management!) cryptographic
> way of authenticating the binding(s) between the various
> addresses/identifiers. I think that MIPv6 ended up
> mandating IPSec/ESP or equivalent must be used for
> the binding updates which is, of course, not terribly
> Delay/Disruption friendly, but we need to define some
> equivalent key managment functionality in any case
> for the BAH/PSH fields - this just gives us another
> reason to need that.
> 
> Anyway, the net effect is that if we do include such
> desirable mobility features in the DTN architecture (and
> I think we ought to, if we can) then there's this
> additional security issue to consider.

I could easily be wrong, but this sounds to me like the loose source routing capability that people have talked about wanting for some time now.  I am still not quite convinced that it's a good idea to put an entire loose source route in a single endpoint ID (subject to an appropriately defined schema, etc.).  I think we get a simpler, more flexible, and more powerful architecture if a loose source route is expressed in a separate Loose Source Route header comprising multiple concatenated endpoint IDs, each of which might individually be represented in a different schema.  The security concern you raise might also be easier to deal with if loose source routing information were contained in this way, I dunno.

Scott

Date: Mon, 04 Apr 2005 10:02:52 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Keith Scott wrote:
>  
> 
> 
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of 
>>Scott Burleigh
>>Sent: Sunday, April 03, 2005 6:18 PM
>>To: [email-masked]
>>Subject: Re: [dtn-interest] Comments on DTNRG documents from 
>>BBN SPINDLE project
>>
>>I think we're just tussling over wording here.  I think it's 
>>important to identify this step explicitly in this "model" 
>>because in some cases it's exactly what you do.  You are 
>>absolutely right, it is always possible to route on 
>>"arbitrary strings" that don't have any topological 
>>significance that is visible to the naked eye.  But I would 
>>say that if you've got the machinery to enable this (like 
>>distributed hash tables or whatever) then the string you're 
>>routing on *does* have topological significance, by 
>>definition.  Maybe it's implicit or inscrutable topological 
>>significance, maybe it's topological significance only in the 
>>context of that particular flavor of routing machinery -- but 
>>if you can route on the string without resolving it to 
>>another string then the string is topologically significant.
> 
> 
> No.  For a small region, I could simply require that each application
> instance acquire a completely random 128-bit number, and that's it.  All
> entries in the routing tables for that region would be the moral equivalent
> of /32s in IPv4, and there is no difference between routing information and
> application demux information.  I claim that these strings have no
> topological significance in and of themselves because simply examining the
> string gives no clue whatsoever as to the location of the endpoint.

It's still just a question of language.  When I say a string is "topologically significant" I mean that I don't have to resolve (transform, map, whatever) that string into another string before using it -- in some unspecified way -- to compute a route to some single location in the network; that definition encompasses the case you describe.  When you say a string is "topologically significant" I think you mean that the string unambiguously identifies a single location in the network, which enables you to compute a route to that location; that definition clearly excludes the case you describe.

My formulation is maybe more general but not necessarily better, and in any case this isn't a term that we have to agree on.  The important thing is to agree on the model as a whole (whatever words we use to describe it), which I believe we do.

Scott

Date: Mon, 04 Apr 2005 09:38:50 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Sender: [email-masked]

Scott,Keith L. wrote:
> Maybe this is what everyone else has understood all along.  If so, I think
> I'm on board.  I will try to restate my understanding of the currently
> proposed approach and would like to know if this meshes with everyone
> else's.

I think this is really close, but I would quibble with two points as noted in-line below.

> We completely do away with regions, and endpoint identifiers are simply URI
> schema.  We can have the GUID schema, the Kevin's_DHT schema, the
> Keshav's_DHT schema, plus others.  I could make my own schema that is the
> 'region' schema, whose schema-specific part is region/STUFF, where region
> has topological significance and STUFF is probably another URI but I'm not
> sure.  There's nothing at all special about my region schema, it's just
> another DTN schema, peer with all the rest.  Nobody has to do anything
> special to deal with this.

Perfect.

  How demuxing to applications is done is part of
> the schema definition, not a problem here.

My first quibble.  We can do this, certainly, but I think we would get substantial benefit (in terms of simplicity and intelligibility, at least) by clearly distinguishing between routing and demuxing in more or less the same way that the Internet architecture does.

In the IP world, the port numbers that enable demuxing to applications are kept quite distinct from the IP addresses that enable routing to the hosts at which the demuxing happens.

In the same way, I think we will make life easier for ourselves in the DTN world if the demux tokens ("client IDs" or whatever) that enable demuxing to applications are kept distinct from the endpoint IDs (which are these strings of the general form "<schema_name>:<schema-specific part>") that enable routing to the bundle agents at which the demuxing happens.

That is, just as in the IP world we don't tack port number onto the end of IP address and route/demux on the whole thing, in the DTN world I think we shouldn't tack client ID onto the end of endpoint ID and route/demux on the whole thing.  These are tokens that are used for different purposes, and we would save ourselves many headaches by formally recognizing them as different things for which different representation principles might apply.  We would never have had to introduce the "administrative endpoint ID" concept, for example, if we had done this right from the start.

> When a DTN router gets ahold of a bundle, it looks at the destination
> endpoint identifier schema and decides where to forward the bundle.  If the
> DTN router 'groks' the particular schema, it may make use of the
> schema-specific part to do fine-grained routing (as the current DTN2
> implementation does with the 'host' part of the 'internet' schema).  If the
> router does not know how to parse the schema-specific part, it's got to do
> something (or drop the bundle, or maybe just hold onto it in the hopes of
> acquiring a clue later -- implementation specific).  Again, nothing special
> about any particular schema.

Right.

> If a DTN router receives a bundle with a destination schema it does not
> understand (one for which it cannot interpret the schema-specific part),
> what does it do?  1. It might have a default route for all schemas it
> doesn't understand;

Yes.  This was Mike's default notion.

  2. there might be configuration information that says,
> "schemaB send this way, schemaC that way, all others some other way",

Sure.  This amounts to multiple default routes, one per schema.  And you probably still need option 1 as well, for schemas you've never heard of.

> or 3. there might be an 'inter-schema' DTN routing protocol that distributes
> information about points of attachment between the various schemas (the
> dynamic routing verion of 2).

Sure, we could eventually invent a protocol that dynamically conveys the information needed to populate the configuration information that option 2 relies on.

  All of these (including combinations) are
> options, and all schemas are treated the same.  Places that can support
> 'inter-schema' routing can have a single default route, etc.

I'm not totally sure I understand what you're saying here, but I think I agree.

> This would (I think) support a very rich generality of naming, allowing the
> use of GUID schemas, DHT  and I3 schemas, and (in those networks that might
> need it) schemas containing topological information.

Yes, exactly.

  Every schema in a
> sense becomes its own overlay network.

Certainly its own address space.  If you posit that there's always a one-to-one correspondence between address spaces and networks (which is not unreasonable) then yes, you've got one network per schema.  But additionally you still have one overarching overlay network that encompasses all of these per-schema networks, provided you've got routers that can interpret endpoint IDs expressed in multiple schemas so that traffic can flow from end to end.

  The old 'end-to-end' picture (with
> bundles traversing multiple regions) then becomes an end-to-end picture
> where a bundle may be routed through multiple distinct 'schemas' on its way
> to the destination.

Yes.  In a sense, the "schema" takes the place of the "region" in the architecture, with the important difference that we can say exactly what a schema is: it's a named set of rules for endpoint ID string syntax and semantics, period.

Scott

Date: Mon, 04 Apr 2005 10:51:11 -0500
From: Matt Bradbury <[email-masked]>
To: "Scott,Keith L." <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] DTN without regions - I think I get it
Sender: [email-masked]

Scott,Keith L. wrote:

>
>If a DTN router receives a bundle with a destination schema it does not
>understand (one for which it cannot interpret the schema-specific part),
>what does it do?  1. It might have a default route for all schemas it
>doesn't understand; 2. there might be configuration information that says,
>"schemaB send this way, schemaC that way, all others some other way", or 3.
>there might be an 'inter-schema' DTN routing protocol that distributes
>information about points of attachment between the various schemas (the
>dynamic routing verion of 2).  All of these (including combinations) are
>options, and all schemas are treated the same.  Places that can support
>'inter-schema' routing can have a single default route, etc.
>  
>
I think the inter-schema routing issues are going to be complex.  I 
think it's more likely we'll have gateways that are similar to NAT 
between the various schemas.  I feel there should be a common schema 
that most hosts use that will be known as the public DTN.  Esoteric 
networks will still be able to have their own schemas, but I don't think 
we can expect all DTN routers to understand all schemas.  This is 
similar to the way the IPv4 world has agreed generally on address 
allocation.  Though there's nothing stopping someone from re-using 
addresses as long as they're seperate from the public internet and do 
translation if they do connect to the public internet.

-Matt

From: "Scott,Keith L." <[email-masked]>
To: <[email-masked]>
Date: Mon, 4 Apr 2005 10:25:22 -0400
Subject: [dtn-interest] DTN without regions - I think I get it
Sender: [email-masked]

Maybe this is what everyone else has understood all along.  If so, I think
I'm on board.  I will try to restate my understanding of the currently
proposed approach and would like to know if this meshes with everyone
else's.

We completely do away with regions, and endpoint identifiers are simply URI
schema.  We can have the GUID schema, the Kevin's_DHT schema, the
Keshav's_DHT schema, plus others.  I could make my own schema that is the
'region' schema, whose schema-specific part is region/STUFF, where region
has topological significance and STUFF is probably another URI but I'm not
sure.  There's nothing at all special about my region schema, it's just
another DTN schema, peer with all the rest.  Nobody has to do anything
special to deal with this.  How demuxing to applications is done is part of
the schema definition, not a problem here.

When a DTN router gets ahold of a bundle, it looks at the destination
endpoint identifier schema and decides where to forward the bundle.  If the
DTN router 'groks' the particular schema, it may make use of the
schema-specific part to do fine-grained routing (as the current DTN2
implementation does with the 'host' part of the 'internet' schema).  If the
router does not know how to parse the schema-specific part, it's got to do
something (or drop the bundle, or maybe just hold onto it in the hopes of
acquiring a clue later -- implementation specific).  Again, nothing special
about any particular schema.

If a DTN router receives a bundle with a destination schema it does not
understand (one for which it cannot interpret the schema-specific part),
what does it do?  1. It might have a default route for all schemas it
doesn't understand; 2. there might be configuration information that says,
"schemaB send this way, schemaC that way, all others some other way", or 3.
there might be an 'inter-schema' DTN routing protocol that distributes
information about points of attachment between the various schemas (the
dynamic routing verion of 2).  All of these (including combinations) are
options, and all schemas are treated the same.  Places that can support
'inter-schema' routing can have a single default route, etc.

This would (I think) support a very rich generality of naming, allowing the
use of GUID schemas, DHT  and I3 schemas, and (in those networks that might
need it) schemas containing topological information.  Every schema in a
sense becomes its own overlay network.  The old 'end-to-end' picture (with
bundles traversing multiple regions) then becomes an end-to-end picture
where a bundle may be routed through multiple distinct 'schemas' on its way
to the destination.

Does this support what everybody would like to do?

		--keith

Date: Mon, 04 Apr 2005 13:56:10 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Wow - some burst of traffic over the weekend!

Generally I think that the (derivation from the) proposal
that Michael D. made seems sensible and I'd love to see that
written up in a page or so all by itself (since I'm fairly
thoroughly confused by the 30+ messages I've just read;-)

There is one possibly additional thing to consider which is
that if you support additional identifiers/addresses like
a "route-to" then you may have the same security problems
that have been difficult for MIPv6 with its care-of address.

Basically, such features can make it easier (and sometimes
trivial) for an on-path node to try to route all future
traffic to some unwanted location - in MIPv6 the effect
was that once you visited a network, (and they see your
IP address) then they could use a binding update request
to assert that all packets for you should continue to
be routed via their network, (or to a bombing-victim),
even after you're finished visiting. You will eventually
figure out that something is wrong, but it may be too
late. This was considered a sufficiently significant
vulnerability that it delayed some telecomms groups from
picking up on MIPv6 for quite a while if I recall correctly.

I haven't been tracking the solutions for that, but it
seems that all solutions require a fairly thoroughly
worked-out (i.e. incl. key management!) cryptographic
way of authenticating the binding(s) between the various
addresses/identifiers. I think that MIPv6 ended up
mandating IPSec/ESP or equivalent must be used for
the binding updates which is, of course, not terribly
Delay/Disruption friendly, but we need to define some
equivalent key managment functionality in any case
for the BAH/PSH fields - this just gives us another
reason to need that.

Anyway, the net effect is that if we do include such
desirable mobility features in the DTN architecture (and
I think we ought to, if we can) then there's this
additional security issue to consider.

Regards,
Stephen.

To: [email-masked]
Date: Sun, 03 Apr 2005 21:09:31 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] cross-post from our 'developing countries' project...
Sender: [email-masked]

------- Forwarded Message

>
> From:  [email-masked]
> Date:  Thu, 17 Mar 2005 14:49:54 PST
> 
> I just returned from the "Policy Options and Models for Bridging Digital Divi
des" conference in Tampere, Finland.
> 
> An interesting project we learned about is this PFNET(People First Network) P
roject in the Solomon Islands (near Papua-New Guinee).
> 
> The project uses HF radios to wirelessly link tens of islands. The links deli
ver 2kbps bandwidth and connect  islands which are several hundreds of kilomete
rs apart.
> 
> Currenly email is the predominant application, and a kiosk is placed on every
 island. E-mail is used for communication, ordering medical supplies, emergenci
es, etc.
> 
> [...]
> There seem to be opportunities for DTN and TIERStore. Currenly, they are (
or intend to) use
> the TEK low connectivity search engine (www.cag.lcs.mit.edu/tek/), that sends
 search queries over email, and gets responses through email as well. In such c
onditions, DTN would work great, and would also be very useful.
> 
> 
> Sergiu.

Date: Sun, 03 Apr 2005 22:32:53 -0400
From: Keith Scott <[email-masked]>
Subject: RE: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
To: "'Scott Burleigh'" <[email-masked]>, [email-masked]
Organization: The MITRE Corporation
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Scott Burleigh
> Sent: Sunday, April 03, 2005 6:18 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] Comments on DTNRG documents from 
> BBN SPINDLE project
> 
> I think we're just tussling over wording here.  I think it's 
> important to identify this step explicitly in this "model" 
> because in some cases it's exactly what you do.  You are 
> absolutely right, it is always possible to route on 
> "arbitrary strings" that don't have any topological 
> significance that is visible to the naked eye.  But I would 
> say that if you've got the machinery to enable this (like 
> distributed hash tables or whatever) then the string you're 
> routing on *does* have topological significance, by 
> definition.  Maybe it's implicit or inscrutable topological 
> significance, maybe it's topological significance only in the 
> context of that particular flavor of routing machinery -- but 
> if you can route on the string without resolving it to 
> another string then the string is topologically significant.

No.  For a small region, I could simply require that each application
instance acquire a completely random 128-bit number, and that's it.  All
entries in the routing tables for that region would be the moral equivalent
of /32s in IPv4, and there is no difference between routing information and
application demux information.  I claim that these strings have no
topological significance in and of themselves because simply examining the
string gives no clue whatsoever as to the location of the endpoint.

Date: Sun, 03 Apr 2005 22:21:31 -0400
From: Keith Scott <[email-masked]>
Subject: RE: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
To: "'Scott Burleigh'" <[email-masked]>, [email-masked]
Organization: The MITRE Corporation
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Scott Burleigh
> Sent: Sunday, April 03, 2005 6:07 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] Comments on DTNRG documents from 
> BBN SPINDLE project
> 
> Michael Demmer wrote:
> >>Would we be willing to constrain these mux/demux tokens to numeric 
> >>values rather than ASCII strings?
> > 
> > Hmm -- maybe we could support both? As Keith pointed out in his 
> > original posting on changes to the bundling protocol, with the move 
> > from next_header_type to header_type, we now have a free 
> byte in the 
> > primary bundle header. We could use some of these bits to denote 
> > whether the bundle is using demux tokens that are numeric, 
> ascii, or 
> > simply nonexistent.
>
> But we haven't yet reached consensus on that change, right?  
> And in any case I don't see any advantage to increasing the 
> complexity of the protocol still further by injecting yet 
> another degree of freedom in the way bundles are constructed 
> and parsed.  If we need ASCII demux tokens, let's figure out 
> how to represent them.  If we don't (as I hope), then it's 
> not an issue.

I've got to go with Scott here, I think this is unnecessarily complex and
restraining.  It would simply recast what used to be the region part of the
endpoint identifier under the guise of an integer in the primary header.
Worse, those bits are specifying the semantics for just a piece of what's in
the admin part?  We're going to need something to say what the semantics of
the (rest of the) admin part are as well, and I don't think that enumerating
the possibilities here and now is the right way to go.

If the semantics of the way applications are identified are a function of
the region, then we're free to use ASCII strings in one region and
self-delimiting integers in another.

		--keith

Date: Sun, 3 Apr 2005 17:43:27 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> >I would say that there must be some function of the admin part that
> >identifies a particular application.  If the admin part is simply the PGP
> >key of an application, and routing in the region is set up to deal with
> >that, then once the bundle reaches the destination bundle agent, that agent
> >will need to look at the whole admin part and make a decision about which
> >application gets the data.
> 
> Right, in the case where we're routing on the PGP key of an application, 
> that key has to be used both for routing to the destination bundle agent 
> and for demuxing to the destination application instance.  In that case the 
> two functions are inextricably entangled, unfortunately.  Remind me why we 
> would want to do this?

It sounds to me like the situation Keith describes is one in which
demux identifiers aren't needed, since the destination bundle agent
can use the endpoint id (the PGP key) to figure out which application
is being addressed.

So then we're not really routing on the demux id, rather we're
demuxing on the endpoint id, which as I said before, we will want to
support anyway for cases in which there may only be one application
per bundle agent.

-m

Date: Sun, 03 Apr 2005 17:20:44 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Keith Scott wrote:
>>Except that an application never is a bundle agent, by 
>>definition.  An application (or, in my mind, an "instance" of 
>>an application) uses the services of a bundle agent.  The 
>>bundle agent might be a separate executable (with the 
>>application client and the bundle agent interacting via some 
>>sort of interprocess communication), or the bundle agent 
>>might be something more nebulous like a state representation 
>>in a database (with the application client and the bundle 
>>agent "interacting" via direct API function calls), but 
>>that's just a matter of implementation.  Architecturally they 
>>are quite distinct.
> 
> 
> "They" being the application and the bundle agent... (right?)

Yes.

>>The application instance or client uses some mechanism (RPC 
>>or some other IPC or a socket connection or a function call) 
>>to "connect" to the bundle agent to pick up bundles, which 
>>are demuxed to it based on a demux string or "local stuff" at 
>>the tail end of the admin part of the destination endpoint ID 
> 
> 
> I would say that there must be some function of the admin part that
> identifies a particular application.  If the admin part is simply the PGP
> key of an application, and routing in the region is set up to deal with
> that, then once the bundle reaches the destination bundle agent, that agent
> will need to look at the whole admin part and make a decision about which
> application gets the data.

Right, in the case where we're routing on the PGP key of an application, that key has to be used both for routing to the destination bundle agent and for demuxing to the destination application instance.  In that case the two functions are inextricably entangled, unfortunately.  Remind me why we would want to do this?

>>Good point about the report-to: you probably do want to 
>>specify a client demux token along with the endpoint ID for 
>>report-to, otherwise the status report can never go any 
>>further than the bundle agent itself.
>>
>>On the other hand, for some environments (such as 
>>interplanetary internet) it is really important to minimize 
>>header size; also it's very convenient to have the primary 
>>header be of fixed length, so I'm reluctant to add anything 
>>more to it.
>>
>>Would we be willing to constrain these mux/demux tokens to 
>>numeric values rather than ASCII strings?  This doesn't cost 
>>us any latitude for experimentation with routing schemes, 
>>because these things aren't in the endpoint IDs that we use 
>>for routing.  If they were always numeric then each one could 
>>be a self-defining numeric value (as in LTP) that could be 
>>represented in as little as a single byte but could range 
>>into the trillions as necessary.  We could put three such 
>>SDNVs -- source client ID, destination client ID, report-to 
>>client ID -- at the start of the Dictionary header, which is 
>>required but is variable-length.  For environments in which 
>>no muxing/demuxing is necessary, such as sensor networks, 
>>you'd only waste three bytes per bundle.
> 
> 
> Do we really want to constrain implementations in resource-rich environments
> to conform to the naming conventions for resource-constrained environments?

Yeah, if this is an issue and we absolutely have to carry ASCII strings to enable demuxing to application clients then I guess we just have to.

> Wouldn't it make sense to have a pretty flexible naming scheme and for the
> resource-constrained environment to use compression,

No.  An environment that is constrained on bandwidth is fairly likely to be computationally constrained as well.  Don't count on the magic of lossless compression to compensate for this kind of design decision.

  or a lookup table

Sure, but lookup on what?  If we carry a number then in a resource-rich environment we can use the number to look up a lengthy string.  If we carry the string then we've got the string.

Scott

Date: Sun, 03 Apr 2005 17:02:28 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Agents
Sender: [email-masked]

Matt Bradbury wrote:
> I want to see if my understanding of bundling agents is correct:
> 
> Bundling agents control access to the DTN, all bundles enter and leave 
> through them.

Yes.

> Does just one bundling agent reside at each "endpoint identifier".  Or 
> can it be many?  Is a bundling agent on the same machine as a DTN 
> router, or is it elsewhere.

Going with Keith's concept: every bundle agent is a DTN router, but it would be possible for a DTN router not to be a bundle agent.  Each is a set of state machines residing on some computer -- not the computer itself.

This is a little different from the way we use the terms in the documents, where I think "bundle agent" is the more general term and "DTN routers" are a subclass of bundle agents that aren't just sources and sinks of bundles but may also forward bundles sourced elsewhere.  We need to resolve this one way or the other, along with a lot of other terminology issues, but for now I don't think there are any contexts in which we get into trouble by using the terms interchangeably.

> Does a bundling agent control many "demux identifiers" or just one?  Or 
> all?

Each "demux identifier" is analogous to a port number, a token that maps to some sort of device at which an application can use the services of the bundle agent.  A bundle agent multiplexes outbound bundle payloads from the devices corresponding to multiple demux identifiers (notionally, multiple application clients) and demultimplexes inbound bundle payloads to them.

> In my head it still seems that the "bundling agent" is nothing more than 
> a glorified API for an application to talk to a DTN router.  The 
> application asks the "bundle agent" to listen to a few different "demux 
> strings".  This seems the same as an application in today's world asking 
> the IP stack to open a few ports and listen to them.

Yep, same model.

  The only 
> difference is that the call to the bundling agents can be done over a 
> network connection to a central DTN router.

And that is strictly a matter of implementation.  There's nothing in the architecture that requires that an application client make any sort of network connection to the bundle agent at which it is registered, and in fact my implementation doesn't operate this way.

Scott

Date: Sun, 03 Apr 2005 16:48:12 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Agents
Sender: [email-masked]

Keith Scott wrote:
> I've always thought of bundle agents as the bundling equivalent of the
> network stack, where one bundle agent could support multiple independent
> applications.

Or maybe more precisely, the network stack instantiated on a single network host?  Not "the stack" as an abstraction, but a set of state machines, right?

Which brings up the question of what we call the set of state machines operating for a single network interface.  If you had a computer with multiple DTN addresses (multiple strings on which you can route bundles to it, analogous to a computer with multiple IP addresses), it would be because you had multiple interfaces in the network.  Your computer would have multiple network identities, multiple adminstrative endpoint IDs.  Would we consider the computer to be a single "bundle agent"?  There would be no single string that uniquely identifies that bundle agent in the network, just as there is no single address that uniquely identifies a multihomed computer in the Internet; IP addresses identify network interface cards, not hosts.  I think we need a name for each of the things that actually are addressable in a DTN-based network -- the interfaces, not the agents/routers -- and we need to be more careful in the architecture and protocol spec documents about which terms we use
 in which contexts.

  With this model there can be multiple demux identifiers per
> bundle agent, and a DTN router and a bundle agent are almost synonymous.

Right.

Date: Sun, 03 Apr 2005 16:24:57 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Michael Demmer wrote:
>>- Agree that in some -- not all -- cases we may have multiple
>>"application instances" (we can probably find another term that is
>>more palatable; I'll say "clients" for now, though that may turn out
>>to be confusing) that are concurrently using the services offered by
>>a given bundle agent.  In those cases we need a way to mux/demux
>>bundle payloads from/to those clients, something functionally
>>analogous to port number.
> 
> 
> Ok as well. We probably need some concept that corresponds to the
> original purpose of the administrative endpoint ID, i.e. a demux
> identifier that corresponds to the agent itself for things like
> custody transfer signals.

You're right.  If we use numbers to represent these things then I would propose that we use zero for this purpose.

  I could actually envision several uses for
> this facility, in that routing protocols could (and probably should)
> communicate using different types of administrative bundles.
> 
> 
>>- Because we don't route on these source and destination mux/demux
>>tokens, because they are optional, and because they are only
>>relevant at the point at which you've reassembled the payload from
>>fragments as necessary (assuming we're still doing bundle
>>fragmentation, which I will argue against at a later time), I would
>>suggest that we add them to the Payload header.  
> 
> 
> I'm tempted to agree, however this may cause problems for status
> reports and fragments, in which I think you would want the demux name
> for the Reply-To endpoint included in the status report, which means
> it couldn't be in the PayloadHeader, unless it were replicated to each
> fragment (assuming we still do fragmentation).

Matt brought up the same point, and I agree.  I'd like to make them SDNVs, and yesterday I suggested that we put them in the Dictionary header.  But that breaks if we're clever enough to omit the Dictionary header in some cases (as you mentioned a couple of emails ago).  Maybe the best answer is to have them at the tail end of the Primary header, even though that makes the Primary header variable-length.

Scott

Date: Sun, 03 Apr 2005 16:17:38 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Michael Demmer wrote:
>>I think the general model for computing the route on which to
>>forward a bundle looks like this:
> 
> 
> 
>>3. If the M-bytes-long substring's semantic significance is not
>>topological, then you have to "resolve" it to another string that
>>does have topological significance.  You do this by whatever
>>mechanism you've got: DNS, /etc/hosts, a database, a distributed
>>hash table, etc.  If this resolution fails, you can't compute the
>>route.
> 
> 
> This I disagree with for the reasons I said before. I don't see why we
> need to forbid routing on strings that may not have topological
> significance. I agree that this type of lookup is in many cases
> necessary, but I could very well imagine a small, isolated pocket of a
> DTN network that routes on arbitrary strings.

I think we're just tussling over wording here.  I think it's important to identify this step explicitly in this "model" because in some cases it's exactly what you do.  You are absolutely right, it is always possible to route on "arbitrary strings" that don't have any topological significance that is visible to the naked eye.  But I would say that if you've got the machinery to enable this (like distributed hash tables or whatever) then the string you're routing on *does* have topological significance, by definition.  Maybe it's implicit or inscrutable topological significance, maybe it's topological significance only in the context of that particular flavor of routing machinery -- but if you can route on the string without resolving it to another string then the string is topologically significant.

After all, the string "131.9.100.107" doesn't have any innate topological significance; it gets that significance from context, i.e., a netmask and a routing table or whatever.  It only looks topologically significant because it looks like the kind of thing we know we routinely route on in the Internet.  To somebody who doesn't know that, it's an arbitrary string.

Scott

Date: Sun, 03 Apr 2005 16:07:17 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Michael Demmer wrote:
>>Would we be willing to constrain these mux/demux tokens to numeric
>>values rather than ASCII strings?  
> 
> Hmm -- maybe we could support both? As Keith pointed out in his
> original posting on changes to the bundling protocol, with the move
> from next_header_type to header_type, we now have a free byte in the
> primary bundle header. We could use some of these bits to denote
> whether the bundle is using demux tokens that are numeric, ascii, or
> simply nonexistent.

But we haven't yet reached consensus on that change, right?  And in any case I don't see any advantage to increasing the complexity of the protocol still further by injecting yet another degree of freedom in the way bundles are constructed and parsed.  If we need ASCII demux tokens, let's figure out how to represent them.  If we don't (as I hope), then it's not an issue.

>>This doesn't cost us any latitude for experimentation with routing
>>schemes, because these things aren't in the endpoint IDs that we use
>>for routing.
> 
> I agree that this doesn't change routing, but it may make things like
> multi-point application delivery or publish-subscribe style
> applications more difficult to support.

If you think of these things as analogous to port numbers, then I would suggest that multicast-style multi-point delivery is probably unaffected since we seem to be able to do that in the IP world without doing anything tricky with port numbers.

As for publish-subscribe, if we venture into building that kind of capability directly into Bundling rather than in a layer above it then I think we can safely abandon any hope of having a working implementation of the complete specification any time this decade.
 
>>If they were always numeric then each one could be a self-defining
>>numeric value (as in LTP) that could be represented in as little as
>>a single byte but could range into the trillions as necessary.  We
>>could put three such SDNVs -- source client ID, destination client
>>ID, report-to client ID -- at the start of the Dictionary header,
>>which is required but is variable-length.  For environments in which
>>no muxing/demuxing is necessary, such as sensor networks, you'd only
>>waste three bytes per bundle.
> 
> SDNV is fine with me -- perhaps we should also use them to help
> address the bundle length discussion from before.
> 
> Note also that if we enumerate all the endpoint naming schemas with
> type codes, perhaps fitting in a single byte, then we may not need a
> dictionary header in all circumstances, and we may be able to get the
> protocol headers down to something reasonable for a constrained sensor
> network.

That is pretty much what I was proposing in my email of the 17th, though the approach I was talking about doesn't depend on (or restrict us to) any particular naming schema.

>>Here I disagree.  Precisely because everybody already has a
>>well-defined idea of exactly what a "host" is and what a "port
>>number" is, when we're talking about things that are different we
>>have got to use different words.  We can say that a bundle agent is
>>*analogous* to a host and that a client ID is *analogous* to a port
>>number, but if we use the terms interchangeably then people will
>>draw inferences about the behavior of bundle agents and bundling
>>clients based on their understanding of these other terms, and they
>>will get things wrong.
> 
> 
> I agree with Scott. We should come up with clear names for the two,
> and I strongly agree that neither should be the term "region", but
> coopting the internet syntax seems like a bad way to go. 
> 
> How about "endpoint identifier" or "agent identifier" for the
> host-like part, and "demux identifier" for the port-like part?

"Endpoint identifier" is what we've been using for the past couple of years; I think it's fine.  My current preference for the demux token that functions like a port number is "client identifier", but "demux identifier" is okay.

Date: Sun, 03 Apr 2005 17:09:50 -0400
From: Keith Scott <[email-masked]>
Subject: RE: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
To: "'Scott Burleigh'" <[email-masked]>, [email-masked]
Organization: The MITRE Corporation
Sender: [email-masked]

It sounds like a lot of assumptions are being made about the way admin parts
have to be, based solely on implementations to date.  There's nothing that
keeps a region from using PGP keys as its admin parts, period.  The region
would have to be set up to somehow direct bundles towards those bundle
agents responsible for them.  _IF_ those bundle agents could support
multiple applications, then they (the bundle agents) would have to associate
keys with particular applications.  Note that in this case, both routing and
application demuxing (if demuxing is used) probably operate on the whole of
the admin part.

Other stuff inline.

		--keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Scott Burleigh
> Sent: Saturday, April 02, 2005 6:44 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] Comments on DTNRG documents from 
> BBN SPINDLE project
> 
> Matt Bradbury wrote:
> > Scott Burleigh wrote:
> > 
> >> Michael Demmer wrote:
> >>
> >>> To throw in my two cents here, I would argue that we define an 
> >>> endpoint to be a <schema>:<name> tuple, where the set of 
> schemas is 
> >>> well-known and layed out in the bundle protocol, but that 
> we do not 
> >>> explicitly distinguish between "addresses" and "identities".
> >>
> >> Yes.
> > 
> > No.  You're talking about defining how the administrative 
> endpoint is 
> > processed in the bundle protocol?  That's just bad and should be 
> > defined elsewhere since we'll never be able to cover all 
> possible schemas.
> > Routing done on regions, demux done on administrative endpoints.
> 
> At this point Mike is still talking about the general syntax 
> for endpoint identifiers, not about the difference between 
> administrative and other endpoints.  But actually, on 
> re-reading more closely I agree with you that the set of all 
> schemas should not be well-known and defined in the bundle 
> protocol document; leaving open the possibility of defining 
> new bundle ID syntax schemas (in supplementary RFCs or 
> whatever) is exactly the point of this more general meta-syntax.

> Routing is and always has been done on endpoint IDs, which 
> have historically encompassed both region names and "admin 
> parts".  Demux to specific clients of the destination bundle 
> agent has historically been done on "local stuff" or "demux 
> strings" that were also stuffed into endpoint IDs, normally 
> at the end; moving away from that model is the point of the 
> remainder of my message.

This is entirely an artifact of the implementations.  Nothing keeps one from
defining a region where the admin part is a DHT identifier, and relying on
the DHT mechanics to get all the way to the application.  The admin part
could similarly be just some random string, that somehow (in that region)
maps all the way to an application.  The point is, in implementations so far
it has been convenient to define the semantics of endpoint identifiers to
be, well, tuples [host][app], but there's nothing that says this has to be
so.

> 
> "Administrative endpoints" are bundle agents that are acting 
> in the role of sources and destinations of bundles -- that 
> is, clients of their own services.  Currently bundle agents 
> are sources and destinations of bundles only when they are 
> exchanging custody transfer signals; the sources and 
> destinations of all other bundles are the "clients" or 
> "application instances" that register with bundle agents.
> 
> >>> One final note that's totally disjoint from the above is that we 
> >>> also need to discuss how demux strings fit into all this 
> (i.e. the 
> >>> dtn equivalent of a TCP or UDP port to identify a particular 
> >>> application attached to a dtn router).
> >>
> >> Yes.  We at one time talked about things called "application 
> >> instances" that were served by bundle agents -- a more 
> precise term 
> >> than just "application", I think, because it seems to me that an 
> >> "application" is a set of capabilities that can be 
> instantiated any 
> >> number of times (like "email") rather than a discrete 
> communicating 
> >> entity (like "Mike's email reader").  But Kevin objected to 
> >> explicitly and formally recognizing these things in the 
> architecture; 
> >> I think this was in part because in some cases, like motes, there 
> >> wouldn't necessarily be any "application" using the bundle 
> agent at 
> >> all -- once a bundle reached the bundle agent on the mote it was 
> >> simply going to be processed by the mote's operating system.
> > 
> > I think Kevin is right and this will be the standard way of using 
> > bundling.  Though with the application being the direct 
> bundling agent.
> 
> Except that an application never is a bundle agent, by 
> definition.  An application (or, in my mind, an "instance" of 
> an application) uses the services of a bundle agent.  The 
> bundle agent might be a separate executable (with the 
> application client and the bundle agent interacting via some 
> sort of interprocess communication), or the bundle agent 
> might be something more nebulous like a state representation 
> in a database (with the application client and the bundle 
> agent "interacting" via direct API function calls), but 
> that's just a matter of implementation.  Architecturally they 
> are quite distinct.

"They" being the application and the bundle agent... (right?)

> 
> >> Still we ended up tacking "local stuff" onto the end of 
> the endpoint 
> >> ID in most cases, to enable this kind of demuxing, because in 
> >> practice we usually do have applications that run on top 
> of bundling.  
> >> We just never accounted for it in the architecture, and
> > 
> > Never understood why so much was trying to be done in the 
> > administrative endpoint ID when the original spec said that 
> it should 
> > be unique to each region.  If you have only one region than you're 
> > going to have to make routing decisions on the 
> administrative data, so 
> > have many regions and route between regions.
> 
> The spec has always said that the "administrative part" of 
> the endpoint ID -- which is very different from an 
> "administrative endpoint ID", the DTN address of an 
> administrative endpoint -- has to be unique within region. 

> You're right that if you've only got one region then you can 
> only make routing decisions on the "admin part" of the 
> destination endpoint ID (whether the endpoint is 
> administrative or not).  I think that's okay, and I think 
> having lots of regions and making a lot of routing decisions 
> on region names is okay, except that I think it's time to 
> ditch the term "region" because after six years we've still 
> got no definition for it.
> 
> >> as you point out this omission eventually catches up to us.  We've 
> >> had to invent the concept of "administrative endpoint ID" -- as 
> >> distinct from the actual bundle source and destination 
> endpoint IDs 
> >> -- as a routing expedient (I'm guessing you don't really 
> route on the 
> >> whole "admin part" of a tuple even in the current implementations; 
> >> you just use the DNS name part of it, which is the administrative 
> >> endpoint ID) and as a destination for custody transfer 
> signals.  And 
> >> consequently we've had to informally invent an algorithm for 
> >> computing from destination endpoint ID the administrative 
> endpoint ID 
> >> of the relevant bundle agent -- to wit, truncate at the 
> "local stuff".
> > 
> > We shouldn't be routing on the admin part at all.  That 
> should be for 
> > local consumption only.

Again, the semantics of routing within a region are entirely up to that
region.  We have used [host][app].  The reason that the admin part is
'administrative' is that it is local to the region (think of a region as an
AS, e.g.)
 
> Except that if you are routing between two bundle agents that 
> are in the same region -- which we've long ago decided is 
> possible (except that, again, I think it's time to ditch the 
> "region" notion) -- then you've got nothing else to route on. 
>  That intra-regional routing *is* "local consumption".

Right.
 
> >> I think it would be good to confront this issue a little more 
> >> directly.  As you point out, the Internet architecture gives us a 
> >> good model.  We don't actually route on port numbers in 
> IP, right?

Some things actually do, but in general you are correct, and certainly not
in the core.
  
> >> Port numbers are distinct from IP addresses; they are carried 
> >> elsewhere in the header structure.  I think this works 
> pretty well, 
> >> and I would propose that we do more or less the same thing:
> > 
> > Agreed.
> > 
> >> -    Agree that bundling "endpoints" is a synonym for 
> "bundle agent", 
> >> period.  (Just as the endpoints of IP are hosts, not instances of
> >> applications.)  An endpoint ID is a bundle agent ID.  All endpoint 
> >> IDs are "administrative" endpoint IDs, so the 
> "administrative endpoint ID"
> >> concept goes away.
> > 
> > I'm still scratching my head from this part.  These terms 
> really are 
> > confusing sometimes.
> 
> You're right.  Yet another argument for going this way, I think.
> 
> >> -    Agree that in some -- not all -- cases we may have multiple 
> >> "application instances" (we can probably find another term that is 
> >> more palatable; I'll say "clients" for now, though that 
> may turn out 
> >> to be confusing) that are concurrently using the services 
> offered by 
> >> a given bundle agent.  In those cases we need a way to mux/demux 
> >> bundle payloads from/to those clients, something functionally 
> >> analogous to port number.
> > 
> > I always envisioned that the bundling layer got the bundles to the 
> > individual host, and that the bundling agent was the 
> application that 
> > connected (local or remote) to the bundling 
> host/router/server to pick 
> > up bundles based on the administrative part.
> 
> This is generally the right picture, but with slightly wrong 
> labels on some of the bits.
> 
> The bundling layer does get the bundles to the individual 
> bundle agent -- not "host", which is the corresponding IP 
> architectural term.  A bundle agent might reside on an IP 
> host, but alternatively it might reside on a sensor network 
> mote or deep space robot that has no IP address at all.
> 
> The application instance or client uses some mechanism (RPC 
> or some other IPC or a socket connection or a function call) 
> to "connect" to the bundle agent to pick up bundles, which 
> are demuxed to it based on a demux string or "local stuff" at 
> the tail end of the admin part of the destination endpoint ID 

I would say that there must be some function of the admin part that
identifies a particular application.  If the admin part is simply the PGP
key of an application, and routing in the region is set up to deal with
that, then once the bundle reaches the destination bundle agent, that agent
will need to look at the whole admin part and make a decision about which
application gets the data.

> -- not on the whole admin part.  The remainder of the admin 
> part of the destination endpoint ID (everything preceding the 
> demux string) is what was used to route the bundle to the 
> destination bundle agent from the point at which it entered 
> the region.
> 
> Your interpretation is a very reasonable one but it's not the 
> model we've been working with.  Again I think this is a 
> strong argument for clarifying some language and squeezing 
> some ambiguity out of the documents.
> 
> >> -    Because we don't route on these source and 
> destination mux/demux 
> >> tokens, because they are optional, and because they are 
> only relevant 
> >> at the point at which you've reassembled the payload from 
> fragments 
> >> as necessary (assuming we're still doing bundle 
> fragmentation, which 
> >> I will argue against at a later time), I would suggest that we add 
> >> them to the Payload header.  Let's make them LVs to 
> minimize overhead 
> >> in deployments where they aren't needed: a 1-byte length 
> followed by
> >> 0-255 bytes of mux/demux name.
> > 
> > What about return addresses?  Report-to addresses?  Keep the demux 
> > info in the main header.  That way the bundle router 
> doesn't ever look 
> > at the payload header, it just hands it off.  Though I 
> suspect it will 
> > be easier to design firewalls and layer 4 type switches in 
> the future 
> > if the demux info is in the main header.
> 
> Good point about the report-to: you probably do want to 
> specify a client demux token along with the endpoint ID for 
> report-to, otherwise the status report can never go any 
> further than the bundle agent itself.
> 
> On the other hand, for some environments (such as 
> interplanetary internet) it is really important to minimize 
> header size; also it's very convenient to have the primary 
> header be of fixed length, so I'm reluctant to add anything 
> more to it.
> 
> Would we be willing to constrain these mux/demux tokens to 
> numeric values rather than ASCII strings?  This doesn't cost 
> us any latitude for experimentation with routing schemes, 
> because these things aren't in the endpoint IDs that we use 
> for routing.  If they were always numeric then each one could 
> be a self-defining numeric value (as in LTP) that could be 
> represented in as little as a single byte but could range 
> into the trillions as necessary.  We could put three such 
> SDNVs -- source client ID, destination client ID, report-to 
> client ID -- at the start of the Dictionary header, which is 
> required but is variable-length.  For environments in which 
> no muxing/demuxing is necessary, such as sensor networks, 
> you'd only waste three bytes per bundle.

Do we really want to constrain implementations in resource-rich environments
to conform to the naming conventions for resource-constrained environments?
Wouldn't it make sense to have a pretty flexible naming scheme and for the
resource-constrained environment to use compression, or a lookup table, to
cut down on overhead?  It's also a lot easier to remember ntp than port 123.

> 
> >> I think this could scrub a lot of ambiguity out of the 
> architecture, 
> >> simplify the bundling protocol spec considerably, and in 
> the long run 
> >> save us a lot of heartache.
> >>
> >> Scott
> > 
> > I keep getting the feeling that everyone is afraid of bringing the 
> > bundling protocol into every network/server/host/router.  Aren't we 
> > talking about an overlay network that is ubiquitous?
> 
> I agree with you, I think that's exactly what we should be aiming for.

Why?  In a region that's well-connected, like the Internet, we may not need
bundle agents everywhere there's currently an IP router (or maybe I'm
misunderstaning your intent).

>   The reason IP has 
> > done so well is that it managed to bridge many different link layer 
> > technologies into one unified layer.  Layer 3 of the OSI 
> model is the 
> > thin waste on the curvy women, everything goes through that 
> one layer, 
> > and there's a lot of extras above and below it.  We should 
> be bridging 
> > every conceivable way of passing a bundle of data around 
> and make it 
> > routable.  Isn't the whole problem currently with the 
> administrative 
> > endpoint id the fact that the sender needs to know how the network 
> > works on the other end to send data to a specific bundling 
> agent?

The sender needs some token (maybe provided to it by the receiver, but
opaque outside of the receiver's region) that says how to reach the
receiver, that's it.  Taking the PGP key example again, if my app in region
A, which uses PGP keys as the admin parts, provides its key to somebody in
region C, then the thing in C doesn't need to know the innerds of region A,
or even that what it's been handed is a PGP key and not a
[host][app_identifier] tuple.

> As 
> > soon as things like network protocols and dns entries show 
> up in the 
> > demux field, it gets messy.  Keep that field simple and 
> clean.  If you 
> > want to get a bundle to a specific host, run the bundling 
> software on 
> > that host and route the bundles to it, then do a demux there.
> 
> Sure, routing on endpoint ID and demuxing on this newly 
> isolated mux/demux token (client ID, whatever).
> 
> > I also propose that we change the names of the fields in 
> the tuples.  
> > The current region field should be called 'host' and the current 
> > administrative endpoint id should be called 'port'.  This will gell 
> > better with people's current network understanding. How the 
> host field 
> > is parsed to give routing information is up to discussion, but I'd 
> > like to propose my tree based hierarchy outlined in a previous mail.
> 
> Here I disagree.  Precisely because everybody already has a 
> well-defined idea of exactly what a "host" is and what a 
> "port number" is, when we're talking about things that are 
> different we have got to use different words.  We can say 
> that a bundle agent is *analogous* to a host and that a 
> client ID is *analogous* to a port number, but if we use the 
> terms interchangeably then people will draw inferences about 
> the behavior of bundle agents and bundling clients based on 
> their understanding of these other terms, and they will get 
> things wrong.
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Sun, 03 Apr 2005 16:40:12 -0400
From: Keith Scott <[email-masked]>
Subject: RE: [dtn-interest] Bundling Agents
To: "'Matt Bradbury'" <[email-masked]>, [email-masked]
Organization: The MITRE Corporation
Sender: [email-masked]

I've always thought of bundle agents as the bundling equivalent of the
network stack, where one bundle agent could support multiple independent
applications.  With this model there can be multiple demux identifiers per
bundle agent, and a DTN router and a bundle agent are almost synonymous.
The only possible difference would be if one implemented a DTN router with
no API (an IP stack with no sockets interface) [not something I've given
serious thought to].

As an aside, there's not anything in the architecture document or the
protocol spec that says anything about the structure of the administrative
parts of endpoint addresses.  It has been convenient, in past
implementations, to structure them as [some sort of host identifier][some
sort of application identifier], for obvious reasons.  Even this allows a
level of indirection, since if the [host_identifier] part is allowed to be a
DNS name, there's a late bound name-to-address resolution that takes place.
Regions were the mechanism to allow for multiple naming/identifying
mechanisms to coexist.  Regions whose admin parts are DHT addresses, phone
numbers, or PGP keys are all valid (though some would be harder to route
_within_ than others, IMHO).  If one wanted to define a region where the
application identifiers were integers that came in the middle of DNS names
(dept.company[17]com, where [17] identifies a particular application) --
you're free to do so.

For each region, some encoding would be needed to get to an application.
Whether that coding is explicit [host_id][app_token] or implicit
[PGP_key_of_app] is up to the region.  For the PGP_key_of_app region, you've
got the problem of how to route to what is essentially a random string, but
that's the problem of that particular region, and does NOT (in the old
region model) propagate outside of that region.

  --keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Matt Bradbury
> Sent: Sunday, April 03, 2005 1:07 PM
> To: [email-masked]
> Subject: [dtn-interest] Bundling Agents
> 
> I want to see if my understanding of bundling agents is correct:
> 
> Bundling agents control access to the DTN, all bundles enter 
> and leave through them.
> 
> Does just one bundling agent reside at each "endpoint 
> identifier".  Or can it be many?  Is a bundling agent on the 
> same machine as a DTN router, or is it elsewhere.
> 
> Does a bundling agent control many "demux identifiers" or 
> just one?  Or all?
> 
> In my head it still seems that the "bundling agent" is 
> nothing more than a glorified API for an application to talk 
> to a DTN router.  The application asks the "bundle agent" to 
> listen to a few different "demux strings".  This seems the 
> same as an application in today's world asking the IP stack 
> to open a few ports and listen to them.  The only difference 
> is that the call to the bundling agents can be done over a 
> network connection to a central DTN router.
> 
> Please explain the fundamental differentness of the DTN way 
> from the current IP way.
> 
> -Matt
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Sun, 03 Apr 2005 13:06:52 -0500
From: Matt Bradbury <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Bundling Agents
Sender: [email-masked]

I want to see if my understanding of bundling agents is correct:

Bundling agents control access to the DTN, all bundles enter and leave 
through them.

Does just one bundling agent reside at each "endpoint identifier".  Or 
can it be many?  Is a bundling agent on the same machine as a DTN 
router, or is it elsewhere.

Does a bundling agent control many "demux identifiers" or just one?  Or all?

In my head it still seems that the "bundling agent" is nothing more than 
a glorified API for an application to talk to a DTN router.  The 
application asks the "bundle agent" to listen to a few different "demux 
strings".  This seems the same as an application in today's world asking 
the IP stack to open a few ports and listen to them.  The only 
difference is that the call to the bundling agents can be done over a 
network connection to a central DTN router.

Please explain the fundamental differentness of the DTN way from the 
current IP way.

-Matt

Date: Sun, 03 Apr 2005 13:04:51 -0500
From: Matt Bradbury <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Michael Demmer wrote:

>  
>
>>3. If the M-bytes-long substring's semantic significance is not
>>topological, then you have to "resolve" it to another string that
>>does have topological significance.  You do this by whatever
>>mechanism you've got: DNS, /etc/hosts, a database, a distributed
>>hash table, etc.  If this resolution fails, you can't compute the
>>route.
>>    
>>
>
>This I disagree with for the reasons I said before. I don't see why we
>need to forbid routing on strings that may not have topological
>significance. I agree that this type of lookup is in many cases
>necessary, but I could very well imagine a small, isolated pocket of a
>DTN network that routes on arbitrary strings.
>  
>
I think Michael is right, this shouldn't be in the bundle spec 
directly.  But it could be policy of a particular DTN.  Different 
routing schemes and the way they use the "endpoint identifier" to do 
routing, should be seperate specifications.

>  
>
>>I think we can easily retain all the advantages of the original
>>"tuple" syntax while gaining the flexibility that everyone seems to
>>want.  Let's agree on some overarching meta-syntactical structure
>>that enables us to determine by inspection which of the various
>>possible syntaxes a given endpoint ID conforms to: put a
>>colon-terminated "schema" name at the front as Mike proposes,
>>whatever.  Then let's define at least one such syntax -- a really
>>simple one -- that can by default be used by those of us who are
>>trying to deploy something in the near term.  Then let's move on.
>>People can define whatever additional, alternative endpoint ID
>>syntaxes they like, to support whatever routing models they like,
>>and we can see which ones work out best.
>>    
>>
>
>That seems fine to me. 
>
>What is the general feeling on my proposal for integral type codes
>that correspond to the different schemas? The reason it comes up here
>is that perhaps the colon syntax need not be mandated by the
>architecture and/or bundle protocol and could be left open to the
>implementation.
>
>  
>
Hmm, I have some doubts.  I think we should stick to the tuple 
definition for the clear demarcation between routing information and 
local demux info.

-Matt

Date: Sat, 2 Apr 2005 18:00:56 -0800
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> - Agree that bundling "endpoints" is a synonym for "bundle agent",
> period.  (Just as the endpoints of IP are hosts, not instances of
> applications.)  An endpoint ID is a bundle agent ID.  All endpoint
> IDs are "administrative" endpoint IDs, so the "administrative
> endpoint ID" concept goes away.

Ok with me.

> - Agree that in some -- not all -- cases we may have multiple
> "application instances" (we can probably find another term that is
> more palatable; I'll say "clients" for now, though that may turn out
> to be confusing) that are concurrently using the services offered by
> a given bundle agent.  In those cases we need a way to mux/demux
> bundle payloads from/to those clients, something functionally
> analogous to port number.

Ok as well. We probably need some concept that corresponds to the
original purpose of the administrative endpoint ID, i.e. a demux
identifier that corresponds to the agent itself for things like
custody transfer signals. I could actually envision several uses for
this facility, in that routing protocols could (and probably should)
communicate using different types of administrative bundles.

> - Because we don't route on these source and destination mux/demux
> tokens, because they are optional, and because they are only
> relevant at the point at which you've reassembled the payload from
> fragments as necessary (assuming we're still doing bundle
> fragmentation, which I will argue against at a later time), I would
> suggest that we add them to the Payload header.  

I'm tempted to agree, however this may cause problems for status
reports and fragments, in which I think you would want the demux name
for the Reply-To endpoint included in the status report, which means
it couldn't be in the PayloadHeader, unless it were replicated to each
fragment (assuming we still do fragmentation).

-m

Date: Sat, 2 Apr 2005 17:51:34 -0800
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> I think the general model for computing the route on which to
> forward a bundle looks like this:

> 1. You start with the destination endpoint ID, an ASCII string of
> length N.  [This would be *after* you've retrieved that string from
> a pre-positioned dictionary if you're using the mechanism I proposed
> in my email of, I think, the 17th -- which we're not discussing
> here.]

Ok.

> 2. You parse out an M-bytes-long substring of that string, 0 <= M <=
> N, such that the substring has semantic significance for you.  [The
> other bytes of the destination endpoint ID are "opaque" to you.]
> That substring is different at different points along the path from
> the source endpoint to the destination endpoint: different bundle
> agents have differing capacities for parsing a semantically
> significant substring out of an endpoint ID, depending on the
> endpoint ID's syntax and the contextual information [things like
> resolution services and routing tables and distributed hash tables]
> available to the agents for this purpose.

Sure.

> 3. If the M-bytes-long substring's semantic significance is not
> topological, then you have to "resolve" it to another string that
> does have topological significance.  You do this by whatever
> mechanism you've got: DNS, /etc/hosts, a database, a distributed
> hash table, etc.  If this resolution fails, you can't compute the
> route.

This I disagree with for the reasons I said before. I don't see why we
need to forbid routing on strings that may not have topological
significance. I agree that this type of lookup is in many cases
necessary, but I could very well imagine a small, isolated pocket of a
DTN network that routes on arbitrary strings.

> 4. At this point you've got a topologically-meaningful string of
> length L, either the original M-bytes-long substring (L = M) or else
> the string you got by resolving that original string.  You now
> invoke some sort of function that (by some process, eventually) maps
> the L-bytes-long string to one or more specific mechanisms for
> transmitting bundles to other bundle agents ("interfaces", maybe).
> We can contemplate a lot of variations in the process by which this
> happens:

Seems right on to me.

> I think we can easily retain all the advantages of the original
> "tuple" syntax while gaining the flexibility that everyone seems to
> want.  Let's agree on some overarching meta-syntactical structure
> that enables us to determine by inspection which of the various
> possible syntaxes a given endpoint ID conforms to: put a
> colon-terminated "schema" name at the front as Mike proposes,
> whatever.  Then let's define at least one such syntax -- a really
> simple one -- that can by default be used by those of us who are
> trying to deploy something in the near term.  Then let's move on.
> People can define whatever additional, alternative endpoint ID
> syntaxes they like, to support whatever routing models they like,
> and we can see which ones work out best.

That seems fine to me. 

What is the general feeling on my proposal for integral type codes
that correspond to the different schemas? The reason it comes up here
is that perhaps the colon syntax need not be mandated by the
architecture and/or bundle protocol and could be left open to the
implementation.

> But please, let's stop using the word "region".  If after six years
> we still can't all agree on a clear, unambiguous definition of this
> term, it seems evident to me that the term itself isn't doing us
> much good.  I don't want ever again to waste even five minutes of my
> life arguing over questions like "what's a region?" and "what does
> it mean to be in a region?" and "what happens when you change
> regions?"  Our continuing inability to explain a fundamental concept
> of the DTN architecture, to anybody else or even to ourselves, has
> become kind of embarrassing.

Agreed (again).

-m

Date: Sat, 2 Apr 2005 17:44:39 -0800
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Mail-Followup-To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

> At this point Mike is still talking about the general syntax for
> endpoint identifiers, not about the difference between
> administrative and other endpoints.  But actually, on re-reading
> more closely I agree with you that the set of all schemas should not
> be well-known and defined in the bundle protocol document; leaving
> open the possibility of defining new bundle ID syntax schemas (in
> supplementary RFCs or whatever) is exactly the point of this more
> general meta-syntax.

I completely agree, sorry I wasn't clearer in my earlier message.
What I should have said is that we explicitly specify some set of
naming schemas, either in the bundling RFC or in other supplemental
RFCs, along with all rules for matching, lookup, etc. But we should
also explicitly leave open and offer a path for future naming
extensions.

We would then need to define some set of rules for forwarding bundles
whose destinations are unparsable by the daemon. Maybe the only thing
you can do is forward on a default route, but you could certainly do
that.

> Would we be willing to constrain these mux/demux tokens to numeric
> values rather than ASCII strings?  

Hmm -- maybe we could support both? As Keith pointed out in his
original posting on changes to the bundling protocol, with the move
from next_header_type to header_type, we now have a free byte in the
primary bundle header. We could use some of these bits to denote
whether the bundle is using demux tokens that are numeric, ascii, or
simply nonexistent.

> This doesn't cost us any latitude for experimentation with routing
> schemes, because these things aren't in the endpoint IDs that we use
> for routing.

I agree that this doesn't change routing, but it may make things like
multi-point application delivery or publish-subscribe style
applications more difficult to support. 

> If they were always numeric then each one could be a self-defining
> numeric value (as in LTP) that could be represented in as little as
> a single byte but could range into the trillions as necessary.  We
> could put three such SDNVs -- source client ID, destination client
> ID, report-to client ID -- at the start of the Dictionary header,
> which is required but is variable-length.  For environments in which
> no muxing/demuxing is necessary, such as sensor networks, you'd only
> waste three bytes per bundle.

SDNV is fine with me -- perhaps we should also use them to help
address the bundle length discussion from before.

Note also that if we enumerate all the endpoint naming schemas with
type codes, perhaps fitting in a single byte, then we may not need a
dictionary header in all circumstances, and we may be able to get the
protocol headers down to something reasonable for a constrained sensor
network.

> Here I disagree.  Precisely because everybody already has a
> well-defined idea of exactly what a "host" is and what a "port
> number" is, when we're talking about things that are different we
> have got to use different words.  We can say that a bundle agent is
> *analogous* to a host and that a client ID is *analogous* to a port
> number, but if we use the terms interchangeably then people will
> draw inferences about the behavior of bundle agents and bundling
> clients based on their understanding of these other terms, and they
> will get things wrong.

I agree with Scott. We should come up with clear names for the two,
and I strongly agree that neither should be the term "region", but
coopting the internet syntax seems like a bad way to go. 

How about "endpoint identifier" or "agent identifier" for the
host-like part, and "demux identifier" for the port-like part?

-m

Date: Sat, 02 Apr 2005 15:44:07 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Matt Bradbury wrote:
> Scott Burleigh wrote:
> 
>> Michael Demmer wrote:
>>
>>> To throw in my two cents here, I would argue that we define an
>>> endpoint to be a <schema>:<name> tuple, where the set of schemas is
>>> well-known and layed out in the bundle protocol, but that we do not
>>> explicitly distinguish between "addresses" and "identities".
>>
>> Yes.
> 
> No.  You're talking about defining how the administrative endpoint is 
> processed in the bundle protocol?  That's just bad and should be defined 
> elsewhere since we'll never be able to cover all possible schemas.  
> Routing done on regions, demux done on administrative endpoints.

At this point Mike is still talking about the general syntax for endpoint identifiers, not about the difference between administrative and other endpoints.  But actually, on re-reading more closely I agree with you that the set of all schemas should not be well-known and defined in the bundle protocol document; leaving open the possibility of defining new bundle ID syntax schemas (in supplementary RFCs or whatever) is exactly the point of this more general meta-syntax.

Routing is and always has been done on endpoint IDs, which have historically encompassed both region names and "admin parts".  Demux to specific clients of the destination bundle agent has historically been done on "local stuff" or "demux strings" that were also stuffed into endpoint IDs, normally at the end; moving away from that model is the point of the remainder of my message.

"Administrative endpoints" are bundle agents that are acting in the role of sources and destinations of bundles -- that is, clients of their own services.  Currently bundle agents are sources and destinations of bundles only when they are exchanging custody transfer signals; the sources and destinations of all other bundles are the "clients" or "application instances" that register with bundle agents.

>>> One final note that's totally disjoint from the above is that we also
>>> need to discuss how demux strings fit into all this (i.e. the dtn
>>> equivalent of a TCP or UDP port to identify a particular application
>>> attached to a dtn router).
>>
>> Yes.  We at one time talked about things called "application 
>> instances" that were served by bundle agents -- a more precise term 
>> than just "application", I think, because it seems to me that an 
>> "application" is a set of capabilities that can be instantiated any 
>> number of times (like "email") rather than a discrete communicating 
>> entity (like "Mike's email reader").  But Kevin objected to explicitly 
>> and formally recognizing these things in the architecture; I think 
>> this was in part because in some cases, like motes, there wouldn't 
>> necessarily be any "application" using the bundle agent at all -- once 
>> a bundle reached the bundle agent on the mote it was simply going to 
>> be processed by the mote's operating system.
> 
> I think Kevin is right and this will be the standard way of using 
> bundling.  Though with the application being the direct bundling agent.

Except that an application never is a bundle agent, by definition.  An application (or, in my mind, an "instance" of an application) uses the services of a bundle agent.  The bundle agent might be a separate executable (with the application client and the bundle agent interacting via some sort of interprocess communication), or the bundle agent might be something more nebulous like a state representation in a database (with the application client and the bundle agent "interacting" via direct API function calls), but that's just a matter of implementation.  Architecturally they are quite distinct.

>> Still we ended up tacking "local stuff" onto the end of the endpoint 
>> ID in most cases, to enable this kind of demuxing, because in practice 
>> we usually do have applications that run on top of bundling.  We just 
>> never accounted for it in the architecture, and
> 
> Never understood why so much was trying to be done in the administrative 
> endpoint ID when the original spec said that it should be unique to each 
> region.  If you have only one region than you're going to have to make 
> routing decisions on the administrative data, so have many regions and 
> route between regions.

The spec has always said that the "administrative part" of the endpoint ID -- which is very different from an "administrative endpoint ID", the DTN address of an administrative endpoint -- has to be unique within region.  You're right that if you've only got one region then you can only make routing decisions on the "admin part" of the destination endpoint ID (whether the endpoint is administrative or not).  I think that's okay, and I think having lots of regions and making a lot of routing decisions on region names is okay, except that I think it's time to ditch the term "region" because after six years we've still got no definition for it.

>> as you point out this omission eventually catches up to us.  We've had 
>> to invent the concept of "administrative endpoint ID" -- as distinct 
>> from the actual bundle source and destination endpoint IDs -- as a 
>> routing expedient (I'm guessing you don't really route on the whole 
>> "admin part" of a tuple even in the current implementations; you just 
>> use the DNS name part of it, which is the administrative endpoint ID) 
>> and as a destination for custody transfer signals.  And consequently 
>> we've had to informally invent an algorithm for computing from 
>> destination endpoint ID the administrative endpoint ID of the relevant 
>> bundle agent -- to wit, truncate at the "local stuff".
> 
> We shouldn't be routing on the admin part at all.  That should be for 
> local consumption only.

Except that if you are routing between two bundle agents that are in the same region -- which we've long ago decided is possible (except that, again, I think it's time to ditch the "region" notion) -- then you've got nothing else to route on.  That intra-regional routing *is* "local consumption".

>> I think it would be good to confront this issue a little more 
>> directly.  As you point out, the Internet architecture gives us a good 
>> model.  We don't actually route on port numbers in IP, right?  Port 
>> numbers are distinct from IP addresses; they are carried elsewhere in 
>> the header structure.  I think this works pretty well, and I would 
>> propose that we do more or less the same thing:
> 
> Agreed.
> 
>> -    Agree that bundling "endpoints" is a synonym for "bundle agent", 
>> period.  (Just as the endpoints of IP are hosts, not instances of 
>> applications.)  An endpoint ID is a bundle agent ID.  All endpoint IDs 
>> are "administrative" endpoint IDs, so the "administrative endpoint ID" 
>> concept goes away.
> 
> I'm still scratching my head from this part.  These terms really are 
> confusing sometimes.

You're right.  Yet another argument for going this way, I think.

>> -    Agree that in some -- not all -- cases we may have multiple 
>> "application instances" (we can probably find another term that is 
>> more palatable; I'll say "clients" for now, though that may turn out 
>> to be confusing) that are concurrently using the services offered by a 
>> given bundle agent.  In those cases we need a way to mux/demux bundle 
>> payloads from/to those clients, something functionally analogous to 
>> port number.
> 
> I always envisioned that the bundling layer got the bundles to the 
> individual host, and that the bundling agent was the application that 
> connected (local or remote) to the bundling host/router/server to pick 
> up bundles based on the administrative part.

This is generally the right picture, but with slightly wrong labels on some of the bits.

The bundling layer does get the bundles to the individual bundle agent -- not "host", which is the corresponding IP architectural term.  A bundle agent might reside on an IP host, but alternatively it might reside on a sensor network mote or deep space robot that has no IP address at all.

The application instance or client uses some mechanism (RPC or some other IPC or a socket connection or a function call) to "connect" to the bundle agent to pick up bundles, which are demuxed to it based on a demux string or "local stuff" at the tail end of the admin part of the destination endpoint ID -- not on the whole admin part.  The remainder of the admin part of the destination endpoint ID (everything preceding the demux string) is what was used to route the bundle to the destination bundle agent from the point at which it entered the region.

Your interpretation is a very reasonable one but it's not the model we've been working with.  Again I think this is a strong argument for clarifying some language and squeezing some ambiguity out of the documents.

>> -    Because we don't route on these source and destination mux/demux 
>> tokens, because they are optional, and because they are only relevant 
>> at the point at which you've reassembled the payload from fragments as 
>> necessary (assuming we're still doing bundle fragmentation, which I 
>> will argue against at a later time), I would suggest that we add them 
>> to the Payload header.  Let's make them LVs to minimize overhead in 
>> deployments where they aren't needed: a 1-byte length followed by 
>> 0-255 bytes of mux/demux name.
> 
> What about return addresses?  Report-to addresses?  Keep the demux info 
> in the main header.  That way the bundle router doesn't ever look at the 
> payload header, it just hands it off.  Though I suspect it will be 
> easier to design firewalls and layer 4 type switches in the future if 
> the demux info is in the main header.

Good point about the report-to: you probably do want to specify a client demux token along with the endpoint ID for report-to, otherwise the status report can never go any further than the bundle agent itself.

On the other hand, for some environments (such as interplanetary internet) it is really important to minimize header size; also it's very convenient to have the primary header be of fixed length, so I'm reluctant to add anything more to it.

Would we be willing to constrain these mux/demux tokens to numeric values rather than ASCII strings?  This doesn't cost us any latitude for experimentation with routing schemes, because these things aren't in the endpoint IDs that we use for routing.  If they were always numeric then each one could be a self-defining numeric value (as in LTP) that could be represented in as little as a single byte but could range into the trillions as necessary.  We could put three such SDNVs -- source client ID, destination client ID, report-to client ID -- at the start of the Dictionary header, which is required but is variable-length.  For environments in which no muxing/demuxing is necessary, such as sensor networks, you'd only waste three bytes per bundle.

>> I think this could scrub a lot of ambiguity out of the architecture, 
>> simplify the bundling protocol spec considerably, and in the long run 
>> save us a lot of heartache.
>>
>> Scott
> 
> I keep getting the feeling that everyone is afraid of bringing the 
> bundling protocol into every network/server/host/router.  Aren't we 
> talking about an overlay network that is ubiquitous?

I agree with you, I think that's exactly what we should be aiming for.

  The reason IP has 
> done so well is that it managed to bridge many different link layer 
> technologies into one unified layer.  Layer 3 of the OSI model is the 
> thin waste on the curvy women, everything goes through that one layer, 
> and there's a lot of extras above and below it.  We should be bridging 
> every conceivable way of passing a bundle of data around and make it 
> routable.  Isn't the whole problem currently with the administrative 
> endpoint id the fact that the sender needs to know how the network works 
> on the other end to send data to a specific bundling agent?  As soon as 
> things like network protocols and dns entries show up in the demux 
> field, it gets messy.  Keep that field simple and clean.  If you want to 
> get a bundle to a specific host, run the bundling software on that host 
> and route the bundles to it, then do a demux there.

Sure, routing on endpoint ID and demuxing on this newly isolated mux/demux token (client ID, whatever).

> I also propose that we change the names of the fields in the tuples.  
> The current region field should be called 'host' and the current 
> administrative endpoint id should be called 'port'.  This will gell 
> better with people's current network understanding. How the host field 
> is parsed to give routing information is up to discussion, but I'd like 
> to propose my tree based hierarchy outlined in a previous mail.

Here I disagree.  Precisely because everybody already has a well-defined idea of exactly what a "host" is and what a "port number" is, when we're talking about things that are different we have got to use different words.  We can say that a bundle agent is *analogous* to a host and that a client ID is *analogous* to a port number, but if we use the terms interchangeably then people will draw inferences about the behavior of bundle agents and bundling clients based on their understanding of these other terms, and they will get things wrong.

Scott

Date: Sat, 02 Apr 2005 15:01:15 -0600
From: Matt Bradbury <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Scott Burleigh wrote:

> Michael Demmer wrote:
>
>> To throw in my two cents here, I would argue that we define an
>> endpoint to be a <schema>:<name> tuple, where the set of schemas is
>> well-known and layed out in the bundle protocol, but that we do not
>> explicitly distinguish between "addresses" and "identities".
>
>
> Yes.

No.  You're talking about defining how the administrative endpoint is 
processed in the bundle protocol?  That's just bad and should be defined 
elsewhere since we'll never be able to cover all possible schemas.  
Routing done on regions, demux done on administrative endpoints.

>> One final note that's totally disjoint from the above is that we also
>> need to discuss how demux strings fit into all this (i.e. the dtn
>> equivalent of a TCP or UDP port to identify a particular application
>> attached to a dtn router).
>
>
> Yes.  We at one time talked about things called "application 
> instances" that were served by bundle agents -- a more precise term 
> than just "application", I think, because it seems to me that an 
> "application" is a set of capabilities that can be instantiated any 
> number of times (like "email") rather than a discrete communicating 
> entity (like "Mike's email reader").  But Kevin objected to explicitly 
> and formally recognizing these things in the architecture; I think 
> this was in part because in some cases, like motes, there wouldn't 
> necessarily be any "application" using the bundle agent at all -- once 
> a bundle reached the bundle agent on the mote it was simply going to 
> be processed by the mote's operating system.

I think Kevin is right and this will be the standard way of using 
bundling.  Though with the application being the direct bundling agent. 

>
> Still we ended up tacking "local stuff" onto the end of the endpoint 
> ID in most cases, to enable this kind of demuxing, because in practice 
> we usually do have applications that run on top of bundling.  We just 
> never accounted for it in the architecture, and

Never understood why so much was trying to be done in the administrative 
endpoint ID when the original spec said that it should be unique to each 
region.  If you have only one region than you're going to have to make 
routing decisions on the administrative data, so have many regions and 
route between regions.

> as you point out this omission eventually catches up to us.  We've had 
> to invent the concept of "administrative endpoint ID" -- as distinct 
> from the actual bundle source and destination endpoint IDs -- as a 
> routing expedient (I'm guessing you don't really route on the whole 
> "admin part" of a tuple even in the current implementations; you just 
> use the DNS name part of it, which is the administrative endpoint ID) 
> and as a destination for custody transfer signals.  And consequently 
> we've had to informally invent an algorithm for computing from 
> destination endpoint ID the administrative endpoint ID of the relevant 
> bundle agent -- to wit, truncate at the "local stuff".

We shouldn't be routing on the admin part at all.  That should be for 
local consumption only.

>
> I think it would be good to confront this issue a little more 
> directly.  As you point out, the Internet architecture gives us a good 
> model.  We don't actually route on port numbers in IP, right?  Port 
> numbers are distinct from IP addresses; they are carried elsewhere in 
> the header structure.  I think this works pretty well, and I would 
> propose that we do more or less the same thing:

Agreed.

>
>
> -    Agree that bundling "endpoints" is a synonym for "bundle agent", 
> period.  (Just as the endpoints of IP are hosts, not instances of 
> applications.)  An endpoint ID is a bundle agent ID.  All endpoint IDs 
> are "administrative" endpoint IDs, so the "administrative endpoint ID" 
> concept goes away.

I'm still scratching my head from this part.  These terms really are 
confusing sometimes.

>
> -    Agree that in some -- not all -- cases we may have multiple 
> "application instances" (we can probably find another term that is 
> more palatable; I'll say "clients" for now, though that may turn out 
> to be confusing) that are concurrently using the services offered by a 
> given bundle agent.  In those cases we need a way to mux/demux bundle 
> payloads from/to those clients, something functionally analogous to 
> port number.

I always envisioned that the bundling layer got the bundles to the 
individual host, and that the bundling agent was the application that 
connected (local or remote) to the bundling host/router/server to pick 
up bundles based on the administrative part. 

>
> -    Because we don't route on these source and destination mux/demux 
> tokens, because they are optional, and because they are only relevant 
> at the point at which you've reassembled the payload from fragments as 
> necessary (assuming we're still doing bundle fragmentation, which I 
> will argue against at a later time), I would suggest that we add them 
> to the Payload header.  Let's make them LVs to minimize overhead in 
> deployments where they aren't needed: a 1-byte length followed by 
> 0-255 bytes of mux/demux name.

What about return addresses?  Report-to addresses?  Keep the demux info 
in the main header.  That way the bundle router doesn't ever look at the 
payload header, it just hands it off.  Though I suspect it will be 
easier to design firewalls and layer 4 type switches in the future if 
the demux info is in the main header.

>
> I think this could scrub a lot of ambiguity out of the architecture, 
> simplify the bundling protocol spec considerably, and in the long run 
> save us a lot of heartache.
>
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

I keep getting the feeling that everyone is afraid of bringing the 
bundling protocol into every network/server/host/router.  Aren't we 
talking about an overlay network that is ubiquitous?  The reason IP has 
done so well is that it managed to bridge many different link layer 
technologies into one unified layer.  Layer 3 of the OSI model is the 
thin waste on the curvy women, everything goes through that one layer, 
and there's a lot of extras above and below it.  We should be bridging 
every conceivable way of passing a bundle of data around and make it 
routable.  Isn't the whole problem currently with the administrative 
endpoint id the fact that the sender needs to know how the network works 
on the other end to send data to a specific bundling agent?  As soon as 
things like network protocols and dns entries show up in the demux 
field, it gets messy.  Keep that field simple and clean.  If you want to 
get a bundle to a specific host, run the bundling software on that host 
and route the bundles to it, then do a demux there. 

I also propose that we change the names of the fields in the tuples.  
The current region field should be called 'host' and the current 
administrative endpoint id should be called 'port'.  This will gell 
better with people's current network understanding. How the host field 
is parsed to give routing information is up to discussion, but I'd like 
to propose my tree based hierarchy outlined in a previous mail.

-Matt

Date: Sat, 02 Apr 2005 13:53:18 -0600
From: Matt Bradbury <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: Jakob Eriksson <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Michael Demmer wrote:

>Jacob, etc,
>
>One question that distills from this discussion which is how much
>detail of the _operational_ characteristics of a dtn network should be
>mandated by the architecture.
>
>While I like many things about Matt's scenario, the part where it is
>indicated that routers in the .in.earth.sol region should use DNS for
>name resolution is one that I feel should not be an architectural
>mandate, but rather a deployment characteristic. Similarly, although
>the concentric "russian-doll" approach to regions is well suited for
>interplanetary scenarios, it is not well suited for many others, like
>situations that use data mules or highly mobile end-hosts that move
>around topologically.
>
>  
>
My thinking on the DNS routing architecture is that it's only specific 
to regions that desire to use it.  If the "in.earth.sol" region would 
like to use a different routing scheme to locate regions, more power to 
them.  The underlying bundle protocol is still the same from region to 
region, only the routing is different in each region which allows for 
different approaches in different regions.

Inside the "in.earth.sol" region as I described it, you would 
essentially have a fully meshed network with any 'host' being able to 
directly connect to other 'hosts'.  The cost of entry to the routing 
tables is a domain name and the wherewithal to add a single entry in DNS 
pointing to the dtn router for your region/domain.

For the highly mobile end user, I see a situation where you have to have 
a fixed address that can queue bundles, and the mobile device checks in 
with the fixed address to have bundles forwarded to it in whatever new 
location it's at.  I keep wanting to use the "report-to" field for 
this.  With the 'from" address being the address of whatever mobile 
network you're currently connected to, and the "report-to" field being 
the permanent address.  In the scenario I'm laying out, I'm going to use 
another header field that doesn't exist yet.  Let's call it a secondary 
destination.  Just like a normal destination tuple, just a failover.

Let me try to setup a scenario:

My cell phone is bluetooth, 802.11b, GPRS capable.  When I connect over 
GPRS, my cell provider gives me an address of 
"5125551212.1.gsm.terra.earth.sol".  When I connect with bluetooth to my 
home desktop (enigma.windu.com), I get 
"bluetooth1.enigma.windu.com.in.earth.sol".  When I connect with 802.11b 
at the coffeehouse, I get "dchp21.coffehouse.com.in.earth.sol".  Now 
let's say I have a permanent address of 
"mattcell.windu.com.in.earth.sol".  The permanent address will always be 
the "report-to" field of bundles my phone sends out, with the interface 
specific address being set in the "from" field.

I walk into the coffeeshop and connect to the 802.11b network and get my 
"dchp21.coffehouse.com.in.earth.sol" address.  I also lose my cell 
signal at roughly the same time.   The first thing I do is send a bundle 
to my mobile manager "windu.com.in.earth.sol" telling it my new 
address.  A second bundle gets sent to the mobile manager indicating the 
lost connection to the GSM address "5125551212.1.gsm.terra.earth.sol".  
I drink my coffee, surf the web, and start chatting with a buddy across 
town.  I get up, and start walking home.  My buddy is oblivious to this 
and keeps blabbering away about the fantastic night he had on Sixth 
Street.  The next chat message that came to me at the coffeeshop doesn't 
get delivered to me because I'm out of range.  But that bundle had a 
secondary destination that was the report-to tuple on the bundles I sent 
him.  The router at the coffeeshop seeing that I'm no longer in range, 
encapsulates the bundle and sends it to the secondary destination which 
is "mattcell.windu.com.in.earth.sol" in this scenario.  It also sends a 
notification to the original sender indicating that the coffeeshop has 
no route to the "dhcp21..." address anymore.  When my buddy's computer 
gets this, it knows to only send to the 'report-to' "mattcell...." 
address until it gets a new address for me. The "windu.com.in.earth.sol" 
router gets the bounced bundle from the coffeeshop and removes the 
coffeshops' DTN address from the forwarding table for "mattcell.....".  
With nowhere to forward the bundle, it stores it.  A few minutes later 
my cell phone finally reconnects to the GSM network.  The cell sends a 
message to it's mobile manager telling it of the new address.   
"windu.com.in.earth.sol" now starts forwarding it's stored bundles to 
the new GSM DTN addresss.  I get my buddy's stored chat messages and 
respond to one of them.  This response now has a new 'from' address but 
the same 'report-to' address from before.  My buddy, seeing the new 
'from' address will now route the conversation to that address instead 
of the "mattcell..." address, which is now the secondary destination again.

The buddy never realizes I disconnected.  The same scenario can be 
played out when I connect my cell to my home machine.  To continue this 
scenario a bit into the data mule problem.  While chatting with my 
buddy, he mentions he wants to get a copy of a DVD I ripped.  At 4gigs, 
these things don't upload well on my dinky cable connection.  I tell him 
I'll have it with me when I see him next.  I have a rule on my desktop 
machine's DTN router, that anything larger than 100 megs destined for my 
buddy's desktop gets sent to my cell phone for data mule'ing.  I have 
rules on my phone that tell it to only forward these massive bundles to 
my buddy's cell phone or to his desktop when directly connected to 
them.  I send the DVD bundle to his desktop, which since it's >100megs 
gets forwarded to my phone where it's stored.  I meet up with my buddy 
for drinks and I've forgotten I have the DVD for him, but luckily my 
phone didn't forget, because as soon as it got within wireless range of 
the other phone, it started dumping the bundle to it.  My buddy winds up 
staggering home, puts the phone on it's cradle and goes to sleep not 
even realizing in his stupor that he's picked up the DVD bundle from 
me.  The phone realizing it's connected to the desktop uploads the 
bundle.  My buddy wakes up the next morning realizing he got the DVD 
from me and didn't even have to think about getting it.

-Matt

ps.  I really like having the seperate region and endpoints in a tuple.  
It's very well defined that if I'm not the region/host indicated by the 
region field, then I ignore the endpoint info.

 I like the hierarchial region concept due to the simple fact that 
everyone has their own namespace if they have a DTN address currently.  
Something that's always frustrated me with the current internet is the 
arbitrary limitations on address space due to the fact that they have to 
be unique and there is a limited supply.  With a hierarchy, they still 
have to be unique, but there's an infinite amount of address space 
available to everyone, and it doesn't need to be coordinated with 
everyone else like BGP requires.  The way IPv6 is being implemented is 
making multi-homing very difficult for smaller organizations.  Shoot, 
even for a lowly tech like myself, I'd love to be able to get massive 
redundancy with a cable modem and a dsl line.  Currently there is no way 
in hell that you could BGP peer over those kinds of connections and have 
true multi-homing.  I also believe that a hierarchy more clearly aligns 
with the way the world works.  There are large networks like cable 
modem, cell networks, phone system (DSL), that are only tied together at 
the top, with the rest of the network essentially isolated from each 
other.  Most of the packets go up and down these hierarchies and not 
across them.

pps. This was way too long.

Date: Sat, 02 Apr 2005 11:18:18 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Michael Demmer wrote:
> To throw in my two cents here, I would argue that we define an
> endpoint to be a <schema>:<name> tuple, where the set of schemas is
> well-known and layed out in the bundle protocol, but that we do not
> explicitly distinguish between "addresses" and "identities".

Yes.

> One final note that's totally disjoint from the above is that we also
> need to discuss how demux strings fit into all this (i.e. the dtn
> equivalent of a TCP or UDP port to identify a particular application
> attached to a dtn router).

Yes.  We at one time talked about things called "application instances" that were served by bundle agents -- a more precise term than just "application", I think, because it seems to me that an "application" is a set of capabilities that can be instantiated any number of times (like "email") rather than a discrete communicating entity (like "Mike's email reader").  But Kevin objected to explicitly and formally recognizing these things in the architecture; I think this was in part because in some cases, like motes, there wouldn't necessarily be any "application" using the bundle agent at all -- once a bundle reached the bundle agent on the mote it was simply going to be processed by the mote's operating system.

Still we ended up tacking "local stuff" onto the end of the endpoint ID in most cases, to enable this kind of demuxing, because in practice we usually do have applications that run on top of bundling.  We just never accounted for it in the architecture, and as you point out this omission eventually catches up to us.  We've had to invent the concept of "administrative endpoint ID" -- as distinct from the actual bundle source and destination endpoint IDs -- as a routing expedient (I'm guessing you don't really route on the whole "admin part" of a tuple even in the current implementations; you just use the DNS name part of it, which is the administrative endpoint ID) and as a destination for custody transfer signals.  And consequently we've had to informally invent an algorithm for computing from destination endpoint ID the administrative endpoint ID of the relevant bundle agent -- to wit, truncate at the "local stuff".

I think it would be good to confront this issue a little more directly.  As you point out, the Internet architecture gives us a good model.  We don't actually route on port numbers in IP, right?  Port numbers are distinct from IP addresses; they are carried elsewhere in the header structure.  I think this works pretty well, and I would propose that we do more or less the same thing:

-	Agree that bundling "endpoints" is a synonym for "bundle agent", period.  (Just as the endpoints of IP are hosts, not instances of applications.)  An endpoint ID is a bundle agent ID.  All endpoint IDs are "administrative" endpoint IDs, so the "administrative endpoint ID" concept goes away.

-	Agree that in some -- not all -- cases we may have multiple "application instances" (we can probably find another term that is more palatable; I'll say "clients" for now, though that may turn out to be confusing) that are concurrently using the services offered by a given bundle agent.  In those cases we need a way to mux/demux bundle payloads from/to those clients, something functionally analogous to port number.

-	Because we don't route on these source and destination mux/demux tokens, because they are optional, and because they are only relevant at the point at which you've reassembled the payload from fragments as necessary (assuming we're still doing bundle fragmentation, which I will argue against at a later time), I would suggest that we add them to the Payload header.  Let's make them LVs to minimize overhead in deployments where they aren't needed: a 1-byte length followed by 0-255 bytes of mux/demux name.

I think this could scrub a lot of ambiguity out of the architecture, simplify the bundling protocol spec considerably, and in the long run save us a lot of heartache.

Scott

Date: Sat, 02 Apr 2005 10:31:30 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Durst,Robert C. wrote:
> I'm still not sure we have consensus on this.  Some of us feel that
> regions are very much -in- the picture, both for routing and
> information containment.  We need to know how we're going to
> aggregate routing information and deal with the case where we need to
> make a *real* routing decision without having to go to some sort of
> 'resolution server'.
> 
> Bob and Keith

Sure, but I don't think a routing decision is any less "real" just because you have to resolve an administratively-meaningful string to a topologically-meaningful string (possibly a number) before you can begin computing your route.  Starting with a topologically-meaningful string doesn't make the decision any more "real", it just makes it more direct: you skip the resolution step.

I think the general model for computing the route on which to forward a bundle looks like this:

1.	You start with the destination endpoint ID, an ASCII string of length N.  [This would be *after* you've retrieved that string from a pre-positioned dictionary if you're using the mechanism I proposed in my email of, I think, the 17th -- which we're not discussing here.]

2.	You parse out an M-bytes-long substring of that string, 0 <= M <= N, such that the substring has semantic significance for you.  [The other bytes of the destination endpoint ID are "opaque" to you.]  That substring is different at different points along the path from the source endpoint to the destination endpoint: different bundle agents have differing capacities for parsing a semantically significant substring out of an endpoint ID, depending on the endpoint ID's syntax and the contextual information [things like resolution services and routing tables and distributed hash tables] available to the agents for this purpose.

3.	If the M-bytes-long substring's semantic significance is not topological, then you have to "resolve" it to another string that does have topological significance.  You do this by whatever mechanism you've got: DNS, /etc/hosts, a database, a distributed hash table, etc.  If this resolution fails, you can't compute the route.

4.	At this point you've got a topologically-meaningful string of length L, either the original M-bytes-long substring (L = M) or else the string you got by resolving that original string.  You now invoke some sort of function that (by some process, eventually) maps the L-bytes-long string to one or more specific mechanisms for transmitting bundles to other bundle agents ("interfaces", maybe).  We can contemplate a lot of variations in the process by which this happens:

	-	Maybe L = 0, and you just queue up the bundle for transmission on the "default route" (really a default queue to some interface).

	-	Maybe you've got a routing table with wild-carded entries that aggregate sets of lexically-related topologically-meaningful strings, and you just do a first-match search through this table.  Maybe this search is recursive: you take the result of one search as the search argument for the next until you reach some end condition.

	-	Maybe you've got a hash table of all strings that are topologically meaningful to you, and you just look up your L-bytes-long string in that table.

	-	And lots of variants on the above and on other clever schemes.

What our "tuple" syntax of "region" and "administrative part" did was establish a single universal rule for doing step 2:

-	There's a well-known, universal convention for parsing a special substring called the "region name" out of the destination endpoint ID.

-	If that region name matches the name of a region you are "in" (whatever that means), then your M-bytes-long semantically significant substring is everything after the end of the region name (the "admin part"), and you know from the region name what procedure to use to map that M-bytes-long substring to one or more interfaces for bundle transmission.  In practice, we generally had a DNS name in that string, along with some optional "local stuff" for demuxing to a specific application entity.

-	Otherwise, your M-bytes-long semantically significant substring is just the region name itself, and that's all you've got to route on (the "routing part").

The only thing that changes when we discard the "tuple" syntax is that we open the door for lots of other ways of doing step 2.  Most everybody seems to want that, and maybe it's a good idea.  It doesn't get us any closer to having a demonstrable and usable product, but that's not necessarily our principal goal; certainly it offers many more avenues for research.

I think we can easily retain all the advantages of the original "tuple" syntax while gaining the flexibility that everyone seems to want.  Let's agree on some overarching meta-syntactical structure that enables us to determine by inspection which of the various possible syntaxes a given endpoint ID conforms to: put a colon-terminated "schema" name at the front as Mike proposes, whatever.  Then let's define at least one such syntax -- a really simple one -- that can by default be used by those of us who are trying to deploy something in the near term.  Then let's move on.  People can define whatever additional, alternative endpoint ID syntaxes they like, to support whatever routing models they like, and we can see which ones work out best.

But please, let's stop using the word "region".  If after six years we still can't all agree on a clear, unambiguous definition of this term, it seems evident to me that the term itself isn't doing us much good.  I don't want ever again to waste even five minutes of my life arguing over questions like "what's a region?" and "what does it mean to be in a region?" and "what happens when you change regions?"  Our continuing inability to explain a fundamental concept of the DTN architecture, to anybody else or even to ourselves, has become kind of embarrassing.

Scott

Scott

Date: Sat, 2 Apr 2005 09:46:55 -0800
From: Michael Demmer <[email-masked]>
To: Jakob Eriksson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Mail-Followup-To: Jakob Eriksson <[email-masked]>, [email-masked]
Sender: [email-masked]

Jacob, etc,

One question that distills from this discussion which is how much
detail of the _operational_ characteristics of a dtn network should be
mandated by the architecture.

While I like many things about Matt's scenario, the part where it is
indicated that routers in the .in.earth.sol region should use DNS for
name resolution is one that I feel should not be an architectural
mandate, but rather a deployment characteristic. Similarly, although
the concentric "russian-doll" approach to regions is well suited for
interplanetary scenarios, it is not well suited for many others, like
situations that use data mules or highly mobile end-hosts that move
around topologically.

My preference is to try to keep as few operational restrictions as
possible from creeping into the general DTN architecture. The
architecture would then really just define the language of DTN. In
other words, it would in a general way define the concept of a bundle,
a registration, a router, an endpoint (say <schema>:<name>),
mechanisms for resolving endpoints, etc.

Also, the general rules for routing would be included there. For
instance, if we adopt Jacob's proposal of an optional
intermediary-address along with each bundle, or some variant thereof,
this would be layed out in the architecture. But not the particular
combination of address schemas and resolution rules. That would be
left to the deployment.

Then, a companion set of DTN deployment scenarios, including one for
IPN, would define the operational rules for that network. So all the
stuff that Matt layed out for how the .in region triggers a DNS
lookup would be specific to a particular instantiation of the DTN
architecture, not endemic to all DTN deployments.

A reason for the difficulties in nailing down this whole region
concept stems from the widely varying ways in which DTN has been
proposed. I think it will be hard to come up with a one size fits all
approach, and instead that we should look more towards this set of
scenarios coupled with a general purpose architecture.

-m

To: [email-masked]
Date: Fri, 01 Apr 2005 18:06:21 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] request for the minutes at the last IETF meetings
Sender: [email-masked]

Hi all.  I believe one or more of you was kind enough to be scribe
at the last IETF meeting.  Whoever has notes, could you please drop
me a copy ?  Thanks.  Its time to upload them to the secretariat.

=- K

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Date: Fri, 1 Apr 2005 16:34:18 -0800
To: [email-masked]
Sender: [email-masked]

On Apr 1, 2005, at 4:06 PM, Matt Bradbury wrote:

> Jakob Eriksson wrote:
>> However, what happens when Joe loses his machine spelunker playing 
>> pool with a green martian? He now has to use some cobbled up mess of 
>> PC hardware he found in a dust-proof closet, called 
>> cavediver.marineris.mars.sol.
>
> This is the same thing that happens on the current internet.  If your 
> machine goes down, you either re-route the name, or fix the problem.  
> This is why most of us don't get domain names pointed to our home 
> machines to run email.  We can do it if we're willing to take the 
> risks of a machine crashing.  This freedom is one of the things I'm 
> hoping to convey.

I'm fully aware that this is how it works in the internet. I just 
question whether this is the way it should work. While we could design 
the DTN architecture to behave the same as the Internet, I would 
advocate learning from 30 years of Internet experience, and trying to 
do even better.

On the Internet, if I open an ssh session at work, then put my laptop 
to sleep and go home, I can't wake it up and continue using my ssh 
session from home. This is because the network layer was built assuming 
that nodes are stationary. Mobile-IP is merely a workaround for this 
architectural decision, and as far as I know, it isn't even deployed 
yet. I certainly have never observed it in the wild.

Instead of relying on our successors applying patches like Mobile-IP to 
the network we're building, let's try to do it right in the first 
place.

> My argument may have been a bit hacked together with the mail going to 
> the guys end machine directly instead of a centralized mail server for 
> the organization.  In my example, you'll notice the sub was a central 
> system with only one DTN region, no subregions.
> There's nothing stopping someone from having centralized servers and 
> users connecting to the bundling server/router to pickup bundles for 
> endpoints they control.   In the sub example, Hank probably used some 
> kind of terminal connection to the central server to write his email.  
> Or even some derivative of pop/smtp that understands DTN addresses.  
> And again, the beauty of each region being able to deal with endpoints 
> any way they see fit. Though I'm sure a few standards will emerge to 
> allow for re-use of software.

You're right in that there is usually a workaround. The Internet, for 
example, is chock full of them. NAT's, DHCP servers, Mobile-IP. 
Brute-force BPG routing tables with 120,000+ entries. Instant messaging 
between internet connected nodes that nevertheless have to go through 
intermediate servers...

The DTN problem gives us a chance to step back and see what things we 
can do different from how we do things today. I think it would be a 
shame to waste it.

- Jakob

Date: Fri, 01 Apr 2005 18:06:29 -0600
From: Matt Bradbury <[email-masked]>
To: Jakob Eriksson <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Jakob Eriksson wrote:

> Hi Matt, all,
>
> I enjoyed your use scenario, especially the happily ever after part.
>
> However, what happens when Joe loses his machine spelunker playing 
> pool with a green martian? He now has to use some cobbled up mess of 
> PC hardware he found in a dust-proof closet, called 
> cavediver.marineris.mars.sol.

Glad you enjoyed it.

This is the same thing that happens on the current internet.  If your 
machine goes down, you either re-route the name, or fix the problem.  
This is why most of us don't get domain names pointed to our home 
machines to run email.  We can do it if we're willing to take the risks 
of a machine crashing.  This freedom is one of the things I'm hoping to 
convey.

My argument may have been a bit hacked together with the mail going to 
the guys end machine directly instead of a centralized mail server for 
the organization.  In my example, you'll notice the sub was a central 
system with only one DTN region, no subregions. 

There's nothing stopping someone from having centralized servers and 
users connecting to the bundling server/router to pickup bundles for 
endpoints they control.   In the sub example, Hank probably used some 
kind of terminal connection to the central server to write his email.  
Or even some derivative of pop/smtp that understands DTN addresses.  And 
again, the beauty of each region being able to deal with endpoints any 
way they see fit. Though I'm sure a few standards will emerge to allow 
for re-use of software.

-Matt

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Date: Fri, 1 Apr 2005 15:34:45 -0800
To: [email-masked]
Sender: [email-masked]

Hi Matt, all,

I enjoyed your use scenario, especially the happily ever after part.

However, what happens when Joe loses his machine spelunker playing pool 
with a green martian? He now has to use some cobbled up mess of PC 
hardware he found in a dust-proof closet, called 
cavediver.marineris.mars.sol.

> Let's follow a bundle from the USS Dallas to the Marineris Base on 
> Mars:
> from: ["dallas.uss.ships.terra.earth.sol","mail:hank"]
> to:   ["spelunker.marineris.mars.sol","mail:joe"]

This is where the address=identity assumption breaks down. Due to his 
lame pool playing (had to much romulan ale, is all, he's really pretty 
good at 1/2 gravity pool), Joe is no longer able to receive bundles 
from his friend Hank. The only way to enable receiving again, is to 
notify hank of the new address.

I propose an alternative scheme. Hank addresses his bundles to 
person://[email-masked] instead. This is just a unique identifier, 
making use of the already existing email name-space. Address resolution 
in the earth system reports that person://[email-masked] is in the 
mars system. Joes DTN router sends the bundle out looking something 
like:

final-destination: person://[email-masked]
intermediate-destination: region://mars.sol
<SNIP/>

Once the packet gets to the region://mars.sol. The Mars-local address 
resolution says Joe is in Valles Marineris, so the packet now looks 
like

final-destination: person://[email-masked]
intermediate-destination: region://marineris.mars.sol
<SNIP/>

and finally, the marineris-local address resolution is aware that Joe 
lost fouled up his game, and is now at cavediver.

final-destination: person://[email-masked]
intermediate-destination: region://cavediver.marineris.mars.sol
<SNIP/>

Once the bundle arrives at cavediver, that machine knows 
person://[email-masked] is there, so the bundle has reached its final 
destination.

Like I mentioned earlier, sometimes, the local address resolver simply 
haven't a clue where a given identifier is, and doing a wider range 
address resolution (sending address resolution requests all across the 
solar system), may not be feasible. In such a case, Hank could, for 
example, provide an intermediate-destination header on his own.

final-destination: person://[email-masked]
intermediate-destination: region://mars.sol

- Jakob

Date: Fri, 01 Apr 2005 16:14:39 -0600
From: Matt Bradbury <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Sender: [email-masked]

Rajesh Krishnan wrote:

>Scott,
>
>Thank you for your detailed responses. I will share read them with my
>group.
>
>You mentioned that "regions are out of the picture". Would you have any 
>writeup on the what the current DTNRG thoughts are regarding naming.
>
>Best Regards,
>Rajesh
>
>
I'm curious as well on the "regions are out of the picture" statement. 

And to keep things interesting I thought I'd share my vision of how 
regions were going to be used in the IPN/DTN.

I envisioned a hierarchial namespace of regions which would aid in 
routing.  I wanted to have a system where anyone, anywhere could address 
anyone, anywhere assuming they both used the DTN.  The two people could 
be on opposite ends of the solar system. 

Let's run with a hypothetical use case:
  Joe is on Mars and Hank is in a submarine under the Pacific Ocean and 
they want to relay messages.  But how do you address these two places?  
One of the restrictions on a region was that it had to know how to get 
to "hosts" in that region.  I propose having regions inside regions, 
Russian Doll style.  A region can be a host, and a host is always a region.
  So both of my hypothetical chatters are in the "sol" region which 
implies our solar system.  This is pretty vague and not terribly useful 
so you need sub-regions, "earth.sol" and "mars.sol".  The guy on Mars is 
studying Valles Marineris and his base is simply called Marineris so his 
dtn address so far is "marineris.mars.sol".  His laptop is called 
"spelunker" since the guy likes caves and exploring, so to send an email 
to him you'd send it to the tuple 
["spelunker.marineris.mars.sol","mail:joe"].  Hank on the other hand is 
on Earth in the USS Dallas under the waves.  The sub's dtn region could 
be "dallas.uss.ships.terra.earth.sol" .  Notice a couple of things, the 
"ships" and "terra" regions under the "earth" region.  I use "terra" to 
specifically refer to the planet and not the earth-moon system.  The 
moon base that are hypothetical Joe launched from to get to Mars could 
be "armstrong.luna.earth.sol".  Back to our submariner Hank, he doesn't 
have his own laptop and uses the sub's systems to get mail.  So his 
tuple is ["dallas.uss.ships.terra.earth.sol","mail:hank"].  The "ships" 
region is used to denote ocean-going ships, since they can pretty much 
be anywhere on the globe, they're under the "ships.terrra.earth.sol" 
region. 

Hank, being the submariner he is, finds out Joe, the space cadet, has a 
sister living in San Diego, Hank's next port of call.  Hank asks Joe for 
the email address of his sister Sara which is 
["aol.com.in.earth.sol","mail:sara_sd84"] and they chat, meet up and get 
married happily ever after.  :)  But you'll notice that this dtn region 
is a bit odd as well ( other than the fact that aol will pollute the 
cosmos eventually ) with the simple "in" region and no "terra" region.  
The "in" region corresponds to the public internet as we know it today.  
It's not under the "terra" region because latencies in the earth-moon 
system are low enough to still allow internet protocols to work 
sufficiently and the moon and space stations are connected to the public 
internet as well.  So to address anyone on the public internet, their 
dtn region will always end in "in.earth.sol". 

So how does routing work in this world?  There are lots of 
possibilities, but I'll try to outline a few hypotheticals.  Inside the 
"in.earth.sol" region, domains like aol.com will have DNS entries 
pointing to their dtn routers.  My personal domain "windu.com" will be 
found in a similar manner.  I also have a desktop called "enigma" that I 
don't want to have a DNS entry for since it's dynamic and behind 
firewalls, but I'd like to be able to still get bundles.  So I configure 
the dtn router at "windu.com.in.earth.sol" to queue bundles for 
"enigma.windu.com.in.earth.sol" until enigma polls the server.  Now 
here's the beauty, no one on the entire DTN has a route to 
"enigma.windu.com.in.earth.sol".  Not even it's upstream.  Since each 
region is supposed to know how to get to it's sub-regions, the routers 
on mars just need to know how to get to "earth.sol" or just "sol".  
"earth.sol" needs to know how to get to the internet "in.earth.sol".  
The internet needs to find "com.in.earth.sol", which it won't, but the 
internet does have a more specific route for "windu.com.in.earth.sol" 
which gets routed to my co-located server.  And finally my server knows 
about "enigma.windu.com.in.earth.sol" well enough to know to hang on to 
the bundles waiting for me to poll.

Routing to the submarine is an interesting problem.  They have various 
ways of communicating with the outside world.  They can do satellite 
bursts when they surface, ship-to-ship at the surface, maybe even 
digital sound communication underwater.  And when they get to port they 
could use a landline to shore to connect to the public internet.  Since 
they're under the "ships.terra.earth.sol" region, some sort of 
international naval authority would regulate how routing is done in this 
region.  Maybe you pay your dues to them and they'll queue your bundles 
until you can contact them over the internet or through sat uplinks.  
Maybe they route all of your bundles to another ship that is known to be 
rendezvousing with the sub in the middle of the ocean.  But this would 
be determined by the "ships.terra.earth.sol" regional authority.

Since each region can have arbitrary regions underneath it, it can allow 
for a lot of local practices that are different from region to region.

I also propose that encapsulation of bundles within bundles be made part 
of the bundling spec to aid in routing.

Here's a sample hierarchy that's been in my head for a while:

sol
|--- ships (interplanetary ships)
|--- ipn (ipn network backbone hosts - in various orbits, ground 
stations, etc. )
|--- mars
|    |--- marineris
|    |    |--- spelunker
|    |    |--- relay
|    |   
|    |--- orbiters
|    |    |--- mars-surveyor
|    |
|    |--- rovers
|         |--- spirit
|         |--- opportunity
|
|--- earth
     |--- luna
     |--- terra
     |    |--- ships
     |    |    |--- uss 
     |    |         |--- dallas
     |    |--- gsm  (mobile networks)
     |    |    |--- 15125551212 
     |    |
     |    |--- antarctica  (not exactly a well connected internet locale)
     |    |    |--- mcmurdo
     |    |--- ham  (amateur radio)
     |   
     |--- in
     |    |--- (domain names of the internet)
     |--- ships  ( spaceships, maybe earth-moon shuttles )

Let's follow a bundle from the USS Dallas to the Marineris Base on Mars:
from: ["dallas.uss.ships.terra.earth.sol","mail:hank"]
to:   ["spelunker.marineris.mars.sol","mail:joe"]

1) Hank types the message to Joe while underwater - bundle queued for 
delivery
    - default route nexthop: gw.uss.ships.terra.earth.sol

2) Sub breaks surface, uplinks bundle over satellite to a ground 
station. "gw.uss.ships.terra.earth.sol"

3) The ground station has a route to "sol" that specifies 
"ipn.nasa.gov.in.earth.sol" as next hop.  Since the ground station is in 
the "in.earth.sol" region as well, it delivers the bundle directly after 
looking up "mars.nasa.gov" in the DNS.

3) "ipn.nasa.gov.in.earth.sol" has a route to the IPN, but the IPN 
satellites are a bit dumb, and only have routes
to other 'hosts' in the "ipn.sol" region so it can't route correctly 
bundles destined outside of "ipn.sol".  The nexthop for "mars.sol" is 
"mars.ipn.sol", but we only have a route for "ipn.sol", so we 
encapsulate the bundle into a new bundle destined for "mars.ipn.sol" and 
upload the bundle to "orbiter7.earth.ipn.sol" which is the nexthop for 
the "ipn.sol" route.

4) "orbiter7.earth.ipn.sol" manages to relay the bundle to 
"orbiter1.mars.ipn.sol"

5) "orbiter1.mars.ipn.sol" un-encapsulates the bundle since it's 
configured to unencapsulate bundles destined to the "mars.ipn.sol" 
region.  It sees the destination of the unwrapped bundle as 
"marineris.mars.sol".  The orbiter has a direct route to the marineris 
base, but it's half an orbit away.  The orbiter stores the bundle until 
contact is made with marineris.

6) The orbiter sends the bundle to  "relay.marineris.mars.sol"

7) "relay.marineris.mars.sol" forwards the bundle over the base's IPv6 
network to "spelunker.marineris.mars.sol" where Joe reads the message.

Notes: 
1) The routing protocol for the "in.earth.sol" is DNS.
2) The ipn could use some sort of FSPF (Future Shortest Path First) 
algorithm that takes into consideration planned connections in the future.
3) Sample DNS record already in the current dns system:
Run this on Unix: 'dig IN SRV _dtn._tcp.windu.com.'
Bind entry:
_dtn._tcp.windu.com.       IN      SRV     0       5       6474    
dtn.windu.com.

My java implementation uses this, but I'm currently rewriting the TCP 
convergence layer to work with the DTN2 code so it's unfortunately 
unavailable just yet.  Hopefully get it going in the next 2 weeks.

Feel free to flame

-Matt Bradbury
[email-masked]

Date: Fri, 1 Apr 2005 13:24:28 -0800
From: Michael Demmer <[email-masked]>
To: Jakob Eriksson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Mail-Followup-To: Jakob Eriksson <[email-masked]>, [email-masked]
Sender: [email-masked]

To throw in my two cents here, I would argue that we define an
endpoint to be a <schema>:<name> tuple, where the set of schemas is
well-known and layed out in the bundle protocol, but that we do not
explicitly distinguish between "addresses" and "identities".

To start, some examples of names could be:

 fixed:0xa5
  ipv4:192.168.0.1:80
 ether:00:0D:56:58:2C:B2
  guid:00-01-02-03-04-05
   dns:www.cs.berkeley.edu
opaque:thequickbrownfoxjumpedoverthelazydog

Each schema definition would include any relevant rules for pattern
matching, wildcarding, aggregation, and resolution. One advantage of
defining the schemas apriori is that we don't need to carry the schema
strings along in the bundle protocol, rather could just use a one byte
integer. This (I think) would make the protocol somewhat more amenable
to resource constrained environments, as many of the above could be
expressed in a concise binary format on the wire.

Now, a routing table on the bundle daemon would contain entries that
conform to pattern specifications of a particular schema, and would
specify the rules for processing bundles that match that pattern.

For example, I could have a rule that says "send all traffic destined
for dns:*.berkeley.edu using tcp to the endpoint
dns:dtn0.cs.berkeley.edu". This would pass the dns name of the next
hop to the tcp convergence layer, which would engage the
schema-specific lookup protocol (dns) to resolve the name into
something needed to make a connection, i.e. an IP address.

Now take another example, in which my route table has an entry that
matches ip:192.168.0.0/16, and indicates that whatever the destination
address is, the daemon should send the bundle over UDP to port X on
that IP address. No resolution lookup is necessary. In this case, the
destination endpoint identifier is used both as a name (to index into
the routing table) and an address (to connect to a host via a
convergence layer).

Third example -- my route entry contains an entry that says that all
bundles destined for guid://* should be sent to some well known point,
where it triggers an OpenDHT lookup to resolve the guid into some
other identifier that indicates the correct current address of the
node corresponding to the GUID.

Now, I like Jacob's notion of routing hints to accomplish some of the
topological uses that we had for regions. However, my preference would
be to encode the hint destination according to the above naming
schemas, and when passing it with a bundle, that we include it in a
source route header. This allows it to be more general, i.e. where
hints could be stacked or multiple alternatives could be provided.

So, say I send a bundle from within Intel with a destination endpoint
id of ip:192.168.0.1. Now this address happens to match some host
within Intel, but I also include a routing hint of dns:mitre.org. Now,
the bundle routers within Intel will look at this header, and rather
than sending directly to the destination, instead will forward it
according to the routing entries for dns:mitre.org. Assuming a
functioning routing protocol, this will successfully get the bundle
inside mitre. Once that's happened, the routers within mitre will
know that the first step of this "source route" has been satisfied,
and will then route based on the ip:192.168.0.1 endpoint, getting the
bundle to my destination.

I guess the main distinction between this and what Jacob proposed
today (and yesterday) is that I do not think the architecture should
make a hard and fast distinction between "addresses" and "names", but
rather should define some naming semantics (the above schemas) that
include, where appropriate, mechanisms for aggregation and resolution,
but leave their usage up to the user. So, basically, if someone
deploys a 1,000,000 node dtn network with completely flat identifiers,
then they're likely to be in trouble. But I don't think there's a good
reason why the architecture needs to forbid it, since there are many
cases in which I may very well want to use flat naming with no lookup
at all (i.e. a very small, sparsely connected network). 

One final note that's totally disjoint from the above is that we also
need to discuss how demux strings fit into all this (i.e. the dtn
equivalent of a TCP or UDP port to identify a particular application
attached to a dtn router).

My sincere apologies if this isn't clear, I have some other things I
need to get done this afternoon so I kinda rushed through this, but I
did want to get my thoughts out while the question is still fresh.

-m

From: "Scott,Keith L." <[email-masked]>
To: "'Jakob Eriksson'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Date: Fri, 1 Apr 2005 15:32:53 -0500
Sender: [email-masked]

The 'hints' approach is, of course, very similar to the supername piece of
the SPINDLE proposal.  I think there may be some real utility in going to a
more general notion of what the 'region' part of a name is (like hits), for
exactly the reasons you mention.  Whether this is a 'separate piece of a
tuple' or 'just a piece of a URI' is, to me, semantics that I (don't think
I) particularly care about.  If you have thoughts on a way to help address
aggregation and enable mobility through the use of a GUID of some sort,
please post quickly   :)

		--keith

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Jakob Eriksson
>Sent: Friday, April 01, 2005 3:13 PM
>To: [email-masked]
>Subject: Re: [dtn-interest] Comments on DTNRG documents from 
>BBN SPINDLE project
>
>
>The approach that I advocate is a separation of addresses (ip, phone  
>number, street address), which appear in routing tables, from  
>identities (name, guid, etc), which do not appear in routing tables,  
>but which uniquely identify users or services.
>
>This allows us a great deal of flexibility in terms of node  
>mobility/nomadicity, topology changes, etc. However, as Bob 
>points out,  
>separating name and address means there will be a need for an address  
>resolution service. In cases where this isn't feasible, a compromise  
>would have to be made. For example, the identifier
>
>guid://00-01-02-03-04-05
>
>does not provide any location information. Oftentimes, this is  
>desirable, because it means the identifier is valid even if the user  
>moves, or if his means of connectivity changes (dhcp lease expiry for  
>example?). Sometimes, for example in a mars scenario, a lookup would  
>have to travel all the way to earth to find out that the destination  
>was in fact in the jupiter system. A compromise, which leaves the  
>architecture open for later improvements, is to allow name spaces to  
>incorporate location information, or location hints. For example
>
>location-guid://00-01-02-03-04-05@jupiter
>
>or potentially
>
>hint-guid://00-01-02-03-04-05@jupiter
>
>meaning "try jupiter first, if it doesn't work, use a default  
>resolution server (probably at earth).". The local resolver 
>would look  
>at the URI, and immediately resolve it to the address "jupiter". Once  
>in the jovian system, the jovian DHT would determine where the user  
>indicated by the guid string is located at the moment. Note that  
>different name spaces may have completely different methods for  
>resolving the address of a node.
>
>Besides the advantage of persistent identifiers, separating id and  
>address also allows us the flexibility to play with address 
>allocation  
>to enable aggregation. I'm working on a more detailed writeup of this  
>approach, together with its advantages, as we speak.
>
>- Jakob
>
>
>On Apr 1, 2005, at 11:28 AM, Durst,Robert C. wrote:
>
>> I'm still not sure we have consensus on this.  Some of us feel that  
>> regions are very much -in- the picture, both for routing and  
>> information containment.  We need to know how we're going to 
>aggregate  
>> routing information and deal with the case where we need to make a  
>> *real* routing decision without having to go to some sort of  
>> 'resolution server'.
>>
>> Bob and Keith
>>
>>
>> Robert C. Durst
>>
>>
>> -----Original Message-----
>> From: [email-masked]  
>> <[email-masked]>
>> To: Scott Burleigh <[email-masked]>
>> CC: [email-masked] 
><[email-masked]>;  
>> [email-masked] <[email-masked]>
>> Sent: Fri Apr 01 14:10:29 2005
>> Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN  
>> SPINDLE project
>>
>> Scott,
>>
>> Thank you for your detailed responses. I will share read them with my
>> group.
>>
>> You mentioned that "regions are out of the picture". Would 
>you have any
>> writeup on the what the current DTNRG thoughts are regarding naming.
>>
>> Best Regards,
>> Rajesh
>>
>>>
>>> Rajesh, I'm sorry it has taken me so long to respond to your  
>>> comments; it's been a month of everything being 
>top-priority at the  
>>> same time, so reflecting on DTN architecture and the bundling  
>>> protocol unfortunately slipped to second priority.
>>>
>>> Some remarks in-line below.
>>>
>>> Scott
>>>
>>> Rajesh Krishnan wrote:
>>>> 
>..................................................................... 
>>>> ..........
>>>> Comments on DTN Architecture
>>>> ============================
>>>>
>>>> * Scope: The comments in this section refer specifically 
>to the text
>>>>   contained in draft-irtf-dtnrg-arch-02.txt
>>>>
>>>> * Overall: The following aspects have not received 
>adequate treatment
>>>>   in the architecture:
>>>>
>>>>   - Mobility
>>>
>>> I think we're all agreed on this.
>>>
>>>>     o especially, node mobility between regions and region mobility
>>>
>>> But this particular aspect of the problem may have 
>disappeared, now  
>>> that we're moving away from preserving any formal "region" 
>notion in  
>>> the architecture.
>>>
>>>>   - Management
>>>>     o ownership and administrative boundaries for nodes and regions
>>>
>>> I guess ownership of nodes remains an issue of some sort, 
>but why is  
>>> it an issue that needs to be addressed in the Architecture document?
>>>
>>>>     o instrumentation of DTN nodes for observing and controlling  
>>>> remote
>>>>       network state
>>>>     o error conditions at a node such as a persistent store failure
>>>>     o declarative (external) specification and enforcement of  
>>>> policies
>>>
>>> I think all of these may be important, but I don't think 
>any of them  
>>> should be addressed in the Architecture document.  They are 
>low-level  
>>> and protocol-specific, and in some cases implementation-specific.
>>>
>>>>   - Disruptions occurring at short timescales (the focus is on  
>>>> tolerance
>>>>     to delays at large timescales)
>>>
>>> Right, we spent a little time on this at the meeting.  I 
>still don't  
>>> understand the issue or its significance.  What is the unsolved  
>>> problem here, and why is DTN the right instrument for solving it?
>>>
>>>> * The abstract defines the delay tolerant network as an 
>"overlay that
>>>>   exists above the transport layer."  It appears that there is  
>>>> nothing
>>>>   in the architecture that fundamentally requires a DTN to be  
>>>> overlaid
>>>>   over the transport layer of the underlying network.
>>>
>>> Right, we could say "exists, notionally, above the 
>transport layer."   
>>> Could be above some other transmission layer which, strictly  
>>> speaking, doesn't even necessarily have to be reliable 
>[though if it  
>>> isn't then you don't have a lot of reliability in your network; in  
>>> the general case, custodial retransmission is not a mechanism you  
>>> want to count on as your primary guarantor of reliability in a  
>>> delay-tolerant network].
>>>
>>>>   On the other hand, there appear to be some _implicit_ service  
>>>> requirements
>>>>   assumed for the underlying network.  These requirements may be  
>>>> typically
>>>>   satisfied by the transport layer  in an IP network, but 
>it is not  
>>>> clear
>>>>   the same holds for other networks.  These assumptions 
>must be made  
>>>> explicit
>>>>   irrespective of which layer of the underlying network DTN is  
>>>> overlaid upon.
>>>
>>> Very good point.
>>>
>>>>   Since DTN is an overlay, the underlying network appears 
>to the DTN  
>>>> to be
>>>>   a (more capable) link layer rather than a transport 
>layer, and DTN  
>>>> needs
>>>>   to implement functionality (e.g. routing) typically associated  
>>>> with the
>>>>   network layer.
>>>
>>> Except that, to DTN, TCP/IP looks like a link layer system, 
>while to  
>>> the rest of the world it looks like transport.
>>>
>>> The alien concept here, I think, is that "network-ness" and  
>>> "link-ness" are *relative* rather than absolute.  The OSI 7-layer  
>>> model encourages us to think of a particular element of 
>communication  
>>> functionality having an absolute location in the stack, 
>rather than  
>>> articulating more general principles of layer dependency (relative  
>>> location in the stack) that would help us make more sense of this  
>>> stuff.  It may be that, while the layering notion itself is still  
>>> very valuable [I am old-fashioned and think it is; I 
>realize there is  
>>> dissent], it's time to move on to a more powerful and 
>general model  
>>> of layering.
>>>
>>> TCP/IP is to Bundling as Ethernet is to IP -- except that Bundling  
>>> typically needs its underlying "Ethernet" to be more reliable, so  
>>> maybe it's more accurate to say that TCP/IP is to Bundling as  
>>> Ethernet with (say) Type 3 LLC is to IP.
>>>
>>>>   We suggest generalizing this statement to "overlay that exists  
>>>> above any
>>>>   layer of an underlying network that provides the <enumerated>  
>>>> capabilities
>>>>   (possibly through a convergence sublayer)".
>>>
>>> Yes, something like that, except that I would omit the 
>parenthetical  
>>> clause.  I think there is *always* a convergence sublayer 
>in any DTN  
>>> implementation, and in fact I suspect there is always one 
>in any IP  
>>> implementation; it's just that in the IP world that 
>convergence layer  
>>> is sometimes formally identified, exposed, and documented 
>(e.g., the  
>>> VxWorks "MUX" layer) and sometimes not.
>>>
>>>> * In Section 3.1 it is not clear whether aggregation of 
>bundles is  
>>>> allowed.
>>>
>>> I think there's a pretty clear statement that a bundle 
>encapsulates a  
>>> "message" and that messages are atomic, but maybe that could be  
>>> emphasized.  There currently is no provision for a bundle agent  
>>> aggregating multiple messages into its (single) payload; is 
>that what  
>>> you're thinking of?  What advantage would this offer?
>>>>
>>>> * Section 3.2, assumptions 1-3. Assumptions (1) and (2) are not  
>>>> generally
>>>>   valid for tactical military networks -- a large 
>application area  
>>>> seeking
>>>>   this technology. Storage is neither plentiful nor 
>well-distributed.
>>>>   However, it is not clear that the *architecture* per se *needs*
>>>>   assumption 1.  Within this architecture, one could build routing
>>>>   mechanisms that perform coordinated, distributed storage.
>>>
>>> I think these assumptions still hold, if we agree that "plentiful"  
>>> and "well-distributed" are relative terms.  Deferred transmission  
>>> requires storage.  If each node has enough storage [somewhere] to  
>>> accomplish whatever transmission deferral it needs to do in 
>order to  
>>> be a viable bundle agent, then we can think of its storage as  
>>> plentiful and well-distributed; if not, then you have got a busted  
>>> delay-tolerant network.
>>>
>>>> * Sec 3.2. Bulk/Normal/Expedited classes. Is the treatment on a  
>>>> per-next-hop
>>>>   basis? Can one give a Bulk bundle destined for the south 
>pole to a  
>>>> contact
>>>>   headed south while the queue contains an Expedited 
>bundle destined  
>>>> for the
>>>>   north pole? we guess the answer is yes, but it is not entirely  
>>>> clear from
>>>>   the text.
>>>
>>> Good clarification.
>>>
>>>> * In Section 3.3 it is not clear whether the transferrer or  
>>>> transferee
>>>>   generates the custody transfer indication.
>>>
>>> The transferee (receiver) generates the report -- it's the only  
>>> entity that has sufficient information to do so, as it's 
>the only one  
>>> that knows the custody transfer was successfully completed.
>>>
>>>     Also if these indications
>>>>   are all sent to the report-to node, then how many reports per  
>>>> bundle
>>>>   does it receive?  Will this scale?  Can reports be aggregated or
>>>>   piggybacked opportunistically or not?
>>>
>>> These indications are designed for tracing and network performance  
>>> analysis, and they are issued on an as-needed per-bundle 
>basis; you  
>>> can (and usually do) have custody transfer without them.  If they  
>>> were requested on every single custodial bundle then you 
>might indeed  
>>> have a scaling problem, but that would be bad practice; maybe we  
>>> should legislate against this, maybe not, I dunno.
>>>
>>>> * In Section 3.3, for the expiration time and the curent 
>time of day,
>>>>   what is the reference?  Will GMT / Earth time be used in the IPN?
>>>
>>> Yes, there will be some single Earth-based time reference, 
>maybe UTC;  
>>> JPL, at least, already operates this way.
>>>
>>>> * Sec 3.4/3.5. Does the notion of a region include hierarchical  
>>>> nesting in a
>>>>   topologically significant way? That is, can the "A" in 
>(R,A) turn  
>>>> contain an
>>>>   (R1,A1) and so on?
>>>
>>> Because "regions" are now out of the picture, I think this 
>question  
>>> is moot.  The lexical structure of the endpoint ID is now 
>somewhat up  
>>> in the air, as we discussed in yesterday's DTN telecon, but in any  
>>> event it's not a tuple.
>>>
>>>> * In Section 3.5, the requirement that "any node not in R1 must  
>>>> treat A
>>>>   as "opaque" (i.e. it cannot interpret A)" seems needlessly  
>>>> restrictive.
>>>>   It seems sufficient to require that A not be modified 
>outside R1.   
>>>> To
>>>>   support mobility efficiently (and avoid needless telescoping of  
>>>> routes),
>>>>   it may become necessary to interpret A (e.g. location hints)  
>>>> outside R1.
>>>>
>>>>   Furthermore, it can be argued that the "name invariance 
>family" in  
>>>> the
>>>>   Bundle Protocol Specification is indeed an interpretation of A  
>>>> outside
>>>>   R1.
>>>>
>>>> * In Section 3.5 "Every node in a region R1 shall have the 
>ability to
>>>>   eventually deliver messages to every other node in R1 
>..." needs to
>>>>   be qualified with a "barring a permanent network partition or  
>>>> permananent
>>>>   destruction of nodes, and provided the expiration time of the  
>>>> bundle
>>>>   exceeds the time the network is partitioned, and there is  
>>>> sufficient
>>>>   storage in the network."
>>>>
>>>> * Sec. 3.5, assumption 3 ("every node in a region should 
>be able to  
>>>> eventually
>>>>   deliver to every other node"). Not clear whether this 
>assumption  
>>>> requires
>>>>   that the "eventual delivery" be made with or without the use of  
>>>> data
>>>>   hauling nodes (DTN  routers). If we cannot use DTN 
>routers within  
>>>> the
>>>>   region, then this seriously limits the applicability of this
>>>>   architecture to the tactical military environment. For 
>instance,  
>>>> the region
>>>>   could be a brigade with HMMMVs, soldiers, UAVs etc. A brigade  
>>>> could be
>>>>   partitioned with UAV or helicopters doing the data hauling. In  
>>>> such a case
>>>>   we need a few DTN routers within the region. On the 
>other hand, if
>>>>   DTN routers can be used to heal such partitions within a 
>region,  
>>>> it is
>>>>   not clear how the addressing scheme will work.
>>>
>>> I think all three of these points are now moot.
>>>
>>>> * In Section 3.8 "graph" is used to mean "multi-graph".
>>>
>>> Yes.
>>>
>>>> * Section 3.8.1. Types of contacts. How is contact volatility  
>>>> managed?
>>>>   When you lose contact, you are not sure whether it is 
>"still out  
>>>> there" or
>>>>   "gone". In other words, do you envisage the use of a 
>link up/down  
>>>> protocol
>>>>   like in OSPF or MANETs to "maintain" contacts.  Is this 
>function  
>>>> at the
>>>>   bundle layer or in the convergence layer?
>>>
>>> I would say this is always at the convergence layer, 
>because the way  
>>> you do it may be dependent on the nature of the underlying 
>protocols.  
>>>  But we may not have consensus on this yet.
>>>
>>>> * Sec. 3.9, Reactive fragmenting. This implicitly assumes 
>that the  
>>>> sender and
>>>>   receiver can communicate throughout the message 
>exchange. What if  
>>>> the
>>>>   link/subnet-path breaks after receiving part of the message? In  
>>>> this case
>>>>   the sender cannot learn that only a portion of the message was  
>>>> received.
>>>>   Actually, this is the likely case -- if X receives only 
>part of a  
>>>> message
>>>>   from Y, it is probably because there was some disruption in the  
>>>> communication
>>>>   -- and this same disruption will likely be a barrier for the  
>>>> sender to
>>>>   "learn" anything at all about the outcome of its transmission.
>>>
>>> Yes.  I am increasingly skeptical about including reactive  
>>> fragmentation -- and in fact any kind of fragmentation at 
>all -- as a  
>>> Bundling function.  I'm hoping to have time this afternoon 
>to lay out  
>>> my whole argument on this, in yet another interminable email.
>>>
>>>> * Section 3.9 what does it mean for DTN nodes to "share an edge"
>>>
>>> It means they are the two vertices on which the edge is incident.
>>>
>>>> * Section 3.10, can ACKs be aggregated or piggybacked  
>>>> opportunistically?
>>>
>>> They currently are not.  Worth discussing.
>>>
>>>> * Section 3.11, seems the use of seconds for expiration 
>presupposes  
>>>> the
>>>>   use of DTN in high delay environments, and precludes 
>applications  
>>>> to
>>>>   high-speed optical networks (or computer interconnects), 
>and other
>>>>   distributed applications, where custody transfers and data  
>>>> expiration
>>>>   may indeed happen at faster timescales.
>>>>
>>>>   Why should not DTN scale _down_ in delays and 
>disconnections the  
>>>> same
>>>>   way it scales up?
>>>
>>> I think it's because we haven't identified a need to do so. 
> This was  
>>> mentioned earlier; again, I don't understand the issue or its  
>>> significance.
>>>
>>>> * Section 3.12. Congestion control. We are not sure if congestion  
>>>> control
>>>>   should be considered within this architecture. 
>Presumably, DTN is  
>>>> deployed
>>>>   in a network where only a (small?) subset of the nodes are DTN  
>>>> capable (DTN
>>>>   routers/nodes).
>>>
>>> Not necessarily; they may well all be DTN agents.  But I 
>don't think  
>>> this is relevant: you need to do something to minimize data 
>loss due  
>>> to resource oversubscription at bundle agents functioning 
>as routers,  
>>> no matter how many of them you have.
>>>
>>>     Thus there may be plenty of other traffic that DTN has no
>>>>   control over. Congestion is a network-layer/MAC layer 
>phenomenon  
>>>> and best
>>>>   controlled there.
>>>
>>> But Bundling *is* at network layer, in the overlay network.
>>>
>>>     No matter what we do at the DTN layer, it will be of no
>>>>   avail if other applications/protocols using the 
>underlying network  
>>>> blast
>>>>   away to glory.
>>>
>>> I'm not sure I understand your point, but I suspect I 
>disagree.  I've  
>>> got a Bundling congestion control system implemented and it 
>seems to  
>>> work pretty well; Esther and I are trying frantically to 
>get a paper  
>>> on it ready in time for the SIGCOMM workshop.
>>>
>>>> * Section 3.12. Flow control for solving the congestion control.  
>>>> This only
>>>>   works even partially if the receiver capacity is lower 
>or equal to  
>>>> the
>>>>   capacity of the intermediate nodes -- may not be a realistic  
>>>> assumption,
>>>>   especially in a tactial military environment where the 
>bundle may  
>>>> have
>>>>   to go over multiple wireless hops.
>>>
>>> Again, I'm not sure I understand your point.  We should probably  
>>> spend a few moments discussing the way I've got it implemented.
>>>
>>>> * Section 3.13, The security architecture (based on checking at  
>>>> edges) may
>>>>   be challenged by mobility, especially of the edges. What if the  
>>>> edges of
>>>>   the network are continuously redefined due to mobility?
>>>
>>> Right, we are all agreed that a lot of security issues 
>remain to be  
>>> nailed down.
>>>
>>>> * Section 4.3 makes a critical point regarding state 
>versus protocol
>>>>   behavior and the possibility of state being shared across  
>>>> protocols.
>>>>   A corollary of this sattement is the need to identify information
>>>>   models for sharing (and storing) routing, forwarding, and name
>>>>   resolution state.
>>>
>>> I would expect these models to be identified in the course of  
>>> developing the relevant protocols; I think this stuff is too  
>>> low-level for the architecture document.
>>>
>>>> * Section 5, For disruption tolerance, the application 
>structuring  
>>>> issues
>>>>   must include cases where the DTN node where the application is  
>>>> registered
>>>>   is mobile or is otherwise soon to be disconnected (and needs to  
>>>> transfer
>>>>   custody of the registration).
>>>
>>> Mobility of registration is a concept we haven't discussed at all  
>>> yet, as far as I know, and I'm not yet convinced of its utility.   
>>> Again, the whole question of mobility needs more work.  It may be  
>>> "just" a routing problem.
>>>>
>>>> * Section 5, application needs to be better defined -- are they  
>>>> strictly
>>>>   point-to-point or can aplication endpoints reside in a 
>distributed
>>>>   manner (anycast or multicast basis) in the delay tolerant network
>>>
>>> We don't yet have any definition of DTN multipoint delivery 
>service  
>>> that would encompass anycast or multicast.  We are all 
>agreed that we  
>>> need such a definition, but it's not ready yet.
>>>
>>>> * Section 6 should list mandatory requirements for the 
>convergence  
>>>> layers
>>>>   in terms of what services they must provide to the bundle layer.
>>>
>>> I think the Bundling spec is the right place for this; it's too  
>>> low-layer for the architecture document.
>>>
>>>> * DTN has some goals similar to X.400; the X.400 delivery service  
>>>> classes
>>>>   are worth evaluating in this context (a citation of X.400 is  
>>>> appropriate
>>>>   as relevant prior work)
>>>
>>> Sure.
>>>
>>>> * Consider the terminology "hold-and-forward" to 
>distinguish from the
>>>>   usage elsewhere of "store-and-forward" to mean 
>"queue-and-forward"
>>>
>>> But I don't think a distinction needs to be drawn; I think they're  
>>> the same.  It's just a matter of degree: how much can be 
>queued, how  
>>> long data may need to be held in the queue, and possibly 
>whether or  
>>> not it's advisable to manage the queues in non-volatile storage  
>>> rather than in DRAM.
>>>
>>>> * Consider the terminology "data hauling" to the case 
>where mobility
>>>>   is exploited for delivery e.g. data mules, message ferries, ...
>>>
>>> Sure, an interesting suggestion.
>>>
>>>> Comments on the Bundle Protocol Specification
>>>> =============================================
>>>>
>>>> * Scope: The comments in this section refer specifically 
>to the text
>>>>   contained in draft-irtf-dtnrg-bundle-spec-02.txt
>>>>
>>>> * This document is well written.  In particular, the format used to
>>>>   describe the primitives and their semantics aids the 
>understanding
>>>>   of the document.
>>>
>>> Thanks!
>>>
>>>> * The term interface is never defined rigorously and is used in  
>>>> multiple
>>>>   contexts such as a software/service interface or a network  
>>>> interface.
>>>>   This should be done in the introduction.
>>>
>>> Good point.
>>>
>>>> * The endpoint ID terminology differs from what is used in the  
>>>> architecture.
>>>>   For example, the architecture indicates that a node must 
>have at  
>>>> least one
>>>>   MEI, but allows multiple MEIs per node; we think the MEI 
>maps to  
>>>> the Agent
>>>>   administration endpoint ID in the bundle protocol specification,
>>>
>>> Yes, we need to resolve this terminology issue.
>>>
>>>>   which seems to suggest that there is exactly one agent  
>>>> administration endpoint ID.
>>>
>>> Not a conflict, but we should clarify: each "interface" has an  
>>> administrative endpoint ID in the same way that each network  
>>> interface card in an IP-based network has its own IP address.
>>>
>>>> * Does the endpoint ID apply to the node or the interface? 
>  Appears
>>>>   to be the former but worth clarifying.
>>>
>>> Nope, the latter.  Which leaves open a question: what's the 
>ID of the  
>>> node as a whole?  We don't really have such a notion in the  
>>> architecture, which I think is kind of ugly, but again I 
>believe it's  
>>> analogous to what we do in the IP world: if you've got a 
>multi-homed  
>>> host, which interface's DNS name (mapping to its unique IP 
>address)  
>>> do you use as the "hostname"?
>>>
>>>> * Name Mobility: Is the communications endpoint ID allowed 
>to move  
>>>> from
>>>>   node to node?  If so, what state related to the 
>registration (e.g.
>>>>   bundles waiting to be delivered, the "delivery failure" action)  
>>>> MUST/
>>>>   SHOULD/MAY be migrated?
>>>>
>>>>   In other words, can nodes transfer custody of a 
>"registration"?   
>>>> (As an
>>>>   analogy consider arguments for and against TCP session 
>migration.)
>>>
>>> Again, I don't think we've contemplated this in the architecture.   
>>> Worth discussing.
>>>
>>>>   Treating the registration as an "active mailbox" object 
>may be a  
>>>> useful
>>>>   metaphor here.
>>>>
>>>>   This may be a larger issue here related to the 
>relinquishment of  
>>>> name
>>>>   bindings by individual nodes.
>>>>
>>>> * Can the CancelBundle.request (sometimes aliased to 
>Cancel.request)
>>>
>>> An error.
>>>
>>>>   only apply if the bundle is locally stored?
>>>
>>> Yes.
>>>
>>>     For example, upon a cancel request
>>>>   can a node launch a "k-hop trace and delete" on a pattern of  
>>>> bundles that
>>>>   were sent earlier?  This will be useful to purge 
>bundles/replicas  
>>>> with
>>>>   large expiration times (that have either been delivered or  
>>>> canceled)?
>>>
>>> Yes, we've discussed the possibility of flooding the network with  
>>> "kill packets" to accomplish this kind of thing.  I'm 
>doubtful that  
>>> there's a lot of advantage in it.
>>>
>>>> * The hash carried by bundles in the security header can 
>have other  
>>>> uses.
>>>>   For example, this hash can be used to populate say a 
>Bloom filter  
>>>> on en
>>>>   route nodes for traceback.
>>>
>>> Cool.
>>>
>>>> * What happens to any bundles that arrive between 
>registration and  
>>>> start
>>>>   delivery?   Does the default delivery action go into effect  
>>>> automatically
>>>>   upon registration?
>>>
>>> Yes.
>>>
>>>>   It may be useful to point out that there is a distinct 
>poll mode  
>>>> (active
>>>>   reception?) when passive reception is first introduced.
>>>
>>> Sure.
>>>
>>>> * What happens to bundles that arrive after a 
>deregister.request?   
>>>> We assume
>>>>   they MUST be discarded.
>>>
>>> Yes, at that point there is no endpoint to deliver them to. 
> It's as  
>>> if the bundles were mis-addressed from the beginning.
>>>
>>>> * MUST the SENDERROR.INDICATION always include the 
>application data  
>>>> unit?
>>>
>>> Conceptually, yes, so that the application can resend or 
>whatever.   
>>> This is an abstract service spec, so how you accomplish this is  
>>> entirely a matter of implementation.
>>>
>>>> * For the administrative part of the endpoint ID, some 
>rationale is  
>>>> required
>>>>   regarding why 8-bit, 16-bit, and URIs are supported in 
>particular?  
>>>>  Why is
>>>>   URI not sufficient?  Why not 32-bit or 48-bit?
>>>
>>> We need to support extremely small bundle headers for some  
>>> environments; that rules out URIs.  I think we worked out that the  
>>> minimum legal length for a URI was 3 bytes, so 8-bit and 16-bit  
>>> endpoint IDs were available for this alternative purpose.  
>32-bit and  
>>> 48-bit numeric endpoint IDs might be indistinguishable from legal  
>>> 4-byte and 6-byte URIs; by confining ourselves to the 
>smaller numbers  
>>> we can use endpoint ID length to disambiguate.
>>>
>>>> * A generic user-defined experimental header mechanism 
>(syntax and  
>>>> semantics
>>>>   for nodes not implementing that header) is needed in order to  
>>>> enable
>>>>   experimentation.
>>>
>>> Yes, we agreed on this at the last DTNRG meeting.
>>>
>>>> * A source routing header extension will be useful.
>>>
>>> Yes, we agreed to think about this too.
>>>
>>>> * Since the dictionary header only allows 16 strings, and since  
>>>> there can
>>>>   be only one header of each type, it appears that 
>extension headers  
>>>> will
>>>>   need their own dictionaries.  For example, consider a 17-hop  
>>>> source route.
>>>
>>> I'd say just carry the strings themselves in the extension 
>headers.   
>>> The strings aren't so likely to be multiply-referenced, so a  
>>> dictionary doesn't buy you much.
>>>
>>>> * It appears that generating a unique ID based purely on 
>the creation
>>>>   timestamp and endpointID may cause problems.  A node with  
>>>> concurrent
>>>>   embedded processors may be able to generate more than 
>one bundle  
>>>> per
>>>>   clock tick.  Therefore, an additional sequence counter may be  
>>>> needed.
>>>
>>> Right, we've agreed that the "fraction" part of the 
>timestamp can be  
>>> a monotonically increasing counter within second.
>>>
>>>> * It is desirable to use the same style in Section 4 as in 
>Section 2
>>>>   (i.e. explicitly call out primitives and desribe their 
>semantics).
>>>
>>> This section is Procedure, not abstract Service, so it's 
>not exactly  
>>> the same.  But you're right, we could start off with some useful  
>>> semantic clarifications.
>>>
>>>> * When a bundle is discarded (in Section 4.2) due to authentication
>>>>   failure, can the report to the adminsitrative endpoint contain a
>>>>   copy of the inauthentic bundle or not?  Since the bundle is  
>>>> otherwise
>>>>   discarded and not processed further, this copy is potentially  
>>>> useful
>>>>   for instrumenting various security mechanisms.
>>>
>>> Currently this doesn't happen.  Worth discussing.
>>>
>>>> * There is a potential for denial-of-service attacks that make use
>>>>   of the report-to field. This is a problem in a DTN since 
>the sender
>>>>   can legitimately be disconnected and vanish.  Has the report-to
>>>>   third party have any say in the matter?  For example, does the
>>>>   bundle carry any credentials from the report-to?
>>>
>>> Denial of service in general is a nightmare.  The only real 
>defense  
>>> we've got, I think, is bundle authentication ("mutual suspicion"  
>>> among bundle agents).
>>>
>>>> * In the bundle fragmentation section, it is assumed that 
>the sending
>>>>   agent "knows" when a transmission is terminated before 
>the entire  
>>>> payload
>>>>   has been transmitted.  Is this (signaling of partial 
>transmission)  
>>>> an
>>>>   explicit requirement for a DTN convergence layer?
>>>
>>> It has been but, again, I am increasingly doubtful.
>>>
>>>> * Currently, the fragmentation information carried in the 
>headers do  
>>>> not
>>>>   provide for redundant encodings of the fragments -- i.e. to  
>>>> indicate
>>>>   how the bundle was fragmented and erasure-coded.  Yet 
>one may wish  
>>>> to
>>>>   apply these codes precisely when there is fragmentation.
>>>>
>>>>   In the current architecture, erasure or digital fountain type  
>>>> encoding
>>>>   must occur either below the convergence layer (which means the  
>>>> protection
>>>>   cannot cross multiple networks), or end to end at the 
>application  
>>>> which
>>>>   means the application cannot selectively erasure-code only when  
>>>> there
>>>>   is fragmentation.
>>>
>>> Right, the whole question of fragmentation is a bag of snakes, and  
>>> always has been.  I will write more on this later today if I have  
>>> time.
>>>
>>>> * In Table 5 there is no way to indicate that a bundle was received
>>>>   in error, but was or was not reconstructable (using the erasure
>>>>   coding). Such a feedback will aid in adjusting the 
>strength of the
>>>>   code.
>>>
>>> I think this belongs at a layer above Bundling, in the same 
>way that  
>>> Digital Fountain lives above IP.  But I know we don't have 
>consensus  
>>> on this.
>>>
>>>> Anticipated Requirements / Areas for Possible Draft Proposals
>>>> =============================================================
>>>>
>>>> * Experimental headers: Our SPINDLE project will use the 
>bundle as  
>>>> the
>>>>   means of message encapsulation, however, we will require the  
>>>> ability
>>>>   to add and experiment with additional headers.  We 
>request that a  
>>>> user
>>>>   definable experimental header mechanism be added to the bundle
>>>>   protocol specification.  In particular, we anticipate 
>the need for
>>>>   extension headers to:
>>>>
>>>>   - support braid-spray routing
>>>>   - carry name resolution hints
>>>>   - carry resource accounting tokens
>>>>   - support management tasks such as bundle traceback, proactive
>>>>     distributed purge of canceled or delivered bundles (as opposed
>>>>     to waiting in storage until bundle expiration).
>>>>   - possibly others
>>>
>>> Sure.
>>>
>>>> * Interpretation of names: We expect we will require a 
>modest change  
>>>> to
>>>>   the DTNRG architecture to allow any region to interpret 
>(but not  
>>>> modify)
>>>>   the "opaque" A part of the {R,A} tuple that constitutes a DTNRG  
>>>> name.
>>>>   Related modifiable information (e.g. resolution hints) may be  
>>>> carried in
>>>>   a late binding header that we may specify.  We 
>anticipate that the  
>>>> unique
>>>>   part of our supername will map to the DTNRG name syntax.
>>>
>>> No longer an issue, I think.
>>>
>>>> * Region interpretation: We anticipate that the routing and late  
>>>> binding
>>>>   frameworks developed within the DARPA DTN program to support  
>>>> tactical
>>>>   mobility may each interpret and use regions differently 
>(e.g. what  
>>>> is
>>>>   a region, who owns/administers a region, mobility of nodes across
>>>>   regions, mobility of regions themselves, and sub-region  
>>>> partitioning).
>>>
>>> I think this is now moot.
>>>
>>>> * We anticipate the DTN program will propose new frameworks for  
>>>> bundle
>>>>   routing (family of routing protocols) and delayed resolution of  
>>>> names.
>>>>   We anticipate we will generate specifications of information  
>>>> models for
>>>>   storing and sharing topology, adjacency, reachability, and name  
>>>> resolution
>>>>   across nodes and across algorithms.
>>>
>>> Sure.
>>>
>>>> * To facilitate regular DTN-DTNRG interaction, a monthly  
>>>> teleconference
>>>>   between the DTN and DTNRG to address DTN-specific issues will be
>>>>   beneficial.
>>>
>>> Yes.
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>Jakob Eriksson
>Ph.D. Candidate
>http://www.cs.ucr.edu/~jeriksson
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Date: Fri, 1 Apr 2005 12:12:30 -0800
To: [email-masked]
Sender: [email-masked]

The approach that I advocate is a separation of addresses (ip, phone  
number, street address), which appear in routing tables, from  
identities (name, guid, etc), which do not appear in routing tables,  
but which uniquely identify users or services.

This allows us a great deal of flexibility in terms of node  
mobility/nomadicity, topology changes, etc. However, as Bob points out,  
separating name and address means there will be a need for an address  
resolution service. In cases where this isn't feasible, a compromise  
would have to be made. For example, the identifier

guid://00-01-02-03-04-05

does not provide any location information. Oftentimes, this is  
desirable, because it means the identifier is valid even if the user  
moves, or if his means of connectivity changes (dhcp lease expiry for  
example?). Sometimes, for example in a mars scenario, a lookup would  
have to travel all the way to earth to find out that the destination  
was in fact in the jupiter system. A compromise, which leaves the  
architecture open for later improvements, is to allow name spaces to  
incorporate location information, or location hints. For example

location-guid://00-01-02-03-04-05@jupiter

or potentially

hint-guid://00-01-02-03-04-05@jupiter

meaning "try jupiter first, if it doesn't work, use a default  
resolution server (probably at earth).". The local resolver would look  
at the URI, and immediately resolve it to the address "jupiter". Once  
in the jovian system, the jovian DHT would determine where the user  
indicated by the guid string is located at the moment. Note that  
different name spaces may have completely different methods for  
resolving the address of a node.

Besides the advantage of persistent identifiers, separating id and  
address also allows us the flexibility to play with address allocation  
to enable aggregation. I'm working on a more detailed writeup of this  
approach, together with its advantages, as we speak.

- Jakob

On Apr 1, 2005, at 11:28 AM, Durst,Robert C. wrote:

> I'm still not sure we have consensus on this.  Some of us feel that  
> regions are very much -in- the picture, both for routing and  
> information containment.  We need to know how we're going to aggregate  
> routing information and deal with the case where we need to make a  
> *real* routing decision without having to go to some sort of  
> 'resolution server'.
>
> Bob and Keith
>
>
> Robert C. Durst
>
>
> -----Original Message-----
> From: [email-masked]  
> <[email-masked]>
> To: Scott Burleigh <[email-masked]>
> CC: [email-masked] <[email-masked]>;  
> [email-masked] <[email-masked]>
> Sent: Fri Apr 01 14:10:29 2005
> Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN  
> SPINDLE project
>
> Scott,
>
> Thank you for your detailed responses. I will share read them with my
> group.
>
> You mentioned that "regions are out of the picture". Would you have any
> writeup on the what the current DTNRG thoughts are regarding naming.
>
> Best Regards,
> Rajesh
>
>>
>> Rajesh, I'm sorry it has taken me so long to respond to your  
>> comments; it's been a month of everything being top-priority at the  
>> same time, so reflecting on DTN architecture and the bundling  
>> protocol unfortunately slipped to second priority.
>>
>> Some remarks in-line below.
>>
>> Scott
>>
>> Rajesh Krishnan wrote:
>>> ..................................................................... 
>>> ..........
>>> Comments on DTN Architecture
>>> ============================
>>>
>>> * Scope: The comments in this section refer specifically to the text
>>>   contained in draft-irtf-dtnrg-arch-02.txt
>>>
>>> * Overall: The following aspects have not received adequate treatment
>>>   in the architecture:
>>>
>>>   - Mobility
>>
>> I think we're all agreed on this.
>>
>>>     o especially, node mobility between regions and region mobility
>>
>> But this particular aspect of the problem may have disappeared, now  
>> that we're moving away from preserving any formal "region" notion in  
>> the architecture.
>>
>>>   - Management
>>>     o ownership and administrative boundaries for nodes and regions
>>
>> I guess ownership of nodes remains an issue of some sort, but why is  
>> it an issue that needs to be addressed in the Architecture document?
>>
>>>     o instrumentation of DTN nodes for observing and controlling  
>>> remote
>>>       network state
>>>     o error conditions at a node such as a persistent store failure
>>>     o declarative (external) specification and enforcement of  
>>> policies
>>
>> I think all of these may be important, but I don't think any of them  
>> should be addressed in the Architecture document.  They are low-level  
>> and protocol-specific, and in some cases implementation-specific.
>>
>>>   - Disruptions occurring at short timescales (the focus is on  
>>> tolerance
>>>     to delays at large timescales)
>>
>> Right, we spent a little time on this at the meeting.  I still don't  
>> understand the issue or its significance.  What is the unsolved  
>> problem here, and why is DTN the right instrument for solving it?
>>
>>> * The abstract defines the delay tolerant network as an "overlay that
>>>   exists above the transport layer."  It appears that there is  
>>> nothing
>>>   in the architecture that fundamentally requires a DTN to be  
>>> overlaid
>>>   over the transport layer of the underlying network.
>>
>> Right, we could say "exists, notionally, above the transport layer."   
>> Could be above some other transmission layer which, strictly  
>> speaking, doesn't even necessarily have to be reliable [though if it  
>> isn't then you don't have a lot of reliability in your network; in  
>> the general case, custodial retransmission is not a mechanism you  
>> want to count on as your primary guarantor of reliability in a  
>> delay-tolerant network].
>>
>>>   On the other hand, there appear to be some _implicit_ service  
>>> requirements
>>>   assumed for the underlying network.  These requirements may be  
>>> typically
>>>   satisfied by the transport layer  in an IP network, but it is not  
>>> clear
>>>   the same holds for other networks.  These assumptions must be made  
>>> explicit
>>>   irrespective of which layer of the underlying network DTN is  
>>> overlaid upon.
>>
>> Very good point.
>>
>>>   Since DTN is an overlay, the underlying network appears to the DTN  
>>> to be
>>>   a (more capable) link layer rather than a transport layer, and DTN  
>>> needs
>>>   to implement functionality (e.g. routing) typically associated  
>>> with the
>>>   network layer.
>>
>> Except that, to DTN, TCP/IP looks like a link layer system, while to  
>> the rest of the world it looks like transport.
>>
>> The alien concept here, I think, is that "network-ness" and  
>> "link-ness" are *relative* rather than absolute.  The OSI 7-layer  
>> model encourages us to think of a particular element of communication  
>> functionality having an absolute location in the stack, rather than  
>> articulating more general principles of layer dependency (relative  
>> location in the stack) that would help us make more sense of this  
>> stuff.  It may be that, while the layering notion itself is still  
>> very valuable [I am old-fashioned and think it is; I realize there is  
>> dissent], it's time to move on to a more powerful and general model  
>> of layering.
>>
>> TCP/IP is to Bundling as Ethernet is to IP -- except that Bundling  
>> typically needs its underlying "Ethernet" to be more reliable, so  
>> maybe it's more accurate to say that TCP/IP is to Bundling as  
>> Ethernet with (say) Type 3 LLC is to IP.
>>
>>>   We suggest generalizing this statement to "overlay that exists  
>>> above any
>>>   layer of an underlying network that provides the <enumerated>  
>>> capabilities
>>>   (possibly through a convergence sublayer)".
>>
>> Yes, something like that, except that I would omit the parenthetical  
>> clause.  I think there is *always* a convergence sublayer in any DTN  
>> implementation, and in fact I suspect there is always one in any IP  
>> implementation; it's just that in the IP world that convergence layer  
>> is sometimes formally identified, exposed, and documented (e.g., the  
>> VxWorks "MUX" layer) and sometimes not.
>>
>>> * In Section 3.1 it is not clear whether aggregation of bundles is  
>>> allowed.
>>
>> I think there's a pretty clear statement that a bundle encapsulates a  
>> "message" and that messages are atomic, but maybe that could be  
>> emphasized.  There currently is no provision for a bundle agent  
>> aggregating multiple messages into its (single) payload; is that what  
>> you're thinking of?  What advantage would this offer?
>>>
>>> * Section 3.2, assumptions 1-3. Assumptions (1) and (2) are not  
>>> generally
>>>   valid for tactical military networks -- a large application area  
>>> seeking
>>>   this technology. Storage is neither plentiful nor well-distributed.
>>>   However, it is not clear that the *architecture* per se *needs*
>>>   assumption 1.  Within this architecture, one could build routing
>>>   mechanisms that perform coordinated, distributed storage.
>>
>> I think these assumptions still hold, if we agree that "plentiful"  
>> and "well-distributed" are relative terms.  Deferred transmission  
>> requires storage.  If each node has enough storage [somewhere] to  
>> accomplish whatever transmission deferral it needs to do in order to  
>> be a viable bundle agent, then we can think of its storage as  
>> plentiful and well-distributed; if not, then you have got a busted  
>> delay-tolerant network.
>>
>>> * Sec 3.2. Bulk/Normal/Expedited classes. Is the treatment on a  
>>> per-next-hop
>>>   basis? Can one give a Bulk bundle destined for the south pole to a  
>>> contact
>>>   headed south while the queue contains an Expedited bundle destined  
>>> for the
>>>   north pole? we guess the answer is yes, but it is not entirely  
>>> clear from
>>>   the text.
>>
>> Good clarification.
>>
>>> * In Section 3.3 it is not clear whether the transferrer or  
>>> transferee
>>>   generates the custody transfer indication.
>>
>> The transferee (receiver) generates the report -- it's the only  
>> entity that has sufficient information to do so, as it's the only one  
>> that knows the custody transfer was successfully completed.
>>
>>     Also if these indications
>>>   are all sent to the report-to node, then how many reports per  
>>> bundle
>>>   does it receive?  Will this scale?  Can reports be aggregated or
>>>   piggybacked opportunistically or not?
>>
>> These indications are designed for tracing and network performance  
>> analysis, and they are issued on an as-needed per-bundle basis; you  
>> can (and usually do) have custody transfer without them.  If they  
>> were requested on every single custodial bundle then you might indeed  
>> have a scaling problem, but that would be bad practice; maybe we  
>> should legislate against this, maybe not, I dunno.
>>
>>> * In Section 3.3, for the expiration time and the curent time of day,
>>>   what is the reference?  Will GMT / Earth time be used in the IPN?
>>
>> Yes, there will be some single Earth-based time reference, maybe UTC;  
>> JPL, at least, already operates this way.
>>
>>> * Sec 3.4/3.5. Does the notion of a region include hierarchical  
>>> nesting in a
>>>   topologically significant way? That is, can the "A" in (R,A) turn  
>>> contain an
>>>   (R1,A1) and so on?
>>
>> Because "regions" are now out of the picture, I think this question  
>> is moot.  The lexical structure of the endpoint ID is now somewhat up  
>> in the air, as we discussed in yesterday's DTN telecon, but in any  
>> event it's not a tuple.
>>
>>> * In Section 3.5, the requirement that "any node not in R1 must  
>>> treat A
>>>   as "opaque" (i.e. it cannot interpret A)" seems needlessly  
>>> restrictive.
>>>   It seems sufficient to require that A not be modified outside R1.   
>>> To
>>>   support mobility efficiently (and avoid needless telescoping of  
>>> routes),
>>>   it may become necessary to interpret A (e.g. location hints)  
>>> outside R1.
>>>
>>>   Furthermore, it can be argued that the "name invariance family" in  
>>> the
>>>   Bundle Protocol Specification is indeed an interpretation of A  
>>> outside
>>>   R1.
>>>
>>> * In Section 3.5 "Every node in a region R1 shall have the ability to
>>>   eventually deliver messages to every other node in R1 ..." needs to
>>>   be qualified with a "barring a permanent network partition or  
>>> permananent
>>>   destruction of nodes, and provided the expiration time of the  
>>> bundle
>>>   exceeds the time the network is partitioned, and there is  
>>> sufficient
>>>   storage in the network."
>>>
>>> * Sec. 3.5, assumption 3 ("every node in a region should be able to  
>>> eventually
>>>   deliver to every other node"). Not clear whether this assumption  
>>> requires
>>>   that the "eventual delivery" be made with or without the use of  
>>> data
>>>   hauling nodes (DTN  routers). If we cannot use DTN routers within  
>>> the
>>>   region, then this seriously limits the applicability of this
>>>   architecture to the tactical military environment. For instance,  
>>> the region
>>>   could be a brigade with HMMMVs, soldiers, UAVs etc. A brigade  
>>> could be
>>>   partitioned with UAV or helicopters doing the data hauling. In  
>>> such a case
>>>   we need a few DTN routers within the region. On the other hand, if
>>>   DTN routers can be used to heal such partitions within a region,  
>>> it is
>>>   not clear how the addressing scheme will work.
>>
>> I think all three of these points are now moot.
>>
>>> * In Section 3.8 "graph" is used to mean "multi-graph".
>>
>> Yes.
>>
>>> * Section 3.8.1. Types of contacts. How is contact volatility  
>>> managed?
>>>   When you lose contact, you are not sure whether it is "still out  
>>> there" or
>>>   "gone". In other words, do you envisage the use of a link up/down  
>>> protocol
>>>   like in OSPF or MANETs to "maintain" contacts.  Is this function  
>>> at the
>>>   bundle layer or in the convergence layer?
>>
>> I would say this is always at the convergence layer, because the way  
>> you do it may be dependent on the nature of the underlying protocols.  
>>  But we may not have consensus on this yet.
>>
>>> * Sec. 3.9, Reactive fragmenting. This implicitly assumes that the  
>>> sender and
>>>   receiver can communicate throughout the message exchange. What if  
>>> the
>>>   link/subnet-path breaks after receiving part of the message? In  
>>> this case
>>>   the sender cannot learn that only a portion of the message was  
>>> received.
>>>   Actually, this is the likely case -- if X receives only part of a  
>>> message
>>>   from Y, it is probably because there was some disruption in the  
>>> communication
>>>   -- and this same disruption will likely be a barrier for the  
>>> sender to
>>>   "learn" anything at all about the outcome of its transmission.
>>
>> Yes.  I am increasingly skeptical about including reactive  
>> fragmentation -- and in fact any kind of fragmentation at all -- as a  
>> Bundling function.  I'm hoping to have time this afternoon to lay out  
>> my whole argument on this, in yet another interminable email.
>>
>>> * Section 3.9 what does it mean for DTN nodes to "share an edge"
>>
>> It means they are the two vertices on which the edge is incident.
>>
>>> * Section 3.10, can ACKs be aggregated or piggybacked  
>>> opportunistically?
>>
>> They currently are not.  Worth discussing.
>>
>>> * Section 3.11, seems the use of seconds for expiration presupposes  
>>> the
>>>   use of DTN in high delay environments, and precludes applications  
>>> to
>>>   high-speed optical networks (or computer interconnects), and other
>>>   distributed applications, where custody transfers and data  
>>> expiration
>>>   may indeed happen at faster timescales.
>>>
>>>   Why should not DTN scale _down_ in delays and disconnections the  
>>> same
>>>   way it scales up?
>>
>> I think it's because we haven't identified a need to do so.  This was  
>> mentioned earlier; again, I don't understand the issue or its  
>> significance.
>>
>>> * Section 3.12. Congestion control. We are not sure if congestion  
>>> control
>>>   should be considered within this architecture. Presumably, DTN is  
>>> deployed
>>>   in a network where only a (small?) subset of the nodes are DTN  
>>> capable (DTN
>>>   routers/nodes).
>>
>> Not necessarily; they may well all be DTN agents.  But I don't think  
>> this is relevant: you need to do something to minimize data loss due  
>> to resource oversubscription at bundle agents functioning as routers,  
>> no matter how many of them you have.
>>
>>     Thus there may be plenty of other traffic that DTN has no
>>>   control over. Congestion is a network-layer/MAC layer phenomenon  
>>> and best
>>>   controlled there.
>>
>> But Bundling *is* at network layer, in the overlay network.
>>
>>     No matter what we do at the DTN layer, it will be of no
>>>   avail if other applications/protocols using the underlying network  
>>> blast
>>>   away to glory.
>>
>> I'm not sure I understand your point, but I suspect I disagree.  I've  
>> got a Bundling congestion control system implemented and it seems to  
>> work pretty well; Esther and I are trying frantically to get a paper  
>> on it ready in time for the SIGCOMM workshop.
>>
>>> * Section 3.12. Flow control for solving the congestion control.  
>>> This only
>>>   works even partially if the receiver capacity is lower or equal to  
>>> the
>>>   capacity of the intermediate nodes -- may not be a realistic  
>>> assumption,
>>>   especially in a tactial military environment where the bundle may  
>>> have
>>>   to go over multiple wireless hops.
>>
>> Again, I'm not sure I understand your point.  We should probably  
>> spend a few moments discussing the way I've got it implemented.
>>
>>> * Section 3.13, The security architecture (based on checking at  
>>> edges) may
>>>   be challenged by mobility, especially of the edges. What if the  
>>> edges of
>>>   the network are continuously redefined due to mobility?
>>
>> Right, we are all agreed that a lot of security issues remain to be  
>> nailed down.
>>
>>> * Section 4.3 makes a critical point regarding state versus protocol
>>>   behavior and the possibility of state being shared across  
>>> protocols.
>>>   A corollary of this sattement is the need to identify information
>>>   models for sharing (and storing) routing, forwarding, and name
>>>   resolution state.
>>
>> I would expect these models to be identified in the course of  
>> developing the relevant protocols; I think this stuff is too  
>> low-level for the architecture document.
>>
>>> * Section 5, For disruption tolerance, the application structuring  
>>> issues
>>>   must include cases where the DTN node where the application is  
>>> registered
>>>   is mobile or is otherwise soon to be disconnected (and needs to  
>>> transfer
>>>   custody of the registration).
>>
>> Mobility of registration is a concept we haven't discussed at all  
>> yet, as far as I know, and I'm not yet convinced of its utility.   
>> Again, the whole question of mobility needs more work.  It may be  
>> "just" a routing problem.
>>>
>>> * Section 5, application needs to be better defined -- are they  
>>> strictly
>>>   point-to-point or can aplication endpoints reside in a distributed
>>>   manner (anycast or multicast basis) in the delay tolerant network
>>
>> We don't yet have any definition of DTN multipoint delivery service  
>> that would encompass anycast or multicast.  We are all agreed that we  
>> need such a definition, but it's not ready yet.
>>
>>> * Section 6 should list mandatory requirements for the convergence  
>>> layers
>>>   in terms of what services they must provide to the bundle layer.
>>
>> I think the Bundling spec is the right place for this; it's too  
>> low-layer for the architecture document.
>>
>>> * DTN has some goals similar to X.400; the X.400 delivery service  
>>> classes
>>>   are worth evaluating in this context (a citation of X.400 is  
>>> appropriate
>>>   as relevant prior work)
>>
>> Sure.
>>
>>> * Consider the terminology "hold-and-forward" to distinguish from the
>>>   usage elsewhere of "store-and-forward" to mean "queue-and-forward"
>>
>> But I don't think a distinction needs to be drawn; I think they're  
>> the same.  It's just a matter of degree: how much can be queued, how  
>> long data may need to be held in the queue, and possibly whether or  
>> not it's advisable to manage the queues in non-volatile storage  
>> rather than in DRAM.
>>
>>> * Consider the terminology "data hauling" to the case where mobility
>>>   is exploited for delivery e.g. data mules, message ferries, ...
>>
>> Sure, an interesting suggestion.
>>
>>> Comments on the Bundle Protocol Specification
>>> =============================================
>>>
>>> * Scope: The comments in this section refer specifically to the text
>>>   contained in draft-irtf-dtnrg-bundle-spec-02.txt
>>>
>>> * This document is well written.  In particular, the format used to
>>>   describe the primitives and their semantics aids the understanding
>>>   of the document.
>>
>> Thanks!
>>
>>> * The term interface is never defined rigorously and is used in  
>>> multiple
>>>   contexts such as a software/service interface or a network  
>>> interface.
>>>   This should be done in the introduction.
>>
>> Good point.
>>
>>> * The endpoint ID terminology differs from what is used in the  
>>> architecture.
>>>   For example, the architecture indicates that a node must have at  
>>> least one
>>>   MEI, but allows multiple MEIs per node; we think the MEI maps to  
>>> the Agent
>>>   administration endpoint ID in the bundle protocol specification,
>>
>> Yes, we need to resolve this terminology issue.
>>
>>>   which seems to suggest that there is exactly one agent  
>>> administration endpoint ID.
>>
>> Not a conflict, but we should clarify: each "interface" has an  
>> administrative endpoint ID in the same way that each network  
>> interface card in an IP-based network has its own IP address.
>>
>>> * Does the endpoint ID apply to the node or the interface?   Appears
>>>   to be the former but worth clarifying.
>>
>> Nope, the latter.  Which leaves open a question: what's the ID of the  
>> node as a whole?  We don't really have such a notion in the  
>> architecture, which I think is kind of ugly, but again I believe it's  
>> analogous to what we do in the IP world: if you've got a multi-homed  
>> host, which interface's DNS name (mapping to its unique IP address)  
>> do you use as the "hostname"?
>>
>>> * Name Mobility: Is the communications endpoint ID allowed to move  
>>> from
>>>   node to node?  If so, what state related to the registration (e.g.
>>>   bundles waiting to be delivered, the "delivery failure" action)  
>>> MUST/
>>>   SHOULD/MAY be migrated?
>>>
>>>   In other words, can nodes transfer custody of a "registration"?   
>>> (As an
>>>   analogy consider arguments for and against TCP session migration.)
>>
>> Again, I don't think we've contemplated this in the architecture.   
>> Worth discussing.
>>
>>>   Treating the registration as an "active mailbox" object may be a  
>>> useful
>>>   metaphor here.
>>>
>>>   This may be a larger issue here related to the relinquishment of  
>>> name
>>>   bindings by individual nodes.
>>>
>>> * Can the CancelBundle.request (sometimes aliased to Cancel.request)
>>
>> An error.
>>
>>>   only apply if the bundle is locally stored?
>>
>> Yes.
>>
>>     For example, upon a cancel request
>>>   can a node launch a "k-hop trace and delete" on a pattern of  
>>> bundles that
>>>   were sent earlier?  This will be useful to purge bundles/replicas  
>>> with
>>>   large expiration times (that have either been delivered or  
>>> canceled)?
>>
>> Yes, we've discussed the possibility of flooding the network with  
>> "kill packets" to accomplish this kind of thing.  I'm doubtful that  
>> there's a lot of advantage in it.
>>
>>> * The hash carried by bundles in the security header can have other  
>>> uses.
>>>   For example, this hash can be used to populate say a Bloom filter  
>>> on en
>>>   route nodes for traceback.
>>
>> Cool.
>>
>>> * What happens to any bundles that arrive between registration and  
>>> start
>>>   delivery?   Does the default delivery action go into effect  
>>> automatically
>>>   upon registration?
>>
>> Yes.
>>
>>>   It may be useful to point out that there is a distinct poll mode  
>>> (active
>>>   reception?) when passive reception is first introduced.
>>
>> Sure.
>>
>>> * What happens to bundles that arrive after a deregister.request?   
>>> We assume
>>>   they MUST be discarded.
>>
>> Yes, at that point there is no endpoint to deliver them to.  It's as  
>> if the bundles were mis-addressed from the beginning.
>>
>>> * MUST the SENDERROR.INDICATION always include the application data  
>>> unit?
>>
>> Conceptually, yes, so that the application can resend or whatever.   
>> This is an abstract service spec, so how you accomplish this is  
>> entirely a matter of implementation.
>>
>>> * For the administrative part of the endpoint ID, some rationale is  
>>> required
>>>   regarding why 8-bit, 16-bit, and URIs are supported in particular?  
>>>  Why is
>>>   URI not sufficient?  Why not 32-bit or 48-bit?
>>
>> We need to support extremely small bundle headers for some  
>> environments; that rules out URIs.  I think we worked out that the  
>> minimum legal length for a URI was 3 bytes, so 8-bit and 16-bit  
>> endpoint IDs were available for this alternative purpose.  32-bit and  
>> 48-bit numeric endpoint IDs might be indistinguishable from legal  
>> 4-byte and 6-byte URIs; by confining ourselves to the smaller numbers  
>> we can use endpoint ID length to disambiguate.
>>
>>> * A generic user-defined experimental header mechanism (syntax and  
>>> semantics
>>>   for nodes not implementing that header) is needed in order to  
>>> enable
>>>   experimentation.
>>
>> Yes, we agreed on this at the last DTNRG meeting.
>>
>>> * A source routing header extension will be useful.
>>
>> Yes, we agreed to think about this too.
>>
>>> * Since the dictionary header only allows 16 strings, and since  
>>> there can
>>>   be only one header of each type, it appears that extension headers  
>>> will
>>>   need their own dictionaries.  For example, consider a 17-hop  
>>> source route.
>>
>> I'd say just carry the strings themselves in the extension headers.   
>> The strings aren't so likely to be multiply-referenced, so a  
>> dictionary doesn't buy you much.
>>
>>> * It appears that generating a unique ID based purely on the creation
>>>   timestamp and endpointID may cause problems.  A node with  
>>> concurrent
>>>   embedded processors may be able to generate more than one bundle  
>>> per
>>>   clock tick.  Therefore, an additional sequence counter may be  
>>> needed.
>>
>> Right, we've agreed that the "fraction" part of the timestamp can be  
>> a monotonically increasing counter within second.
>>
>>> * It is desirable to use the same style in Section 4 as in Section 2
>>>   (i.e. explicitly call out primitives and desribe their semantics).
>>
>> This section is Procedure, not abstract Service, so it's not exactly  
>> the same.  But you're right, we could start off with some useful  
>> semantic clarifications.
>>
>>> * When a bundle is discarded (in Section 4.2) due to authentication
>>>   failure, can the report to the adminsitrative endpoint contain a
>>>   copy of the inauthentic bundle or not?  Since the bundle is  
>>> otherwise
>>>   discarded and not processed further, this copy is potentially  
>>> useful
>>>   for instrumenting various security mechanisms.
>>
>> Currently this doesn't happen.  Worth discussing.
>>
>>> * There is a potential for denial-of-service attacks that make use
>>>   of the report-to field. This is a problem in a DTN since the sender
>>>   can legitimately be disconnected and vanish.  Has the report-to
>>>   third party have any say in the matter?  For example, does the
>>>   bundle carry any credentials from the report-to?
>>
>> Denial of service in general is a nightmare.  The only real defense  
>> we've got, I think, is bundle authentication ("mutual suspicion"  
>> among bundle agents).
>>
>>> * In the bundle fragmentation section, it is assumed that the sending
>>>   agent "knows" when a transmission is terminated before the entire  
>>> payload
>>>   has been transmitted.  Is this (signaling of partial transmission)  
>>> an
>>>   explicit requirement for a DTN convergence layer?
>>
>> It has been but, again, I am increasingly doubtful.
>>
>>> * Currently, the fragmentation information carried in the headers do  
>>> not
>>>   provide for redundant encodings of the fragments -- i.e. to  
>>> indicate
>>>   how the bundle was fragmented and erasure-coded.  Yet one may wish  
>>> to
>>>   apply these codes precisely when there is fragmentation.
>>>
>>>   In the current architecture, erasure or digital fountain type  
>>> encoding
>>>   must occur either below the convergence layer (which means the  
>>> protection
>>>   cannot cross multiple networks), or end to end at the application  
>>> which
>>>   means the application cannot selectively erasure-code only when  
>>> there
>>>   is fragmentation.
>>
>> Right, the whole question of fragmentation is a bag of snakes, and  
>> always has been.  I will write more on this later today if I have  
>> time.
>>
>>> * In Table 5 there is no way to indicate that a bundle was received
>>>   in error, but was or was not reconstructable (using the erasure
>>>   coding). Such a feedback will aid in adjusting the strength of the
>>>   code.
>>
>> I think this belongs at a layer above Bundling, in the same way that  
>> Digital Fountain lives above IP.  But I know we don't have consensus  
>> on this.
>>
>>> Anticipated Requirements / Areas for Possible Draft Proposals
>>> =============================================================
>>>
>>> * Experimental headers: Our SPINDLE project will use the bundle as  
>>> the
>>>   means of message encapsulation, however, we will require the  
>>> ability
>>>   to add and experiment with additional headers.  We request that a  
>>> user
>>>   definable experimental header mechanism be added to the bundle
>>>   protocol specification.  In particular, we anticipate the need for
>>>   extension headers to:
>>>
>>>   - support braid-spray routing
>>>   - carry name resolution hints
>>>   - carry resource accounting tokens
>>>   - support management tasks such as bundle traceback, proactive
>>>     distributed purge of canceled or delivered bundles (as opposed
>>>     to waiting in storage until bundle expiration).
>>>   - possibly others
>>
>> Sure.
>>
>>> * Interpretation of names: We expect we will require a modest change  
>>> to
>>>   the DTNRG architecture to allow any region to interpret (but not  
>>> modify)
>>>   the "opaque" A part of the {R,A} tuple that constitutes a DTNRG  
>>> name.
>>>   Related modifiable information (e.g. resolution hints) may be  
>>> carried in
>>>   a late binding header that we may specify.  We anticipate that the  
>>> unique
>>>   part of our supername will map to the DTNRG name syntax.
>>
>> No longer an issue, I think.
>>
>>> * Region interpretation: We anticipate that the routing and late  
>>> binding
>>>   frameworks developed within the DARPA DTN program to support  
>>> tactical
>>>   mobility may each interpret and use regions differently (e.g. what  
>>> is
>>>   a region, who owns/administers a region, mobility of nodes across
>>>   regions, mobility of regions themselves, and sub-region  
>>> partitioning).
>>
>> I think this is now moot.
>>
>>> * We anticipate the DTN program will propose new frameworks for  
>>> bundle
>>>   routing (family of routing protocols) and delayed resolution of  
>>> names.
>>>   We anticipate we will generate specifications of information  
>>> models for
>>>   storing and sharing topology, adjacency, reachability, and name  
>>> resolution
>>>   across nodes and across algorithms.
>>
>> Sure.
>>
>>> * To facilitate regular DTN-DTNRG interaction, a monthly  
>>> teleconference
>>>   between the DTN and DTNRG to address DTN-specific issues will be
>>>   beneficial.
>>
>> Yes.
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
Jakob Eriksson
Ph.D. Candidate
http://www.cs.ucr.edu/~jeriksson

From: "Scott,Keith L." <[email-masked]>
To: "'Scott Burleigh'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project team
Date: Fri, 1 Apr 2005 14:55:47 -0500
Sender: [email-masked]

I'm really worried about the way this is headed.  I may be slow here, but I
don't see how a 'flat address space' can work WITHOUT having to have full
knowledge of where to forward towards all destinations in each router?  The
reason that internet routing works is that in the core of the network, each
router maintains 'a few tens of thousands' (without trying to get bogged
down in the exact number) of routing entries.  This is possible because of
the way IP CIDR masks (roughly, netmasks) work (all JPL [137.78.X.X] stuff
heads for the west coast, all NASA HQ stuff heads for DC).  Regions
provide(d) the mechanism for hierarchical routing, allowing each region to
deal with its own internal mess and hiding the need to know about those
internals from other regions.  Indirection mechanisms are fine (I3, DNS,
other DHT, take your pick), but if the 'resolve' function has to be done
remote from the indirection infrastructure (in time, bandwidth, and/or bit
error rate), it's going to be rough.

Second, the whole notion of 'the endpoint identifier is just a string and
you route on as much of it as you know how' is great.  There's a sort of
'continuous transmission' version of late binding there that might be really
great, and it's the generalization of the tuple notion that's in the current
architecture document.  BUT.  There are semantics necessary to know what the
next XX bits mean, to know if I know how to route on them or not.  Those
semantics define 'tuples'.  For example, if we say that endpoint identifiers
are simply URIs, realize that that defines a tuple: a scheme name, and
scheme-specific stuff.

Finally, are we on the road to an architecture/implementation where all
instances can (modulo policy, security, etc.) at least _address_ each other?
If so, then the first point about how much routing information has to be
propagated into remote networks is really pertinent.  This is probably NOT
an issue for those DTNs that will be pure stub networks (ones that do not
accept transit traffic that travels through them to get to the destination).
Such networks can survive perfectly well where every node has a default
route to the stub's point of attachment to 'the Internet'.  For transit
networks that need to make real routing decisions about where to forward
packets, I think it's an issue.

		--keith

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Scott Burleigh
>Sent: Friday, April 01, 2005 11:59 AM
>To: [email-masked]
>Subject: Re: [dtn-interest] Comments on DTNRG documents from 
>BBN SPINDLE project team
>
>Rajesh, I'm sorry it has taken me so long to respond to your 
>comments; it's been a month of everything being top-priority 
>at the same time, so reflecting on DTN architecture and the 
>bundling protocol unfortunately slipped to second priority.
>
>Some remarks in-line below.
>
>Scott
>
>Rajesh Krishnan wrote:
>> 
>...............................................................
>................
>> Comments on DTN Architecture 
>> ============================
>> 
>> * Scope: The comments in this section refer specifically to the text 
>>   contained in draft-irtf-dtnrg-arch-02.txt
>> 
>> * Overall: The following aspects have not received adequate treatment
>>   in the architecture:
>> 
>>   - Mobility
>
>I think we're all agreed on this.
>
>>     o especially, node mobility between regions and region mobility
>
>But this particular aspect of the problem may have 
>disappeared, now that we're moving away from preserving any 
>formal "region" notion in the architecture.
>
>>   - Management
>>     o ownership and administrative boundaries for nodes and regions
>
>I guess ownership of nodes remains an issue of some sort, but 
>why is it an issue that needs to be addressed in the 
>Architecture document?
>
>>     o instrumentation of DTN nodes for observing and 
>controlling remote
>>       network state
>>     o error conditions at a node such as a persistent store failure
>>     o declarative (external) specification and enforcement 
>of policies
>
>I think all of these may be important, but I don't think any 
>of them should be addressed in the Architecture document.  
>They are low-level and protocol-specific, and in some cases 
>implementation-specific.
>
>>   - Disruptions occurring at short timescales (the focus is 
>on tolerance 
>>     to delays at large timescales)
>
>Right, we spent a little time on this at the meeting.  I still 
>don't understand the issue or its significance.  What is the 
>unsolved problem here, and why is DTN the right instrument for 
>solving it?
>
>> * The abstract defines the delay tolerant network as an 
>"overlay that 
>>   exists above the transport layer."  It appears that there 
>is nothing
>>   in the architecture that fundamentally requires a DTN to 
>be overlaid
>>   over the transport layer of the underlying network.
>
>Right, we could say "exists, notionally, above the transport 
>layer."  Could be above some other transmission layer which, 
>strictly speaking, doesn't even necessarily have to be 
>reliable [though if it isn't then you don't have a lot of 
>reliability in your network; in the general case, custodial 
>retransmission is not a mechanism you want to count on as your 
>primary guarantor of reliability in a delay-tolerant network].
>
>>   On the other hand, there appear to be some _implicit_ 
>service requirements 
>>   assumed for the underlying network.  These requirements 
>may be typically 
>>   satisfied by the transport layer  in an IP network, but it 
>is not clear 
>>   the same holds for other networks.  These assumptions must 
>be made explicit 
>>   irrespective of which layer of the underlying network DTN 
>is overlaid upon.
>
>Very good point.
>  
>>   Since DTN is an overlay, the underlying network appears to 
>the DTN to be 
>>   a (more capable) link layer rather than a transport layer, 
>and DTN needs 
>>   to implement functionality (e.g. routing) typically 
>associated with the 
>>   network layer.
>
>Except that, to DTN, TCP/IP looks like a link layer system, 
>while to the rest of the world it looks like transport.
>
>The alien concept here, I think, is that "network-ness" and 
>"link-ness" are *relative* rather than absolute.  The OSI 
>7-layer model encourages us to think of a particular element 
>of communication functionality having an absolute location in 
>the stack, rather than articulating more general principles of 
>layer dependency (relative location in the stack) that would 
>help us make more sense of this stuff.  It may be that, while 
>the layering notion itself is still very valuable [I am 
>old-fashioned and think it is; I realize there is dissent], 
>it's time to move on to a more powerful and general model of layering.
>
>TCP/IP is to Bundling as Ethernet is to IP -- except that 
>Bundling typically needs its underlying "Ethernet" to be more 
>reliable, so maybe it's more accurate to say that TCP/IP is to 
>Bundling as Ethernet with (say) Type 3 LLC is to IP.
>
>>   We suggest generalizing this statement to "overlay that 
>exists above any 
>>   layer of an underlying network that provides the 
><enumerated> capabilities 
>>   (possibly through a convergence sublayer)".
>
>Yes, something like that, except that I would omit the 
>parenthetical clause.  I think there is *always* a convergence 
>sublayer in any DTN implementation, and in fact I suspect 
>there is always one in any IP implementation; it's just that 
>in the IP world that convergence layer is sometimes formally 
>identified, exposed, and documented (e.g., the VxWorks "MUX" 
>layer) and sometimes not.
>
>> * In Section 3.1 it is not clear whether aggregation of 
>bundles is allowed.
>
>I think there's a pretty clear statement that a bundle 
>encapsulates a "message" and that messages are atomic, but 
>maybe that could be emphasized.  There currently is no 
>provision for a bundle agent aggregating multiple messages 
>into its (single) payload; is that what you're thinking of?  
>What advantage would this offer?
>> 
>> * Section 3.2, assumptions 1-3. Assumptions (1) and (2) are 
>not generally
>>   valid for tactical military networks -- a large 
>application area seeking
>>   this technology. Storage is neither plentiful nor 
>well-distributed. 
>>   However, it is not clear that the *architecture* per se *needs* 
>>   assumption 1.  Within this architecture, one could build routing 
>>   mechanisms that perform coordinated, distributed storage.
>
>I think these assumptions still hold, if we agree that 
>"plentiful" and "well-distributed" are relative terms.  
>Deferred transmission requires storage.  If each node has 
>enough storage [somewhere] to accomplish whatever transmission 
>deferral it needs to do in order to be a viable bundle agent, 
>then we can think of its storage as plentiful and 
>well-distributed; if not, then you have got a busted 
>delay-tolerant network.
>
>> * Sec 3.2. Bulk/Normal/Expedited classes. Is the treatment 
>on a per-next-hop 
>>   basis? Can one give a Bulk bundle destined for the south 
>pole to a contact 
>>   headed south while the queue contains an Expedited bundle 
>destined for the 
>>   north pole? we guess the answer is yes, but it is not 
>entirely clear from 
>>   the text.
>
>Good clarification.
>
>> * In Section 3.3 it is not clear whether the transferrer or 
>transferee 
>>   generates the custody transfer indication.
>
>The transferee (receiver) generates the report -- it's the 
>only entity that has sufficient information to do so, as it's 
>the only one that knows the custody transfer was successfully 
>completed.
>
>    Also if these indications
>>   are all sent to the report-to node, then how many reports 
>per bundle
>>   does it receive?  Will this scale?  Can reports be aggregated or
>>   piggybacked opportunistically or not?
>
>These indications are designed for tracing and network 
>performance analysis, and they are issued on an as-needed 
>per-bundle basis; you can (and usually do) have custody 
>transfer without them.  If they were requested on every single 
>custodial bundle then you might indeed have a scaling problem, 
>but that would be bad practice; maybe we should legislate 
>against this, maybe not, I dunno.
>
>> * In Section 3.3, for the expiration time and the curent 
>time of day, 
>>   what is the reference?  Will GMT / Earth time be used in the IPN?
>
>Yes, there will be some single Earth-based time reference, 
>maybe UTC; JPL, at least, already operates this way.
>
>> * Sec 3.4/3.5. Does the notion of a region include 
>hierarchical nesting in a
>>   topologically significant way? That is, can the "A" in 
>(R,A) turn contain an 
>>   (R1,A1) and so on?
>
>Because "regions" are now out of the picture, I think this 
>question is moot.  The lexical structure of the endpoint ID is 
>now somewhat up in the air, as we discussed in yesterday's DTN 
>telecon, but in any event it's not a tuple.
>
>> * In Section 3.5, the requirement that "any node not in R1 
>must treat A 
>>   as "opaque" (i.e. it cannot interpret A)" seems needlessly 
>restrictive.  
>>   It seems sufficient to require that A not be modified 
>outside R1.  To 
>>   support mobility efficiently (and avoid needless 
>telescoping of routes), 
>>   it may become necessary to interpret A (e.g. location 
>hints) outside R1.
>> 
>>   Furthermore, it can be argued that the "name invariance 
>family" in the
>>   Bundle Protocol Specification is indeed an interpretation 
>of A outside 
>>   R1.
>> 
>> * In Section 3.5 "Every node in a region R1 shall have the 
>ability to 
>>   eventually deliver messages to every other node in R1 ..." needs to
>>   be qualified with a "barring a permanent network partition 
>or permananent 
>>   destruction of nodes, and provided the expiration time of 
>the bundle 
>>   exceeds the time the network is partitioned, and there is 
>sufficient
>>   storage in the network."
>> 
>> * Sec. 3.5, assumption 3 ("every node in a region should be 
>able to eventually
>>   deliver to every other node"). Not clear whether this 
>assumption requires 
>>   that the "eventual delivery" be made with or without the 
>use of data 
>>   hauling nodes (DTN  routers). If we cannot use DTN routers 
>within the 
>>   region, then this seriously limits the applicability of this
>>   architecture to the tactical military environment. For 
>instance, the region
>>   could be a brigade with HMMMVs, soldiers, UAVs etc. A 
>brigade could be
>>   partitioned with UAV or helicopters doing the data 
>hauling. In such a case
>>   we need a few DTN routers within the region. On the other hand, if 
>>   DTN routers can be used to heal such partitions within a 
>region, it is 
>>   not clear how the addressing scheme will work.
>
>I think all three of these points are now moot.
>
>> * In Section 3.8 "graph" is used to mean "multi-graph".
>
>Yes.
>
>> * Section 3.8.1. Types of contacts. How is contact 
>volatility managed?
>>   When you lose contact, you are not sure whether it is 
>"still out there" or
>>   "gone". In other words, do you envisage the use of a link 
>up/down protocol
>>   like in OSPF or MANETs to "maintain" contacts.  Is this 
>function at the 
>>   bundle layer or in the convergence layer?
>
>I would say this is always at the convergence layer, because 
>the way you do it may be dependent on the nature of the 
>underlying protocols.  But we may not have consensus on this yet.
>
>> * Sec. 3.9, Reactive fragmenting. This implicitly assumes 
>that the sender and
>>   receiver can communicate throughout the message exchange. 
>What if the 
>>   link/subnet-path breaks after receiving part of the 
>message? In this case 
>>   the sender cannot learn that only a portion of the message 
>was received. 
>>   Actually, this is the likely case -- if X receives only 
>part of a message
>>   from Y, it is probably because there was some disruption 
>in the communication
>>   -- and this same disruption will likely be a barrier for 
>the sender to
>>   "learn" anything at all about the outcome of its transmission.
>
>Yes.  I am increasingly skeptical about including reactive 
>fragmentation -- and in fact any kind of fragmentation at all 
>-- as a Bundling function.  I'm hoping to have time this 
>afternoon to lay out my whole argument on this, in yet another 
>interminable email.
>
>> * Section 3.9 what does it mean for DTN nodes to "share an edge"
>
>It means they are the two vertices on which the edge is incident.
>
>> * Section 3.10, can ACKs be aggregated or piggybacked 
>opportunistically?
>
>They currently are not.  Worth discussing.
>
>> * Section 3.11, seems the use of seconds for expiration 
>presupposes the
>>   use of DTN in high delay environments, and precludes 
>applications to 
>>   high-speed optical networks (or computer interconnects), and other
>>   distributed applications, where custody transfers and data 
>expiration 
>>   may indeed happen at faster timescales.
>> 
>>   Why should not DTN scale _down_ in delays and 
>disconnections the same
>>   way it scales up?
>
>I think it's because we haven't identified a need to do so.  
>This was mentioned earlier; again, I don't understand the 
>issue or its significance.
>
>> * Section 3.12. Congestion control. We are not sure if 
>congestion control 
>>   should be considered within this architecture. Presumably, 
>DTN is deployed 
>>   in a network where only a (small?) subset of the nodes are 
>DTN capable (DTN
>>   routers/nodes).
>
>Not necessarily; they may well all be DTN agents.  But I don't 
>think this is relevant: you need to do something to minimize 
>data loss due to resource oversubscription at bundle agents 
>functioning as routers, no matter how many of them you have.
>
>    Thus there may be plenty of other traffic that DTN has no
>>   control over. Congestion is a network-layer/MAC layer 
>phenomenon and best
>>   controlled there.
>
>But Bundling *is* at network layer, in the overlay network.
>
>    No matter what we do at the DTN layer, it will be of no
>>   avail if other applications/protocols using the underlying 
>network blast 
>>   away to glory.
>
>I'm not sure I understand your point, but I suspect I 
>disagree.  I've got a Bundling congestion control system 
>implemented and it seems to work pretty well; Esther and I are 
>trying frantically to get a paper on it ready in time for the 
>SIGCOMM workshop.
>
>> * Section 3.12. Flow control for solving the congestion 
>control. This only
>>   works even partially if the receiver capacity is lower or 
>equal to the 
>>   capacity of the intermediate nodes -- may not be a 
>realistic assumption, 
>>   especially in a tactial military environment where the 
>bundle may have 
>>   to go over multiple wireless hops.
>
>Again, I'm not sure I understand your point.  We should 
>probably spend a few moments discussing the way I've got it 
>implemented.
>
>> * Section 3.13, The security architecture (based on checking 
>at edges) may 
>>   be challenged by mobility, especially of the edges. What 
>if the edges of 
>>   the network are continuously redefined due to mobility?
>
>Right, we are all agreed that a lot of security issues remain 
>to be nailed down.
>
>> * Section 4.3 makes a critical point regarding state versus protocol
>>   behavior and the possibility of state being shared across 
>protocols.
>>   A corollary of this sattement is the need to identify information
>>   models for sharing (and storing) routing, forwarding, and name
>>   resolution state.
>
>I would expect these models to be identified in the course of 
>developing the relevant protocols; I think this stuff is too 
>low-level for the architecture document.
> 
>> * Section 5, For disruption tolerance, the application 
>structuring issues 
>>   must include cases where the DTN node where the 
>application is registered
>>   is mobile or is otherwise soon to be disconnected (and 
>needs to transfer 
>>   custody of the registration).
>
>Mobility of registration is a concept we haven't discussed at 
>all yet, as far as I know, and I'm not yet convinced of its 
>utility.  Again, the whole question of mobility needs more 
>work.  It may be "just" a routing problem.
>> 
>> * Section 5, application needs to be better defined -- are 
>they strictly 
>>   point-to-point or can aplication endpoints reside in a distributed 
>>   manner (anycast or multicast basis) in the delay tolerant network
>
>We don't yet have any definition of DTN multipoint delivery 
>service that would encompass anycast or multicast.  We are all 
>agreed that we need such a definition, but it's not ready yet.
>
>> * Section 6 should list mandatory requirements for the 
>convergence layers
>>   in terms of what services they must provide to the bundle layer.
>
>I think the Bundling spec is the right place for this; it's 
>too low-layer for the architecture document.
>
>> * DTN has some goals similar to X.400; the X.400 delivery 
>service classes 
>>   are worth evaluating in this context (a citation of X.400 
>is appropriate 
>>   as relevant prior work)
>
>Sure.
>
>> * Consider the terminology "hold-and-forward" to distinguish 
>from the 
>>   usage elsewhere of "store-and-forward" to mean "queue-and-forward"
>
>But I don't think a distinction needs to be drawn; I think 
>they're the same.  It's just a matter of degree: how much can 
>be queued, how long data may need to be held in the queue, and 
>possibly whether or not it's advisable to manage the queues in 
>non-volatile storage rather than in DRAM.
>
>> * Consider the terminology "data hauling" to the case where mobility
>>   is exploited for delivery e.g. data mules, message ferries, ...
>
>Sure, an interesting suggestion.
>
>> Comments on the Bundle Protocol Specification 
>> =============================================
>> 
>> * Scope: The comments in this section refer specifically to the text
>>   contained in draft-irtf-dtnrg-bundle-spec-02.txt
>> 
>> * This document is well written.  In particular, the format used to 
>>   describe the primitives and their semantics aids the understanding
>>   of the document.
>
>Thanks!
>
>> * The term interface is never defined rigorously and is used 
>in multiple
>>   contexts such as a software/service interface or a network 
>interface.
>>   This should be done in the introduction.
>
>Good point.
>
>> * The endpoint ID terminology differs from what is used in 
>the architecture.
>>   For example, the architecture indicates that a node must 
>have at least one 
>>   MEI, but allows multiple MEIs per node; we think the MEI 
>maps to the Agent 
>>   administration endpoint ID in the bundle protocol specification,
>
>Yes, we need to resolve this terminology issue.
>
>>   which seems to suggest that there is exactly one agent 
>administration endpoint ID.
>
>Not a conflict, but we should clarify: each "interface" has an 
>administrative endpoint ID in the same way that each network 
>interface card in an IP-based network has its own IP address.
>
>> * Does the endpoint ID apply to the node or the interface?   Appears
>>   to be the former but worth clarifying.
>
>Nope, the latter.  Which leaves open a question: what's the ID 
>of the node as a whole?  We don't really have such a notion in 
>the architecture, which I think is kind of ugly, but again I 
>believe it's analogous to what we do in the IP world: if 
>you've got a multi-homed host, which interface's DNS name 
>(mapping to its unique IP address) do you use as the "hostname"?
>
>> * Name Mobility: Is the communications endpoint ID allowed 
>to move from 
>>   node to node?  If so, what state related to the registration (e.g. 
>>   bundles waiting to be delivered, the "delivery failure" 
>action) MUST/
>>   SHOULD/MAY be migrated? 
>> 
>>   In other words, can nodes transfer custody of a 
>"registration"?  (As an 
>>   analogy consider arguments for and against TCP session migration.)
>
>Again, I don't think we've contemplated this in the 
>architecture.  Worth discussing.
>
>>   Treating the registration as an "active mailbox" object 
>may be a useful
>>   metaphor here.
>> 
>>   This may be a larger issue here related to the 
>relinquishment of name
>>   bindings by individual nodes.
>> 
>> * Can the CancelBundle.request (sometimes aliased to Cancel.request)
>
>An error.
>
>>   only apply if the bundle is locally stored?
>
>Yes.
>
>    For example, upon a cancel request
>>   can a node launch a "k-hop trace and delete" on a pattern 
>of bundles that 
>>   were sent earlier?  This will be useful to purge 
>bundles/replicas with 
>>   large expiration times (that have either been delivered or 
>canceled)?
>
>Yes, we've discussed the possibility of flooding the network 
>with "kill packets" to accomplish this kind of thing.  I'm 
>doubtful that there's a lot of advantage in it.
>
>> * The hash carried by bundles in the security header can 
>have other uses.
>>   For example, this hash can be used to populate say a Bloom 
>filter on en 
>>   route nodes for traceback.
>
>Cool.
>
>> * What happens to any bundles that arrive between 
>registration and start 
>>   delivery?   Does the default delivery action go into 
>effect automatically
>>   upon registration?
>
>Yes.
>
>>   It may be useful to point out that there is a distinct 
>poll mode (active 
>>   reception?) when passive reception is first introduced.
>
>Sure.
>
>> * What happens to bundles that arrive after a 
>deregister.request?  We assume
>>   they MUST be discarded.
>
>Yes, at that point there is no endpoint to deliver them to.  
>It's as if the bundles were mis-addressed from the beginning.
>
>> * MUST the SENDERROR.INDICATION always include the 
>application data unit?
>
>Conceptually, yes, so that the application can resend or 
>whatever.  This is an abstract service spec, so how you 
>accomplish this is entirely a matter of implementation.
>
>> * For the administrative part of the endpoint ID, some 
>rationale is required 
>>   regarding why 8-bit, 16-bit, and URIs are supported in 
>particular?  Why is
>>   URI not sufficient?  Why not 32-bit or 48-bit?
>
>We need to support extremely small bundle headers for some 
>environments; that rules out URIs.  I think we worked out that 
>the minimum legal length for a URI was 3 bytes, so 8-bit and 
>16-bit endpoint IDs were available for this alternative 
>purpose.  32-bit and 48-bit numeric endpoint IDs might be 
>indistinguishable from legal 4-byte and 6-byte URIs; by 
>confining ourselves to the smaller numbers we can use endpoint 
>ID length to disambiguate.
>
>> * A generic user-defined experimental header mechanism 
>(syntax and semantics
>>   for nodes not implementing that header) is needed in order 
>to enable 
>>   experimentation.
>
>Yes, we agreed on this at the last DTNRG meeting.
>
>> * A source routing header extension will be useful.
>
>Yes, we agreed to think about this too.
>
>> * Since the dictionary header only allows 16 strings, and 
>since there can
>>   be only one header of each type, it appears that extension 
>headers will 
>>   need their own dictionaries.  For example, consider a 
>17-hop source route.
>
>I'd say just carry the strings themselves in the extension 
>headers.  The strings aren't so likely to be 
>multiply-referenced, so a dictionary doesn't buy you much.
>
>> * It appears that generating a unique ID based purely on the creation
>>   timestamp and endpointID may cause problems.  A node with 
>concurrent 
>>   embedded processors may be able to generate more than one 
>bundle per 
>>   clock tick.  Therefore, an additional sequence counter may 
>be needed.
>
>Right, we've agreed that the "fraction" part of the timestamp 
>can be a monotonically increasing counter within second.
>
>> * It is desirable to use the same style in Section 4 as in Section 2 
>>   (i.e. explicitly call out primitives and desribe their semantics).
>
>This section is Procedure, not abstract Service, so it's not 
>exactly the same.  But you're right, we could start off with 
>some useful semantic clarifications.
>
>> * When a bundle is discarded (in Section 4.2) due to authentication 
>>   failure, can the report to the adminsitrative endpoint contain a
>>   copy of the inauthentic bundle or not?  Since the bundle 
>is otherwise 
>>   discarded and not processed further, this copy is 
>potentially useful 
>>   for instrumenting various security mechanisms.
>
>Currently this doesn't happen.  Worth discussing.
>
>> * There is a potential for denial-of-service attacks that make use
>>   of the report-to field. This is a problem in a DTN since 
>the sender 
>>   can legitimately be disconnected and vanish.  Has the report-to 
>>   third party have any say in the matter?  For example, does the
>>   bundle carry any credentials from the report-to?
>
>Denial of service in general is a nightmare.  The only real 
>defense we've got, I think, is bundle authentication ("mutual 
>suspicion" among bundle agents).
>
>> * In the bundle fragmentation section, it is assumed that the sending
>>   agent "knows" when a transmission is terminated before the 
>entire payload 
>>   has been transmitted.  Is this (signaling of partial 
>transmission) an 
>>   explicit requirement for a DTN convergence layer?
>
>It has been but, again, I am increasingly doubtful.
>
>> * Currently, the fragmentation information carried in the 
>headers do not 
>>   provide for redundant encodings of the fragments -- i.e. 
>to indicate 
>>   how the bundle was fragmented and erasure-coded.  Yet one 
>may wish to
>>   apply these codes precisely when there is fragmentation.
>> 
>>   In the current architecture, erasure or digital fountain 
>type encoding 
>>   must occur either below the convergence layer (which means 
>the protection
>>   cannot cross multiple networks), or end to end at the 
>application which
>>   means the application cannot selectively erasure-code only 
>when there
>>   is fragmentation.
>
>Right, the whole question of fragmentation is a bag of snakes, 
>and always has been.  I will write more on this later today if 
>I have time.
>
>> * In Table 5 there is no way to indicate that a bundle was received
>>   in error, but was or was not reconstructable (using the erasure 
>>   coding). Such a feedback will aid in adjusting the strength of the
>>   code.
>
>I think this belongs at a layer above Bundling, in the same 
>way that Digital Fountain lives above IP.  But I know we don't 
>have consensus on this.
>
>> Anticipated Requirements / Areas for Possible Draft Proposals  
>> =============================================================
>> 
>> * Experimental headers: Our SPINDLE project will use the 
>bundle as the 
>>   means of message encapsulation, however, we will require 
>the ability 
>>   to add and experiment with additional headers.  We request 
>that a user
>>   definable experimental header mechanism be added to the bundle
>>   protocol specification.  In particular, we anticipate the need for 
>>   extension headers to:
>> 
>>   - support braid-spray routing
>>   - carry name resolution hints  
>>   - carry resource accounting tokens 
>>   - support management tasks such as bundle traceback, proactive 
>>     distributed purge of canceled or delivered bundles (as opposed 
>>     to waiting in storage until bundle expiration).
>>   - possibly others
>
>Sure.
>
>> * Interpretation of names: We expect we will require a 
>modest change to 
>>   the DTNRG architecture to allow any region to interpret 
>(but not modify) 
>>   the "opaque" A part of the {R,A} tuple that constitutes a 
>DTNRG name.  
>>   Related modifiable information (e.g. resolution hints) may 
>be carried in 
>>   a late binding header that we may specify.  We anticipate 
>that the unique 
>>   part of our supername will map to the DTNRG name syntax.
>
>No longer an issue, I think.
>
>> * Region interpretation: We anticipate that the routing and 
>late binding
>>   frameworks developed within the DARPA DTN program to 
>support tactical 
>>   mobility may each interpret and use regions differently 
>(e.g. what is 
>>   a region, who owns/administers a region, mobility of nodes across 
>>   regions, mobility of regions themselves, and sub-region 
>partitioning).
>
>I think this is now moot.
>
>> * We anticipate the DTN program will propose new frameworks 
>for bundle 
>>   routing (family of routing protocols) and delayed 
>resolution of names.
>>   We anticipate we will generate specifications of 
>information models for 
>>   storing and sharing topology, adjacency, reachability, and 
>name resolution 
>>   across nodes and across algorithms.
>
>Sure.
>
>> * To facilitate regular DTN-DTNRG interaction, a monthly 
>teleconference
>>   between the DTN and DTNRG to address DTN-specific issues will be 
>>   beneficial.
>
>Yes.
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
Date: Fri, 1 Apr 2005 14:28:22 -0500
From: "Durst,Robert C." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I'm still not sure we have consensus on this.  Some of us feel that regions are very much -in- the picture, both for routing and information containment.  We need to know how we're going to aggregate routing information and deal with the case where we need to make a *real* routing decision without having to go to some sort of 'resolution server'.

Bob and Keith

Robert C. Durst

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Fri Apr 01 14:10:29 2005
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project

Scott,

Thank you for your detailed responses. I will share read them with my
group.

You mentioned that "regions are out of the picture". Would you have any 
writeup on the what the current DTNRG thoughts are regarding naming.

Best Regards,
Rajesh

> 
> Rajesh, I'm sorry it has taken me so long to respond to your comments; it's been a month of everything being top-priority at the same time, so reflecting on DTN architecture and the bundling protocol unfortunately slipped to second priority.
> 
> Some remarks in-line below.
> 
> Scott
> 
> Rajesh Krishnan wrote:
> > ...............................................................................
> > Comments on DTN Architecture 
> > ============================
> > 
> > * Scope: The comments in this section refer specifically to the text 
> >   contained in draft-irtf-dtnrg-arch-02.txt
> > 
> > * Overall: The following aspects have not received adequate treatment
> >   in the architecture:
> > 
> >   - Mobility
> 
> I think we're all agreed on this.
> 
> >     o especially, node mobility between regions and region mobility
> 
> But this particular aspect of the problem may have disappeared, now that we're moving away from preserving any formal "region" notion in the architecture.
> 
> >   - Management
> >     o ownership and administrative boundaries for nodes and regions
> 
> I guess ownership of nodes remains an issue of some sort, but why is it an issue that needs to be addressed in the Architecture document?
> 
> >     o instrumentation of DTN nodes for observing and controlling remote
> >       network state
> >     o error conditions at a node such as a persistent store failure
> >     o declarative (external) specification and enforcement of policies
> 
> I think all of these may be important, but I don't think any of them should be addressed in the Architecture document.  They are low-level and protocol-specific, and in some cases implementation-specific.
> 
> >   - Disruptions occurring at short timescales (the focus is on tolerance 
> >     to delays at large timescales)
> 
> Right, we spent a little time on this at the meeting.  I still don't understand the issue or its significance.  What is the unsolved problem here, and why is DTN the right instrument for solving it?
> 
> > * The abstract defines the delay tolerant network as an "overlay that 
> >   exists above the transport layer."  It appears that there is nothing
> >   in the architecture that fundamentally requires a DTN to be overlaid
> >   over the transport layer of the underlying network.
> 
> Right, we could say "exists, notionally, above the transport layer."  Could be above some other transmission layer which, strictly speaking, doesn't even necessarily have to be reliable [though if it isn't then you don't have a lot of reliability in your network; in the general case, custodial retransmission is not a mechanism you want to count on as your primary guarantor of reliability in a delay-tolerant network].
> 
> >   On the other hand, there appear to be some _implicit_ service requirements 
> >   assumed for the underlying network.  These requirements may be typically 
> >   satisfied by the transport layer  in an IP network, but it is not clear 
> >   the same holds for other networks.  These assumptions must be made explicit 
> >   irrespective of which layer of the underlying network DTN is overlaid upon.
> 
> Very good point.
>   
> >   Since DTN is an overlay, the underlying network appears to the DTN to be 
> >   a (more capable) link layer rather than a transport layer, and DTN needs 
> >   to implement functionality (e.g. routing) typically associated with the 
> >   network layer.
> 
> Except that, to DTN, TCP/IP looks like a link layer system, while to the rest of the world it looks like transport.
> 
> The alien concept here, I think, is that "network-ness" and "link-ness" are *relative* rather than absolute.  The OSI 7-layer model encourages us to think of a particular element of communication functionality having an absolute location in the stack, rather than articulating more general principles of layer dependency (relative location in the stack) that would help us make more sense of this stuff.  It may be that, while the layering notion itself is still very valuable [I am old-fashioned and think it is; I realize there is dissent], it's time to move on to a more powerful and general model of layering.
> 
> TCP/IP is to Bundling as Ethernet is to IP -- except that Bundling typically needs its underlying "Ethernet" to be more reliable, so maybe it's more accurate to say that TCP/IP is to Bundling as Ethernet with (say) Type 3 LLC is to IP.
> 
> >   We suggest generalizing this statement to "overlay that exists above any 
> >   layer of an underlying network that provides the <enumerated> capabilities 
> >   (possibly through a convergence sublayer)".
> 
> Yes, something like that, except that I would omit the parenthetical clause.  I think there is *always* a convergence sublayer in any DTN implementation, and in fact I suspect there is always one in any IP implementation; it's just that in the IP world that convergence layer is sometimes formally identified, exposed, and documented (e.g., the VxWorks "MUX" layer) and sometimes not.
> 
> > * In Section 3.1 it is not clear whether aggregation of bundles is allowed.
> 
> I think there's a pretty clear statement that a bundle encapsulates a "message" and that messages are atomic, but maybe that could be emphasized.  There currently is no provision for a bundle agent aggregating multiple messages into its (single) payload; is that what you're thinking of?  What advantage would this offer?
> > 
> > * Section 3.2, assumptions 1-3. Assumptions (1) and (2) are not generally
> >   valid for tactical military networks -- a large application area seeking
> >   this technology. Storage is neither plentiful nor well-distributed. 
> >   However, it is not clear that the *architecture* per se *needs* 
> >   assumption 1.  Within this architecture, one could build routing 
> >   mechanisms that perform coordinated, distributed storage.
> 
> I think these assumptions still hold, if we agree that "plentiful" and "well-distributed" are relative terms.  Deferred transmission requires storage.  If each node has enough storage [somewhere] to accomplish whatever transmission deferral it needs to do in order to be a viable bundle agent, then we can think of its storage as plentiful and well-distributed; if not, then you have got a busted delay-tolerant network.
> 
> > * Sec 3.2. Bulk/Normal/Expedited classes. Is the treatment on a per-next-hop 
> >   basis? Can one give a Bulk bundle destined for the south pole to a contact 
> >   headed south while the queue contains an Expedited bundle destined for the 
> >   north pole? we guess the answer is yes, but it is not entirely clear from 
> >   the text.
> 
> Good clarification.
> 
> > * In Section 3.3 it is not clear whether the transferrer or transferee 
> >   generates the custody transfer indication.
> 
> The transferee (receiver) generates the report -- it's the only entity that has sufficient information to do so, as it's the only one that knows the custody transfer was successfully completed.
> 
>     Also if these indications
> >   are all sent to the report-to node, then how many reports per bundle
> >   does it receive?  Will this scale?  Can reports be aggregated or
> >   piggybacked opportunistically or not?
> 
> These indications are designed for tracing and network performance analysis, and they are issued on an as-needed per-bundle basis; you can (and usually do) have custody transfer without them.  If they were requested on every single custodial bundle then you might indeed have a scaling problem, but that would be bad practice; maybe we should legislate against this, maybe not, I dunno.
> 
> > * In Section 3.3, for the expiration time and the curent time of day, 
> >   what is the reference?  Will GMT / Earth time be used in the IPN?
> 
> Yes, there will be some single Earth-based time reference, maybe UTC; JPL, at least, already operates this way.
> 
> > * Sec 3.4/3.5. Does the notion of a region include hierarchical nesting in a
> >   topologically significant way? That is, can the "A" in (R,A) turn contain an 
> >   (R1,A1) and so on?
> 
> Because "regions" are now out of the picture, I think this question is moot.  The lexical structure of the endpoint ID is now somewhat up in the air, as we discussed in yesterday's DTN telecon, but in any event it's not a tuple.
> 
> > * In Section 3.5, the requirement that "any node not in R1 must treat A 
> >   as "opaque" (i.e. it cannot interpret A)" seems needlessly restrictive.  
> >   It seems sufficient to require that A not be modified outside R1.  To 
> >   support mobility efficiently (and avoid needless telescoping of routes), 
> >   it may become necessary to interpret A (e.g. location hints) outside R1.
> > 
> >   Furthermore, it can be argued that the "name invariance family" in the
> >   Bundle Protocol Specification is indeed an interpretation of A outside 
> >   R1.
> > 
> > * In Section 3.5 "Every node in a region R1 shall have the ability to 
> >   eventually deliver messages to every other node in R1 ..." needs to
> >   be qualified with a "barring a permanent network partition or permananent 
> >   destruction of nodes, and provided the expiration time of the bundle 
> >   exceeds the time the network is partitioned, and there is sufficient
> >   storage in the network."
> > 
> > * Sec. 3.5, assumption 3 ("every node in a region should be able to eventually
> >   deliver to every other node"). Not clear whether this assumption requires 
> >   that the "eventual delivery" be made with or without the use of data 
> >   hauling nodes (DTN  routers). If we cannot use DTN routers within the 
> >   region, then this seriously limits the applicability of this
> >   architecture to the tactical military environment. For instance, the region
> >   could be a brigade with HMMMVs, soldiers, UAVs etc. A brigade could be
> >   partitioned with UAV or helicopters doing the data hauling. In such a case
> >   we need a few DTN routers within the region. On the other hand, if 
> >   DTN routers can be used to heal such partitions within a region, it is 
> >   not clear how the addressing scheme will work.
> 
> I think all three of these points are now moot.
> 
> > * In Section 3.8 "graph" is used to mean "multi-graph".
> 
> Yes.
> 
> > * Section 3.8.1. Types of contacts. How is contact volatility managed?
> >   When you lose contact, you are not sure whether it is "still out there" or
> >   "gone". In other words, do you envisage the use of a link up/down protocol
> >   like in OSPF or MANETs to "maintain" contacts.  Is this function at the 
> >   bundle layer or in the convergence layer?
> 
> I would say this is always at the convergence layer, because the way you do it may be dependent on the nature of the underlying protocols.  But we may not have consensus on this yet.
> 
> > * Sec. 3.9, Reactive fragmenting. This implicitly assumes that the sender and
> >   receiver can communicate throughout the message exchange. What if the 
> >   link/subnet-path breaks after receiving part of the message? In this case 
> >   the sender cannot learn that only a portion of the message was received. 
> >   Actually, this is the likely case -- if X receives only part of a message
> >   from Y, it is probably because there was some disruption in the communication
> >   -- and this same disruption will likely be a barrier for the sender to
> >   "learn" anything at all about the outcome of its transmission.
> 
> Yes.  I am increasingly skeptical about including reactive fragmentation -- and in fact any kind of fragmentation at all -- as a Bundling function.  I'm hoping to have time this afternoon to lay out my whole argument on this, in yet another interminable email.
> 
> > * Section 3.9 what does it mean for DTN nodes to "share an edge"
> 
> It means they are the two vertices on which the edge is incident.
> 
> > * Section 3.10, can ACKs be aggregated or piggybacked opportunistically?
> 
> They currently are not.  Worth discussing.
> 
> > * Section 3.11, seems the use of seconds for expiration presupposes the
> >   use of DTN in high delay environments, and precludes applications to 
> >   high-speed optical networks (or computer interconnects), and other
> >   distributed applications, where custody transfers and data expiration 
> >   may indeed happen at faster timescales.
> > 
> >   Why should not DTN scale _down_ in delays and disconnections the same
> >   way it scales up?
> 
> I think it's because we haven't identified a need to do so.  This was mentioned earlier; again, I don't understand the issue or its significance.
> 
> > * Section 3.12. Congestion control. We are not sure if congestion control 
> >   should be considered within this architecture. Presumably, DTN is deployed 
> >   in a network where only a (small?) subset of the nodes are DTN capable (DTN
> >   routers/nodes).
> 
> Not necessarily; they may well all be DTN agents.  But I don't think this is relevant: you need to do something to minimize data loss due to resource oversubscription at bundle agents functioning as routers, no matter how many of them you have.
> 
>     Thus there may be plenty of other traffic that DTN has no
> >   control over. Congestion is a network-layer/MAC layer phenomenon and best
> >   controlled there.
> 
> But Bundling *is* at network layer, in the overlay network.
> 
>     No matter what we do at the DTN layer, it will be of no
> >   avail if other applications/protocols using the underlying network blast 
> >   away to glory.
> 
> I'm not sure I understand your point, but I suspect I disagree.  I've got a Bundling congestion control system implemented and it seems to work pretty well; Esther and I are trying frantically to get a paper on it ready in time for the SIGCOMM workshop.
> 
> > * Section 3.12. Flow control for solving the congestion control. This only
> >   works even partially if the receiver capacity is lower or equal to the 
> >   capacity of the intermediate nodes -- may not be a realistic assumption, 
> >   especially in a tactial military environment where the bundle may have 
> >   to go over multiple wireless hops.
> 
> Again, I'm not sure I understand your point.  We should probably spend a few moments discussing the way I've got it implemented.
> 
> > * Section 3.13, The security architecture (based on checking at edges) may 
> >   be challenged by mobility, especially of the edges. What if the edges of 
> >   the network are continuously redefined due to mobility?
> 
> Right, we are all agreed that a lot of security issues remain to be nailed down.
> 
> > * Section 4.3 makes a critical point regarding state versus protocol
> >   behavior and the possibility of state being shared across protocols.
> >   A corollary of this sattement is the need to identify information
> >   models for sharing (and storing) routing, forwarding, and name
> >   resolution state.
> 
> I would expect these models to be identified in the course of developing the relevant protocols; I think this stuff is too low-level for the architecture document.
>  
> > * Section 5, For disruption tolerance, the application structuring issues 
> >   must include cases where the DTN node where the application is registered
> >   is mobile or is otherwise soon to be disconnected (and needs to transfer 
> >   custody of the registration).
> 
> Mobility of registration is a concept we haven't discussed at all yet, as far as I know, and I'm not yet convinced of its utility.  Again, the whole question of mobility needs more work.  It may be "just" a routing problem.
> > 
> > * Section 5, application needs to be better defined -- are they strictly 
> >   point-to-point or can aplication endpoints reside in a distributed 
> >   manner (anycast or multicast basis) in the delay tolerant network
> 
> We don't yet have any definition of DTN multipoint delivery service that would encompass anycast or multicast.  We are all agreed that we need such a definition, but it's not ready yet.
> 
> > * Section 6 should list mandatory requirements for the convergence layers
> >   in terms of what services they must provide to the bundle layer.
> 
> I think the Bundling spec is the right place for this; it's too low-layer for the architecture document.
> 
> > * DTN has some goals similar to X.400; the X.400 delivery service classes 
> >   are worth evaluating in this context (a citation of X.400 is appropriate 
> >   as relevant prior work)
> 
> Sure.
> 
> > * Consider the terminology "hold-and-forward" to distinguish from the 
> >   usage elsewhere of "store-and-forward" to mean "queue-and-forward"
> 
> But I don't think a distinction needs to be drawn; I think they're the same.  It's just a matter of degree: how much can be queued, how long data may need to be held in the queue, and possibly whether or not it's advisable to manage the queues in non-volatile storage rather than in DRAM.
> 
> > * Consider the terminology "data hauling" to the case where mobility
> >   is exploited for delivery e.g. data mules, message ferries, ...
> 
> Sure, an interesting suggestion.
> 
> > Comments on the Bundle Protocol Specification 
> > =============================================
> > 
> > * Scope: The comments in this section refer specifically to the text
> >   contained in draft-irtf-dtnrg-bundle-spec-02.txt
> > 
> > * This document is well written.  In particular, the format used to 
> >   describe the primitives and their semantics aids the understanding
> >   of the document.
> 
> Thanks!
> 
> > * The term interface is never defined rigorously and is used in multiple
> >   contexts such as a software/service interface or a network interface.
> >   This should be done in the introduction.
> 
> Good point.
> 
> > * The endpoint ID terminology differs from what is used in the architecture.
> >   For example, the architecture indicates that a node must have at least one 
> >   MEI, but allows multiple MEIs per node; we think the MEI maps to the Agent 
> >   administration endpoint ID in the bundle protocol specification,
> 
> Yes, we need to resolve this terminology issue.
> 
> >   which seems to suggest that there is exactly one agent administration endpoint ID.
> 
> Not a conflict, but we should clarify: each "interface" has an administrative endpoint ID in the same way that each network interface card in an IP-based network has its own IP address.
> 
> > * Does the endpoint ID apply to the node or the interface?   Appears
> >   to be the former but worth clarifying.
> 
> Nope, the latter.  Which leaves open a question: what's the ID of the node as a whole?  We don't really have such a notion in the architecture, which I think is kind of ugly, but again I believe it's analogous to what we do in the IP world: if you've got a multi-homed host, which interface's DNS name (mapping to its unique IP address) do you use as the "hostname"?
> 
> > * Name Mobility: Is the communications endpoint ID allowed to move from 
> >   node to node?  If so, what state related to the registration (e.g. 
> >   bundles waiting to be delivered, the "delivery failure" action) MUST/
> >   SHOULD/MAY be migrated? 
> > 
> >   In other words, can nodes transfer custody of a "registration"?  (As an 
> >   analogy consider arguments for and against TCP session migration.)
> 
> Again, I don't think we've contemplated this in the architecture.  Worth discussing.
> 
> >   Treating the registration as an "active mailbox" object may be a useful
> >   metaphor here.
> > 
> >   This may be a larger issue here related to the relinquishment of name
> >   bindings by individual nodes.
> > 
> > * Can the CancelBundle.request (sometimes aliased to Cancel.request)
> 
> An error.
> 
> >   only apply if the bundle is locally stored?
> 
> Yes.
> 
>     For example, upon a cancel request
> >   can a node launch a "k-hop trace and delete" on a pattern of bundles that 
> >   were sent earlier?  This will be useful to purge bundles/replicas with 
> >   large expiration times (that have either been delivered or canceled)?
> 
> Yes, we've discussed the possibility of flooding the network with "kill packets" to accomplish this kind of thing.  I'm doubtful that there's a lot of advantage in it.
> 
> > * The hash carried by bundles in the security header can have other uses.
> >   For example, this hash can be used to populate say a Bloom filter on en 
> >   route nodes for traceback.
> 
> Cool.
> 
> > * What happens to any bundles that arrive between registration and start 
> >   delivery?   Does the default delivery action go into effect automatically
> >   upon registration?
> 
> Yes.
> 
> >   It may be useful to point out that there is a distinct poll mode (active 
> >   reception?) when passive reception is first introduced.
> 
> Sure.
> 
> > * What happens to bundles that arrive after a deregister.request?  We assume
> >   they MUST be discarded.
> 
> Yes, at that point there is no endpoint to deliver them to.  It's as if the bundles were mis-addressed from the beginning.
> 
> > * MUST the SENDERROR.INDICATION always include the application data unit?
> 
> Conceptually, yes, so that the application can resend or whatever.  This is an abstract service spec, so how you accomplish this is entirely a matter of implementation.
> 
> > * For the administrative part of the endpoint ID, some rationale is required 
> >   regarding why 8-bit, 16-bit, and URIs are supported in particular?  Why is
> >   URI not sufficient?  Why not 32-bit or 48-bit?
> 
> We need to support extremely small bundle headers for some environments; that rules out URIs.  I think we worked out that the minimum legal length for a URI was 3 bytes, so 8-bit and 16-bit endpoint IDs were available for this alternative purpose.  32-bit and 48-bit numeric endpoint IDs might be indistinguishable from legal 4-byte and 6-byte URIs; by confining ourselves to the smaller numbers we can use endpoint ID length to disambiguate.
> 
> > * A generic user-defined experimental header mechanism (syntax and semantics
> >   for nodes not implementing that header) is needed in order to enable 
> >   experimentation.
> 
> Yes, we agreed on this at the last DTNRG meeting.
> 
> > * A source routing header extension will be useful.
> 
> Yes, we agreed to think about this too.
> 
> > * Since the dictionary header only allows 16 strings, and since there can
> >   be only one header of each type, it appears that extension headers will 
> >   need their own dictionaries.  For example, consider a 17-hop source route.
> 
> I'd say just carry the strings themselves in the extension headers.  The strings aren't so likely to be multiply-referenced, so a dictionary doesn't buy you much.
> 
> > * It appears that generating a unique ID based purely on the creation
> >   timestamp and endpointID may cause problems.  A node with concurrent 
> >   embedded processors may be able to generate more than one bundle per 
> >   clock tick.  Therefore, an additional sequence counter may be needed.
> 
> Right, we've agreed that the "fraction" part of the timestamp can be a monotonically increasing counter within second.
> 
> > * It is desirable to use the same style in Section 4 as in Section 2 
> >   (i.e. explicitly call out primitives and desribe their semantics).
> 
> This section is Procedure, not abstract Service, so it's not exactly the same.  But you're right, we could start off with some useful semantic clarifications.
> 
> > * When a bundle is discarded (in Section 4.2) due to authentication 
> >   failure, can the report to the adminsitrative endpoint contain a
> >   copy of the inauthentic bundle or not?  Since the bundle is otherwise 
> >   discarded and not processed further, this copy is potentially useful 
> >   for instrumenting various security mechanisms.
> 
> Currently this doesn't happen.  Worth discussing.
> 
> > * There is a potential for denial-of-service attacks that make use
> >   of the report-to field. This is a problem in a DTN since the sender 
> >   can legitimately be disconnected and vanish.  Has the report-to 
> >   third party have any say in the matter?  For example, does the
> >   bundle carry any credentials from the report-to?
> 
> Denial of service in general is a nightmare.  The only real defense we've got, I think, is bundle authentication ("mutual suspicion" among bundle agents).
> 
> > * In the bundle fragmentation section, it is assumed that the sending
> >   agent "knows" when a transmission is terminated before the entire payload 
> >   has been transmitted.  Is this (signaling of partial transmission) an 
> >   explicit requirement for a DTN convergence layer?
> 
> It has been but, again, I am increasingly doubtful.
> 
> > * Currently, the fragmentation information carried in the headers do not 
> >   provide for redundant encodings of the fragments -- i.e. to indicate 
> >   how the bundle was fragmented and erasure-coded.  Yet one may wish to
> >   apply these codes precisely when there is fragmentation.
> > 
> >   In the current architecture, erasure or digital fountain type encoding 
> >   must occur either below the convergence layer (which means the protection
> >   cannot cross multiple networks), or end to end at the application which
> >   means the application cannot selectively erasure-code only when there
> >   is fragmentation.
> 
> Right, the whole question of fragmentation is a bag of snakes, and always has been.  I will write more on this later today if I have time.
> 
> > * In Table 5 there is no way to indicate that a bundle was received
> >   in error, but was or was not reconstructable (using the erasure 
> >   coding). Such a feedback will aid in adjusting the strength of the
> >   code.
> 
> I think this belongs at a layer above Bundling, in the same way that Digital Fountain lives above IP.  But I know we don't have consensus on this.
> 
> > Anticipated Requirements / Areas for Possible Draft Proposals  
> > =============================================================
> > 
> > * Experimental headers: Our SPINDLE project will use the bundle as the 
> >   means of message encapsulation, however, we will require the ability 
> >   to add and experiment with additional headers.  We request that a user
> >   definable experimental header mechanism be added to the bundle
> >   protocol specification.  In particular, we anticipate the need for 
> >   extension headers to:
> > 
> >   - support braid-spray routing
> >   - carry name resolution hints  
> >   - carry resource accounting tokens 
> >   - support management tasks such as bundle traceback, proactive 
> >     distributed purge of canceled or delivered bundles (as opposed 
> >     to waiting in storage until bundle expiration).
> >   - possibly others
> 
> Sure.
> 
> > * Interpretation of names: We expect we will require a modest change to 
> >   the DTNRG architecture to allow any region to interpret (but not modify) 
> >   the "opaque" A part of the {R,A} tuple that constitutes a DTNRG name.  
> >   Related modifiable information (e.g. resolution hints) may be carried in 
> >   a late binding header that we may specify.  We anticipate that the unique 
> >   part of our supername will map to the DTNRG name syntax.
> 
> No longer an issue, I think.
> 
> > * Region interpretation: We anticipate that the routing and late binding
> >   frameworks developed within the DARPA DTN program to support tactical 
> >   mobility may each interpret and use regions differently (e.g. what is 
> >   a region, who owns/administers a region, mobility of nodes across 
> >   regions, mobility of regions themselves, and sub-region partitioning).
> 
> I think this is now moot.
> 
> > * We anticipate the DTN program will propose new frameworks for bundle 
> >   routing (family of routing protocols) and delayed resolution of names.
> >   We anticipate we will generate specifications of information models for 
> >   storing and sharing topology, adjacency, reachability, and name resolution 
> >   across nodes and across algorithms.
> 
> Sure.
> 
> > * To facilitate regular DTN-DTNRG interaction, a monthly teleconference
> >   between the DTN and DTNRG to address DTN-specific issues will be 
> >   beneficial.
> 
> Yes.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

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

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
To: [email-masked] (Scott Burleigh)
Date: Fri, 1 Apr 2005 14:10:29 -0500 (EST)
Cc: [email-masked], [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Scott,

Thank you for your detailed responses. I will share read them with my
group.

You mentioned that "regions are out of the picture". Would you have any 
writeup on the what the current DTNRG thoughts are regarding naming.

Best Regards,
Rajesh

> 
> Rajesh, I'm sorry it has taken me so long to respond to your comments; it's been a month of everything being top-priority at the same time, so reflecting on DTN architecture and the bundling protocol unfortunately slipped to second priority.
> 
> Some remarks in-line below.
> 
> Scott
> 
> Rajesh Krishnan wrote:
> > ...............................................................................
> > Comments on DTN Architecture 
> > ============================
> > 
> > * Scope: The comments in this section refer specifically to the text 
> >   contained in draft-irtf-dtnrg-arch-02.txt
> > 
> > * Overall: The following aspects have not received adequate treatment
> >   in the architecture:
> > 
> >   - Mobility
> 
> I think we're all agreed on this.
> 
> >     o especially, node mobility between regions and region mobility
> 
> But this particular aspect of the problem may have disappeared, now that we're moving away from preserving any formal "region" notion in the architecture.
> 
> >   - Management
> >     o ownership and administrative boundaries for nodes and regions
> 
> I guess ownership of nodes remains an issue of some sort, but why is it an issue that needs to be addressed in the Architecture document?
> 
> >     o instrumentation of DTN nodes for observing and controlling remote
> >       network state
> >     o error conditions at a node such as a persistent store failure
> >     o declarative (external) specification and enforcement of policies
> 
> I think all of these may be important, but I don't think any of them should be addressed in the Architecture document.  They are low-level and protocol-specific, and in some cases implementation-specific.
> 
> >   - Disruptions occurring at short timescales (the focus is on tolerance 
> >     to delays at large timescales)
> 
> Right, we spent a little time on this at the meeting.  I still don't understand the issue or its significance.  What is the unsolved problem here, and why is DTN the right instrument for solving it?
> 
> > * The abstract defines the delay tolerant network as an "overlay that 
> >   exists above the transport layer."  It appears that there is nothing
> >   in the architecture that fundamentally requires a DTN to be overlaid
> >   over the transport layer of the underlying network.
> 
> Right, we could say "exists, notionally, above the transport layer."  Could be above some other transmission layer which, strictly speaking, doesn't even necessarily have to be reliable [though if it isn't then you don't have a lot of reliability in your network; in the general case, custodial retransmission is not a mechanism you want to count on as your primary guarantor of reliability in a delay-tolerant network].
> 
> >   On the other hand, there appear to be some _implicit_ service requirements 
> >   assumed for the underlying network.  These requirements may be typically 
> >   satisfied by the transport layer  in an IP network, but it is not clear 
> >   the same holds for other networks.  These assumptions must be made explicit 
> >   irrespective of which layer of the underlying network DTN is overlaid upon.
> 
> Very good point.
>   
> >   Since DTN is an overlay, the underlying network appears to the DTN to be 
> >   a (more capable) link layer rather than a transport layer, and DTN needs 
> >   to implement functionality (e.g. routing) typically associated with the 
> >   network layer.
> 
> Except that, to DTN, TCP/IP looks like a link layer system, while to the rest of the world it looks like transport.
> 
> The alien concept here, I think, is that "network-ness" and "link-ness" are *relative* rather than absolute.  The OSI 7-layer model encourages us to think of a particular element of communication functionality having an absolute location in the stack, rather than articulating more general principles of layer dependency (relative location in the stack) that would help us make more sense of this stuff.  It may be that, while the layering notion itself is still very valuable [I am old-fashioned and think it is; I realize there is dissent], it's time to move on to a more powerful and general model of layering.
> 
> TCP/IP is to Bundling as Ethernet is to IP -- except that Bundling typically needs its underlying "Ethernet" to be more reliable, so maybe it's more accurate to say that TCP/IP is to Bundling as Ethernet with (say) Type 3 LLC is to IP.
> 
> >   We suggest generalizing this statement to "overlay that exists above any 
> >   layer of an underlying network that provides the <enumerated> capabilities 
> >   (possibly through a convergence sublayer)".
> 
> Yes, something like that, except that I would omit the parenthetical clause.  I think there is *always* a convergence sublayer in any DTN implementation, and in fact I suspect there is always one in any IP implementation; it's just that in the IP world that convergence layer is sometimes formally identified, exposed, and documented (e.g., the VxWorks "MUX" layer) and sometimes not.
> 
> > * In Section 3.1 it is not clear whether aggregation of bundles is allowed.
> 
> I think there's a pretty clear statement that a bundle encapsulates a "message" and that messages are atomic, but maybe that could be emphasized.  There currently is no provision for a bundle agent aggregating multiple messages into its (single) payload; is that what you're thinking of?  What advantage would this offer?
> > 
> > * Section 3.2, assumptions 1-3. Assumptions (1) and (2) are not generally
> >   valid for tactical military networks -- a large application area seeking
> >   this technology. Storage is neither plentiful nor well-distributed. 
> >   However, it is not clear that the *architecture* per se *needs* 
> >   assumption 1.  Within this architecture, one could build routing 
> >   mechanisms that perform coordinated, distributed storage.
> 
> I think these assumptions still hold, if we agree that "plentiful" and "well-distributed" are relative terms.  Deferred transmission requires storage.  If each node has enough storage [somewhere] to accomplish whatever transmission deferral it needs to do in order to be a viable bundle agent, then we can think of its storage as plentiful and well-distributed; if not, then you have got a busted delay-tolerant network.
> 
> > * Sec 3.2. Bulk/Normal/Expedited classes. Is the treatment on a per-next-hop 
> >   basis? Can one give a Bulk bundle destined for the south pole to a contact 
> >   headed south while the queue contains an Expedited bundle destined for the 
> >   north pole? we guess the answer is yes, but it is not entirely clear from 
> >   the text.
> 
> Good clarification.
> 
> > * In Section 3.3 it is not clear whether the transferrer or transferee 
> >   generates the custody transfer indication.
> 
> The transferee (receiver) generates the report -- it's the only entity that has sufficient information to do so, as it's the only one that knows the custody transfer was successfully completed.
> 
>     Also if these indications
> >   are all sent to the report-to node, then how many reports per bundle
> >   does it receive?  Will this scale?  Can reports be aggregated or
> >   piggybacked opportunistically or not?
> 
> These indications are designed for tracing and network performance analysis, and they are issued on an as-needed per-bundle basis; you can (and usually do) have custody transfer without them.  If they were requested on every single custodial bundle then you might indeed have a scaling problem, but that would be bad practice; maybe we should legislate against this, maybe not, I dunno.
> 
> > * In Section 3.3, for the expiration time and the curent time of day, 
> >   what is the reference?  Will GMT / Earth time be used in the IPN?
> 
> Yes, there will be some single Earth-based time reference, maybe UTC; JPL, at least, already operates this way.
> 
> > * Sec 3.4/3.5. Does the notion of a region include hierarchical nesting in a
> >   topologically significant way? That is, can the "A" in (R,A) turn contain an 
> >   (R1,A1) and so on?
> 
> Because "regions" are now out of the picture, I think this question is moot.  The lexical structure of the endpoint ID is now somewhat up in the air, as we discussed in yesterday's DTN telecon, but in any event it's not a tuple.
> 
> > * In Section 3.5, the requirement that "any node not in R1 must treat A 
> >   as "opaque" (i.e. it cannot interpret A)" seems needlessly restrictive.  
> >   It seems sufficient to require that A not be modified outside R1.  To 
> >   support mobility efficiently (and avoid needless telescoping of routes), 
> >   it may become necessary to interpret A (e.g. location hints) outside R1.
> > 
> >   Furthermore, it can be argued that the "name invariance family" in the
> >   Bundle Protocol Specification is indeed an interpretation of A outside 
> >   R1.
> > 
> > * In Section 3.5 "Every node in a region R1 shall have the ability to 
> >   eventually deliver messages to every other node in R1 ..." needs to
> >   be qualified with a "barring a permanent network partition or permananent 
> >   destruction of nodes, and provided the expiration time of the bundle 
> >   exceeds the time the network is partitioned, and there is sufficient
> >   storage in the network."
> > 
> > * Sec. 3.5, assumption 3 ("every node in a region should be able to eventually
> >   deliver to every other node"). Not clear whether this assumption requires 
> >   that the "eventual delivery" be made with or without the use of data 
> >   hauling nodes (DTN  routers). If we cannot use DTN routers within the 
> >   region, then this seriously limits the applicability of this
> >   architecture to the tactical military environment. For instance, the region
> >   could be a brigade with HMMMVs, soldiers, UAVs etc. A brigade could be
> >   partitioned with UAV or helicopters doing the data hauling. In such a case
> >   we need a few DTN routers within the region. On the other hand, if 
> >   DTN routers can be used to heal such partitions within a region, it is 
> >   not clear how the addressing scheme will work.
> 
> I think all three of these points are now moot.
> 
> > * In Section 3.8 "graph" is used to mean "multi-graph".
> 
> Yes.
> 
> > * Section 3.8.1. Types of contacts. How is contact volatility managed?
> >   When you lose contact, you are not sure whether it is "still out there" or
> >   "gone". In other words, do you envisage the use of a link up/down protocol
> >   like in OSPF or MANETs to "maintain" contacts.  Is this function at the 
> >   bundle layer or in the convergence layer?
> 
> I would say this is always at the convergence layer, because the way you do it may be dependent on the nature of the underlying protocols.  But we may not have consensus on this yet.
> 
> > * Sec. 3.9, Reactive fragmenting. This implicitly assumes that the sender and
> >   receiver can communicate throughout the message exchange. What if the 
> >   link/subnet-path breaks after receiving part of the message? In this case 
> >   the sender cannot learn that only a portion of the message was received. 
> >   Actually, this is the likely case -- if X receives only part of a message
> >   from Y, it is probably because there was some disruption in the communication
> >   -- and this same disruption will likely be a barrier for the sender to
> >   "learn" anything at all about the outcome of its transmission.
> 
> Yes.  I am increasingly skeptical about including reactive fragmentation -- and in fact any kind of fragmentation at all -- as a Bundling function.  I'm hoping to have time this afternoon to lay out my whole argument on this, in yet another interminable email.
> 
> > * Section 3.9 what does it mean for DTN nodes to "share an edge"
> 
> It means they are the two vertices on which the edge is incident.
> 
> > * Section 3.10, can ACKs be aggregated or piggybacked opportunistically?
> 
> They currently are not.  Worth discussing.
> 
> > * Section 3.11, seems the use of seconds for expiration presupposes the
> >   use of DTN in high delay environments, and precludes applications to 
> >   high-speed optical networks (or computer interconnects), and other
> >   distributed applications, where custody transfers and data expiration 
> >   may indeed happen at faster timescales.
> > 
> >   Why should not DTN scale _down_ in delays and disconnections the same
> >   way it scales up?
> 
> I think it's because we haven't identified a need to do so.  This was mentioned earlier; again, I don't understand the issue or its significance.
> 
> > * Section 3.12. Congestion control. We are not sure if congestion control 
> >   should be considered within this architecture. Presumably, DTN is deployed 
> >   in a network where only a (small?) subset of the nodes are DTN capable (DTN
> >   routers/nodes).
> 
> Not necessarily; they may well all be DTN agents.  But I don't think this is relevant: you need to do something to minimize data loss due to resource oversubscription at bundle agents functioning as routers, no matter how many of them you have.
> 
>     Thus there may be plenty of other traffic that DTN has no
> >   control over. Congestion is a network-layer/MAC layer phenomenon and best
> >   controlled there.
> 
> But Bundling *is* at network layer, in the overlay network.
> 
>     No matter what we do at the DTN layer, it will be of no
> >   avail if other applications/protocols using the underlying network blast 
> >   away to glory.
> 
> I'm not sure I understand your point, but I suspect I disagree.  I've got a Bundling congestion control system implemented and it seems to work pretty well; Esther and I are trying frantically to get a paper on it ready in time for the SIGCOMM workshop.
> 
> > * Section 3.12. Flow control for solving the congestion control. This only
> >   works even partially if the receiver capacity is lower or equal to the 
> >   capacity of the intermediate nodes -- may not be a realistic assumption, 
> >   especially in a tactial military environment where the bundle may have 
> >   to go over multiple wireless hops.
> 
> Again, I'm not sure I understand your point.  We should probably spend a few moments discussing the way I've got it implemented.
> 
> > * Section 3.13, The security architecture (based on checking at edges) may 
> >   be challenged by mobility, especially of the edges. What if the edges of 
> >   the network are continuously redefined due to mobility?
> 
> Right, we are all agreed that a lot of security issues remain to be nailed down.
> 
> > * Section 4.3 makes a critical point regarding state versus protocol
> >   behavior and the possibility of state being shared across protocols.
> >   A corollary of this sattement is the need to identify information
> >   models for sharing (and storing) routing, forwarding, and name
> >   resolution state.
> 
> I would expect these models to be identified in the course of developing the relevant protocols; I think this stuff is too low-level for the architecture document.
>  
> > * Section 5, For disruption tolerance, the application structuring issues 
> >   must include cases where the DTN node where the application is registered
> >   is mobile or is otherwise soon to be disconnected (and needs to transfer 
> >   custody of the registration).
> 
> Mobility of registration is a concept we haven't discussed at all yet, as far as I know, and I'm not yet convinced of its utility.  Again, the whole question of mobility needs more work.  It may be "just" a routing problem.
> > 
> > * Section 5, application needs to be better defined -- are they strictly 
> >   point-to-point or can aplication endpoints reside in a distributed 
> >   manner (anycast or multicast basis) in the delay tolerant network
> 
> We don't yet have any definition of DTN multipoint delivery service that would encompass anycast or multicast.  We are all agreed that we need such a definition, but it's not ready yet.
> 
> > * Section 6 should list mandatory requirements for the convergence layers
> >   in terms of what services they must provide to the bundle layer.
> 
> I think the Bundling spec is the right place for this; it's too low-layer for the architecture document.
> 
> > * DTN has some goals similar to X.400; the X.400 delivery service classes 
> >   are worth evaluating in this context (a citation of X.400 is appropriate 
> >   as relevant prior work)
> 
> Sure.
> 
> > * Consider the terminology "hold-and-forward" to distinguish from the 
> >   usage elsewhere of "store-and-forward" to mean "queue-and-forward"
> 
> But I don't think a distinction needs to be drawn; I think they're the same.  It's just a matter of degree: how much can be queued, how long data may need to be held in the queue, and possibly whether or not it's advisable to manage the queues in non-volatile storage rather than in DRAM.
> 
> > * Consider the terminology "data hauling" to the case where mobility
> >   is exploited for delivery e.g. data mules, message ferries, ...
> 
> Sure, an interesting suggestion.
> 
> > Comments on the Bundle Protocol Specification 
> > =============================================
> > 
> > * Scope: The comments in this section refer specifically to the text
> >   contained in draft-irtf-dtnrg-bundle-spec-02.txt
> > 
> > * This document is well written.  In particular, the format used to 
> >   describe the primitives and their semantics aids the understanding
> >   of the document.
> 
> Thanks!
> 
> > * The term interface is never defined rigorously and is used in multiple
> >   contexts such as a software/service interface or a network interface.
> >   This should be done in the introduction.
> 
> Good point.
> 
> > * The endpoint ID terminology differs from what is used in the architecture.
> >   For example, the architecture indicates that a node must have at least one 
> >   MEI, but allows multiple MEIs per node; we think the MEI maps to the Agent 
> >   administration endpoint ID in the bundle protocol specification,
> 
> Yes, we need to resolve this terminology issue.
> 
> >   which seems to suggest that there is exactly one agent administration endpoint ID.
> 
> Not a conflict, but we should clarify: each "interface" has an administrative endpoint ID in the same way that each network interface card in an IP-based network has its own IP address.
> 
> > * Does the endpoint ID apply to the node or the interface?   Appears
> >   to be the former but worth clarifying.
> 
> Nope, the latter.  Which leaves open a question: what's the ID of the node as a whole?  We don't really have such a notion in the architecture, which I think is kind of ugly, but again I believe it's analogous to what we do in the IP world: if you've got a multi-homed host, which interface's DNS name (mapping to its unique IP address) do you use as the "hostname"?
> 
> > * Name Mobility: Is the communications endpoint ID allowed to move from 
> >   node to node?  If so, what state related to the registration (e.g. 
> >   bundles waiting to be delivered, the "delivery failure" action) MUST/
> >   SHOULD/MAY be migrated? 
> > 
> >   In other words, can nodes transfer custody of a "registration"?  (As an 
> >   analogy consider arguments for and against TCP session migration.)
> 
> Again, I don't think we've contemplated this in the architecture.  Worth discussing.
> 
> >   Treating the registration as an "active mailbox" object may be a useful
> >   metaphor here.
> > 
> >   This may be a larger issue here related to the relinquishment of name
> >   bindings by individual nodes.
> > 
> > * Can the CancelBundle.request (sometimes aliased to Cancel.request)
> 
> An error.
> 
> >   only apply if the bundle is locally stored?
> 
> Yes.
> 
>     For example, upon a cancel request
> >   can a node launch a "k-hop trace and delete" on a pattern of bundles that 
> >   were sent earlier?  This will be useful to purge bundles/replicas with 
> >   large expiration times (that have either been delivered or canceled)?
> 
> Yes, we've discussed the possibility of flooding the network with "kill packets" to accomplish this kind of thing.  I'm doubtful that there's a lot of advantage in it.
> 
> > * The hash carried by bundles in the security header can have other uses.
> >   For example, this hash can be used to populate say a Bloom filter on en 
> >   route nodes for traceback.
> 
> Cool.
> 
> > * What happens to any bundles that arrive between registration and start 
> >   delivery?   Does the default delivery action go into effect automatically
> >   upon registration?
> 
> Yes.
> 
> >   It may be useful to point out that there is a distinct poll mode (active 
> >   reception?) when passive reception is first introduced.
> 
> Sure.
> 
> > * What happens to bundles that arrive after a deregister.request?  We assume
> >   they MUST be discarded.
> 
> Yes, at that point there is no endpoint to deliver them to.  It's as if the bundles were mis-addressed from the beginning.
> 
> > * MUST the SENDERROR.INDICATION always include the application data unit?
> 
> Conceptually, yes, so that the application can resend or whatever.  This is an abstract service spec, so how you accomplish this is entirely a matter of implementation.
> 
> > * For the administrative part of the endpoint ID, some rationale is required 
> >   regarding why 8-bit, 16-bit, and URIs are supported in particular?  Why is
> >   URI not sufficient?  Why not 32-bit or 48-bit?
> 
> We need to support extremely small bundle headers for some environments; that rules out URIs.  I think we worked out that the minimum legal length for a URI was 3 bytes, so 8-bit and 16-bit endpoint IDs were available for this alternative purpose.  32-bit and 48-bit numeric endpoint IDs might be indistinguishable from legal 4-byte and 6-byte URIs; by confining ourselves to the smaller numbers we can use endpoint ID length to disambiguate.
> 
> > * A generic user-defined experimental header mechanism (syntax and semantics
> >   for nodes not implementing that header) is needed in order to enable 
> >   experimentation.
> 
> Yes, we agreed on this at the last DTNRG meeting.
> 
> > * A source routing header extension will be useful.
> 
> Yes, we agreed to think about this too.
> 
> > * Since the dictionary header only allows 16 strings, and since there can
> >   be only one header of each type, it appears that extension headers will 
> >   need their own dictionaries.  For example, consider a 17-hop source route.
> 
> I'd say just carry the strings themselves in the extension headers.  The strings aren't so likely to be multiply-referenced, so a dictionary doesn't buy you much.
> 
> > * It appears that generating a unique ID based purely on the creation
> >   timestamp and endpointID may cause problems.  A node with concurrent 
> >   embedded processors may be able to generate more than one bundle per 
> >   clock tick.  Therefore, an additional sequence counter may be needed.
> 
> Right, we've agreed that the "fraction" part of the timestamp can be a monotonically increasing counter within second.
> 
> > * It is desirable to use the same style in Section 4 as in Section 2 
> >   (i.e. explicitly call out primitives and desribe their semantics).
> 
> This section is Procedure, not abstract Service, so it's not exactly the same.  But you're right, we could start off with some useful semantic clarifications.
> 
> > * When a bundle is discarded (in Section 4.2) due to authentication 
> >   failure, can the report to the adminsitrative endpoint contain a
> >   copy of the inauthentic bundle or not?  Since the bundle is otherwise 
> >   discarded and not processed further, this copy is potentially useful 
> >   for instrumenting various security mechanisms.
> 
> Currently this doesn't happen.  Worth discussing.
> 
> > * There is a potential for denial-of-service attacks that make use
> >   of the report-to field. This is a problem in a DTN since the sender 
> >   can legitimately be disconnected and vanish.  Has the report-to 
> >   third party have any say in the matter?  For example, does the
> >   bundle carry any credentials from the report-to?
> 
> Denial of service in general is a nightmare.  The only real defense we've got, I think, is bundle authentication ("mutual suspicion" among bundle agents).
> 
> > * In the bundle fragmentation section, it is assumed that the sending
> >   agent "knows" when a transmission is terminated before the entire payload 
> >   has been transmitted.  Is this (signaling of partial transmission) an 
> >   explicit requirement for a DTN convergence layer?
> 
> It has been but, again, I am increasingly doubtful.
> 
> > * Currently, the fragmentation information carried in the headers do not 
> >   provide for redundant encodings of the fragments -- i.e. to indicate 
> >   how the bundle was fragmented and erasure-coded.  Yet one may wish to
> >   apply these codes precisely when there is fragmentation.
> > 
> >   In the current architecture, erasure or digital fountain type encoding 
> >   must occur either below the convergence layer (which means the protection
> >   cannot cross multiple networks), or end to end at the application which
> >   means the application cannot selectively erasure-code only when there
> >   is fragmentation.
> 
> Right, the whole question of fragmentation is a bag of snakes, and always has been.  I will write more on this later today if I have time.
> 
> > * In Table 5 there is no way to indicate that a bundle was received
> >   in error, but was or was not reconstructable (using the erasure 
> >   coding). Such a feedback will aid in adjusting the strength of the
> >   code.
> 
> I think this belongs at a layer above Bundling, in the same way that Digital Fountain lives above IP.  But I know we don't have consensus on this.
> 
> > Anticipated Requirements / Areas for Possible Draft Proposals  
> > =============================================================
> > 
> > * Experimental headers: Our SPINDLE project will use the bundle as the 
> >   means of message encapsulation, however, we will require the ability 
> >   to add and experiment with additional headers.  We request that a user
> >   definable experimental header mechanism be added to the bundle
> >   protocol specification.  In particular, we anticipate the need for 
> >   extension headers to:
> > 
> >   - support braid-spray routing
> >   - carry name resolution hints  
> >   - carry resource accounting tokens 
> >   - support management tasks such as bundle traceback, proactive 
> >     distributed purge of canceled or delivered bundles (as opposed 
> >     to waiting in storage until bundle expiration).
> >   - possibly others
> 
> Sure.
> 
> > * Interpretation of names: We expect we will require a modest change to 
> >   the DTNRG architecture to allow any region to interpret (but not modify) 
> >   the "opaque" A part of the {R,A} tuple that constitutes a DTNRG name.  
> >   Related modifiable information (e.g. resolution hints) may be carried in 
> >   a late binding header that we may specify.  We anticipate that the unique 
> >   part of our supername will map to the DTNRG name syntax.
> 
> No longer an issue, I think.
> 
> > * Region interpretation: We anticipate that the routing and late binding
> >   frameworks developed within the DARPA DTN program to support tactical 
> >   mobility may each interpret and use regions differently (e.g. what is 
> >   a region, who owns/administers a region, mobility of nodes across 
> >   regions, mobility of regions themselves, and sub-region partitioning).
> 
> I think this is now moot.
> 
> > * We anticipate the DTN program will propose new frameworks for bundle 
> >   routing (family of routing protocols) and delayed resolution of names.
> >   We anticipate we will generate specifications of information models for 
> >   storing and sharing topology, adjacency, reachability, and name resolution 
> >   across nodes and across algorithms.
> 
> Sure.
> 
> > * To facilitate regular DTN-DTNRG interaction, a monthly teleconference
> >   between the DTN and DTNRG to address DTN-specific issues will be 
> >   beneficial.
> 
> Yes.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
To: [email-masked] (Stephen Farrell)
Date: Fri, 1 Apr 2005 13:49:56 -0500 (EST)
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

> >> * To facilitate regular DTN-DTNRG interaction, a monthly teleconference
> >>   between the DTN and DTNRG to address DTN-specific issues will be   
> >>   beneficial.
> 
> I think that that might be useful. If its really intended to link
> the DARPA and IRTF groups then presumably it'll be an open call for
> anyone interested (DTNRG being an open IRTF RG). If so, I'd be
> interested in taking part in (some) such calls.

For starters, I need to find out how to join the weekly DTNRG 
teleconferences.  The plan was to discuss issues of interest 
to the DTN program on one of these meetings every month.

I was assuming an open call, but any information we share from 
the DTN program must have been cleared for public release.

-Rajesh

> If not, I'd be interested in complaining about the lack of
> openness:-)
> 
> Stephen.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Fri, 01 Apr 2005 18:28:53 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project team
Sender: [email-masked]

>> * To facilitate regular DTN-DTNRG interaction, a monthly teleconference
>>   between the DTN and DTNRG to address DTN-specific issues will be   
>> beneficial.

I think that that might be useful. If its really intended to link
the DARPA and IRTF groups then presumably it'll be an open call for
anyone interested (DTNRG being an open IRTF RG). If so, I'd be
interested in taking part in (some) such calls.

If not, I'd be interested in complaining about the lack of
openness:-)

Stephen.

Date: Fri, 01 Apr 2005 08:59:24 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project team
Sender: [email-masked]

Rajesh, I'm sorry it has taken me so long to respond to your comments; it's been a month of everything being top-priority at the same time, so reflecting on DTN architecture and the bundling protocol unfortunately slipped to second priority.

Some remarks in-line below.

Scott

Rajesh Krishnan wrote:
> ...............................................................................
> Comments on DTN Architecture 
> ============================
> 
> * Scope: The comments in this section refer specifically to the text 
>   contained in draft-irtf-dtnrg-arch-02.txt
> 
> * Overall: The following aspects have not received adequate treatment
>   in the architecture:
> 
>   - Mobility

I think we're all agreed on this.

>     o especially, node mobility between regions and region mobility

But this particular aspect of the problem may have disappeared, now that we're moving away from preserving any formal "region" notion in the architecture.

>   - Management
>     o ownership and administrative boundaries for nodes and regions

I guess ownership of nodes remains an issue of some sort, but why is it an issue that needs to be addressed in the Architecture document?

>     o instrumentation of DTN nodes for observing and controlling remote
>       network state
>     o error conditions at a node such as a persistent store failure
>     o declarative (external) specification and enforcement of policies

I think all of these may be important, but I don't think any of them should be addressed in the Architecture document.  They are low-level and protocol-specific, and in some cases implementation-specific.

>   - Disruptions occurring at short timescales (the focus is on tolerance 
>     to delays at large timescales)

Right, we spent a little time on this at the meeting.  I still don't understand the issue or its significance.  What is the unsolved problem here, and why is DTN the right instrument for solving it?

> * The abstract defines the delay tolerant network as an "overlay that 
>   exists above the transport layer."  It appears that there is nothing
>   in the architecture that fundamentally requires a DTN to be overlaid
>   over the transport layer of the underlying network.

Right, we could say "exists, notionally, above the transport layer."  Could be above some other transmission layer which, strictly speaking, doesn't even necessarily have to be reliable [though if it isn't then you don't have a lot of reliability in your network; in the general case, custodial retransmission is not a mechanism you want to count on as your primary guarantor of reliability in a delay-tolerant network].

>   On the other hand, there appear to be some _implicit_ service requirements 
>   assumed for the underlying network.  These requirements may be typically 
>   satisfied by the transport layer  in an IP network, but it is not clear 
>   the same holds for other networks.  These assumptions must be made explicit 
>   irrespective of which layer of the underlying network DTN is overlaid upon.

Very good point.
  
>   Since DTN is an overlay, the underlying network appears to the DTN to be 
>   a (more capable) link layer rather than a transport layer, and DTN needs 
>   to implement functionality (e.g. routing) typically associated with the 
>   network layer.

Except that, to DTN, TCP/IP looks like a link layer system, while to the rest of the world it looks like transport.

The alien concept here, I think, is that "network-ness" and "link-ness" are *relative* rather than absolute.  The OSI 7-layer model encourages us to think of a particular element of communication functionality having an absolute location in the stack, rather than articulating more general principles of layer dependency (relative location in the stack) that would help us make more sense of this stuff.  It may be that, while the layering notion itself is still very valuable [I am old-fashioned and think it is; I realize there is dissent], it's time to move on to a more powerful and general model of layering.

TCP/IP is to Bundling as Ethernet is to IP -- except that Bundling typically needs its underlying "Ethernet" to be more reliable, so maybe it's more accurate to say that TCP/IP is to Bundling as Ethernet with (say) Type 3 LLC is to IP.

>   We suggest generalizing this statement to "overlay that exists above any 
>   layer of an underlying network that provides the <enumerated> capabilities 
>   (possibly through a convergence sublayer)".

Yes, something like that, except that I would omit the parenthetical clause.  I think there is *always* a convergence sublayer in any DTN implementation, and in fact I suspect there is always one in any IP implementation; it's just that in the IP world that convergence layer is sometimes formally identified, exposed, and documented (e.g., the VxWorks "MUX" layer) and sometimes not.

> * In Section 3.1 it is not clear whether aggregation of bundles is allowed.

I think there's a pretty clear statement that a bundle encapsulates a "message" and that messages are atomic, but maybe that could be emphasized.  There currently is no provision for a bundle agent aggregating multiple messages into its (single) payload; is that what you're thinking of?  What advantage would this offer?
> 
> * Section 3.2, assumptions 1-3. Assumptions (1) and (2) are not generally
>   valid for tactical military networks -- a large application area seeking
>   this technology. Storage is neither plentiful nor well-distributed. 
>   However, it is not clear that the *architecture* per se *needs* 
>   assumption 1.  Within this architecture, one could build routing 
>   mechanisms that perform coordinated, distributed storage.

I think these assumptions still hold, if we agree that "plentiful" and "well-distributed" are relative terms.  Deferred transmission requires storage.  If each node has enough storage [somewhere] to accomplish whatever transmission deferral it needs to do in order to be a viable bundle agent, then we can think of its storage as plentiful and well-distributed; if not, then you have got a busted delay-tolerant network.

> * Sec 3.2. Bulk/Normal/Expedited classes. Is the treatment on a per-next-hop 
>   basis? Can one give a Bulk bundle destined for the south pole to a contact 
>   headed south while the queue contains an Expedited bundle destined for the 
>   north pole? we guess the answer is yes, but it is not entirely clear from 
>   the text.

Good clarification.

> * In Section 3.3 it is not clear whether the transferrer or transferee 
>   generates the custody transfer indication.

The transferee (receiver) generates the report -- it's the only entity that has sufficient information to do so, as it's the only one that knows the custody transfer was successfully completed.

    Also if these indications
>   are all sent to the report-to node, then how many reports per bundle
>   does it receive?  Will this scale?  Can reports be aggregated or
>   piggybacked opportunistically or not?

These indications are designed for tracing and network performance analysis, and they are issued on an as-needed per-bundle basis; you can (and usually do) have custody transfer without them.  If they were requested on every single custodial bundle then you might indeed have a scaling problem, but that would be bad practice; maybe we should legislate against this, maybe not, I dunno.

> * In Section 3.3, for the expiration time and the curent time of day, 
>   what is the reference?  Will GMT / Earth time be used in the IPN?

Yes, there will be some single Earth-based time reference, maybe UTC; JPL, at least, already operates this way.

> * Sec 3.4/3.5. Does the notion of a region include hierarchical nesting in a
>   topologically significant way? That is, can the "A" in (R,A) turn contain an 
>   (R1,A1) and so on?

Because "regions" are now out of the picture, I think this question is moot.  The lexical structure of the endpoint ID is now somewhat up in the air, as we discussed in yesterday's DTN telecon, but in any event it's not a tuple.

> * In Section 3.5, the requirement that "any node not in R1 must treat A 
>   as "opaque" (i.e. it cannot interpret A)" seems needlessly restrictive.  
>   It seems sufficient to require that A not be modified outside R1.  To 
>   support mobility efficiently (and avoid needless telescoping of routes), 
>   it may become necessary to interpret A (e.g. location hints) outside R1.
> 
>   Furthermore, it can be argued that the "name invariance family" in the
>   Bundle Protocol Specification is indeed an interpretation of A outside 
>   R1.
> 
> * In Section 3.5 "Every node in a region R1 shall have the ability to 
>   eventually deliver messages to every other node in R1 ..." needs to
>   be qualified with a "barring a permanent network partition or permananent 
>   destruction of nodes, and provided the expiration time of the bundle 
>   exceeds the time the network is partitioned, and there is sufficient
>   storage in the network."
> 
> * Sec. 3.5, assumption 3 ("every node in a region should be able to eventually
>   deliver to every other node"). Not clear whether this assumption requires 
>   that the "eventual delivery" be made with or without the use of data 
>   hauling nodes (DTN  routers). If we cannot use DTN routers within the 
>   region, then this seriously limits the applicability of this
>   architecture to the tactical military environment. For instance, the region
>   could be a brigade with HMMMVs, soldiers, UAVs etc. A brigade could be
>   partitioned with UAV or helicopters doing the data hauling. In such a case
>   we need a few DTN routers within the region. On the other hand, if 
>   DTN routers can be used to heal such partitions within a region, it is 
>   not clear how the addressing scheme will work.

I think all three of these points are now moot.

> * In Section 3.8 "graph" is used to mean "multi-graph".

Yes.

> * Section 3.8.1. Types of contacts. How is contact volatility managed?
>   When you lose contact, you are not sure whether it is "still out there" or
>   "gone". In other words, do you envisage the use of a link up/down protocol
>   like in OSPF or MANETs to "maintain" contacts.  Is this function at the 
>   bundle layer or in the convergence layer?

I would say this is always at the convergence layer, because the way you do it may be dependent on the nature of the underlying protocols.  But we may not have consensus on this yet.

> * Sec. 3.9, Reactive fragmenting. This implicitly assumes that the sender and
>   receiver can communicate throughout the message exchange. What if the 
>   link/subnet-path breaks after receiving part of the message? In this case 
>   the sender cannot learn that only a portion of the message was received. 
>   Actually, this is the likely case -- if X receives only part of a message
>   from Y, it is probably because there was some disruption in the communication
>   -- and this same disruption will likely be a barrier for the sender to
>   "learn" anything at all about the outcome of its transmission.

Yes.  I am increasingly skeptical about including reactive fragmentation -- and in fact any kind of fragmentation at all -- as a Bundling function.  I'm hoping to have time this afternoon to lay out my whole argument on this, in yet another interminable email.

> * Section 3.9 what does it mean for DTN nodes to "share an edge"

It means they are the two vertices on which the edge is incident.

> * Section 3.10, can ACKs be aggregated or piggybacked opportunistically?

They currently are not.  Worth discussing.

> * Section 3.11, seems the use of seconds for expiration presupposes the
>   use of DTN in high delay environments, and precludes applications to 
>   high-speed optical networks (or computer interconnects), and other
>   distributed applications, where custody transfers and data expiration 
>   may indeed happen at faster timescales.
> 
>   Why should not DTN scale _down_ in delays and disconnections the same
>   way it scales up?

I think it's because we haven't identified a need to do so.  This was mentioned earlier; again, I don't understand the issue or its significance.

> * Section 3.12. Congestion control. We are not sure if congestion control 
>   should be considered within this architecture. Presumably, DTN is deployed 
>   in a network where only a (small?) subset of the nodes are DTN capable (DTN
>   routers/nodes).

Not necessarily; they may well all be DTN agents.  But I don't think this is relevant: you need to do something to minimize data loss due to resource oversubscription at bundle agents functioning as routers, no matter how many of them you have.

    Thus there may be plenty of other traffic that DTN has no
>   control over. Congestion is a network-layer/MAC layer phenomenon and best
>   controlled there.

But Bundling *is* at network layer, in the overlay network.

    No matter what we do at the DTN layer, it will be of no
>   avail if other applications/protocols using the underlying network blast 
>   away to glory.

I'm not sure I understand your point, but I suspect I disagree.  I've got a Bundling congestion control system implemented and it seems to work pretty well; Esther and I are trying frantically to get a paper on it ready in time for the SIGCOMM workshop.

> * Section 3.12. Flow control for solving the congestion control. This only
>   works even partially if the receiver capacity is lower or equal to the 
>   capacity of the intermediate nodes -- may not be a realistic assumption, 
>   especially in a tactial military environment where the bundle may have 
>   to go over multiple wireless hops.

Again, I'm not sure I understand your point.  We should probably spend a few moments discussing the way I've got it implemented.

> * Section 3.13, The security architecture (based on checking at edges) may 
>   be challenged by mobility, especially of the edges. What if the edges of 
>   the network are continuously redefined due to mobility?

Right, we are all agreed that a lot of security issues remain to be nailed down.

> * Section 4.3 makes a critical point regarding state versus protocol
>   behavior and the possibility of state being shared across protocols.
>   A corollary of this sattement is the need to identify information
>   models for sharing (and storing) routing, forwarding, and name
>   resolution state.

I would expect these models to be identified in the course of developing the relevant protocols; I think this stuff is too low-level for the architecture document.
 
> * Section 5, For disruption tolerance, the application structuring issues 
>   must include cases where the DTN node where the application is registered
>   is mobile or is otherwise soon to be disconnected (and needs to transfer 
>   custody of the registration).

Mobility of registration is a concept we haven't discussed at all yet, as far as I know, and I'm not yet convinced of its utility.  Again, the whole question of mobility needs more work.  It may be "just" a routing problem.
> 
> * Section 5, application needs to be better defined -- are they strictly 
>   point-to-point or can aplication endpoints reside in a distributed 
>   manner (anycast or multicast basis) in the delay tolerant network

We don't yet have any definition of DTN multipoint delivery service that would encompass anycast or multicast.  We are all agreed that we need such a definition, but it's not ready yet.

> * Section 6 should list mandatory requirements for the convergence layers
>   in terms of what services they must provide to the bundle layer.

I think the Bundling spec is the right place for this; it's too low-layer for the architecture document.

> * DTN has some goals similar to X.400; the X.400 delivery service classes 
>   are worth evaluating in this context (a citation of X.400 is appropriate 
>   as relevant prior work)

Sure.

> * Consider the terminology "hold-and-forward" to distinguish from the 
>   usage elsewhere of "store-and-forward" to mean "queue-and-forward"

But I don't think a distinction needs to be drawn; I think they're the same.  It's just a matter of degree: how much can be queued, how long data may need to be held in the queue, and possibly whether or not it's advisable to manage the queues in non-volatile storage rather than in DRAM.

> * Consider the terminology "data hauling" to the case where mobility
>   is exploited for delivery e.g. data mules, message ferries, ...

Sure, an interesting suggestion.

> Comments on the Bundle Protocol Specification 
> =============================================
> 
> * Scope: The comments in this section refer specifically to the text
>   contained in draft-irtf-dtnrg-bundle-spec-02.txt
> 
> * This document is well written.  In particular, the format used to 
>   describe the primitives and their semantics aids the understanding
>   of the document.

Thanks!

> * The term interface is never defined rigorously and is used in multiple
>   contexts such as a software/service interface or a network interface.
>   This should be done in the introduction.

Good point.

> * The endpoint ID terminology differs from what is used in the architecture.
>   For example, the architecture indicates that a node must have at least one 
>   MEI, but allows multiple MEIs per node; we think the MEI maps to the Agent 
>   administration endpoint ID in the bundle protocol specification,

Yes, we need to resolve this terminology issue.

>   which seems to suggest that there is exactly one agent administration endpoint ID.

Not a conflict, but we should clarify: each "interface" has an administrative endpoint ID in the same way that each network interface card in an IP-based network has its own IP address.

> * Does the endpoint ID apply to the node or the interface?   Appears
>   to be the former but worth clarifying.

Nope, the latter.  Which leaves open a question: what's the ID of the node as a whole?  We don't really have such a notion in the architecture, which I think is kind of ugly, but again I believe it's analogous to what we do in the IP world: if you've got a multi-homed host, which interface's DNS name (mapping to its unique IP address) do you use as the "hostname"?

> * Name Mobility: Is the communications endpoint ID allowed to move from 
>   node to node?  If so, what state related to the registration (e.g. 
>   bundles waiting to be delivered, the "delivery failure" action) MUST/
>   SHOULD/MAY be migrated? 
> 
>   In other words, can nodes transfer custody of a "registration"?  (As an 
>   analogy consider arguments for and against TCP session migration.)

Again, I don't think we've contemplated this in the architecture.  Worth discussing.

>   Treating the registration as an "active mailbox" object may be a useful
>   metaphor here.
> 
>   This may be a larger issue here related to the relinquishment of name
>   bindings by individual nodes.
> 
> * Can the CancelBundle.request (sometimes aliased to Cancel.request)

An error.

>   only apply if the bundle is locally stored?

Yes.

    For example, upon a cancel request
>   can a node launch a "k-hop trace and delete" on a pattern of bundles that 
>   were sent earlier?  This will be useful to purge bundles/replicas with 
>   large expiration times (that have either been delivered or canceled)?

Yes, we've discussed the possibility of flooding the network with "kill packets" to accomplish this kind of thing.  I'm doubtful that there's a lot of advantage in it.

> * The hash carried by bundles in the security header can have other uses.
>   For example, this hash can be used to populate say a Bloom filter on en 
>   route nodes for traceback.

Cool.

> * What happens to any bundles that arrive between registration and start 
>   delivery?   Does the default delivery action go into effect automatically
>   upon registration?

Yes.

>   It may be useful to point out that there is a distinct poll mode (active 
>   reception?) when passive reception is first introduced.

Sure.

> * What happens to bundles that arrive after a deregister.request?  We assume
>   they MUST be discarded.

Yes, at that point there is no endpoint to deliver them to.  It's as if the bundles were mis-addressed from the beginning.

> * MUST the SENDERROR.INDICATION always include the application data unit?

Conceptually, yes, so that the application can resend or whatever.  This is an abstract service spec, so how you accomplish this is entirely a matter of implementation.

> * For the administrative part of the endpoint ID, some rationale is required 
>   regarding why 8-bit, 16-bit, and URIs are supported in particular?  Why is
>   URI not sufficient?  Why not 32-bit or 48-bit?

We need to support extremely small bundle headers for some environments; that rules out URIs.  I think we worked out that the minimum legal length for a URI was 3 bytes, so 8-bit and 16-bit endpoint IDs were available for this alternative purpose.  32-bit and 48-bit numeric endpoint IDs might be indistinguishable from legal 4-byte and 6-byte URIs; by confining ourselves to the smaller numbers we can use endpoint ID length to disambiguate.

> * A generic user-defined experimental header mechanism (syntax and semantics
>   for nodes not implementing that header) is needed in order to enable 
>   experimentation.

Yes, we agreed on this at the last DTNRG meeting.

> * A source routing header extension will be useful.

Yes, we agreed to think about this too.

> * Since the dictionary header only allows 16 strings, and since there can
>   be only one header of each type, it appears that extension headers will 
>   need their own dictionaries.  For example, consider a 17-hop source route.

I'd say just carry the strings themselves in the extension headers.  The strings aren't so likely to be multiply-referenced, so a dictionary doesn't buy you much.

> * It appears that generating a unique ID based purely on the creation
>   timestamp and endpointID may cause problems.  A node with concurrent 
>   embedded processors may be able to generate more than one bundle per 
>   clock tick.  Therefore, an additional sequence counter may be needed.

Right, we've agreed that the "fraction" part of the timestamp can be a monotonically increasing counter within second.

> * It is desirable to use the same style in Section 4 as in Section 2 
>   (i.e. explicitly call out primitives and desribe their semantics).

This section is Procedure, not abstract Service, so it's not exactly the same.  But you're right, we could start off with some useful semantic clarifications.

> * When a bundle is discarded (in Section 4.2) due to authentication 
>   failure, can the report to the adminsitrative endpoint contain a
>   copy of the inauthentic bundle or not?  Since the bundle is otherwise 
>   discarded and not processed further, this copy is potentially useful 
>   for instrumenting various security mechanisms.

Currently this doesn't happen.  Worth discussing.

> * There is a potential for denial-of-service attacks that make use
>   of the report-to field. This is a problem in a DTN since the sender 
>   can legitimately be disconnected and vanish.  Has the report-to 
>   third party have any say in the matter?  For example, does the
>   bundle carry any credentials from the report-to?

Denial of service in general is a nightmare.  The only real defense we've got, I think, is bundle authentication ("mutual suspicion" among bundle agents).

> * In the bundle fragmentation section, it is assumed that the sending
>   agent "knows" when a transmission is terminated before the entire payload 
>   has been transmitted.  Is this (signaling of partial transmission) an 
>   explicit requirement for a DTN convergence layer?

It has been but, again, I am increasingly doubtful.

> * Currently, the fragmentation information carried in the headers do not 
>   provide for redundant encodings of the fragments -- i.e. to indicate 
>   how the bundle was fragmented and erasure-coded.  Yet one may wish to
>   apply these codes precisely when there is fragmentation.
> 
>   In the current architecture, erasure or digital fountain type encoding 
>   must occur either below the convergence layer (which means the protection
>   cannot cross multiple networks), or end to end at the application which
>   means the application cannot selectively erasure-code only when there
>   is fragmentation.

Right, the whole question of fragmentation is a bag of snakes, and always has been.  I will write more on this later today if I have time.

> * In Table 5 there is no way to indicate that a bundle was received
>   in error, but was or was not reconstructable (using the erasure 
>   coding). Such a feedback will aid in adjusting the strength of the
>   code.

I think this belongs at a layer above Bundling, in the same way that Digital Fountain lives above IP.  But I know we don't have consensus on this.

> Anticipated Requirements / Areas for Possible Draft Proposals  
> =============================================================
> 
> * Experimental headers: Our SPINDLE project will use the bundle as the 
>   means of message encapsulation, however, we will require the ability 
>   to add and experiment with additional headers.  We request that a user
>   definable experimental header mechanism be added to the bundle
>   protocol specification.  In particular, we anticipate the need for 
>   extension headers to:
> 
>   - support braid-spray routing
>   - carry name resolution hints  
>   - carry resource accounting tokens 
>   - support management tasks such as bundle traceback, proactive 
>     distributed purge of canceled or delivered bundles (as opposed 
>     to waiting in storage until bundle expiration).
>   - possibly others

Sure.

> * Interpretation of names: We expect we will require a modest change to 
>   the DTNRG architecture to allow any region to interpret (but not modify) 
>   the "opaque" A part of the {R,A} tuple that constitutes a DTNRG name.  
>   Related modifiable information (e.g. resolution hints) may be carried in 
>   a late binding header that we may specify.  We anticipate that the unique 
>   part of our supername will map to the DTNRG name syntax.

No longer an issue, I think.

> * Region interpretation: We anticipate that the routing and late binding
>   frameworks developed within the DARPA DTN program to support tactical 
>   mobility may each interpret and use regions differently (e.g. what is 
>   a region, who owns/administers a region, mobility of nodes across 
>   regions, mobility of regions themselves, and sub-region partitioning).

I think this is now moot.

> * We anticipate the DTN program will propose new frameworks for bundle 
>   routing (family of routing protocols) and delayed resolution of names.
>   We anticipate we will generate specifications of information models for 
>   storing and sharing topology, adjacency, reachability, and name resolution 
>   across nodes and across algorithms.

Sure.

> * To facilitate regular DTN-DTNRG interaction, a monthly teleconference
>   between the DTN and DTNRG to address DTN-specific issues will be 
>   beneficial.

Yes.