Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

From: John Zinky <[email-masked]>
Date: Tue, 4 Sep 2012 12:16:15 -0400

The Erasure Coding specification exposes many protocol design issues that are intrinsic to disruption tolerant networks (DTNs). Specifically, that DTN services tend to crosscut traditional network layering.

Forward Error correction in IP networks is a property of the link layer to remove physical channel errors or end-to-end drops then the transport layer. The forward error correction scheme can be tailored to the channel error characteristics, and there is a wide continuum of solutions that can trade off end station processing against channel overhead. The choice of the FEC can be dynamically determined at runtime, based on real-time measurements. 

But DTNs have extreme channel characteristics, with high drop rates, reordering, duplicates, and long delays. Basically, the DTN network is running open loop with very little or no end-to-end feedback.

The result was that for even a strait forward service, such as FEC, the service design touched many layers in the DTN protocol suite. The design had to specify how to set the primary block parameters, added an extension block, and even specify the format of the payload. 
  http://tools.ietf.org/html/draft-irtf-dtnrg-zinky-erasure-coding-extension-00

The open question for discussion is, if DTNs services do not layer nicely and each service needs to use and set parameters across multiple layers. How should DTN services be defined?

For FEC, we created an extension block with several aspects that really can be used by other services. 

Data Object Format: The format of the payload is not specified in 5050. For FEC, the combined payload over multiple bundles needs to be specified. The solution we chose was to make an explicit next protocol field that is part of the Erasure Coding Extension Block. But how does this interact with the "Application-layer", where the payload format is implicitly specified in the Destination EID. Should "Next Protocol" be pulled out into is own extension block?

Data Object UUID: FEC works over a group of bundles that encode the same data object. FEC needs a field that indicates the data object that is associated with an encoding bundle. But, grouping bundles could be a service in its own right. Should "Session ID" be pulled out into its own extension block?

Handling Specification: Because the DTN transfer is basically open loop, the sender has to make use of an oracle to predict the channel characteristics across the DTN. These channel characteristic assumptions can be specified in a "Handling Specification" for the encoding bundles. For FEC, how an individual bundle is forwarded between routers is not as important as how the whole group of FEC bundles is treated. For example, the order of encoding bundles being sent between contacts between quickly moving BPAs, should not be First Come First Serve, i.e. only the first Bundles of a group will be forwarded. Other application bundle streams also want specialized handling, such as Situational Awareness wants to send the most recent status update (Last In First Out). Should the "Handling Spec" be pulled out into its own extension block?

End-to-end Feedback Messages: FEC is more efficient with more feedback from neighbors and from the destination(s).
The 5050 notifications are about specific bundles and not about groups of bundles. Should notification for groups of bundles, be encoded in extension blocks or the payload? Also, how should feedback about a group of bundles be aggregated? 

Concluding Remark:
DTN is an opportunity to address the Quality of Service issues that have plagued TCP/IP networks, because of its explicit/fixed layers in the IP protocol suite. QoS issues crosscut the traditional layers, so the DTN protocol suite could have a different layering decomposition or it could embrace the notion of crosscutting and create a set of extensions that can be composed into multiple services, i.e. mixed and matched. I would like to see other examples of DTN network services and how they interact, such as encryption, compression, aggregation, situation awareness, pub-sub service (e.g DDS), multicast, geo-loc/role based routing, content dissemination, etc.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 6 Sep 2012 16:39:10 +0000

John, thanks for an interesting message.  I need to get back into your I-D and re-read it in more detail to be able to discuss the specifics of some of these points, but a general observation occurs to me.  Most -- perhaps all -- of the service adaptations you speak of resemble features of an end-to-end bundle application service layer called "Delay-Tolerant Payload Conditioning" that we've been developing within NASA, to address some requirements identified by the European Space Agency and others that were identified in the course of a tactical communications project that JPL worked on for DARPA.

Unfortunately we haven't got an Internet Draft on DTPC whipped into publishable shape quite yet.  If we had, I think you'd recognize in it some things that closely resemble your "Data Object Format", "Data Object UUID", end-to-end feedback messages, and even some handling specifications such as "latest available data".  In fact, we've even discussed including an erasure coding option in DTPC.

I think the key point here is that, at least for the purposes of all the requirements we've identified, these features matter only at the ends of the path; they're not relevant at the forwarding points within the network, and in some cases it's not even feasible to support them at those interim forwarding points.  DTPC is conceived as a strictly end-to-end service based on a protocol that is layered above BP, which enables it to take full advantage of whatever routing, security, and CoS capabilities are provided by BP and its convergence-layer protocols without diving into the combinatoric complexity that I think would result from trying to infuse all those features into BP itself.  DTPC can be fully specified without introducing a lot of new dependencies, and the relatively simple core of BP is preserved without modification.

Are there ways in which this general approach wouldn't work for the FEC service you've proposed?

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Tuesday, September 04, 2012 9:16 AM
To: [email-masked]
Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Concluding Remark:

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

---

From: Jayram Déshpandé <[email-masked]>
Date: Thu, 6 Sep 2012 13:05:15 -0700 (PDT)

Hello,

Here's a Master's thesis work[1] that explores the End to End QoS aspects of Delay and Disruption tolerant networking scenarios where bundles are transmitted across multiple (deep space or otherwise ) hops. 

The efforts were focused towards optimizing immediate next hop link resource (typically bandwidth ) by minimizing the amount of FEC applied to a given bundle based upon how critical the bundle is. In simplest scenario high priority bundles are heavily encoded while low priority bundles are not encoded at all. 

The work goes a step further to find optimal FEC to be applied by taking into consideration the end to end link characteristics. As in D (Delay )TN environments this information may be stale and/or completely out of date, it tries to find appropriate correction factor.

We defined an experimental QoS Extension Bundle header to transport some of these parameters on the way to destination.

Regards,
-Jay.

[1] http://etd.ohiolink.edu/view.cgi?acc_num=ohiou1163644692

________________________________
 From: "Burleigh, Scott C (313B)" <[email-masked]>
To: John Zinky <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, September 6, 2012 9:39 AM
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Tuesday, September 04, 2012 9:16 AM
To: [email-masked]
Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Concluding Remark:

---

From: "Fall, Kevin" <[email-masked]>
Date: Fri, 7 Sep 2012 16:50:27 +0000

Just to remind/note--

The IETF Reliable Multicast Transport (RMT) WG and RG have, over the last decade or so, gone down two primary paths for RMT.  One is essentially a NACK-based transport style (see RFC 5740), which obviously requires some form of back channel.  The other major path is FEC-based multicast transport, including a framework that can accommodate various FEC codes.  Of particular note, please see the update to FLUTE which is just about to be a new RFC:

http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/

Although it is possible to use a FEC style purely at the endpoints of a communication, for DTN style environments I can imagine it is useful also at the networking layer.  This is because you may have a transit network that is more ad-hoc or mule-based in nature and there is a potential benefit in using (e.g., fountain code style) FEC for them
(see, eg, http://conferences.sigcomm.org/sigcomm/2005/paper-JaiDem.pdf).

- K

From: Jayram Déshpandé <[email-masked]<mailto:[email-masked]>>
Reply-To: Jayram Déshpandé <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 6, 2012 1:05 PM PDT
To: "Burleigh, Scott C (313B)" <[email-masked]<mailto:[email-masked]>>, John Zinky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Hello,

Regards,
-Jay.

________________________________
From: "Burleigh, Scott C (313B)" <[email-masked]<mailto:[email-masked]>>
To: John Zinky <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 6, 2012 9:39 AM
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Scott

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Zinky
Sent: Tuesday, September 04, 2012 9:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Concluding Remark:

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

---

From: John Zinky <[email-masked]>
Date: Fri, 7 Sep 2012 16:28:32 -0400

Jay, 
Thanks for the reference to your paper.

Some notes to tease out distinctions.
1) If I understand your paper, FEC is used hop-by-hop at the CLA/link layer to protect the integrity of a single bundle.
The Eraser-Coding extension is designed for the end-to-end transfer of a large data object, so it handles the reliable transfer of a GROUP of bundles that represent one data object.

2) I am glad that your QoS model includes the concepts of Urgency (Immediacy) and Importance (Intrinsic Value).
DTN has good support (relative to IP) for Urgency, with its fine grain notion of lifetime.
But the use of priority class is lacking, because there is no specification for trading off High Urgency Low Importance bundles against Low Urgency High Importance bundles. 

3) An extension of your work would be how to handle groups of bundles. 
The current DTN 5050 specification does not have a way of marking bundles that are part of the same group, stream, or flow.
The Handling Specification would define how to handle bundles within the same group and between groups.
As one can see from your paper FEC is one knob for the Handling Spec, it is not the only knob. 
For example, maybe the FEC Handling Specification should be pulled out into a separate extension block.

---

From: <[email-masked]>
Date: Sun, 9 Sep 2012 14:30:23 +0100

I am very puzzled by this. And my puzzlement comes back to thinking about layering and the bundle protocol.

The bundle protocol isn't a network protocol. It only has endpoints IDs, after all - not network IDs. It has little truck with network addressing or routing.

And yet, the bundle protocol is not really a transport protocol. It doesn't provide reliable delivery, custody transfer doesn't work. The EIDs can be overloaded to distinguish different applications, and provide stream separation at the endpoints.

In the above-convergence-layer world where you have a reliable transport protocol (TCP) under the bundle protocol, the bundle protocol becomes a data format, or arguably, a slim session layer. This is the analogy of old with email.

In the CCSDS world, where you have a link layer and that's pretty much it (because running CFDP over bundling or vice versa would be redundant), the bundle protocol, which isn't networking or transport, becomes really just the equivalent of a datagram over that link layer. Which, I think, is why CCSDS bundles are relatively small, and why this 'end-to-end bundle application service' -- or transport protocol - is now being built for the bundle protocol. This new application service is the TCP to the bundle protocol's IP, and this layered structure will be very different to what is used outside CCSDS.

We can debate the layering model and whether it applies endlessly. But a more interesting question is whether we are seeing the development of two different layering models, articulating two very different views of what the bundle protocol is and what it is for. And if there are transports both above and below the bundle protocol, what value does the bundle protocol add?

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

who suspects that bundle FEC fails because you can't FEC or even checksum the headers....

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Burleigh, Scott C (313B) [[email-masked]]
Sent: 06 September 2012 17:39
To: John Zinky; [email-masked]
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Tuesday, September 04, 2012 9:16 AM
To: [email-masked]
Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Concluding Remark:

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 10 Sep 2012 02:41:55 +0000

In the unlikely event that anyone is confused by this posting:

Bundle protocol is an overlay network protocol.  In an Internet environment it runs over the Internet, treating Internet connections as links.  In an environment where there is no Internet it treats the available R/F (or whatever) links as links.  As we are all well aware, BP does indeed do routing, spanning Internet and non-Internet environments.

It's not unreasonable to observe that "this new application service is the TCP to the bundle protocol's IP".  This layered structure may or may not be very different from what is used outside CCSDS, depending on how people want to deploy the protocols.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, September 09, 2012 6:30 AM
To: [email-masked]
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Lloyd Wood

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Tuesday, September 04, 2012 9:16 AM
To: [email-masked]
Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

Concluding Remark: