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

[John Zinky <[e-mail]>]

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.