Subject: [dtn-interest] DTN architecture issues for handling Huge Content Objects

From: John Zinky <[email-masked]>
Date: Tue, 4 Dec 2012 18:00:29 -0500

Kevin Fall says:
[The Erasure Coding] document really defines a new, different architecture that seems to use DTN as a sort of transport mechanism underneath yet it also seems to liberally make changes in a variety of bits and pieces of the existing structure, protocols and even architecture

I think the DTN architecture you are referring to is a DTN envisioned as a push model of content (payload) to destination (URI). Given delays and disruption, the DTN push is open loop (one-way) reducing reliance on end-to-end feedback. 

Erasure Coding embraces that architecture, but unfortunately Huge Content (multiple GBs) can not go into one bundle. So this may be the first use case where DTN must deal with the end-to-end transfer of GROUPS of bundles. 

Dealing with End-to-End issues and multiple bundles is traditionally done by the transport, session, and presentation layers. But if you look at the Erasure Coding suite, it seems to cross cut this layered protocol model. See Slide 20 in:
  https://dist-systems.bbn.com/papers/2011/Zinky/ErasureCodingExtBlockSpec-IRTF-2011-07-25-Rev1-2-2.pdf

I would claim that all Quality of Service (QoS) management issues cross-cut the OSI layering model. Getting QoS into the TCP/IP stack has been hard because of the information hiding restrictions of a layered architecture. DTN by its very name is suppose to handle extreme QoS issues and in my opinion would benefit from a non-layered architecture. 

What I mean is that the DTN extension blocks could be organized so that they do not form a nested layer of headers, but instead are open to multiple protocol aspects each of which can peak and poke into any extension block they choose. This architecture was proposed in:

Robert Braden, Ted Faber, and Mark Handley. 2003. From protocol stack to protocol heap: role-based architecture. SIGCOMM Computer. Comm. Rev. 33, 1 (January 2003), 17-22. DOI=10.1145/774763.774765 
  http://doi.acm.org/10.1145/774763.774765

And I used it successfully in the Cougaar Agent System Message transport. See section 4 of
  https://dist-systems.bbn.com/papers/2007/DOA/

I think your criticism of the EC suite is that it has to touch so many layers. But I think that is an opportunity, not a flaw. DTN actually has the chance of creating a different kind of protocol suite, one not based on layers, but based on composeable building blocks. 

Note, Erasure Coding needs to deal with several issues that overlap with other building blocks.
 1) grouping bundles (session)
 2) End-to-End transfer requirement (transport)
 3) Forwarding order (Handling specification)
 4) Object format (presentation)

Some of these feature where added to the single Erasure Coding extension block. But that extension block could be divided into multiple pieces if more a comprehensive approach was taken for designing a holistic DTN protocol suite.

For example, the handling spec should be pulled out into an extension block that specifically deals with choosing the order of which bundles to send to neighbors. But that is a topic for a different thread.

So the question for the community is:
"How should a DTN protocol suite be designed that can handle the wide range of Application with a wide range of QoS requirements?"

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Wed, 5 Dec 2012 18:53:55 +0000

John, some comments in-line below.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Tuesday, December 04, 2012 3:00 PM
To: [email-masked]
Subject: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Kevin Fall says:

	>>>	Is this really true?  Payload size is an SDNV, and bundle fragmentation in DTN is pretty well defined; there's nothing in the spec to prevent you from sending a Huge Content item in a single bundle, then proactively fragmenting that bundle into N fragmentary bundles.  The fragments would then be forwarded to the destination endpoint, where their fragmentary payloads would be reassembled into the original Huge Content item for delivery.  In this sense, dealing with the end-to-end transfer of a group of related bundles has been covered by DTN for many years, right?

	>>>	But in DTN the bundle protocol handles all these issues.  There are some end-to-end issues, such as end-to-end acknowledgment, that must be handled at a layer above BP, but fragmentation and reassembly isn't one of them.

	>>>	Which it already has, to some extent, because additional features such as QoS are added in extension blocks (e.g., BSP and Extended Class of Service) rather than in additional layers.
 
What I mean is that the DTN extension blocks could be organized so that they do not form a nested layer of headers, but instead are open to multiple protocol aspects each of which can peak and poke into any extension block they choose.

	>>>	Sure, this is already the case.  The only DTN extension blocks that can be said to nest are the BSP extensions, and I there's a strong argument for removing that nesting as well.

This architecture was proposed in:

	>>>	And in fact it is already doing so.  Layering doesn't go away altogether: there are still application protocols that shouldn't be made part of BP, so they're at a different layer, and there are still underlying transport protocols that shouldn't be made part of BP, so they're at a different layer.  But anything that has to do with operating the network itself does indeed go into extension blocks rather than into additional layers.

	>>>	But grouping of bundles is already handled by core BP (fragmentation and reassembly), and forwarding order is already handled by BP's class of service and the various routing mechanisms.  And does payload format actually have anything to do with erasure coding, or indeed with network operation at all?
	>>>	Incorporating erasure coding into an end-to-end transfer service may indeed make a lot of sense, but that is the one piece of the picture that really *should* be at a layer above BP.  It ought to be operating only at the ends, not at every bundle forwarding agent along the path.
	>>>	Given all of which, I don't see a strong argument for redesigning the Bundle Protocol.  What am I missing?

_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 5 Dec 2012 13:28:13 -0600

> Erasure Coding embraces that architecture, but unfortunately Huge Content
> (multiple GBs) can not go into one bundle. So this may be the first use case
> where DTN must deal with the end-to-end transfer of GROUPS of bundles.
> 
>>>> Is this really true?  Payload size is an SDNV, and bundle fragmentation in
>>>> DTN is pretty well defined; there's nothing in the spec to prevent you from
>>>> sending a Huge Content item in a single bundle, then proactively
>>>> fragmenting that bundle into N fragmentary bundles.  The fragments would
>>>> then be forwarded to the destination endpoint, where their fragmentary
>>>> payloads would be reassembled into the original Huge Content item for
>>>> delivery.  In this sense, dealing with the end-to-end transfer of a group
>>>> of related bundles has been covered by DTN for many years, right?

But Reactive Fragmentation  and proactive fragmentation in the middle of a
transmission and Bundle Security do not mix.  FEC may not have this problem
if done at the source.  It is analogous to proactive fragmentation then
securing each bundle.

> 
>>>> But grouping of bundles is already handled by core BP (fragmentation and
>>>> reassembly), and forwarding order is already handled by BP's class of
>>>> service and the various routing mechanisms.  And does payload format
>>>> actually have anything to do with erasure coding, or indeed with network
>>>> operation at all?
>>>> Incorporating erasure coding into an end-to-end transfer service may indeed
>>>> make a lot of sense, but that is the one piece of the picture that really
>>>> *should* be at a layer above BP.  It ought to be operating only at the
>>>> ends, not at every bundle forwarding agent along the path.

Agreed.  Otherwise more things will break.

>>>> Bundle Protocol.  What am I missing?

For erasure codes I agree. There are a whole lot of other reasons to
redesign the protocol.  But that is another issue.

> "How should a DTN protocol suite be designed that can handle the wide range of
> Application with a wide range of QoS requirements?"

If you want it widely deployed, sure.

-Will

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Wed, 5 Dec 2012 20:38:15 +0000

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2012 11:28 AM
To: Burleigh, Scott C (313B); John Zinky; [email-masked]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

> Erasure Coding embraces that architecture, but unfortunately Huge 
> Content (multiple GBs) can not go into one bundle. So this may be the 
> first use case where DTN must deal with the end-to-end transfer of GROUPS of bundles.
> 
>>>> Is this really true?  Payload size is an SDNV, and bundle 
>>>> fragmentation in DTN is pretty well defined; there's nothing in the 
>>>> spec to prevent you from sending a Huge Content item in a single 
>>>> bundle, then proactively fragmenting that bundle into N fragmentary 
>>>> bundles.  The fragments would then be forwarded to the destination 
>>>> endpoint, where their fragmentary payloads would be reassembled 
>>>> into the original Huge Content item for delivery.  In this sense, 
>>>> dealing with the end-to-end transfer of a group of related bundles has been covered by DTN for many years, right?

But Reactive Fragmentation  and proactive fragmentation in the middle of a transmission and Bundle Security do not mix.  FEC may not have this problem if done at the source.  It is analogous to proactive fragmentation then securing each bundle.

	>>>	Will, I think that might well be an argument against doing reactive fragmentation and/or mid-stream proactive fragmentation (though I'm not altogether convinced of this).  But the fact remains that core BP already handles end-to-end transfer of groups of related bundles, right?

>>>> But grouping of bundles is already handled by core BP 
>>>> (fragmentation and reassembly), and forwarding order is already 
>>>> handled by BP's class of service and the various routing 
>>>> mechanisms.  And does payload format actually have anything to do 
>>>> with erasure coding, or indeed with network operation at all?
>>>> Incorporating erasure coding into an end-to-end transfer service 
>>>> may indeed make a lot of sense, but that is the one piece of the 
>>>> picture that really
>>>> *should* be at a layer above BP.  It ought to be operating only at 
>>>> the ends, not at every bundle forwarding agent along the path.

>>>> the Bundle Protocol.  What am I missing?

For erasure codes I agree. There are a whole lot of other reasons to redesign the protocol.  But that is another issue.

	>>>	Sure, I think we all have our lists of things we'd like to see changed in an RFC 5050bis.  But not quite yet.

> "How should a DTN protocol suite be designed that can handle the wide 
> range of Application with a wide range of QoS requirements?"

-Will

---

From: John Zinky <[email-masked]>
Date: Wed, 5 Dec 2012 17:06:27 -0500

Scott,
One of your main concerns is about the concept of "grouping" bundles.

> 	>>>	Is this really true?  Payload size is an SDNV, and bundle fragmentation in DTN is pretty well defined; there's nothing in the spec to prevent you from sending a Huge Content item in a single b…

The DTN fragmentation has the same functionality as IP Fragmentation. It is really used to get around limitations in the CLA link protocols. In general, there is a practical limit on the size of a bundle, either because of protocol limits (such as UDP), or contact time. The main advantage of fragmentation is the ability to make a fragment of a fragment. If one could come up with an FEC scheme that could make smaller encodings from a large encoding, we could unify fragmentation and FEC. (Hint Hint FEC researchers).

In the EC use case, A "Group of Bundles" really are independent bundles that are related to each other and not to other bundles, much like a session layer. Forwarding rules and routing can take advantage the grouping metadata.

Some examples of bundle groups may be video streams, situational awareness status tracking, a database archive journal, and query/response (BPQ). All of these applications need a group ID and forwarding rules are different for intra-group vs inter-group. For example:
1) For situational awareness, new bundles from the same group should be sent before old bundles. 
2) For an archive journal, journal update bundles should be delivered in order. 
3) For A video stream that is hierarchically encoded, bundles on different tiers have a different drop probability. 
4) For query/response, responses to the same query may be reused between multiple clients
5) For Erasure Encoding where all the bundles are equivalent, the order of transmission in the group should be random or round-robin. 

So how does the BPA decide the order to send bundles for a new contact when one application requires its group of bundles to use a FIFO queue and other wants LIFO queue? This is an opportunity that TCP/IP, just can't handle!

> 	>>>	Incorporating erasure coding into an end-to-end transfer service may indeed make a lot of sense, but that is the one piece of the picture that really *should* be at a layer above BP.  It ought…

The reason Erasure Coding is not just End-to-End is to take advantage of routing tricks. A BPA inside the network can perform several functions that will enhance the probability of delivery of the content (encoded in a group of bundles).   For example, a BPA can "Recode" a new Encoding bundle from a group of previous received bundles, so that a duplicate bundle is never sent over any link in the network. Also, the Hennesey CHANTS 2012 paper has cool stoping rules for forwarding Recoded bundles, based on knowing the Rank of the information about the Data Object, and not the specific encoding bundles.

We have implemented Erasure Coding Routing in DTN 2.9 BPA and the University of Maryland guys (under Greg Stein) are currently analyzing the tradeoffs. We also implemented pure DTN applications that work solely end to end, but their performance is improved with a little help from the BPAs along the path.

> 	>>>	Given all of which, I don't see a strong argument for redesigning the Bundle Protocol.  What am I missing?

I am NOT suggesting a redesign of the bundle protocol. On the contrary I would like to see the scope increased to create a holistic DTN protocol suite. A lot of effort has been expended on DTN routing protocols. But I think the Erasure Coding use case shows that not enough effort has been expended on end-to-end and forwarding rules.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 5 Dec 2012 16:26:10 -0600

>>>>> dealing with the end-to-end transfer of a group of related bundles has
>>>>> been covered by DTN for many years, right?
> 
> transmission and Bundle Security do not mix.  FEC may not have this problem if
> done at the source.  It is analogous to proactive fragmentation then securing
> each bundle.
> 
>>>>     Will, I think that might well be an argument against doing reactive
>>>> fragmentation and/or mid-stream proactive fragmentation (though I'm not
>>>> altogether convinced of this).  But the fact remains that core BP already
>>>> handles end-to-end transfer of groups of related bundles, right?
> 
Scott, About 2008 or so we showed the usefulness of reactive fragmentation.
In a scheduled network where everything is know and transport delays between
systems may be long, reactive fragmentation may not be to useful, but for
opportunistic networks, reactive fragmentation is likely to be the norm.
You don't know how long the contact will be or when it will end.  You have
sent 7 Mbytes of a 10 Mbyte file.  It sure would be nice to just send the
remainder.  But BPS and reactive fragmentation don't mix in the current
design.

- Will

---

From: <[email-masked]>
Date: Thu, 6 Dec 2012 00:46:35 +0000

> The DTN fragmentation has the same functionality as IP Fragmentation.

only if you believe a bundle is a replacement for an IP packet, rather than being a replacement for a MIME-type file object. We've moved large bundles (hundreds of megabyte files) from orbit, so we believe that a bundle was not intended to be a little IP packet.

> It is really used to get around limitations in the CLA link protocols. In general, there is a practical limit on the size of a bundle, either because of protocol limits (such as UDP), or contact time.

Contact time (constrained by location/visibility/power) is often the driver in a delay tolerant network, especially when you're bringing across large amounts of sensor data. Protocol limits (such as LTP implementation 64K limitations) should not be a factor.

Given the deficiencies in the bundle protocol design (reliability, clocking, etc.), the claim that the bundle protocol compensates for limitations in the CLA _transport_ protocols (again, bundle is not IP), when the reverse is obviously the reality (and there's a reason most bundle work has been done over TCP), is really rather amusing, 

Lloyd Wood
http://sat-net.com/L.Wood/dtn

---

From: "Fall, Kevin" <[email-masked]>
Date: Thu, 6 Dec 2012 01:28:38 +0000

Some comments below..

On 12/5/12 4:46 PM PST, "[email-masked]" <[email-masked]> wrote:

>only if you believe a bundle is a replacement for an IP packet, rather
>than being a replacement for a MIME-type file object. We've moved large
>bundles (hundreds of megabyte files) from orbit, so we believe that a
>bundle was not intended to be a little IP packet.

Right.  The DTN fragmentation isn't intended for the same purposes as IP
fragmentation.
While IP fragmentation is about adapting an abstract datagram (IP
datagram) to be carried on various underlying link layers, DTN
fragmentation is about dividing a big thing into chunks appropriate to
contacts (for proactive fragmentation) and to help in recovery for
unexpected outages (for reactive).

>
>> It is really used to get around limitations in the CLA link protocols.
>>In general, there is a practical limit on the size of a bundle, either
>>because of protocol limits (such as UDP), or contact time.
>
>Contact time (constrained by location/visibility/power) is often the
>driver in a delay tolerant network, especially when you're bringing
>across large amounts of sensor data. Protocol limits (such as LTP
>implementation 64K limitations) should not be a factor.

I also agree with Lloyd here.  There may be limitations in the current
implementation due to selections of the particular transport, but the
underlying shouldn't really be the driver for the top interface.

>
>Given the deficiencies in the bundle protocol design (reliability,
>clocking, etc.), the claim that the bundle protocol compensates for
>limitations in the CLA _transport_ protocols (again, bundle is not IP),
>when the reverse is obviously the reality (and there's a reason most
>bundle work has been done over TCP), is really rather amusing,

This is not correct.  Indeed the DTN architecture (and the BP) are
intended to deal with a certain set of underlying limitations (e.g., size
limitations, connectivity limitations, issues with interconnection of
disparate name space structures).  While I would also not call CLA
"transport protocols", the BP does pretty much what was intended.

- K

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Dec 2012 01:31:00 +0000

On 12/06/2012 12:46 AM, [email-masked] wrote:
> Protocol limits (such as LTP implementation 64K limitations) should not be a factor.

DTN2/LTPlib has no such limit (LTPlib has lots of my crap code
but nothing like that;-), and I don't think recent ION versions
do either, so I dunno what you mean there.

S.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 6 Dec 2012 01:54:04 +0000

But I'd argue that you can do just as well with proactive fragmentation within the network.  "Would be nice" implies that there is some value in retransmitting 3 MB instead of all 10 MB of the bundle.  How much value is that?  If your link is running at 1 Gbps then the extra cost of not doing reactive fragmentation is .056 seconds of transmission, which you incur not for every bundle but only for the bundle that you're transmitting at the end of the contact.  If your mean contact duration is 5 minutes, then the cost of not doing retransmission is .0187% of your bandwidth.  Whereas if you are doing reactive fragmentation then you are paying for additional signaling traffic for all of your bundle transmissions; does the benefit of doing reactive fragmentation (that is, the cost of not doing it) outweigh that cost in additional bandwidth consumption?  (Certainly there's no other benefit, right?)

Okay, suppose your link is only 4800 bps.  Now the extra cost of not doing reactive fragmentation is 11,667 seconds of transmission -- unless you do proactive fragmentation at the time you start sending the bundle, i.e., you break off 600-byte fragments of the bundle one at a time and send them over the link.  Now when the link fails the cost of not doing reactive fragmentation is one entire bundle, but it's only 600 bytes long, still only 1 second of transmission.  Sure, you're paying more in overhead because you're sending more bundles, but you'd also be paying plenty more in overhead if you were sending reactive fragmentation signals fast enough to achieve the same effect.

This is of course a topic on which we've been arguing for over a decade in DTNRG and I am confident that I haven't changed many minds here.  I just want to suggest that it's possible to engineer DTN to be relatively efficient over an opportunistic contact without jettisoning bundle authentication.

Scott

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2012 2:26 PM
To: Burleigh, Scott C (313B); John Zinky; [email-masked]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

>>>>> fragmentation in DTN is pretty well defined; there's nothing in 
>>>>> the spec to prevent you from sending a Huge Content item in a 
>>>>> single bundle, then proactively fragmenting that bundle into N 
>>>>> fragmentary bundles.  The fragments would then be forwarded to the 
>>>>> destination endpoint, where their fragmentary payloads would be 
>>>>> reassembled into the original Huge Content item for delivery.  In 
>>>>> this sense, dealing with the end-to-end transfer of a group of 
>>>>> related bundles has been covered by DTN for many years, right?
> 
> But Reactive Fragmentation  and proactive fragmentation in the middle 
> of a transmission and Bundle Security do not mix.  FEC may not have 
> this problem if done at the source.  It is analogous to proactive 
> fragmentation then securing each bundle.
> 
>>>>     Will, I think that might well be an argument against doing 
>>>> reactive fragmentation and/or mid-stream proactive fragmentation 
>>>> (though I'm not altogether convinced of this).  But the fact 
>>>> remains that core BP already handles end-to-end transfer of groups of related bundles, right?
> 
Scott, About 2008 or so we showed the usefulness of reactive fragmentation.
In a scheduled network where everything is know and transport delays between systems may be long, reactive fragmentation may not be to useful, but for opportunistic networks, reactive fragmentation is likely to be the norm.
You don't know how long the contact will be or when it will end.  You have sent 7 Mbytes of a 10 Mbyte file.  It sure would be nice to just send the remainder.  But BPS and reactive fragmentation don't mix in the current design.

- Will

---

From: John Zinky <[email-masked]>
Date: Thu, 6 Dec 2012 15:15:55 -0500

A deployment context has an effective Maximum Transmission Unit (MTU), whether the limitation comes from a CLA (such as the UDP-Link CLA used on radio broadcast channels) or Contact time. If the source is somehow privy to this runtime constraint (MTU metadata), the Data Object can be divided into appropriate size bundles proactively. As with all QoS adaption the key is to dynamically identify the situation at runtime (effective MTU) and apply the appropriate mechanism (Fragmentation or Encoding). One size does not fit all.

The Eraser Coding draft and the DTN 2.9 implementation offers a different mechanism of reactive fragmentation.  Erasure Coding can be applied to a Big Bundle inside the BPA. The Big Bundle wire-format is treated as a Data Object, encoded by the source BPA,  the Encoding Bundles sent to a destination BPA that decodes the Big Bundle, and the destination reinserts the bundle into the DTN. The group of bundles acts like a tunnel to get the Big Bundle from one place in the DTN to another. The Destination can be chosen based on the runtime situation and does not have to be the same BPA as the destination EID. See Slide 9 in:
  https://dist-systems.bbn.com/papers/2011/Zinky/ErasureCodingExtBlockSpec-IRTF-2011-07-25-Rev1-2-2.pdf

On Dec 5, 2012, at 8:28 PM, "Fall, Kevin" <[email-masked]> wrote:

> The DTN fragmentation isn't intended for the same purposes as IP
> fragmentation. While IP fragmentation is about adapting an abstract datagram (IP datagram) to be carried on various underlying link layers, DTN fragmentation is about dividing a big thing into chunks appropriate to contacts (for proactive fragmentation) and to help in recovery for unexpected outages (for reactive).

On Dec 5, 2012, at 8:54 PM, "Burleigh, Scott C (313B)" <[email-masked]> wrote:

> But I'd argue that you can do just as well with proactive fragmentation within the network.  "Would be nice" implies that there is some value in retransmitting 3 MB instead of all 10 MB of the bundle.  How much value is that?  
...
> Okay, suppose your link is only 4800 bps.  Now the extra cost of not doing reactive fragmentation is 11,667 seconds of transmission -- unless you do proactive fragmentation at the time you start sending the bundle, i.e., you break off 600-byte fragments of the bundle one at a time and send them over the link.  Now when the link fails the cost of not doing reactive fragmentation is one entire bundle, 
...

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 6 Dec 2012 20:46:03 +0000

To clarify what I was suggesting: BP fragmentation can occur at any point on the end-to-end path, and there's nothing in RFC5050 that says that fragmentation has to result in multiple segments that are all of the same size.  This means it's never necessary for the source to know any sort of global MTU size that applies to the whole path.  When a bundle (which may itself be a fragment) residing at any node along the path (not just the source) is about to be forwarded over a link for which it is too large (as determined by the forwarding BPA from local knowledge, acquired however), the BPA can divide that bundle into two fragments: fragment A that is small enough to be efficiently forwarded over this specific link at this particular moment in time, and fragment B that is the rest of the bundle.  Fragment A can then be forwarded, whereupon the same consideration can then be given to fragment B, and so on.  This is generally efficient, highly adaptive, sensitive to even rapidly changing local conditions, and simple.

In CCSDS we've got the beginnings of a spec for something called "Delay-Tolerant Payload Conditioning" (DTPC) which would be the common site for a variety of optional end-to-end services, somewhat TCP-like.  It would be a standardized application service layer -- similar to a transport layer -- running immediately above BP.  (Not quite ready to post as an Internet Draft, but soon, I hope.)  We've thought about adding erasure coding as a DTPC service, which I suspect would have much the same effect as the procedure proposed in the Erasure Coding draft.  I think running LTP over an erasure-coded link service also would make a lot of sense, and in fact the two would not be mutually exclusive.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Thursday, December 06, 2012 12:16 PM
To: [email-masked]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

...
> Okay, suppose your link is only 4800 bps.  Now the extra cost of not 
> doing reactive fragmentation is 11,667 seconds of transmission -- 
> unless you do proactive fragmentation at the time you start sending 
> the bundle, i.e., you break off 600-byte fragments of the bundle one 
> at a time and send them over the link.  Now when the link fails the 
> cost of not doing reactive fragmentation is one entire bundle,
...

---

From: John Zinky <[email-masked]>
Date: Thu, 6 Dec 2012 17:23:22 -0500

On Dec 6, 2012, at 3:46 PM, "Burleigh, Scott C (313B)" <[email-masked]> wrote:

> [BP fragmentation] is generally efficient, highly adaptive, sensitive to even rapidly changing local conditions, and simple.

I would also like to clarify that while Erasure Coding and reactive fragmentation overlap, neither can subsume the other.

I see no conflict having both Erasure Coding and Fragmentation, each has a situation where it is the most effective mechanism.

---

From: John Zinky <[email-masked]>
Date: Thu, 6 Dec 2012 17:30:02 -0500

Scott,
I hope that your new application services will put their headers as extension blocks and not layer them inside the bundle payload. I was really encouraged by your previous posts about non-layered protocols!

On Dec 6, 2012, at 3:46 PM, "Burleigh, Scott C (313B)" <[email-masked]> wrote:

> It would be a standardized application service layer -- similar to a transport layer -- running immediately above BP.

> The only DTN extension blocks that can be said to nest are the BSP extensions, and I there's a strong argument for removing that nesting as well.