Subject: Re: [dtn-interest] BP extension block for Application Data Conditioning
From: Giorgos Papastergiou <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 27 Dec 2010 14:25:49 +0200
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Some more thoughts related to erasure coding:

Although at first glance it makes more sense to implement erasure
coding in each convergence layer, in my opinion, it is not
straightforward whether this approach is optimal for all operational
environments. For example, in power- / storage-constrained
environments, applying erasure coding in a hop-by-hop fashion may
become intolerable. Also, when decoding rate limits data rate,
implementing erasure coding end-to-end could enable offline decoding
and, thus, faster data rates.

Moreover, there is an interesting trade-off that requires further
investigation. While the approach to implement erasure coding in each
convergence layer allows code configurations that are tuned to the
environment, in the ADC approach application-oriented configurations
may be applied (e.g., different QoS).

In any case, as Scott mentioned, erasure coding is suggested just as
an ADC option.

Giorgos Papastergiou
Senior Engineer, Space Internetworking Center
Democritus University of Thrace (DUTH), Xanthi, Greece

On Thu, Dec 23, 2010 at 10:26 PM,  <[email-masked]> wrote:
>
> On 23 Dec 2010, at 18:33, Giorgos Papastergiou wrote:
>
>> Hi All,
>>
>> Recently, we had a discussion with Scott Burleigh (NASA/JPL) about the
>> definition of a BP extension block for application data conditioning
>> (ADC) and decided to widen the discussion and seek for comments.
>>
>> The extension block that we are thinking about relies on a simple
>> end-to-end layer of protocol providing different ADC services, such as
>> aggregation/elision, in-order delivery, encryption, compression,
>> end-to-end acknowledgment and erasure coding, which sits above BP.
>
> Some separate thoughts related to this:
>
> If the application wants encryption and security, why should the application
> trust or involve the BP? If encryption is implemented in the application above
> the BP (or in middleware above the BP but used by the application) then much
> of the BP's own security framework becomes moot, or is only used for
> lightweight reliability checking - this is one way around the reliability
> problems we described in our 'Bundle of Problems' paper (page 7, col. 1).
> That's arguably a good thing, as the keying problem is no longer the
> BP's problem, but the application's, and DTNRG doesn't have to solve it.
> But then, the BP doesn't need to know about the encryption, so why offer an
> extension block supporting it?
>
> Bundle security and convergence layering will also act against the effects of
> erasure coding, making that coding highly inefficient at best. It's difficult
> to match an erasure block size to a sensible bundle size when passing over different
> convergence layers, so the erasures become larger than one might like.
> Wouldn't it make more sense to implement erasure coding in each convergence
> layer, where it could be more useful and tuned to the environment?
>
> And, of course, DTN networks and their disconnections will make end-to-end
> acknowledgement difficult and/or slow. (Custody transfer acknowledgement
> still needs reliability verification before sending an ack; that's easier
> to tackle than the end-to-end case)
>
> If this is only handled by the final BP node, why does the BP even need to know
> about it? Hand it to the application on that node, we're done. An extension
> block that isn't used anywhere other than endpoints is an application
> feature...
>
> This proposal adds complexity to the BP, but I'm having trouble visualising
> the benefits. What is the intended application scenario here?
>
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood/dtn
>
>> Since not all users may necessarily require all or any of the offered
>> services, a single BP extension block with a built-in extensibility
>> structure should make application conditioning layer elements
>> selectable and allow for new services to be easily included in the
>> future.
>>
>> In this context, within that block, we could have several sub-blocks
>> of relevant data for each ADC function (e.g., the maximum length of
>> time to wait for an out-of-order bundle) and their order of appearance
>> inside the block can indicate the order in which ADC procedures were
>> applied by the ADC application, enabling this order to be reversed at
>> the destination, if necessary. In any case, the presence of the ADC
>> extension block signals the presence of such information at the
>> destination.
>>
>> Regarding the general format of the ADC block, a simple sub-block
>> structure seems sufficient. Each sub-block could have a
>> type/length/value format, with SNDVs for the first and second field
>> and a type-specific for the third. This way, sub-blocks can be parsed
>> out of the extension block data in order until block data length is
>> reached.
>>
>> At least for the services we have defined so far the ADC extension
>> block needs to be processed only by the final DTN node, thus the
>> following block processing flags do not make sense and should always
>> be set to 0.
>>
>>     0 - block must be replicated in every fragment.
>>     1 - Transmit status report if block can't be processed.
>>     2 - Delete bundle if block can't be processed.
>>     4 - Discard block if it can't be processed.
>>
>> However, since the bundle protocol agent at the destination node may
>> not be capable of processing this block, a supportive solution needs
>> to be defined, as well. A simple approach could be to introduce
>> similar processing flags that concern only the processing capability
>> of the destination node (such as the A, C fields of token ring, for
>> example); however this issue requires further investigation.
>>
>> Also, there might be occasions, where, although the BP agent of the
>> destination node will be able to process the block, the respective ADC
>> protocol may not be able to support all the indicated ADC procedures.
>> In this case, different actions may be needed depending on whether or
>> not some ADC procedures could be bypassed. Although these actions are
>> not strictly related to the BP agent, it may, nevertheless, be
>> beneficial to let the BP agent itself handle it.
>>
>> Any comments are welcome.
>>
>> Giorgos Papastergiou
>> Senior Engineer, Space Internetworking Center
>> Democritus University of Thrace (DUTH), Xanthi, Greece
>
>
>
>
>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 26 Dec 2010 09:14:57 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] BP extension block for Application Data Conditioning

Lloyd, you raise a good point.  Giorgos and I have gone back and forth on whether or not this "ADC" capability would best be implemented as a BP extension block or simply as an additional layer between BP and the application, one that's not necessarily tied to BP.  I think a case can be made either way.

One consideration is that the protocol stack at the destination node will need to be notified somehow that ADC de-processing is needed before the application data unit can be delivered to the application.  We could do this with some sort of annotation in the destination endpoint ID, but I think we need a more solid definition of EID syntax before we can look at adding this sort of annotation.  Another possibility would be to use one of the unused bundle processing flag bits, analogous to "acknowledgment by application is requested".  Placing the ADC information in an extension block lets us simply leverage off the extension block handling capabilities that are already in place, which might be less work.

I agree with you about erasure coding -- I do think it makes more sense at the convergence layer.  It's suggested as a possible ADC option just because end-to-end erasure coding comes up in our conversations from time to time, but I'm not convinced it's a good idea.

Similarly, as you say, end-to-end acknowledgment will clearly be difficult and/or slow, but in some operational environments its utility will apparently outweigh those drawbacks.  So long as this stuff is at the option of the application I think it can be kept harmless and even useful.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 23, 2010 12:27 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] BP extension block for Application Data Conditioning

On 23 Dec 2010, at 18:33, Giorgos Papastergiou wrote:

> Hi All,
> 
> Recently, we had a discussion with Scott Burleigh (NASA/JPL) about the 
> definition of a BP extension block for application data conditioning
> (ADC) and decided to widen the discussion and seek for comments.
> 
> The extension block that we are thinking about relies on a simple 
> end-to-end layer of protocol providing different ADC services, such as 
> aggregation/elision, in-order delivery, encryption, compression, 
> end-to-end acknowledgment and erasure coding, which sits above BP.

Some separate thoughts related to this:

If the application wants encryption and security, why should the application trust or involve the BP? If encryption is implemented in the application above the BP (or in middleware above the BP but used by the application) then much of the BP's own security framework becomes moot, or is only used for lightweight reliability checking - this is one way around the reliability problems we described in our 'Bundle of Problems' paper (page 7, col. 1).
That's arguably a good thing, as the keying problem is no longer the BP's problem, but the application's, and DTNRG doesn't have to solve it.
But then, the BP doesn't need to know about the encryption, so why offer an extension block supporting it?

Bundle security and convergence layering will also act against the effects of erasure coding, making that coding highly inefficient at best. It's difficult to match an erasure block size to a sensible bundle size when passing over different convergence layers, so the erasures become larger than one might like.
Wouldn't it make more sense to implement erasure coding in each convergence layer, where it could be more useful and tuned to the environment?

And, of course, DTN networks and their disconnections will make end-to-end acknowledgement difficult and/or slow. (Custody transfer acknowledgement still needs reliability verification before sending an ack; that's easier to tackle than the end-to-end case)

If this is only handled by the final BP node, why does the BP even need to know about it? Hand it to the application on that node, we're done. An extension block that isn't used anywhere other than endpoints is an application feature...

This proposal adds complexity to the BP, but I'm having trouble visualising the benefits. What is the intended application scenario here? 

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood/dtn

> Since not all users may necessarily require all or any of the offered 
> services, a single BP extension block with a built-in extensibility 
> structure should make application conditioning layer elements 
> selectable and allow for new services to be easily included in the 
> future.
> 
> In this context, within that block, we could have several sub-blocks 
> of relevant data for each ADC function (e.g., the maximum length of 
> time to wait for an out-of-order bundle) and their order of appearance 
> inside the block can indicate the order in which ADC procedures were 
> applied by the ADC application, enabling this order to be reversed at 
> the destination, if necessary. In any case, the presence of the ADC 
> extension block signals the presence of such information at the 
> destination.
> 
> Regarding the general format of the ADC block, a simple sub-block 
> structure seems sufficient. Each sub-block could have a 
> type/length/value format, with SNDVs for the first and second field 
> and a type-specific for the third. This way, sub-blocks can be parsed 
> out of the extension block data in order until block data length is 
> reached.
> 
> At least for the services we have defined so far the ADC extension 
> block needs to be processed only by the final DTN node, thus the 
> following block processing flags do not make sense and should always 
> be set to 0.
> 
>     0 - block must be replicated in every fragment.
>     1 - Transmit status report if block can't be processed.
>     2 - Delete bundle if block can't be processed.
>     4 - Discard block if it can't be processed.
> 
> However, since the bundle protocol agent at the destination node may 
> not be capable of processing this block, a supportive solution needs 
> to be defined, as well. A simple approach could be to introduce 
> similar processing flags that concern only the processing capability 
> of the destination node (such as the A, C fields of token ring, for 
> example); however this issue requires further investigation.
> 
> Also, there might be occasions, where, although the BP agent of the 
> destination node will be able to process the block, the respective ADC 
> protocol may not be able to support all the indicated ADC procedures.
> In this case, different actions may be needed depending on whether or 
> not some ADC procedures could be bypassed. Although these actions are 
> not strictly related to the BP agent, it may, nevertheless, be 
> beneficial to let the BP agent itself handle it.
> 
> Any comments are welcome.
> 
> Giorgos Papastergiou
> Senior Engineer, Space Internetworking Center Democritus University of 
> Thrace (DUTH), Xanthi, Greece

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

Date: Sun, 26 Dec 2010 10:37:10 +0100
From: Emmanuel Lochin <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] BP extension block for Application Data Conditioning

On 23 December 2010 21:26,  <[email-masked]> wrote:
>
> On 23 Dec 2010, at 18:33, Giorgos Papastergiou wrote:
>
>> Hi All,
>>
>> Recently, we had a discussion with Scott Burleigh (NASA/JPL) about the
>> definition of a BP extension block for application data conditioning
>> (ADC) and decided to widen the discussion and seek for comments.
>>
>> The extension block that we are thinking about relies on a simple
>> end-to-end layer of protocol providing different ADC services, such as
>> aggregation/elision, in-order delivery, encryption, compression,
>> end-to-end acknowledgment and erasure coding, which sits above BP.
>
> Some separate thoughts related to this:
>
> If the application wants encryption and security, why should the application
> trust or involve the BP? If encryption is implemented in the application above
> the BP (or in middleware above the BP but used by the application) then much
> of the BP's own security framework becomes moot, or is only used for
> lightweight reliability checking - this is one way around the reliability
> problems we described in our 'Bundle of Problems' paper (page 7, col. 1).
> That's arguably a good thing, as the keying problem is no longer the
> BP's problem, but the application's, and DTNRG doesn't have to solve it.
> But then, the BP doesn't need to know about the encryption, so why offer an
> extension block supporting it?
>
> Bundle security and convergence layering will also act against the effects of
> erasure coding, making that coding highly inefficient at best. It's difficult
> to match an erasure block size to a sensible bundle size when passing over different
> convergence layers, so the erasures become larger than one might like.
> Wouldn't it make more sense to implement erasure coding in each convergence
> layer, where it could be more useful and tuned to the environment?
>
> And, of course, DTN networks and their disconnections will make end-to-end
> acknowledgement difficult and/or slow. (Custody transfer acknowledgement
> still needs reliability verification before sending an ack; that's easier
> to tackle than the end-to-end case)

That's not true anymore. Using e2e novel erasure coding schemes (known
as on-the-fly erasure coding scheme), tolerant to ACK losses,
can be used to stream data inside a DTN : see "Robust Streaming in
Delay Tolerant Networks"
http://hal.archives-ouvertes.fr/hal-00449936_v1/

EL

>
> If this is only handled by the final BP node, why does the BP even need to know
> about it? Hand it to the application on that node, we're done. An extension
> block that isn't used anywhere other than endpoints is an application
> feature...
>
> This proposal adds complexity to the BP, but I'm having trouble visualising
> the benefits. What is the intended application scenario here?
>
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood/dtn
>
>> Since not all users may necessarily require all or any of the offered
>> services, a single BP extension block with a built-in extensibility
>> structure should make application conditioning layer elements
>> selectable and allow for new services to be easily included in the
>> future.
>>
>> In this context, within that block, we could have several sub-blocks
>> of relevant data for each ADC function (e.g., the maximum length of
>> time to wait for an out-of-order bundle) and their order of appearance
>> inside the block can indicate the order in which ADC procedures were
>> applied by the ADC application, enabling this order to be reversed at
>> the destination, if necessary. In any case, the presence of the ADC
>> extension block signals the presence of such information at the
>> destination.
>>
>> Regarding the general format of the ADC block, a simple sub-block
>> structure seems sufficient. Each sub-block could have a
>> type/length/value format, with SNDVs for the first and second field
>> and a type-specific for the third. This way, sub-blocks can be parsed
>> out of the extension block data in order until block data length is
>> reached.
>>
>> At least for the services we have defined so far the ADC extension
>> block needs to be processed only by the final DTN node, thus the
>> following block processing flags do not make sense and should always
>> be set to 0.
>>
>>     0 - block must be replicated in every fragment.
>>     1 - Transmit status report if block can't be processed.
>>     2 - Delete bundle if block can't be processed.
>>     4 - Discard block if it can't be processed.
>>
>> However, since the bundle protocol agent at the destination node may
>> not be capable of processing this block, a supportive solution needs
>> to be defined, as well. A simple approach could be to introduce
>> similar processing flags that concern only the processing capability
>> of the destination node (such as the A, C fields of token ring, for
>> example); however this issue requires further investigation.
>>
>> Also, there might be occasions, where, although the BP agent of the
>> destination node will be able to process the block, the respective ADC
>> protocol may not be able to support all the indicated ADC procedures.
>> In this case, different actions may be needed depending on whether or
>> not some ADC procedures could be bypassed. Although these actions are
>> not strictly related to the BP agent, it may, nevertheless, be
>> beneficial to let the BP agent itself handle it.
>>
>> Any comments are welcome.
>>
>> Giorgos Papastergiou
>> Senior Engineer, Space Internetworking Center
>> Democritus University of Thrace (DUTH), Xanthi, Greece
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
"This email and any attachments are confidential. They may contain legally
privileged information or copyright material. You should not read, copy, use
or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed"

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 23 Dec 2010 20:26:50 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] BP extension block for Application Data Conditioning

On 23 Dec 2010, at 18:33, Giorgos Papastergiou wrote:

> Hi All,
> 
> Recently, we had a discussion with Scott Burleigh (NASA/JPL) about the
> definition of a BP extension block for application data conditioning
> (ADC) and decided to widen the discussion and seek for comments.
> 
> The extension block that we are thinking about relies on a simple
> end-to-end layer of protocol providing different ADC services, such as
> aggregation/elision, in-order delivery, encryption, compression,
> end-to-end acknowledgment and erasure coding, which sits above BP.

Some separate thoughts related to this:

If the application wants encryption and security, why should the application
trust or involve the BP? If encryption is implemented in the application above
the BP (or in middleware above the BP but used by the application) then much
of the BP's own security framework becomes moot, or is only used for
lightweight reliability checking - this is one way around the reliability
problems we described in our 'Bundle of Problems' paper (page 7, col. 1).
That's arguably a good thing, as the keying problem is no longer the
BP's problem, but the application's, and DTNRG doesn't have to solve it.
But then, the BP doesn't need to know about the encryption, so why offer an
extension block supporting it?

Bundle security and convergence layering will also act against the effects of
erasure coding, making that coding highly inefficient at best. It's difficult
to match an erasure block size to a sensible bundle size when passing over different
convergence layers, so the erasures become larger than one might like.
Wouldn't it make more sense to implement erasure coding in each convergence
layer, where it could be more useful and tuned to the environment?

And, of course, DTN networks and their disconnections will make end-to-end
acknowledgement difficult and/or slow. (Custody transfer acknowledgement
still needs reliability verification before sending an ack; that's easier
to tackle than the end-to-end case)

If this is only handled by the final BP node, why does the BP even need to know
about it? Hand it to the application on that node, we're done. An extension
block that isn't used anywhere other than endpoints is an application
feature...

This proposal adds complexity to the BP, but I'm having trouble visualising
the benefits. What is the intended application scenario here? 

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood/dtn

> Since not all users may necessarily require all or any of the offered
> services, a single BP extension block with a built-in extensibility
> structure should make application conditioning layer elements
> selectable and allow for new services to be easily included in the
> future.
> 
> In this context, within that block, we could have several sub-blocks
> of relevant data for each ADC function (e.g., the maximum length of
> time to wait for an out-of-order bundle) and their order of appearance
> inside the block can indicate the order in which ADC procedures were
> applied by the ADC application, enabling this order to be reversed at
> the destination, if necessary. In any case, the presence of the ADC
> extension block signals the presence of such information at the
> destination.
> 
> Regarding the general format of the ADC block, a simple sub-block
> structure seems sufficient. Each sub-block could have a
> type/length/value format, with SNDVs for the first and second field
> and a type-specific for the third. This way, sub-blocks can be parsed
> out of the extension block data in order until block data length is
> reached.
> 
> At least for the services we have defined so far the ADC extension
> block needs to be processed only by the final DTN node, thus the
> following block processing flags do not make sense and should always
> be set to 0.
> 
>     0 - block must be replicated in every fragment.
>     1 - Transmit status report if block can't be processed.
>     2 - Delete bundle if block can't be processed.
>     4 - Discard block if it can't be processed.
> 
> However, since the bundle protocol agent at the destination node may
> not be capable of processing this block, a supportive solution needs
> to be defined, as well. A simple approach could be to introduce
> similar processing flags that concern only the processing capability
> of the destination node (such as the A, C fields of token ring, for
> example); however this issue requires further investigation.
> 
> Also, there might be occasions, where, although the BP agent of the
> destination node will be able to process the block, the respective ADC
> protocol may not be able to support all the indicated ADC procedures.
> In this case, different actions may be needed depending on whether or
> not some ADC procedures could be bypassed. Although these actions are
> not strictly related to the BP agent, it may, nevertheless, be
> beneficial to let the BP agent itself handle it.
> 
> Any comments are welcome.
> 
> Giorgos Papastergiou
> Senior Engineer, Space Internetworking Center
> Democritus University of Thrace (DUTH), Xanthi, Greece

Date: Thu, 23 Dec 2010 20:33:59 +0200
From: Giorgos Papastergiou <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] BP extension block for Application Data Conditioning

Hi All,

Recently, we had a discussion with Scott Burleigh (NASA/JPL) about the
definition of a BP extension block for application data conditioning
(ADC) and decided to widen the discussion and seek for comments.

The extension block that we are thinking about relies on a simple
end-to-end layer of protocol providing different ADC services, such as
aggregation/elision, in-order delivery, encryption, compression,
end-to-end acknowledgment and erasure coding, which sits above BP.
Since not all users may necessarily require all or any of the offered
services, a single BP extension block with a built-in extensibility
structure should make application conditioning layer elements
selectable and allow for new services to be easily included in the
future.

In this context, within that block, we could have several sub-blocks
of relevant data for each ADC function (e.g., the maximum length of
time to wait for an out-of-order bundle) and their order of appearance
inside the block can indicate the order in which ADC procedures were
applied by the ADC application, enabling this order to be reversed at
the destination, if necessary. In any case, the presence of the ADC
extension block signals the presence of such information at the
destination.

Regarding the general format of the ADC block, a simple sub-block
structure seems sufficient. Each sub-block could have a
type/length/value format, with SNDVs for the first and second field
and a type-specific for the third. This way, sub-blocks can be parsed
out of the extension block data in order until block data length is
reached.

At least for the services we have defined so far the ADC extension
block needs to be processed only by the final DTN node, thus the
following block processing flags do not make sense and should always
be set to 0.

     0 - block must be replicated in every fragment.
     1 - Transmit status report if block can't be processed.
     2 - Delete bundle if block can't be processed.
     4 - Discard block if it can't be processed.

However, since the bundle protocol agent at the destination node may
not be capable of processing this block, a supportive solution needs
to be defined, as well. A simple approach could be to introduce
similar processing flags that concern only the processing capability
of the destination node (such as the A, C fields of token ring, for
example); however this issue requires further investigation.

Also, there might be occasions, where, although the BP agent of the
destination node will be able to process the block, the respective ADC
protocol may not be able to support all the indicated ADC procedures.
In this case, different actions may be needed depending on whether or
not some ADC procedures could be bypassed. Although these actions are
not strictly related to the BP agent, it may, nevertheless, be
beneficial to let the BP agent itself handle it.

Any comments are welcome.

Giorgos Papastergiou
Senior Engineer, Space Internetworking Center
Democritus University of Thrace (DUTH), Xanthi, Greece

Date: Wed, 15 Dec 2010 11:53:07 +0000
From: Stephen Farrell <[email-masked]>
To: Michael Demmer <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Fwd: Proposed change to the way local bundle delivery is handled in DTN2

I've no useful input on where to do this, but we also
just hit this as Aidan was coding up our BPQ thing, so
I guess we'd be for a change unless there's reasons
not to.

S.

On 14/12/10 21:40, Michael Demmer wrote:
> (Forwarding to list from the right address)
> 
> ---------- Forwarded message ----------
> From:  <[email-masked]>
> Date: Tue, Dec 14, 2010 at 1:38 PM
> Subject: Re: [dtn-interest] Proposed change to the way local bundle
> delivery is handled in DTN2
> To: [email-masked]
> 
> 
> You are not allowed to post to this mailing list, and your message has
> been automatically rejected.  If you think that your messages are
> being rejected in error, contact the mailing list owner at
> [email-masked].
> 
> 
> 
> ---------- Forwarded message ----------
> From: Michael Demmer <[email-masked]>
> To: "Scott, Keith L." <[email-masked]>
> Date: Tue, 14 Dec 2010 13:38:27 -0800
> Subject: Re: [dtn-interest] Proposed change to the way local bundle
> delivery is handled in DTN2
> Sounds like a sound idea to me.
> 
> Dusting off the rust from my DTN2 knowledge and after a quick scan of
> the code, it seems a cleaner option would be to move functionality
> from BundleDaemon into a new RegistrationManager class that contains
> the RegistrationTable and handles the events related to local
> registrations (handle_registration_{added,removed,expired}) and is
> responsible for managing local delivery (check_local_delivery).
> 
> This seems like it would be a simple refactoring that would have the
> additional benefit of removing some of the bloat from the BundleDaemon
> class.
> 
> -m
> 
> On Tue, Dec 14, 2010 at 12:13 PM, Scott, Keith L. <[email-masked]> wrote:
>> Greetings,
>>
>>
>>
>> Currently in DTN2, the check for local delivery of bundles (delivery to
>> registrations using the same bundle agent) happens as an integral part of
>> BundleDaemon::handle_bundle_received().  This is a bit problematic if, for
>> example, a DTN2 router wants to append some metadata to all bundles.  In
>> this case, the router doesn’t get its shot at the bundle until after the
>> dispatch call to handle_bundle_received(), hence the bundle that is
>> delivered to local applications would NOT have the router metadata, whereas
>> copies sent out to other destinations WOULD.
>>
>>
>>
>> We’re interested in moving the invocation of check_local_delivery to AFTER
>> the call to router->handle_event() in BundleDaemon::handle_event()  This
>> could be implemented (I think) in a number of ways.  I’m interested if
>> people have insights or opinions as to which would be preferred.  Ways we’ve
>> thought of:
>>
>>
>>
>> 1)      Processing of BUNDLE_RECEIVED events could, if there are matching
>> local registrations, cause a new ‘LOCAL_DELIVERY’ event to be put on the
>> event queue (maybe even pushed on the head)  When processed, this would
>> deliver the bundle to the registrations.
>>
>> 2)      The call to check_local_delivery() could be incorporated into the
>> event_handlers_completed() function (for BUNDLE_RECEIVED events).
>>
>> 3)      A separate call could be made in handle_event (just before the
>> ‘stats_.events_processed_++;’ line, e.g.), possibly embedded in a more
>> generic ‘post-main-event processing’ call
>>
>>
>>
>> Thoughts?
>>
>>
>>
>>                                 --keith
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Sender: [email-masked]
From: Michael Demmer <[email-masked]>
Date: Tue, 14 Dec 2010 13:40:49 -0800
To: [email-masked]
Subject: [dtn-interest] Fwd: Proposed change to the way local bundle delivery is handled in DTN2

(Forwarding to list from the right address)

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Dec 14, 2010 at 1:38 PM
Subject: Re: [dtn-interest] Proposed change to the way local bundle
delivery is handled in DTN2
To: [email-masked]

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
[email-masked].

---------- Forwarded message ----------
From: Michael Demmer <[email-masked]>
To: "Scott, Keith L." <[email-masked]>
Date: Tue, 14 Dec 2010 13:38:27 -0800
Subject: Re: [dtn-interest] Proposed change to the way local bundle
delivery is handled in DTN2
Sounds like a sound idea to me.

Dusting off the rust from my DTN2 knowledge and after a quick scan of
the code, it seems a cleaner option would be to move functionality
from BundleDaemon into a new RegistrationManager class that contains
the RegistrationTable and handles the events related to local
registrations (handle_registration_{added,removed,expired}) and is
responsible for managing local delivery (check_local_delivery).

This seems like it would be a simple refactoring that would have the
additional benefit of removing some of the bloat from the BundleDaemon
class.

-m

On Tue, Dec 14, 2010 at 12:13 PM, Scott, Keith L. <[email-masked]> wrote:
> Greetings,
>
>
>
> Currently in DTN2, the check for local delivery of bundles (delivery to
> registrations using the same bundle agent) happens as an integral part of
> BundleDaemon::handle_bundle_received().  This is a bit problematic if, for
> example, a DTN2 router wants to append some metadata to all bundles.  In
> this case, the router doesn’t get its shot at the bundle until after the
> dispatch call to handle_bundle_received(), hence the bundle that is
> delivered to local applications would NOT have the router metadata, whereas
> copies sent out to other destinations WOULD.
>
>
>
> We’re interested in moving the invocation of check_local_delivery to AFTER
> the call to router->handle_event() in BundleDaemon::handle_event()  This
> could be implemented (I think) in a number of ways.  I’m interested if
> people have insights or opinions as to which would be preferred.  Ways we’ve
> thought of:
>
>
>
> 1)      Processing of BUNDLE_RECEIVED events could, if there are matching
> local registrations, cause a new ‘LOCAL_DELIVERY’ event to be put on the
> event queue (maybe even pushed on the head)  When processed, this would
> deliver the bundle to the registrations.
>
> 2)      The call to check_local_delivery() could be incorporated into the
> event_handlers_completed() function (for BUNDLE_RECEIVED events).
>
> 3)      A separate call could be made in handle_event (just before the
> ‘stats_.events_processed_++;’ line, e.g.), possibly embedded in a more
> generic ‘post-main-event processing’ call
>
>
>
> Thoughts?
>
>
>
>                                 --keith
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

From: "Scott, Keith L." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Dec 2010 15:13:51 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Proposed change to the way local bundle delivery is handled in DTN2

------=_NextPart_000_001A_01CB9BA1.83A09410
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_001B_01CB9BA1.83A09410"

------=_NextPart_001_001B_01CB9BA1.83A09410
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greetings,

Currently in DTN2, the check for local delivery of bundles (delivery to
registrations using the same bundle agent) happens as an integral part of
BundleDaemon::handle_bundle_received().  This is a bit problematic if, for
example, a DTN2 router wants to append some metadata to all bundles.  In
this case, the router doesn't get its shot at the bundle until after the
dispatch call to handle_bundle_received(), hence the bundle that is
delivered to local applications would NOT have the router metadata, whereas
copies sent out to other destinations WOULD.

We're interested in moving the invocation of check_local_delivery to AFTER
the call to router->handle_event() in BundleDaemon::handle_event()  This
could be implemented (I think) in a number of ways.  I'm interested if
people have insights or opinions as to which would be preferred.  Ways we've
thought of:

1)      Processing of BUNDLE_RECEIVED events could, if there are matching
local registrations, cause a new 'LOCAL_DELIVERY' event to be put on the
event queue (maybe even pushed on the head)  When processed, this would
deliver the bundle to the registrations.

2)      The call to check_local_delivery() could be incorporated into the
event_handlers_completed() function (for BUNDLE_RECEIVED events).

3)      A separate call could be made in handle_event (just before the
'stats_.events_processed_++;' line, e.g.), possibly embedded in a more
generic 'post-main-event processing' call

Thoughts?

                                --keith

------=_NextPart_001_001B_01CB9BA1.83A09410
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:183633659;
	mso-list-type:hybrid;
	mso-list-template-ids:-1195987776 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p =
class=3DMsoNormal>Greetings,<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Currently in =
DTN2, the check for local delivery of bundles (delivery to registrations =
using the same bundle agent) happens as an integral part of =
BundleDaemon::handle_bundle_received().&nbsp; This is a bit problematic =
if, for example, a DTN2 router wants to append some metadata to all =
bundles.&nbsp; In this case, the router doesn&#8217;t get its shot at =
the bundle until after the dispatch call to handle_bundle_received(), =
hence the bundle that is delivered to local applications would NOT have =
the router metadata, whereas copies sent out to other destinations =
WOULD.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>We&#8217;re interested in moving the invocation of =
check_local_delivery to AFTER the call to router-&gt;handle_event() in =
BundleDaemon::handle_event()&nbsp; This could be implemented (I think) =
in a number of ways.&nbsp; I&#8217;m interested if people have insights =
or opinions as to which would be preferred.&nbsp; Ways we&#8217;ve =
thought of:<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>1)<span =
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span><![endif]>Processing of BUNDLE_RECEIVED events could, if =
there are matching local registrations, cause a new =
&#8216;LOCAL_DELIVERY&#8217; event to be put on the event queue (maybe =
even pushed on the head)&nbsp; When processed, this would deliver the =
bundle to the registrations.<o:p></o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>2)<span =
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span><![endif]>The call to check_local_delivery() could be =
incorporated into the event_handlers_completed() function (for =
BUNDLE_RECEIVED events).<o:p></o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>3)<span =
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span><![endif]>A separate call could be made in handle_event =
(just before the &#8216;stats_.events_processed_++;&#8217; line, e.g.), =
possibly embedded in a more generic &#8216;post-main-event =
processing&#8217; call<o:p></o:p></p><p class=3DMsoNormal =
style=3D'margin-left:.25in'><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Thoughts?<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--keith<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_001_001B_01CB9BA1.83A09410--

------=_NextPart_000_001A_01CB9BA1.83A09410
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_001A_01CB9BA1.83A09410--

Date: Tue, 14 Dec 2010 11:48:04 -0500
From: Marc Blanchet <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] iana-bp draft

Hello,
  since the IRTF does not have a datatracker as IETF, I can't find 
easily an answer to my question: I wonder what is the state of the 
draft-irtf-dtnrg-iana-bp-registries? where are we? what are the next steps?

Marc.
-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 13 Dec 2010 17:08:28 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] ION 2.3.0 release

Sorry, everybody, the problem got fixed early this morning but I was already en route to Maryland and wasn't able to relay the announcement until now.  Lloyd, thanks for pointing this out; it was a corrupted log file that was affecting the whole Open Channel site.

Scott

-----Original Message-----
From: David Young [mailto:[email-masked]] 
Sent: Sunday, December 12, 2010 4:52 PM
To: [email-masked]
Cc: Burleigh, Scott C (313B); [email-masked]
Subject: Re: [dtn-interest] ION 2.3.0 release

While that error will likely be fixed soon by the OpenChannel
administrator; here's a more direct link to the download page:

http://www.openchannelsoftware.com/orders/index.php?group_id=381

On Sun, Dec 12, 2010 at 7:06 PM,  <[email-masked]> wrote:
> http://www.openchannelfoundation.org/projects/ION/
> says
> An error occured in the logger. Duplicate entry '0' for key 'type_idx'
>
> On 10 Dec 2010, at 22:01, Burleigh, Scott C (313B) wrote:
>
>> Version 2.3.0 of the ION open source implementation of DTN protocols has been released and is now available from http://www.openchannelfoundation.org/projects/ION/.
>>
>> This release adds new facilities for automatically re-routing bundles around communication contact failures, regardless of whether or not custody transfer is requested; includes new utility programs developed at the University of Colorado and additional convergence-layer support developed at Goddard Space Flight Center; includes a number of bug fixes; and provides a significantly upgraded regression test suite.
>>
>> Scott
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young

Date: Sun, 12 Dec 2010 19:51:32 -0500
From: David Young <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] ION 2.3.0 release

While that error will likely be fixed soon by the OpenChannel
administrator; here's a more direct link to the download page:

http://www.openchannelsoftware.com/orders/index.php?group_id=381

On Sun, Dec 12, 2010 at 7:06 PM,  <[email-masked]> wrote:
> http://www.openchannelfoundation.org/projects/ION/
> says
> An error occured in the logger. Duplicate entry '0' for key 'type_idx'
>
> On 10 Dec 2010, at 22:01, Burleigh, Scott C (313B) wrote:
>
>> Version 2.3.0 of the ION open source implementation of DTN protocols has been released and is now available from http://www.openchannelfoundation.org/projects/ION/.
>>
>> This release adds new facilities for automatically re-routing bundles around communication contact failures, regardless of whether or not custody transfer is requested; includes new utility programs developed at the University of Colorado and additional convergence-layer support developed at Goddard Space Flight Center; includes a number of bug fixes; and provides a significantly upgraded regression test suite.
>>
>> Scott
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 13 Dec 2010 00:06:39 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] ION 2.3.0 release

http://www.openchannelfoundation.org/projects/ION/
says
An error occured in the logger. Duplicate entry '0' for key 'type_idx'

On 10 Dec 2010, at 22:01, Burleigh, Scott C (313B) wrote:

> Version 2.3.0 of the ION open source implementation of DTN protocols has been released and is now available from http://www.openchannelfoundation.org/projects/ION/.
> 
> This release adds new facilities for automatically re-routing bundles around communication contact failures, regardless of whether or not custody transfer is requested; includes new utility programs developed at the University of Colorado and additional convergence-layer support developed at Goddard Space Flight Center; includes a number of bug fixes; and provides a significantly upgraded regression test suite.
> 
> Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 10 Dec 2010 14:01:35 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] ION 2.3.0 release

Version 2.3.0 of the ION open source implementation of DTN protocols has been released and is now available from http://www.openchannelfoundation.org/projects/ION/.

This release adds new facilities for automatically re-routing bundles around communication contact failures, regardless of whether or not custody transfer is requested; includes new utility programs developed at the University of Colorado and additional convergence-layer support developed at Goddard Space Flight Center; includes a number of bug fixes; and provides a significantly upgraded regression test suite.

Scott

Date: Thu, 9 Dec 2010 12:44:28 +0100 (CET)
From: Aline Viana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: MOBILITY 2011

------=_Part_1868133_1857107082.1291895068709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

[We apologize in advance if you receive multiple copies of this message]=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MOBILITY 2011 | Call for Papers =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

CALL FOR PAPERS, TUTORIALS, PANELS=20

MOBILITY 2011: The First International Conference on Mobile Services, Resou=
rces, and Users=20
July 17-22, 2011 - Bournemouth, UK=20

General page: http://www.iaria.org/conferences2011/MOBILITY11.html=20

Call for Papers: http://www.iaria.org/conferences2011/CfPMOBILITY11.html=20

Submission deadline: March 1, 2011=20

Technical Co-Sponsors:=20
- The Bournemouth & Poole College=20
- UNIK - University Graduate Center=20
- Bournemouth University=20
- Movation Collaboration Centre=20
- Center for Wireless Innovation, Norway=20
- INRIA=20
- PT Inovacao=20
Sponsored by IARIA, www.iaria.org=20

Extended versions of selected papers will be published in IARIA Journals: h=
ttp://www.iariajournals.org=20

Please note the Poster Forum and Work in Progress options.=20

The topics suggested by the conference can be discussed in term of concepts=
, state of the art, research, standards, implementations, running experimen=
ts, applications, and industrial case studies. Authors are invited to submi=
t complete unpublished papers, which are not under review in any other conf=
erence or journal in the following, but not limited to, topic areas.=20

All tracks are open to both research and industry contributions, in terms o=
f Regular papers, Posters, Work in progress, Technical/marketing/business p=
resentations, Demos, Tutorials, and Panels.=20

Before submission, please check and conform with the Editorial rules: http:=
//www.iaria.org/editorialrules.html=20

MOBILITY 2011 Topics (topics and submission details: see CfP on the site)=
=20

Mobile architectures, mechanisms, protocols=20
Mobility and wireless; Mobility enabling protocols; Mobile software; Servic=
e composition in mobile environments; Knowledge and service discovery in mo=
bile environments; On-demand mobility; User presence in mobile environments=
; Replication in mobile environments; Middleware for mobile environments; I=
nternet and mobility; Software architecture for mobile applications=20

Mobile networking and management=20
Fundamentals of mobile networks; Mobile-Fixed interworking; Heterogenous ne=
tworks; Beyond IMT-A; Mobile network virtualization; Femtocells and relays;=
 Mobile cells; Mobile network sharing and network access; Self-management o=
f mobile networks; Mobility management; Access control in mobile environmen=
ts; Advanced roaming concepts; Mobile network edge-based service delivery p=
latforms; Mobile content delivery networks; Mobile peer-to-peer systems; Mo=
bile VPNs; Quality of experience in mobile networks=20

Mobile devices and services=20
Smart mobile devices; Embedded mobile; Sensors and mobiles; Mobile media, m=
obile content; Mobile applications (mobile learning, mobile healthcare, etc=
.); Mobile games; Mobile business; Mobile Web applications; Apps versus Web=
; Novel software concepts for mobile services; Mobile- and micro payment; m=
Commerce=20

Mobile prosumers and interfaces=20
User interaction and mobility; Mobile communities; Mobile Web interfaces an=
d interaction techniques; Implementations and experimental mobile systems; =
Mobile Web; Mobile search and advertising=20

Mobile Internet of Things=20
Future mobile Internet; Internet of Things; Machine to Machine, People, Bus=
iness (M2x); Online; Smart Homes; Smart Cities=20

Vehicular mobile technology=20
Architectures and platforms; Vehicular ad hoc networks; Vehicular routing m=
etrics and supporting protocols; Mobility management and topology control; =
Standardization of vehicular networks; User aspects; Business enablers=20

Challenges in mobile environments=20
Security and privacy environments; Protection and safety of distributed mob=
ile data; Context-aware mobility and privacy; Mobile emergency communicatio=
n and public safety; Location-based services; Micro-payments; Accuracy and =
preciseness in localizing mobile entities=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
MOBILITY General Chair=20
Josef Noll, University of Oslo & Movation, Norway=20

MOBILITY Advisory Committee=20
Petre Dini, Concordia University, Canada & IARIA, USA=20
Pekka Jappinen. Lappeenranta University of Technology, Finland=20

MOBILITY Industry Liaison Chairs=20
Filipe Cabral Pinto, Telecom Inova=E7=E3o S.A., Portugal=20
Xiang Song, Microsoft, USA=20
Xun Luo, Qualcomm Inc. - San Diego, USA=20

MOBILITY Special Area Chairs on Video=20
Mikko Uitto, VTT Technical Research Centre of Finland, Finland=20

MOBILITY Special Area Chairs on Mobile Wireless Networks=20
Mohammad Mushfiqur Chowdhury, University of Oslo, Norway=20
Masashi Sugano, Osaka Prefecture University, Japan=20

MOBILITY Special Area Chairs on Mobile Web / Application=20
In-Young Ko, Korea Advanced Institute of Science and Technology (KAIST), Ko=
rea=20

MOBILITY Special Area Chairs on Context-aware, Media, and Pervasive=20
Brent Lagesse, Oak Ridge National Laboratory, USA=20

MOBILITY Special Area Chairs on Mobile Internet of Things and Mobile Collab=
orations=20
J =F6 rn Franke, SAP Research Center - Sophia Antipolis, France=20
Nils Olav Skeie, University College Telemark, Norway=20

MOBILITY Special Area Chairs on Vehicular Mobility=20
Gianluca Franchino, CEIICP - Scuola Superiore Sant'Anna - Pisa, Italy=20

MOBILITY Special Area Chairs on Mobile Cloud Computing=20
Chunming Rong, University of Stavanger, Norway=20
Josef Noll, Center for Wireless Innovation, Norway=20

MOBILITY Publicity Chairs=20
Aline Carneiro Viana, INRIA Saclay - Ile de France - Orsay, France=20
Sarfraz Alam, UNIK-University Graduate Center, Norway=20

Committee: http://www.iaria.org/conferences2011/ComMOBILITY11.html=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
------=_Part_1868133_1857107082.1291895068709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'=
><p class=3D"MsoPlainText"><span style=3D"" lang=3D"EN-GB">[We
apologize in advance if you receive multiple copies of this message]</span>=
</p>

<p class=3D"MsoPlainText"><span style=3D"" lang=3D"EN-GB">&nbsp;</span></p>

<br>

<small><font face=3D"Times New Roman, Times, serif">
        <font size=3D"3">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MOBILITY 20=
11 | Call for Papers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
      <br>

        CALL FOR PAPERS, TUTORIALS, PANELS<br>
      <br>

        MOBILITY 2011: The First International Conference on Mobile
        Services, Resources, and Users<br>

        July 17-22, 2011 - Bournemouth, UK<br>
      <br>

        General page:
        <a class=3D"moz-txt-link-freetext" href=3D"http://www.iaria.org/con=
ferences2011/MOBILITY11.html">http://www.iaria.org/conferences2011/MOBILITY=
11.html</a><br>
      <br>

        Call for Papers:
        <a class=3D"moz-txt-link-freetext" href=3D"http://www.iaria.org/con=
ferences2011/CfPMOBILITY11.html">http://www.iaria.org/conferences2011/CfPMO=
BILITY11.html</a><br>
      <br>

        Submission deadline: March 1, 2011<br>
      <br>

        Technical Co-Sponsors:<br>

        - The Bournemouth &amp; Poole College<br>

        - UNIK - University Graduate Center<br>

        - Bournemouth University<br>

        - Movation Collaboration Centre<br>

        - Center for Wireless Innovation, Norway<br>

        - INRIA<br>

        - PT Inovacao<br>

        Sponsored by IARIA, <a class=3D"moz-txt-link-abbreviated" href=3D"h=
ttp://www.iaria.org/">www.iaria.org</a><br>
      <br>

        Extended versions of selected papers will be published in IARIA
        Journals: <a class=3D"moz-txt-link-freetext" href=3D"http://www.iar=
iajournals.org/">http://www.iariajournals.org</a><br>
      <br>

        Please note the Poster Forum and Work in Progress options.<br>
      <br>

        The topics suggested by the conference can be discussed in term
        of concepts, state of the art, research, standards,
        implementations, running experiments, applications, and
        industrial case studies. Authors are invited to submit complete
        unpublished papers, which are not under review in any other
        conference or journal in the following, but not limited to,
        topic areas.<br>
      <br>

        All tracks are open to both research and industry contributions,
        in terms of Regular papers, Posters, Work in progress,
        Technical/marketing/business presentations, Demos, Tutorials,
        and Panels.<br>
      <br>

        Before submission, please check and conform with the Editorial
        rules: <a class=3D"moz-txt-link-freetext" href=3D"http://www.iaria.=
org/editorialrules.html">http://www.iaria.org/editorialrules.html</a><br>
      <br>

        MOBILITY 2011 Topics (topics and submission details: see CfP on
        the site)<br>
      <br>
      <b>Mobile architectures, mechanisms, protocols</b><br>

        Mobility and wireless; Mobility enabling protocols; Mobile
        software; Service composition in mobile environments; Knowledge
        and service discovery in mobile environments; On-demand
        mobility; User presence in mobile environments; Replication in
        mobile environments; Middleware for mobile environments;
        Internet and mobility; Software architecture for mobile
        applications<br>
      <b><br>
          Mobile networking and management</b><br>

        Fundamentals of mobile networks; Mobile-Fixed interworking;
        Heterogenous networks; Beyond IMT-A; Mobile network
        virtualization; Femtocells and relays; Mobile cells; Mobile
        network sharing and network access; Self-management of mobile
        networks; Mobility management; Access control in mobile
        environments; Advanced roaming concepts; Mobile network
        edge-based service delivery platforms; Mobile content delivery
        networks; Mobile peer-to-peer systems; Mobile VPNs; Quality of
        experience in mobile networks<br>
      <br>
      <b>Mobile devices and services</b><br>

        Smart mobile devices; Embedded mobile; Sensors and mobiles;
        Mobile media, mobile content; Mobile applications (mobile
        learning, mobile healthcare, etc.); Mobile games; Mobile
        business; Mobile Web applications; Apps versus Web; Novel
        software concepts for mobile services; Mobile- and micro
        payment; mCommerce<br>
      <br>
      <b>Mobile prosumers and interfaces</b><br>

        User interaction and mobility; Mobile communities; Mobile Web
        interfaces and interaction techniques; Implementations and
        experimental mobile systems; Mobile Web; Mobile search and
        advertising<br>
      <br>
      <b>Mobile Internet of Things</b><br>

        Future mobile Internet; Internet of Things; Machine to Machine,
        People, Business (M2x); Online; Smart Homes; Smart Cities<br>
      <br>
      <b>Vehicular mobile technology</b><br>

        Architectures and platforms; Vehicular ad hoc networks;
        Vehicular routing metrics and supporting protocols; Mobility
        management and topology control; Standardization of vehicular
        networks; User aspects; Business enablers<br>
      <br>
      <b>Challenges in mobile environments</b><br>

        Security and privacy environments; Protection and safety of
        distributed mobile data; Context-aware mobility and privacy;
        Mobile emergency communication and public safety; Location-based
        services; Micro-payments; Accuracy and preciseness in localizing
        mobile entities<br>
      <br>

        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>

        MOBILITY General Chair<br>

        Josef Noll, University of Oslo &amp; Movation, Norway<br>
      <br>

        MOBILITY Advisory Committee<br>

        Petre Dini, Concordia University, Canada &amp; IARIA, USA<br>

        Pekka Jappinen. Lappeenranta University of Technology, Finland<br>
      <br>

        MOBILITY Industry Liaison Chairs<br>

        Filipe Cabral Pinto, Telecom Inova=E7=E3o S.A., Portugal<br>

        Xiang Song, Microsoft, USA<br>

        Xun Luo, Qualcomm Inc. - San Diego, USA<br>
      <br>

        MOBILITY Special Area Chairs on Video<br>

        Mikko Uitto, VTT Technical Research Centre of Finland, Finland<br>
      <br>

        MOBILITY Special Area Chairs on Mobile Wireless Networks<br>

        Mohammad Mushfiqur Chowdhury, University of Oslo, Norway<br>

        Masashi Sugano, Osaka Prefecture University, Japan<br>
      <br>

        MOBILITY Special Area Chairs on Mobile Web / Application<br>

        In-Young Ko, Korea Advanced Institute of Science and Technology
        (KAIST), Korea<br>
      <br>

        MOBILITY Special Area Chairs on Context-aware, Media, and
        Pervasive<br>

        Brent Lagesse, Oak Ridge National Laboratory, USA<br>
      <br>

        MOBILITY Special Area Chairs on Mobile Internet of Things and
        Mobile Collaborations<br>

        J</font></font></small><font size=3D"3"><span style=3D"font-size: 1=
2pt; line-height: 115%; font-family: &quot;Times New Roman&quot;;">=F6</spa=
n><font face=3D"Times New Roman, Times, serif">rn Franke, SAP Research
        Center - Sophia Antipolis, France<br>
        Nils Olav Skeie, University College Telemark, Norway<br>
        <br>
        MOBILITY Special Area Chairs on Vehicular Mobility<br>
        Gianluca Franchino, CEIICP - Scuola Superiore Sant'Anna - Pisa,
        Italy<br>
        <br>
        MOBILITY Special Area Chairs on Mobile Cloud Computing<br>
        Chunming Rong, University of Stavanger, Norway<br>
        Josef Noll, Center for Wireless Innovation, Norway<br>
        <br>
        MOBILITY Publicity Chairs<br>
        Aline Carneiro Viana, INRIA Saclay - Ile de France - Orsay,
        France<br>
        Sarfraz Alam, UNIK-University Graduate Center, Norway<br>
        <br>
        Committee:
        <a class=3D"moz-txt-link-freetext" href=3D"http://www.iaria.org/con=
ferences2011/ComMOBILITY11.html">http://www.iaria.org/conferences2011/ComMO=
BILITY11.html</a><br>
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</font></font></div></body></html>
------=_Part_1868133_1857107082.1291895068709--

Date: Wed, 8 Dec 2010 16:35:50 -0800 (PST)
From: soumya raj <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Research area

--0-994725655-1291854950=:40448
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,=0AI am a graduate student, exploring various research areas in the =
field of =0Acomputer networks to identify a research area.=0ADTN is certain=
ly=A0one of the hot areas of computer networking research. I would =0Agreat=
ly appreciate any suggestions for short term research (max 3 months) in =0A=
DTN, pointers to under-explored areas and so on.=A0 I am looking forward to=
 =0Aexplore DTN as a potential research area.=0A=0AThanks for your suggesti=
ons,=0ASoumya=0A=0A=0A      
--0-994725655-1291854950=:40448
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><DIV style=3D"FONT-FAMILY: times new roman, new york, times=
, serif; FONT-SIZE: 12pt">=0A<DIV>Hi all,</DIV>=0A<DIV>I am a graduate stud=
ent, exploring various research areas in the field of computer networks to =
identify a research area.</DIV>=0A<DIV>DTN is certainly&nbsp;one of the hot=
 areas of computer networking research. I would greatly appreciate any sugg=
estions for short term research (max 3 months) in DTN, pointers to under-ex=
plored areas and so on.&nbsp; I am looking forward to explore DTN as a pote=
ntial research area.</DIV>=0A<DIV>&nbsp;</DIV>=0A<DIV>Thanks for your sugge=
stions,</DIV>=0A<DIV>Soumya</DIV></DIV></div><br>=0A=0A      </body></html>
--0-994725655-1291854950=:40448--

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 6 Dec 2010 09:42:54 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Brad, there's a reason that the term "reliability" does not appear in the discussion of the "streaming" flag in the ECOS I-D: the feature is not intended as a reliability control (although in practice it would result in the selection of CL protocols that are colloquially characterized as "reliable" or "unreliable").

The purpose of the "streaming" flag is strictly and precisely to suppress retransmission, exactly as noted in the specification, nothing more.  The reason for it is the requirement -- identified at JPL, if nowhere else -- to support the transmission of real-time "streaming" data over DTN; the rationale is briefly discussed in the I-D.  It *does not* describe reliability in general terms or provide a general "hint" about reliability.  It *does not* describe (or even refer to) reliability in any way.  "Streaming" is exactly and explicitly what it is all about.

It would be a mistake to puff up this humble little flag, serving a very limited, constrained purpose for which there is a well-defined need, into a general "reliability" control, especially when we're evidently months or years away from reaching consensus on what "reliability" means and how best to express that in protocol.

But sure, there may well also be a requirement for some sort of Reliability control in the ECOS block, and perhaps also some sort of Discardability control (though there's got to be a better word for it).

How about this?  Let's define two additional flags in the Flags byte of the ECOS block:

-	The 0x08 bit, if True, indicates that the "flow label" in this ECOS block (if present; otherwise, the "ordinal" byte) is followed by a numeric "reliability code" in SDNV representation.

-	The 0x10 bit, if True, indicates that the "reliability code" in this ECOS block (if present; otherwise, the "flow label" if present; otherwise, the "ordinal" byte) is followed by a numeric "discardability code" in SDNV representation.

Using SDNVs here gives us plenty of expressive power, so the encoding of the "reliability" and "discardability" control specifications can be as rich as you like.  Implementations that want to use these features can do so, and those that don't yet see a need for them can omit them at no cost in bandwidth, just by leaving the flags unset.  So we'll be using the BP extensions mechanism as a way to explore the utility of these features in practical operation, exactly as it was designed to do.

If you can give me some text defining the reliability and discardability codes you'd like to use, I will happily add them to the ECOS I-D and post a new version.  Or, if you'd prefer to spend some more time on that coding, I can handle them for now in the same way as "flow label" is handled in the text.

Scott

-----Original Message-----
From: Moore, Brad [mailto:[email-masked]] 
Sent: Friday, November 26, 2010 10:10 AM
To: [email-masked]; Burleigh, Scott C (313B); [email-masked]
Subject: RE: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Lloyd Wood wrote:
> Reliable delivery or reliable as in error-free? The concepts are
> confused

I agree that there are multiple sub-properties that fall under the
"reliability" heading.
For example, error-free as in error-detecting, or error-correcting?

One approach would be to define specific flags for each of these
sub-attributes
so that a CL, such as the Saratoga CL (from what you describe), could
take advantage
of its richer feature set and address these attributes with precise
control.

Another approach, (the one that seems to be taken with the ecos draft)
is to
provide a very minimal set of flags that describe reliability in very
general terms,
and it is up to the CL, and the configuration of a Bundle Agent, to
determine how best to
interpret the general hint, and map to specific features of the CL.

I am not sure which of these two approaches is more appealing to me, but
in my opinion the
second approach needs more than just a single flag to represent a
reasonable set of semantics.
Some middle ground is needed.

The more control flags are added to the second approach, the more that
approach starts to
look like the first approach. My position right now is that adding one
more flag to the ecos
proposal is probably good enough to satisfy most needs, though I could
be convinced more towards the
first approach.

I agree that the terminology can be improved though. In fact, I think
"Streaming" can be misleading as well. I foresee the Streaming
flag being used in cases where the associated bundles are not
really part of a stream. Similarly, there can be cases there
streaming is occurring (possibly over TCP as you mention) 
where the Streaming flag may be undesirable.

First, what are the semantic attributes that might be associated with
setting the streaming flag?

 Setting the streaming flag might imply and affect some or all of the
following;
  1. Higher Speed - Lighter weight protocol sends data more quickly
  2. Lower bandwidth usage - Less data being sent 
  3. Lower delivery reliability - less or no resends
  4. Less error detection
  5. Less error correction
  6. Higher discardability - drop bundle if queue build up occurs, 
                             possibly forward only, instead of store and
forward
  7. Less persistence (possibly store in volatile memory rather than on
disk)

I see congestion control between the sender and the receiver 
(communicating round trip times for example) as being a configuration
of the CL as a function of the system contraints independent of the
setting of the streaming flag). Local congestion control (what I call
discardability)
however is more a function of the bundle agent than the CL.

If we set a reliability flag (or if we stuck with only the streaming
flag and this flag was not set), I see that would imply some or all of
the following;

  1. Lower Speed - Heavier weight protocol sends data at a slower rate
  2. Higher bandwidth usage - more data being sent 
  3. Higher delivery reliability - Resends >= 1
  4. More error detection (checksum?)
  5. More error correction (FEC?)
  6. Lower discardability - Avoid dropping bundle if at all possible
  7. More persistence Store on disk or non-volatile memory.

Note that these flags (both streaming, and reliability) can affect more
than just the selection
of CL. It may also affect queue management within the bundle agent for
example.

It's difficult to come up with a label for a single flag that describes
all of these effects.

Having two flags can make this easier, provided that the labels for the
flags are not
the boolean negation of each other. (eg. Streaming vs non-streaming, or
reliable vs non-reliable)

I think if the flags were labeled "Speed" (instead of "Streaming"), and
"Accuracy" (instead of "reliable"), then this would better capture the
semantics.

(Speed=> true, Accuracy=> false) seems to capture the effects associated
with the current streaming flag quite well.

Whereas;

(Speed=> false, Accuracy=> true) conversly seems to capture the effects
assocated with the other end of the spectrum.

As in real life, one cannot generally have both speed and accuracy
unless as some sort of compromise,
So;
(Speed=> true, Accuracy=> true) would be interpretted as being an
interest in both properties and represented as some middle ground
between the two, based on the available CL's, and their capabilities.

(Speed=> false, Accuracy=> false) indicates that neither of these
properties are of interest, and any decisions for the handling of a
bundle should be left to the default behaviours of the bundle agent and
CL.

Brad Moore

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