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

["Fall, Kevin" <[e-mail]>]

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

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)" <[e-mail]<mailto:[e-mail]>>
To: John Zinky <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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.

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of John Zinky
Sent: Tuesday, September 04, 2012 9:16 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

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.


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